O que é OAuth e por que ele é importante

Com a rápida expansão dos sistemas digitais interconectados, a troca de dados sem interrupções entre aplicativos tornou-se essencial para proporcionar experiências de usuário aprimoradas e otimizar a eficiência operacional. No entanto, esse nível de conveniência nunca deve vir à custa da segurança.

É aqui que o OAuth, ou Open Authorization, se mostra indispensável.

O OAuth evoluiu ao longo do tempo, com o OAuth 1.0 sendo agora considerado obsoleto e não mais recomendado para implementações modernas, enquanto o OAuth 2.0 se tornou o padrão atual da indústria devido à sua simplicidade, flexibilidade e maior adoção.

Na maioria dos contextos modernos, incluindo este guia, quando nos referimos ao OAuth, estamos nos referindo ao OAuth 2.0, a menos que explicitamente declarado o contrário.

Como um padrão aberto amplamente adotado, o OAuth permite que os usuários concedam acesso controlado e limitado aos seus dados de um serviço para outro sem nunca expor suas credenciais de login reais. Isso garante tanto a usabilidade quanto uma segurança robusta.

Neste guia, primeiro entenderemos o que é o OAuth em geral e, em seguida, exploraremos como ele evoluiu do OAuth 1.0 para o OAuth 2.0, juntamente com como funciona, por que é importante e muito mais.

OAuth 1.0 vs. OAuth 2.0

O OAuth evoluiu significativamente ao longo do tempo. O OAuth 1.0 depende de assinaturas criptográficas para segurança, enquanto o OAuth 2.0 simplifica a implementação usando tokens de acesso e contando com transporte seguro (HTTPS/TLS). O OAuth 2.0 não é retrocompatível com o OAuth 1.0 e representa um redesenho completo do protocolo.

O que é OAuth?

OAuth é um framework de autorização de padrão aberto que permite que aplicativos de terceiros acessem os recursos de um usuário hospedados em outro provedor de serviços (como Google, Facebook ou uma plataforma bancária) sem exigir a senha do usuário, tornando-o uma parte central dos sistemas modernos de autenticação . 

Além disso, ele oferece uma maneira segura e controlada de delegar acesso.

Como funciona o OAuth?

O OAuth opera através de uma sequência estruturada de interações entre várias partes, incluindo o usuário, o aplicativo cliente, o servidor de autorização e o servidor de recursos.

Este processo garante que credenciais sensíveis nunca sejam expostas, ao mesmo tempo em que permite acesso seguro e baseado em token a recursos protegidos.

Os passos abaixo descrevem o fluxo OAuth 2.0 mais comumente usado, conhecido como fluxo de Código de Autorização (tipicamente implementado com PKCE para segurança aprimorada em aplicações modernas).

Cliente Solicita Autorização 

O utilizador interage com uma aplicação cliente (por exemplo, uma aplicação de edição de fotos) que necessita de acesso a recursos protegidos (como fotos armazenadas no Google Fotos).

O cliente redireciona o utilizador para um Servidor de Autorização, especificando:

• O nível de acesso solicitado (scopes)
• Um URI de redirecionamento para onde o utilizador será enviado após a aprovação 

Autenticação e Consentimento do Utilizador 

O Servidor de Autorização (por exemplo, o sistema de login de um fornecedor) solicita ao utilizador que:

• Autentique a sua identidade (se ainda não tiver sessão iniciada)
• Reveja e aprove as permissões solicitadas através de um ecrã de consentimento

Este passo garante que o utilizador mantém o controlo total sobre quais dados são partilhados e com quem.

Código de Autorização Emitido 

Assim que o utilizador concede permissão, o Servidor de Autorização:

• Gera um código de autorização de curta duração e de uso único
• Redireciona o utilizador de volta para a aplicação cliente através do URI de redirecionamento fornecido, incluindo o código 

Cliente Troca Código por Tokens 

A aplicação cliente envia de forma segura o código de autorização para o endpoint de token do Servidor de Autorização, juntamente com:

• O seu ID de Cliente
• Um Segredo de Cliente (para clientes confidenciais) ou um verificador PKCE (para clientes públicos)

Esta comunicação de back-channel garante que dados sensíveis não são expostos através do navegador do utilizador.

Emissão de Token 

Após validar o pedido, o Servidor de Autorização emite:

• Um token de acesso (usado para aceder a recursos protegidos)
• Opcionalmente, um token de atualização (usado para obter novos tokens de acesso sem exigir que o utilizador inicie sessão novamente) 

Aceder a Recursos Protegidos 

O cliente utiliza o token de acesso para solicitar dados ao Servidor de Recursos (por exemplo, Google Fotos).

O Servidor de Recursos:

• Valida o token (incluindo a sua assinatura, validade e âmbitos)
• Garante que o pedido está autorizado
• Concede acesso apenas aos dados e ações permitidos 

Por que o OAuth é importante?

O OAuth é um pilar fundamental da segurança digital moderna e da experiência do utilizador por várias razões convincentes. Veja:

• Mais seguro do que partilhar credenciais: O OAuth elimina a necessidade de partilhar nomes de utilizador e palavras-passe com aplicações de terceiros. Em vez disso, utiliza tokens de acesso seguros, reduzindo o risco de roubo de credenciais e protegendo os utilizadores mesmo que uma aplicação conectada seja comprometida.
• Acesso com privilégio mínimo e controlo do utilizador: Os utilizadores concedem permissões explícitas através de ecrãs de consentimento, permitindo que as aplicações acedam apenas a dados específicos ou realizem ações limitadas. Esta abordagem baseada em âmbitos garante uma exposição mínima de dados e um maior controlo sobre as informações pessoais.
• Permite experiências digitais modernas: O OAuth impulsiona funcionalidades comuns como "Iniciar sessão com o Google", inícios de sessão sociais, API integrações, e ligações seguras entre serviços, tornando as interações digitais mais fluidas e eficientes.
• Experiência do utilizador melhorada: Os utilizadores podem ligar serviços sem criar novas contas ou introduzir credenciais repetidamente, mantendo ainda uma segurança robusta e controlo sobre os dados partilhados.
• Simplifica o desenvolvimento: Os desenvolvedores podem integrar autenticação e autorização usando provedores confiáveis, evitando a complexidade de construir sistemas seguros do zero.
• Ecossistema seguro para provedores de API: As plataformas podem expor suas APIs com segurança a aplicativos de terceiros, permitindo inovação e integrações, ao mesmo tempo em que mantêm controle rigoroso sobre o acesso e o uso de dados. 

Quais são os papéis e componentes do OAuth?

Para entender como o OAuth funciona, é importante detalhar os principais papéis e componentes envolvidos. Cada um desempenha um papel específico na habilitação de acesso seguro e delegado entre aplicativos.

• Proprietário do Recurso (Usuário Final): O indivíduo que possui os dados protegidos, como e-mails, fotos ou informações de perfil. Ele pode conceder ou negar acesso aos seus recursos.
• Cliente (Aplicativo Solicitando Acesso): O aplicativo (web, móvel ou desktop) que deseja acessar os dados do usuário. Ele deve ser registrado e identificado usando um ID de Cliente e, para clientes confidenciais, um Segredo de Cliente.
• Servidor de Autorização (Sistema de Identidade e Consentimento): Responsável por autenticar o usuário (se aplicável) e obter seu consentimento. Ele emite tokens de acesso (e, opcionalmente, tokens de atualização) após a autorização bem-sucedida.
• Servidor de Recurso (API com Dados Protegidos): Hospeda os dados do usuário e responde a solicitações do cliente. Ele valida os tokens de acesso antes de permitir o acesso a recursos protegidos. Em algumas implementações, o servidor de recurso e o servidor de autorização podem fazer parte do mesmo sistema.
• URI de Redirecionamento (URL de Retorno): O endpoint para onde o usuário é redirecionado após conceder permissão. Ele deve ser pré-registrado e estritamente validado para garantir que a resposta de autorização seja enviada apenas para locais confiáveis.
• Registro de Cliente: O processo de registro de um aplicativo no Servidor de Autorização. Ele estabelece confiança e fornece credenciais como ID de Cliente e Segredo de Cliente (se aplicável).

Tokens OAuth explicados

Os tokens OAuth estão no centro da estrutura, atuando como credenciais seguras que permitem que os aplicativos acessem dados do usuário sem nunca expor detalhes de login, como nomes de usuário ou senhas.

• Tokens de Acesso: Usados por aplicativos para acessar recursos protegidos em nome de um usuário ou do próprio aplicativo (dependendo do fluxo). Geralmente, têm vida curta e são enviados com requisições de API (normalmente como tokens Bearer) para recuperar ou modificar dados de forma segura.
• Tokens de Atualização: Usados para obter novos tokens de acesso após a expiração, sem exigir que o usuário se autentique novamente. Geralmente, têm vida longa, são armazenados de forma segura e podem ser rotacionados ou revogados para maior segurança. Nem todos os fluxos ou provedores OAuth emitem tokens de atualização.
• Escopos, Audiências e Permissões: Escopos definem o nível de acesso solicitado pelo cliente (por exemplo, permissões de leitura ou escrita). A audiência indica o destinatário pretendido do token (como uma API específica ou servidor de recursos), embora este seja um detalhe de implementação e não um requisito central do OAuth.
• Formatos de Token (Opaco vs. JWT): Tokens opacos exigem validação pelo servidor de autorização, enquanto JWTs (JSON Web Tokens) são autocontidos e podem ser verificados localmente usando assinaturas, desde que sejam realizadas verificações de validação adequadas (como expiração e emissor).

Tipos de concessão OAuth (Fluxos) e quando usar cada um?

O OAuth define diferentes fluxos (tipos de concessão) que determinam como um aplicativo obtém tokens de acesso. A escolha depende do tipo de aplicativo e de suas capacidades de segurança.

• Fluxo de Código de Autorização: Um dos fluxos mais seguros e amplamente utilizados para aplicações web baseadas em servidor. Ele usa um código de autorização que é trocado no backend, ajudando a manter as credenciais do cliente seguras e reduzindo os riscos de exposição.
• Código de Autorização + PKCE: Uma versão aprimorada do Fluxo de Código de Autorização, originalmente projetada para aplicativos móveis e single-page applications (SPAs), e agora amplamente recomendada para todos os tipos de clientes.

Ele adiciona uma camada extra de segurança ao mitigar ataques de interceptação de código de autorização, garantindo que apenas o cliente original possa trocar o código por tokens.

• Fluxo de Credenciais do Cliente:  Usado para comunicação máquina a máquina onde nenhum usuário está envolvido. É ideal para serviços de backend e microsserviços que precisam acessar recursos de propriedade do aplicativo de forma segura.
• Fluxo de Autorização de Dispositivo:  Projetado para dispositivos com capacidades de entrada limitadas (por exemplo, TVs, consolas, ferramentas CLI). Os utilizadores autenticam-se num dispositivo separado usando um código, tornando o processo mais fácil de usar em ambientes restritos.
• Credenciais de Senha do Proprietário do Recurso (Descontinuado): Exige que os utilizadores partilhem o seu nome de utilizador e palavra-passe diretamente com a aplicação cliente. Esta abordagem contradiz o princípio central do OAuth de evitar a partilha de credenciais e não deve ser utilizada em aplicações modernas.
• Fluxo Implícito (Descontinuado): Anteriormente utilizado por aplicações baseadas em navegador, mas propenso a fugas de tokens e outros riscos de segurança. Foi largamente substituído pelo Fluxo de Código de Autorização com PKCE para maior segurança.

OAuth vs. Outros Protocolos

O OAuth é frequentemente mencionado juntamente com outros protocolos de identidade e acesso, o que por vezes pode causar confusão. Embora possam sobrepor-se em casos de uso, cada um serve um propósito distinto na autenticação, autorização ou gestão de identidade do utilizador.

OAuth vs OpenID Connect (OIDC)

O OAuth é principalmente um framework de autorização, o que significa que controla o que uma aplicação pode aceder em nome de um utilizador. O OpenID Connect (OIDC), construído sobre o OAuth 2.0, adiciona uma camada de autenticação que fornece informações de identidade padronizadas sobre o utilizador autenticado.

Em termos simples, o OAuth responde “O que esta aplicação pode aceder?” enquanto o OIDC responde “Quem é o utilizador?”. O OIDC introduz um token de ID (tipicamente um JWT) que contém reivindicações de identidade sobre o utilizador e destina-se à aplicação cliente, tornando-o adequado para cenários de login e identidade.

OAuth vs. SAML

O OAuth e o SAML lidam ambos com acesso seguro, mas diferem no design e nos casos de uso. O OAuth é moderno, leve e amplamente utilizado para autorização de API e aplicações móveis/web, dependendo de JSON e REST.

O SAML, por outro lado, é um protocolo mais antigo baseado em XML e é comummente utilizado em sistemas de single sign-on (SSO) empresariais. Embora o SAML seja robusto para federação de identidade empresarial, o OAuth é mais flexível e mais adequado para ecossistemas de aplicações modernas.

OAuth vs. SSO

Quando Combinar OAuth + OIDC

Para experiências modernas como “Entrar com Google,” “Iniciar sessão com Facebook,” ou similares, o OAuth e o OIDC são tipicamente usados em conjunto. O OAuth gere o acesso seguro aos dados do utilizador, enquanto o OIDC fornece informações de identidade verificadas.

Esta combinação permite que as aplicações autentiquem os utilizadores e acedam aos seus dados de forma segura, tornando-a a abordagem padrão para experiências de login social fluidas e seguras.

Melhores Práticas de Implementação do OAuth

A implementação adequada do OAuth é crucial para a segurança e uma experiência de utilizador fluida. A adesão às melhores práticas ajuda a evitar vulnerabilidades comuns.

• Escolha o fluxo certo: Deve selecionar o fluxo OAuth apropriado com base no tipo da sua aplicação. O Fluxo de Código de Autorização é ideal para aplicações web, enquanto o Código de Autorização + PKCE é recomendado para aplicações móveis e SPAs, e os fluxos descontinuados devem ser evitados.
• Utilize tokens de curta duração: Os tokens de acesso devem ter uma vida útil curta para minimizar o risco em caso de comprometimento. Os tokens de atualização devem ser usados para continuidade e rotacionados regularmente para aumentar a segurança.
• Valide os tokens corretamente: Os servidores de recursos devem validar os tokens verificando o emissor, a audiência, a assinatura e a expiração. Isso garante que apenas tokens autênticos e válidos sejam aceites.
• Proteja as credenciais do cliente: Os segredos do cliente devem ser armazenados de forma segura e nunca expostos no código do lado do cliente. Para clientes públicos, padrões seguros como o PKCE devem ser usados em vez de depender de segredos.
• Imponha HTTPS e redirecionamentos seguros: Toda a comunicação OAuth deve ocorrer sobre HTTPS para proteger os dados em trânsito. As URIs de redirecionamento devem ser estritamente validadas contra valores pré-registados para evitar o uso indevido.
• Ative o registo e monitorização: Os sistemas devem registar e monitorizar a atividade OAuth para detetar comportamentos incomuns. Devem também suportar a revogação de tokens e ter um plano de resposta a incidentes em vigor. 

Exemplos Práticos de OAuth em Ação

O OAuth impulsiona muitas interações digitais diárias, funcionando frequentemente de forma integrada em segundo plano para permitir acesso seguro sem partilhar palavras-passe.

Conceder acesso de aplicação a e-mail ou calendário

Por exemplo, uma aplicação de viagens pode adicionar eventos ao seu Google Calendar, redirecionando-o para o Google para login e consentimento. Uma vez aprovado, a aplicação recebe um token para realizar apenas as ações permitidas, sem nunca ver a sua palavra-passe.

Conectar-se a APIs com permissões delimitadas

Ferramentas que se integram com plataformas como GitHub ou Microsoft pedem permissões específicas (como ler dados ou publicar atualizações). Após a aprovação do utilizador, recebem um token de acesso para realizar apenas essas ações, e o acesso pode ser revogado a qualquer momento.

Começar com OAuth

A implementação do OAuth exige planejamento e configuração cuidadosos, mas os benefícios em segurança e experiência do usuário são substanciais.

1. Escolha um provedor de autorização: A maioria das aplicações utiliza Provedores de Identidade (IdPs) existentes, como Google, Microsoft, ou serviços gerenciados como Auth0 ou Okta. Construir o seu próprio é complexo e geralmente não é recomendado.
2. Registre sua aplicação: Você precisará criar um cliente com um ID de Cliente, Segredo de Cliente (se aplicável) e definir URIs de redirecionamento válidas. Isso estabelece confiança e permite uma comunicação segura.
3. Defina escopos e consentimento: Solicite apenas as permissões que sua aplicação realmente precisa. Uma experiência de consentimento clara e transparente ajuda os usuários a entender e confiar no acesso que estão concedendo.
4. Teste e prepare para produção: Comece em um ambiente de sandbox ou desenvolvimento para validar os fluxos. Planeje a produção com segurança, monitoramento e escalabilidade adequados. 

Conclusão

O OAuth é uma parte fundamental do ecossistema digital atual, permitindo o compartilhamento seguro e contínuo de dados entre aplicações sem expor as credenciais do usuário. 

Ao compreender seus conceitos centrais, como acesso delegado, papéis-chave e diferentes fluxos, os desenvolvedores podem construir sistemas mais seguros e amigáveis ao usuário. 

À medida que os serviços digitais continuam a crescer, o OAuth permanece essencial para proteger os dados do usuário e manter a confiança.