OAuth 2.0: Quando você acha que dar um ‘loginzinho’ é só clicar em ‘aceitar cookies’
Vamos falar de OAuth 2.0, aquele sistema que parece fácil, mas na verdade tem mais passos que abrir um chamado no Help Desk. Tudo que ele quer é um token para acessar a API.
Papéis
OAuth 2.0 distribui os papéis como se fosse uma novela:
- Resource Owner – Você, o dono do conteúdo.
- Resource Server – A API cheia de informações que só dá acesso com um token.
- Authorization Server – O serviço central que autentica e cria tokens.
- Client – O app que pede um token.
Tem dúvidas sobre JWT, Bearer e OAuth 2.0? Veja este artigo: Segurança - JWT x Cookies x OAuth 2.0 x Bearer
Como funciona a autenticação
Os passos do OAuth:
- (A) O usuário clica em "login" no Client.
- (B) O Client pede o token.
- (C) O Authorization Server pede a credencial do Client.
- (D) O usuário faz login e recebe o Access Token.
- (E) O Client mostra o token pro Resource Server.
- (F) O Resource Server libera as informações.
Existem outras formas, como Password ou Implicit, mas são "antigas".
1 – Authorization Server
O principal responsável pela autenticação:
- Identifica usuário, client e API.
- Administra os dados dos usuários.
- Cria Access Tokens.
- Faz autenticação como serviço.
2 – Clients
Client é o app que usa o token. Dois tipos:
- Confidential – Protege bem o client secret.
- Public – Exibe o secret no frontend.
Configurações
- Tipo de client (public ou confidential).
- URL de redirecionamento (tem que ser HTTPS).
- Informações extras.
Clients operando em segundo plano
Usam Client Credentials para acessar dados sem interação com o usuário.
Redirect URI
Redireciona só para os URIs registrados. Tem que ser HTTPS.
ClientId e Secret
ClientId é gerado para todos. Secret é para os confidential.
Autorização
Quatro jeitos oficiais:
- Authorization Code – O mais seguro com PKCE.
- Resource Owner Password Credentials – Antigo e desatualizado.
- Implicit – Vai direto para o client.
- Client Credentials – Sem interação com o usuário.
Importante: Use Authorization Code com PKCE para SPAs.
Tipo de Client | Fluxo recomendado |
---|---|
SPAs, MVC | Authorization Code |
Apps não confiáveis | Authorization Code |
Apps internas (confiáveis) | Authorization Code ou Implicit |
Serviços em segundo plano | Client Credentials |
Bearer Token
O token no header Authorization
é usado para acessar recursos:
- É uma string curta.
- Pode ser JWT.
- Carrega informações do usuário.
- Está explicado na RFC6750.
Exemplos
import requests
# Pedindo o token (Authorization Code + PKCE)
response = requests.post(
'https://auth.server.com/oauth/token',
data={
'grant_type': 'authorization_code',
'code': auth_code_obtido,
'redirect_uri': 'https://seuapp.com/callback',
'client_id': CLIENT_ID,
'code_verifier': code_verifier
}
)
token = response.json().get('access_token')
# Usando o token
api_response = requests.get(
'https://api.server.com/userinfo',
headers={'Authorization': f'Bearer {token}'}
)
print(api_response.json())
Resumo
OAuth 2.0 é potente, mas complicado. Dicas rápidas:
- Use Authorization Code + PKCE.
- Evite o Password flow.
- Configure bem client, redirect URI, informações do usuário e regras de token.
Pronto, agora dá pra usar OAuth direito.