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:

  1. Resource Owner – Você, o dono do conteúdo.
  2. Resource Server – A API cheia de informações que só dá acesso com um token.
  3. Authorization Server – O serviço central que autentica e cria tokens.
  4. Client – O app que pede um token.

OAuth Flow

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. client-request-grant
  • (C) O Authorization Server pede a credencial do Client.
  • (D) O usuário faz login e recebe o Access Token. access-grant
    callback
  • (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".

Roles

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:

  1. Confidential – Protege bem o client secret.
  2. 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 ClientFluxo recomendado
SPAs, MVCAuthorization Code
Apps não confiáveisAuthorization Code
Apps internas (confiáveis)Authorization Code ou Implicit
Serviços em segundo planoClient 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.