Entendendo na Prática: o que e OAuth 2.0

O que e OAuth 2.0

OAuth 2.0 e um protocolo de autorização delegada, não de autenticação.

OAuth 2.0 e um protocolo de autorização que permite que um aplicativo acesse recursos em nome de um usuário sem precisar da senha desse usuário. E o protocolo por tras do "Login com Google", "Login com GitHub" e de integrações como "Conectar com Spotify". A confusão mais comum e pensar que OAuth e um protocolo de autenticação. Não e. OAuth resolve autorização delegada: o usuário autoriza o aplicativo a acessar recursos específicos em outro serviço. A autenticação de identidade e resolvida pelo OpenID Connect, que e construído sobre o OAuth 2.0. Entender essa distinção e fundamental para usar o protocolo corretamente e não cometer erros de segurança que comprometam o sistema.

Authorization Code Flow com PKCE

O fluxo mais seguro para web apps e mobile: troca código por token no backend.

O Authorization Code Flow e o fluxo recomendado para aplicações onde há um backend seguro. O usuário e redirecionado para o servidor de autorização, faz login e concede permissão. O servidor redireciona de volta para o app com um código de autorização de curta duração. O backend troca esse código por um access token em uma chamada servidor a servidor, usando o client secret que nunca e exposto ao browser. PKCE, Proof Key for Code Exchange, e uma extensão obrigatória para apps públicos como SPAs e mobile: substitui o client secret por um par de chaves criptograficas geradas em runtime, evitando que o código de autorização seja interceptado por um app malicioso no dispositivo do usuário.

Client Credentials Flow

Fluxo machine-to-machine: nenhum usuário envolvido, o próprio app se autentica.

O Client Credentials Flow e usado em comunicações machine-to-machine onde não há um usuário envolvido. Um serviço backend precisa acessar a API de outro serviço em nome de si mesmo, não em nome de um usuário. O serviço envia seu client_id e client_secret para o servidor de autorização e recebe um access token. Esse token e usado para autenticar as chamadas entre os serviços. Exemplos típicos: um worker que processa filas acessa uma API interna, um sistema de monitoramento coleta métricas de outro sistema, ou um serviço de notificações acessa a API de email. Não há redirect, não há consentimento do usuário. O client_secret deve ser armazenado de forma segura no ambiente de produção, nunca em código ou repositório.

Implicit Flow e por que evitar

Implicit Flow foi descontinuado por ser inseguro em ambientes modernos.

O Implicit Flow foi criado para SPAs que não tinham backend. O access token era retornado diretamente na URL de redirect, sem o passo intermediário do código de autorização. O problema e que o token na URL fica exposto no histórico do browser, em logs de servidor e em headers Referer. Além disso, não suporta refresh tokens. Com a adoção ampla do PKCE, que resolve o mesmo problema de forma muito mais segura, o Implicit Flow foi marcado como obsoleto no OAuth 2.1. Para SPAs modernas, o Authorization Code Flow com PKCE e o padrão correto. Nunca use Implicit Flow em sistemas novos: o risco de exposição do token não justifica a simplicidade aparente do fluxo.

OAuth vs OpenID Connect

OAuth e sobre autorização; OpenID Connect adiciona uma camada de identidade sobre o OAuth.

OAuth 2.0 responde a pergunta: o aplicativo pode acessar este recurso? Ele emite access tokens que autorizam ações. OpenID Connect, ou OIDC, e construído sobre o OAuth 2.0 e responde a pergunta: quem e o usuário? Ele adiciona o ID Token, um JWT com informações do usuário como nome, email e foto de perfil. Enquanto o access token e opaco para o cliente (apenas o servidor de recursos precisa entende-lo), o ID Token e destinado ao cliente e contem claims verificáveis sobre o usuário autenticado. Quando você usa "Login com Google", o Google usa OpenID Connect: você esta autorizando o aplicativo a saber quem você e, e o aplicativo recebe o ID Token com suas informações de identidade do Google.

Login social com OAuth (Google, GitHub)

Login com provedores externos elimina a necessidade de armazenar senhas próprias.

Implementar login social com OAuth segue um fluxo padrão independente do provedor. O usuário clica em Login com Google. O app redireciona para a URL de autorização do Google com client_id, redirect_uri, scope como openid email profile, e um state aleatório para prevenir CSRF. O Google autentica o usuário e redireciona de volta com o código de autorização. O backend troca o código pelo access token e ID Token usando o client secret. O ID Token contem o nome e email do usuário. O backend verifica a assinatura do ID Token com a chave pública do Google, extrai as informações e cria ou atualiza o usuário no banco local. O usuário nunca precisa criar uma senha específica para o sistema, reduzindo o risco de comprometimento de credenciais.

Tokens de acesso e refresh

Access token e de curta duração; refresh token permite renovação sem novo login.

Em OAuth 2.0, o access token e o que o cliente usa para acessar recursos protegidos. Ele tem duração curta, tipicamente entre 1 hora e algumas horas, para limitar o dano se for comprometido. O refresh token e emitido junto com o access token e tem duração muito maior, dias ou semanas. Quando o access token expira, o cliente usa o refresh token para obter um novo access token sem solicitar que o usuário faca login novamente. O refresh token fica armazenado de forma segura e só e trocado com o servidor de autorização, nunca enviado para os servidores de recursos. Se o refresh token for comprometido, o sistema pode revocar o acesso de forma definitiva, algo impossível de fazer de forma imediata com access tokens JWT stateless.

Quando usar OAuth

OAuth faz sentido quando terceiros precisam acessar recursos em nome de usuários.

OAuth 2.0 e a escolha certa quando: você quer oferecer login social sem armazenar senhas; terceiros precisam integrar com sua plataforma em nome dos seus usuários como apps que acessam Google Calendar ou GitHub; você esta construindo uma plataforma de APIs públicas onde parceiros precisam de acesso autorizado; ou quando dois sistemas precisam se comunicar de forma segura sem compartilhar credenciais. Para autenticação simples de usuários próprios em um sistema fechado, um sistema de usuário e senha com JWT pode ser mais simples que OAuth. A complexidade do OAuth se justifica quando há delegação de acesso para terceiros ou quando a confiabilidade de um provedor de identidade externo e mais adequada que manter sua própria solução.

Vantagens e cuidados

Delegação segura e padrão aberto são as vantagens; complexidade e cuidados de segurança são os desafios.

Vantagens do OAuth 2.0: elimina a necessidade de compartilhar senhas entre sistemas; granularidade de permissões com scopes; padrão aberto amplamente suportado; e possibilidade de revogar acesso sem mudar senhas. Cuidados: validar sempre o parametro state para prevenir CSRF; usar PKCE obrigatoriamente em apps públicos; validar redirect_uri para evitar redirecionamento para dominios não autorizados; armazenar client secrets de forma segura em variáveis de ambiente; nunca usar Implicit Flow; validar a assinatura do ID Token antes de confiar nos claims; e definir scopes mínimos necessários, nunca solicitar permissões amplas desnecessariamente.

Resumo

OAuth 2.0 e o protocolo padrão para autorização delegada em APIs e integrações modernas.

OAuth 2.0 resolve a autorização delegada: como um app pode acessar recursos em nome de um usuário sem sua senha. O Authorization Code Flow com PKCE e o padrão recomendado para web e mobile. Client Credentials serve para comunicação machine-to-machine. Implicit Flow e obsoleto e deve ser evitado. OpenID Connect adiciona identidade sobre o OAuth com o ID Token. Login social usa OAuth para autenticar usuários sem armazenar senhas próprias. Access tokens são de curta duração; refresh tokens renovam sem novo login. Com os cuidados de segurança corretos, OAuth 2.0 e uma fundação solida para autenticação e autorização em sistemas modernos que precisam integrar com terceiros.