OAuth 2.0 em Profundidade: Fluxos, Tokens e Segurança

Delegação OAuth 2.0: autorização sem compartilhar a senha do usuário

Princípio central

O cliente recebe autoridade limitada para acessar uma API ; autenticação do usuário e autorização da API continuam sendo decisões distintas.

Edição aprofundada - material de estudo e consulta profissional

radio_button_unchecked Apresentação do capítulo

Os capítulos anteriores separaram identidade, autenticação, autorização e credenciais estáticas. Agora o curso aprofunda o framework OAuth 2.0, criado para permitir que um cliente obtenha autoridade limitada para acessar um recurso protegido. A ideia central é substituir o compartilhamento direto de credenciais por artefatos temporários, com audiência, escopo, duração e contexto controlados.

OAuth 2.0 não é um protocolo único e fechado. É uma família de papéis, endpoints , grants, tipos de cliente, formatos de token e extensões. A segurança de uma implantação depende da composição correta desses elementos. Um Authorization Code flow pode ser robusto quando usa PKCE , redirect URI estrita e proteção de estado, mas pode ser vulnerável quando aceita redirecionamentos amplos, mistura emissores ou expõe códigos e tokens em logs .

A especificação original permanece importante, porém a prática moderna é guiada também por documentos posteriores. O Best Current Practice de segurança consolida experiências operacionais, desaconselha modos inseguros e reforça PKCE , redirect URI exata, proteção contra mix-up, restrição de refresh tokens e defesa contra replay . Extensões como PAR , JAR , RAR, mTLS , DPoP , metadata de recursos e token exchange atendem cenários de maior risco e integrações corporativas.

Este capítulo percorre o ciclo completo: registro do cliente, solicitação de autorização, emissão e uso de tokens , renovação, revogação, introspecção, delegação entre serviços e enforcement no API Gateway . O objetivo é permitir que o leitor projete e diagnostique fluxos reais sem confundir autenticação do usuário, autenticação do cliente, consentimento, autorização do recurso e validação do token .

Estado das especificações

OAuth 2.1 continua sendo um Internet-Draft em 2026. Ele consolida práticas modernas, mas não substitui automaticamente as RFCs publicadas. Para decisões normativas, use as RFCs vigentes e o OAuth 2.0 Security Best Current Practice, verificando a versão atual do draft apenas como orientação adicional.

Objetivos de aprendizagem

• Explicar o problema de delegação resolvido por OAuth 2.0 e seus limites.
• Distinguir resource owner , client , authorization server e resource server .
• Diferenciar authorization endpoint , token endpoint , introspection , revocation e metadata.
• Classificar clientes públicos e confidenciais e escolher autenticação compatível com sua capacidade de proteger chaves.
• Descrever Authorization Code com PKCE e os controles state , nonce , issuer e redirect URI .
• Aplicar Client Credentials , Device Authorization Grant e refresh tokens nos cenários adequados.
• Distinguir grants, códigos, access tokens , refresh tokens e ID tokens .
• Projetar scopes , audiences, resource indicators, consentimento e autorização detalhada.
• Compreender tokens opacos, JWTs , introspecção, revogação e perfis de access token .
• Aplicar PAR , JAR , JARM , RAR, mTLS , DPoP e token exchange conforme o risco.
• Integrar OAuth com API Gateways , Axway API Gateway e Azure API Management.
• Diagnosticar invalid_request, invalid_client, invalid_grant, invalid_token e insufficient_scope.

Estrutura do capítulo

• 16.1 O problema que OAuth 2.0 resolve
• 16.2 Papéis e fronteiras de confiança
• 16.3 Endpoints , metadata e canais
• 16.4 Registro, tipos de cliente e redirect URIs
• 16.5 Grants, fluxos e tipos de token
• 16.6 Authorization Code em profundidade
• 16.7 PKCE e proteção contra interceptação
• 16.8 State , nonce , issuer e proteção contra mix-up
• 16.9 Autenticação de clientes confidenciais
• 16.10 Aplicações web, SPAs, nativas e BFF
• 16.11 Client Credentials
• 16.12 Device Authorization Grant
• 16.13 Refresh tokens , rotação e reutilização
• 16.14 Access tokens , scopes , audience e resource indicators
• 16.15 Tokens opacos, introspecção e revogação
• 16.16 JWT access tokens e validação
• 16.17 Consentimento, least privilege e Rich Authorization Requests
• 16.18 PAR , JAR e JARM
• 16.19 Sender-constrained tokens com mTLS e DPoP
• 16.20 Token Exchange e on-behalf-of
• 16.21 Metadata do authorization server e do recurso protegido
• 16.22 OAuth em API Gateways , Axway e Azure
• 16.23 Ameaças e hardening
• 16.24 Troubleshooting orientado por evidências
• 16.25 Estudos de caso e laboratórios
• Resumo, checklist, exercícios, glossário e referências

radio_button_unchecked 16.1 O problema que OAuth 2.0 resolve

Antes de frameworks de delegação, era comum uma aplicação pedir a senha do usuário para acessar outro sistema. Essa prática entregava ao cliente poder excessivo, impedia limitar operações, dificultava revogação seletiva e expunha credenciais reutilizáveis. Se o cliente fosse comprometido, o atacante poderia agir como o usuário em qualquer interface que aceitasse a mesma senha.

OAuth substitui esse compartilhamento por uma concessão de autoridade. O cliente solicita autorização para uma finalidade; o authorization server autentica o usuário quando necessário, aplica políticas e emite um access token destinado ao resource server . O cliente recebe apenas a capacidade representada pelo token , não a credencial primária do usuário.

O framework não define sozinho como o usuário se autentica, como a API modela permissões de objeto ou como o token deve obrigatoriamente ser formatado. Também não transforma um access token em prova de login para o cliente. OpenID Connect atende a necessidade de comunicar autenticação do usuário ao cliente, enquanto a API continua responsável por autorização fina e regras de negócio.

Modelo mental

OAuth responde: “como um cliente obtém e apresenta autoridade limitada para um recurso?”. Ele não responde sozinho: “quem é o usuário para a interface?”, “o usuário é dono deste objeto?” ou “esta transação é permitida pelo domínio?”.

radio_button_unchecked 16.2 Papéis e fronteiras de confiança

O resource owner é a entidade capaz de conceder acesso ao recurso. Em muitos fluxos é uma pessoa, mas também pode ser uma organização ou política administrativa. O client é a aplicação que solicita acesso. Ele não é proprietário automático dos dados e não deve receber mais autoridade do que a necessária para sua função.

O authorization server autentica o resource owner quando aplicável, avalia a solicitação, registra consentimento ou política e emite tokens . O resource server é a API que aceita access tokens e decide se a operação é permitida. Em uma plataforma corporativa, o API Gateway pode atuar como parte do resource server ao validar o token e aplicar controles transversais, enquanto o backend conserva decisões de domínio.

Papéis lógicos não equivalem obrigatoriamente a processos separados. Um mesmo produto pode hospedar autorização e recursos, e um gateway pode intermediar múltiplas APIs . Mesmo assim, issuer, audience, chaves, endpoints e responsabilidades devem ser distintos para impedir que um token emitido para um serviço seja aceito indevidamente por outro.

radio_button_unchecked 16.3 Endpoints , metadata e canais

O authorization endpoint recebe solicitações por meio do user agent e conduz interação com o resource owner . O token endpoint é acessado diretamente pelo cliente para trocar grants por tokens . Essa separação cria dois canais: front-channel, exposto a navegador, histórico, extensões e redirecionamentos; e back-channel, protegido por TLS e usado para requisições diretas entre cliente e authorization server .

Endpoints opcionais ampliam operação e interoperabilidade. Introspection permite que o resource server consulte o estado de um token . Revocation permite invalidar refresh tokens e, conforme a implementação, access tokens . PAR recebe parâmetros de autorização antecipadamente por back-channel. Metadata descreve issuer, endpoints , métodos de autenticação, algoritmos e capacidades suportadas.

URLs de endpoints são dados de segurança. O cliente não deve construí-las por concatenação nem aceitar metadata de origem não confiável. O issuer retornado precisa corresponder ao emissor configurado. TLS , validação de hostname e resolução DNS confiável continuam essenciais porque OAuth protege autoridade, não substitui a segurança do canal.

radio_button_unchecked 16.4 Registro, tipos de cliente e redirect URIs

O registro associa client_id, redirect URIs , tipo de aplicação, contatos, chaves, métodos de autenticação e grants permitidos. O client_id é um identificador público, não um segredo. A segurança depende do vínculo correto entre o identificador e as propriedades registradas, especialmente redirect URIs e material criptográfico.

Clientes confidenciais conseguem manter credenciais sob controle, como aplicações web com backend ou serviços. Clientes públicos executam em ambientes onde o usuário ou atacante pode extrair o software e seus valores, como SPAs e aplicativos nativos. Inserir client_secret em JavaScript, pacote móvel ou aplicativo distribuído não transforma o cliente em confidencial; o segredo passa a ser copiável.

Redirect URI deve ser comparada por correspondência exata, salvo regras muito específicas para loopback de aplicações nativas. Wildcards, prefix matching e open redirectors permitem desviar códigos. Cada ambiente deve possuir URIs próprias, e a aplicação precisa validar a rota de retorno antes de iniciar qualquer sessão local.

Segredo em cliente público

Um valor embutido em SPA , aplicativo móvel ou binário distribuído deve ser considerado público. A proteção adequada vem de PKCE , redirect URI estrita, sistema operacional, BFF quando aplicável e restrição dos tokens - não da tentativa de ocultar um client_secret.

radio_button_unchecked 16.5 Grants, fluxos e tipos de token

Grant é a representação de uma autorização usada pelo cliente para obter access token . Authorization code , refresh token , client credentials e device code são exemplos. “Fluxo” descreve a sequência completa de interações. Confundir grant com token leva a logs e políticas imprecisas: o authorization code é curto, de uso único e destinado ao token endpoint ; o access token é apresentado à API .

O access token representa autoridade para um resource server . O refresh token permite solicitar novos access tokens e deve ficar restrito ao authorization server . O ID token pertence ao OpenID Connect e comunica ao cliente fatos sobre a autenticação; não deve ser usado como access token . Cada artefato possui destinatário, vida útil e proteção diferentes.

Os antigos Implicit Grant e Resource Owner Password Credentials não devem ser escolhidos para novos projetos. O primeiro expõe tokens no front-channel e perdeu sua justificativa com PKCE ; o segundo entrega credenciais do usuário ao cliente e impede muitos controles modernos. Migrações devem priorizar Authorization Code com PKCE ou fluxos máquina a máquina apropriados.

radio_button_unchecked 16.6 Authorization Code em profundidade

O cliente cria uma solicitação de autorização contendo response_type=code, client_id, redirect_uri, scope , state e parâmetros de PKCE . O navegador é redirecionado ao authorization server , onde o usuário pode ser autenticado e a política avaliada. Em caso de sucesso, o authorization server retorna um authorization code para a redirect URI registrada.

O cliente recebe o code e o troca no token endpoint . Essa requisição direta inclui grant_type=authorization_code, code, redirect_uri e code_verifier. Clientes confidenciais também se autenticam. O servidor verifica uso único, prazo, cliente, redirect URI e PKCE antes de emitir tokens .

O code não deve carregar autoridade reutilizável nem ser enviado a APIs . Ele existe para reduzir exposição de tokens no front-channel e permitir validações no back-channel. Logs , ferramentas de analytics, páginas de erro e referers não devem registrar o valor. Após a troca, a aplicação deve remover parâmetros sensíveis da URL e estabelecer seu próprio estado de sessão de forma segura.

Solicitação de autorização - valores ilustrativos

GET /authorize?response_type=code
  &client_id=portal-pagamentos
  &redirect_uri=https%3A%2F%2Fapp.example%2Fcallback
  &scope=pagamentos.read%20pagamentos.write
  &state=valor-aleatorio
  &code_challenge=base64url-sha256-verifier
  &code_challenge_method=S256

Troca do código por tokens

POST /token
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&code=AUTHORIZATION_CODE
&redirect_uri=https%3A%2F%2Fapp.example%2Fcallback
&client_id=portal-pagamentos
&code_verifier=SEGREDO_ALEATORIO_DA_INSTANCIA

radio_button_unchecked 16.7 PKCE e proteção contra interceptação

PKCE começa com um code_verifier aleatório, de alta entropia e exclusivo por tentativa. O cliente calcula code_challenge = BASE64URL (SHA256(code_verifier)) e envia o challenge no authorization endpoint . Na troca do code, apresenta o verifier original. O authorization server recalcula o challenge e exige correspondência.

Se um atacante interceptar o authorization code , não poderá trocá-lo sem o verifier. O método S256 deve ser usado; plain existe por compatibilidade restrita e não oferece a mesma proteção contra observação do challenge. PKCE não substitui state , redirect URI exata, TLS ou autenticação do cliente confidencial. Ele resolve uma ameaça específica: interceptação e injeção de authorization code .

PKCE deve ser exigido também para clientes confidenciais quando utilizam Authorization Code . Além de padronizar o fluxo, protege contra ataques nos quais um código obtido em outro contexto é injetado na sessão do cliente. O verifier não deve ser reutilizado e precisa ficar associado à mesma transação que contém state e redirect URI .

radio_button_unchecked 16.8 State , nonce , issuer e proteção contra mix-up

State vincula a resposta de autorização à sessão que iniciou a solicitação e ajuda a prevenir CSRF . Deve ser imprevisível, de uso único e associado localmente ao issuer, redirect URI , PKCE e intenção do usuário. Tratar state apenas como URL de retorno assinada pode deixar a sessão sem proteção adequada contra respostas não solicitadas.

Nonce pertence ao OpenID Connect e vincula o ID token à solicitação de autenticação. Ele não substitui state na proteção do fluxo OAuth . Em clientes que usam OIDC , ambos podem ser necessários: state protege o redirecionamento e nonce é validado dentro do ID token .

Ataques de authorization server mix-up exploram clientes que conversam com múltiplos emissores e não vinculam a resposta ao issuer correto. O cliente deve usar metadata confiável, validar o parâmetro iss quando suportado e enviar o code somente ao token endpoint do emissor associado à transação. Nunca selecione o token endpoint com base em dados não validados da resposta.

Estado transacional mínimo

Armazene, por tentativa: issuer esperado, client_id, redirect URI , state , code_verifier, nonce quando houver OIDC , scopes solicitados e horário. Consuma o registro uma única vez e expire rapidamente.

radio_button_unchecked 16.9 Autenticação de clientes confidenciais

O token endpoint precisa distinguir o cliente que apresenta o grant . client_secret_basic é simples, mas depende de segredo simétrico e transporte seguro. client_secret_post coloca o segredo no corpo e aumenta risco de logs ; deve ser evitado quando o método Basic é suportado. Segredos precisam de armazenamento em vault, rotação, owner e escopo por ambiente.

private_key_jwt usa uma asserção JWT assinada pela chave privada do cliente. O authorization server valida issuer/subject, audience, expiração, identificador único e assinatura. A chave privada não é enviada, e a rotação pode ser administrada por JWKS . O mecanismo exige prevenção de replay de jti e validação estrita da audience do token endpoint .

mTLS client authentication vincula a autenticação ao certificado apresentado na conexão TLS . Pode usar PKI tradicional ou certificado registrado. Em ambientes com proxies , deve ficar claro onde TLS termina e como a identidade do certificado é preservada. Autenticação forte do cliente não elimina a necessidade de PKCE no Authorization Code .

radio_button_unchecked 16.10 Aplicações web, SPAs, nativas e BFF

Aplicações web tradicionais mantêm código e credenciais no servidor. O navegador recebe apenas cookie de sessão protegido, enquanto o backend executa Authorization Code , armazena tokens e chama APIs . Essa separação reduz exposição de tokens ao JavaScript, mas exige proteção contra CSRF , fixation, XSS e roubo de sessão.

SPAs são clientes públicos. Authorization Code com PKCE é o fluxo moderno, porém access tokens armazenados no navegador continuam expostos a XSS e extensões. Um Backend for Frontend pode receber o code, manter tokens no servidor e expor ao browser somente cookie HttpOnly, Secure e SameSite. O BFF adiciona estado e infraestrutura, mas reduz a superfície de tokens .

Aplicações nativas utilizam navegador externo e redirect URIs baseadas em app links, universal links, custom schemes ou loopback. Embedded webviews prejudicam segurança e experiência de SSO . O sistema deve impedir que outro aplicativo capture a redirect URI e sempre combinar o mecanismo de retorno com PKCE .

radio_button_unchecked 16.11 Client Credentials

Client Credentials é usado quando o cliente age em seu próprio nome, sem resource owner humano na transação. O cliente se autentica no token endpoint e recebe access token associado à identidade da aplicação. É apropriado para serviços, jobs e automações que possuem permissões próprias.

O grant não deve ser usado para simular usuários nem transportar user_id arbitrário. A autorização deve se basear no principal da aplicação, seu tenant, owner e permissões de aplicação. Se um serviço precisa preservar contexto do usuário ao chamar outro, on-behalf-of ou token exchange é mais adequado.

Como o token pode abrir acesso amplo, credenciais estáticas devem ser substituídas por private_key_jwt, mTLS , managed identity ou workload federation quando possível. Scopes de aplicação precisam ser separados de scopes delegados para impedir que um token app-only seja confundido com autoridade do usuário.

Client Credentials - exemplo conceitual

POST /token
Authorization: Basic base64(client_id:client_secret)
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
&scope=liquidacoes.process

Pergunta de revisão

Se a operação precisa saber “qual usuário autorizou?”, Client Credentials isoladamente não fornece essa resposta. O principal é a aplicação.

radio_button_unchecked 16.12 Device Authorization Grant

O Device Authorization Grant atende dispositivos com entrada limitada ou sem navegador conveniente. O cliente solicita device_code e user_code, apresenta ao usuário uma verification_uri e inicia polling no token endpoint . O usuário conclui autenticação e autorização em outro dispositivo capaz de navegar.

O cliente deve respeitar interval, expires_in e erros como authorization_pending e slow_down. Polling agressivo cria carga e pode provocar bloqueio. O user_code precisa ser curto o suficiente para digitação, mas protegido por rate limiting , expiração e vínculo ao device_code de alta entropia.

O fluxo não deve ser usado como atalho para aplicações que já possuem navegador adequado. A interface deve mostrar claramente qual dispositivo e operação estão sendo autorizados, reduzindo ataques de phishing em que um código enviado por terceiro é inserido pela vítima.

radio_button_unchecked 16.13 Refresh tokens , rotação e reutilização

Refresh token é uma credencial de alto valor porque permite obter novos access tokens sem repetir toda a interação. Deve ser enviado apenas ao token endpoint , protegido em armazenamento adequado e limitado ao cliente e à autorização original. Access tokens curtos reduzem exposição; refresh tokens mantêm continuidade controlada.

Para clientes públicos, o BCP recomenda refresh tokens sender-constrained ou com rotação. Na rotação, cada uso produz um novo refresh token e invalida o anterior. Se um token antigo reaparece, o servidor detecta possível roubo e revoga a família ou a autorização correspondente. A implementação precisa lidar com concorrência e respostas perdidas sem criar falsos positivos.

Expiração absoluta, expiração por inatividade, revogação por logout, mudança de senha, retirada de consentimento e risco devem ser definidos. “ Refresh token nunca expira” transfere todo o controle para uma revogação perfeita, algo difícil em sistemas distribuídos. O cliente deve tratar invalid_grant como necessidade de nova autorização, não como motivo para repetir indefinidamente.

radio_button_unchecked 16.14 Access tokens , scopes , audience e resource indicators

Access token deve ser aceito somente pelo resource server para o qual foi emitido. Audience ampla transforma um token em passe reutilizável entre APIs . Resource Indicators permitem ao cliente declarar o recurso pretendido durante autorização ou token request , ajudando o authorization server a emitir tokens específicos.

Scope representa autoridade solicitada e concedida, mas sua semântica deve ser documentada. Scopes como read e write são simples, porém podem ficar ambíguos em plataformas grandes. Nomes de domínio, operação e recurso ajudam: pagamentos.read, pagamentos.create e conciliacao.execute. Scope não substitui autorização de objeto, tenant ou estado do domínio.

O resource server valida audience, escopo e contexto da requisição. Uma API não deve aceitar um token porque contém “admin” sem verificar issuer, tipo e origem da claim . Claims de autorização precisam ter governança: quem as emite, quando mudam, como são revogadas e qual serviço possui autoridade para interpretá-las.

Resource Indicator - exemplo conceitual

GET /authorize?response_type=code
  &client_id=app
  &resource=https%3A%2F%2Fapi.pagamentos.example
  &scope=pagamentos.read

radio_button_unchecked 16.15 Tokens opacos, introspecção e revogação

Token opaco não revela estrutura ao cliente ou resource server . A API consulta o authorization server por introspecção ou usa estado local distribuído. Essa abordagem facilita revogação imediata e minimiza exposição de claims , mas cria dependência de disponibilidade, latência, autenticação da API e política de cache .

Introspection retorna active e atributos autorizados para o solicitante. active=false deve ser resposta normal para token inválido, expirado, revogado ou desconhecido, sem revelar detalhes. O endpoint precisa autenticar resource servers e limitar quais dados cada um pode consultar. Cache reduz carga, mas aumenta a janela entre revogação e enforcement.

Revocation permite ao cliente solicitar invalidação. A resposta bem-sucedida não deve revelar se o token existia. Revogar refresh token normalmente encerra a capacidade de renovação; access tokens já emitidos podem continuar até expirar se forem auto-contidos. Arquiteturas de alto risco combinam TTL curto, introspecção, eventos de revogação ou denylist.

Introspecção - exemplo simplificado

POST /introspect
Authorization: Basic <credencial-do-resource-server>
Content-Type: application/x-www-form-urlencoded
token=TOKEN_OPACO
HTTP/1.1 200 OK
{
  "active": true,
  "client_id": "portal",
  "scope": "pagamentos.read",
  "exp": 1770000000
}

radio_button_unchecked 16.16 JWT access tokens e validação

JWT permite ao resource server validar localmente assinatura e claims , reduzindo chamadas ao authorization server . O perfil de JWT access token padroniza claims e tipos úteis, mas a API ainda precisa conhecer issuer, audience, algoritmos e chaves confiáveis. Decodificar Base64URL não é validar.

A validação deve fixar algoritmos permitidos, localizar a chave pelo kid em JWKS confiável, verificar assinatura, issuer, audience, expiração, not-before quando presente e tipo esperado. O resource server deve rejeitar tokens emitidos para outro uso, mesmo que a mesma chave assine ID tokens . typ e regras de profile ajudam a impedir confusão entre tipos de JWT .

Rotação de chaves exige cache e atualização controlada. Quando kid desconhecido aparece, o gateway pode atualizar JWKS , mas não deve permitir que o token indique uma URL arbitrária de chave. Falha temporária de metadata não deveria invalidar imediatamente todas as chaves ainda confiáveis; ao mesmo tempo, caches excessivos atrasam remoção de chave comprometida.

Conteúdo não criptografado

Um JWT assinado normalmente protege integridade, não confidencialidade. Evite PII e dados desnecessários. O token passa por clientes, proxies , gateways , ferramentas e logs ; trate-o como credencial sensível.

radio_button_unchecked 16.17 Consentimento, least privilege e Rich Authorization Requests

Consentimento é uma interface de decisão, não um substituto para política. Em ambientes corporativos, algumas permissões são aprovadas por administradores ou contratos, enquanto outras dependem do usuário. A tela deve identificar cliente, dados, ações, duração e consequências, evitando scopes técnicos incompreensíveis.

Least privilege começa na definição dos scopes e continua no resource server . Solicitar todos os scopes “para evitar novo consentimento” aumenta impacto de vazamento. Incremental authorization permite pedir autoridade adicional apenas quando a funcionalidade é usada. O authorization server pode conceder subconjunto e o cliente precisa verificar a resposta.

Rich Authorization Requests representa detalhes estruturados, como valor, moeda, conta e tipo de transação. Isso permite autorizações mais precisas do que strings de scope , especialmente em pagamentos e dados financeiros. O objeto de autorização deve ser validado, assinado ou protegido conforme o perfil adotado e não deve ser aceito como dado livre enviado pelo cliente à API .

Rich Authorization Request - exemplo didático

{
  "authorization_details": [{
    "type": "payment_initiation",
    "instructedAmount": {"currency": "BRL", "amount": "150.00"},
    "creditorAccount": {"iban": "EXEMPLO"}
  }]
}

radio_button_unchecked 16.18 PAR , JAR e JARM

Pushed Authorization Requests permite ao cliente enviar parâmetros ao authorization server por back-channel e receber request_uri de curta duração. O navegador transporta apenas a referência. Isso reduz manipulação, exposição e tamanho da URL , além de permitir autenticação do cliente antes da interação do usuário.

JWT -Secured Authorization Request representa a solicitação em um JWT assinado e, opcionalmente, criptografado. O authorization server valida integridade e origem dos parâmetros. PAR e JAR podem ser combinados: o cliente envia um request object assinado ao endpoint PAR e usa o request_uri no authorization endpoint .

JARM protege a resposta de autorização em um JWT assinado ou criptografado. Em vez de confiar somente em parâmetros soltos no redirect, o cliente valida issuer, audience, assinatura e tempo. Esses mecanismos aumentam complexidade e gestão de chaves, por isso são mais comuns em perfis financeiros, ecossistemas regulados e integrações de alto risco.

radio_button_unchecked 16.19 Sender-constrained tokens com mTLS e DPoP

Bearer token funciona como dinheiro ao portador: quem obtém o valor pode apresentá-lo. Sender-constrained token vincula o access token a uma chave do cliente. O resource server exige, além do token , uma prova de posse correspondente. O objetivo é reduzir replay após vazamento em logs , proxies , memória ou canais laterais.

Com mTLS , o authorization server associa o token ao certificado do cliente e o resource server verifica o certificado apresentado na conexão. O claim cnf pode carregar thumbprint. A arquitetura precisa garantir que a API observe a identidade TLS correta mesmo quando há load balancers ou gateways terminando conexões.

DPoP usa um JWT de prova assinado pelo cliente em cada requisição, contendo método HTTP , URI , horário, identificador único e vínculo ao access token . A API valida assinatura, htm, htu, iat, jti, chave e ath. DPoP é proteção de camada de aplicação e não substitui TLS . Nonce do servidor e cache de jti podem fortalecer replay defense conforme o risco.

radio_button_unchecked 16.20 Token Exchange e on-behalf-of

Em arquiteturas de serviços, o primeiro backend pode precisar chamar outro mantendo parte da autoridade original. Encaminhar o mesmo access token para todos os serviços amplia audiences e expõe a credencial. Token Exchange permite trocar um subject token por outro token apropriado ao próximo recurso.

O novo token pode representar o usuário, o serviço ator ou ambos. Claims de actor ajudam a registrar a cadeia. A política deve limitar quais clientes podem trocar tokens , quais audiences podem ser solicitadas e quais scopes podem ser preservados. A troca não deve elevar privilégio além do token de entrada e da autoridade do ator.

On-behalf-of é uma implementação de delegação em que um serviço atua em nome do usuário. Logs precisam preservar usuário, cliente inicial, serviço intermediário e autorização efetiva. Se uma chamada passa por vários domínios de confiança, cada emissão deve ser tratada como nova decisão, não como simples cópia de headers .

radio_button_unchecked 16.21 Metadata do authorization server e do recurso protegido

Authorization Server Metadata publica issuer, endpoints , métodos de autenticação, grants, scopes e algoritmos. Clientes devem obter o documento de origem configurada e validar coerência entre issuer e URL . Metadata simplifica rotação e interoperabilidade, mas não deve transformar descoberta em confiança automática.

Protected Resource Metadata permite que uma API publique identificador do recurso, authorization servers relacionados, scopes e métodos de apresentação suportados. Isso ajuda clientes e authorization servers a entender como obter tokens para um recurso e melhora desafios WWW-Authenticate.

Metadata deve ser versionada e monitorada como parte da plataforma. Mudanças em endpoint , algoritmo ou issuer podem interromper todos os clientes. Cache precisa respeitar disponibilidade sem congelar configuração indefinidamente. Ambientes internos, externos e de homologação devem ter documentos separados para impedir mistura de confiança.

Authorization Server Metadata - trecho ilustrativo

{
  "issuer": "https://id.example",
  "authorization_endpoint": "https://id.example/authorize",
  "token_endpoint": "https://id.example/token",
  "jwks_uri": "https://id.example/jwks.json",
  "code_challenge_methods_supported": ["S256"]
}

radio_button_unchecked 16.22 OAuth em API Gateways , Axway e Azure

API Gateways podem validar access tokens , consultar introspecção, exigir scopes , aplicar quota por client_id e propagar contexto confiável. Antes de inserir headers internos, o gateway deve remover versões fornecidas pelo cliente. O backend deve aceitar esses headers apenas de uma conexão autenticada proveniente do gateway .

No Azure API Management, validate- jwt e validate-azure-ad- token podem validar tokens antes do backend . Policies podem exigir issuer, audience e claims , enquanto authentication-managed-identity permite ao gateway obter token para um backend compatível. A configuração do developer portal para OAuth facilita testes, mas não substitui enforcement na policy.

No Axway API Gateway , filtros e serviços OAuth podem implementar authorization server , validação de token , autenticação de clientes e políticas de resource server . A topologia precisa registrar qual componente emite, qual valida, onde chaves são armazenadas e como revogação e rotação são tratadas. Como versões e licenças mudam, valide a documentação do produto instalado.

Azure API Management - policy conceitual

<validate-jwt header-name="Authorization"
              require-expiration-time="true"
              require-signed-tokens="true">
  <openid-config url="https://id.example/.well-known/openid-configuration" />
  <audiences><audience>api://pagamentos</audience></audiences>
  <required-claims>
    <claim name="scp" match="any"><value>pagamentos.read</value></claim>
  </required-claims>
</validate-jwt>

Divisão de responsabilidade

O gateway valida issuer, audience, assinatura, tempo, scopes e requisitos transversais. O backend continua verificando tenant, ownership, estado da transação, limites de negócio e autorização de objeto.

radio_button_unchecked 16.23 Ameaças e hardening

Intercepção de authorization code é reduzida por PKCE . CSRF e login CSRF exigem state e vínculo transacional. Mix-up exige associação ao issuer. Redirect URI manipulation exige comparação exata. Token leakage exige TLS , higiene de logs , headers corretos, armazenamento seguro e redução de TTL . Token replay pode exigir sender constraint.

Open redirectors no cliente ou authorization server ampliam desvio de códigos. Referer, histórico e analytics podem capturar parâmetros do front-channel. Tokens em query string vazam com facilidade e não devem ser usados como forma normal de apresentação. Access tokens devem seguir Authorization header e respostas precisam de Cache -Control adequado.

Authorization servers devem proteger endpoints contra brute force, credential stuffing, request flooding e abuso de user_code. Clientes precisam validar todas as respostas e não exibir detalhes internos. Resource servers devem limitar algoritmos, validar audience e não confiar em claims sem namespace e governança. Toda implantação necessita inventário de clientes, owners, grants, redirect URIs e chaves.

Práticas desaconselhadas

Não use Implicit Grant ou Resource Owner Password Credentials em novos projetos. Não armazene client_secret em cliente público. Não aceite redirect URI por prefixo. Não trate ID token como access token . Não aceite JWT somente porque “decodificou sem erro”.

radio_button_unchecked 16.24 Troubleshooting orientado por evidências

O diagnóstico começa identificando o endpoint e a etapa. Erro no authorization endpoint envolve parâmetros, sessão, política e redirect URI . Erro no token endpoint envolve client authentication, code, verifier, grant e relógio. Erro na API envolve apresentação, validação e autorização. Misturar essas etapas transforma invalid_grant em “ JWT inválido” ou 403 em “falha do login”.

Colete correlation ID, issuer esperado, client_id, grant_type, redirect URI normalizada, scopes , audience, kid, horário e status sem registrar tokens ou códigos. Compare o relógio dos componentes. Confirme metadata e JWKS acessadas pelo runtime, não apenas pelo notebook do operador. Em ambientes com proxy , registre hostname, TLS e destino real.

Para intermitência, investigue rotação de chaves, múltiplos nós com cache divergente, reutilização concorrente de authorization code ou refresh token , balanceamento sem afinidade de estado e DNS . Reproduza com um único fluxo controlado e tokens sintéticos. Um token pode funcionar em um gateway e falhar em outro por configuração ou cache diferentes.

Erro externo estável; causa detalhada permanece no log seguro

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="pagamentos",
  error="invalid_token"
Content-Type: application/problem+json
{
  "type": "https://errors.example/oauth/invalid-token",
  "status": 401,
  "correlationId": "corr-8f12"
}

radio_button_unchecked 16.25 Estudos de caso

Caso 1 - SPA com segredo embutido

Uma SPA envia client_secret no token request . O valor é visível no bundle e pode ser copiado por qualquer usuário. A correção é registrar o cliente como público, usar Authorization Code com PKCE e redirect URI exata. Se o risco de tokens no browser for alto, adotar BFF e cookie protegido.

A investigação também verifica CORS , armazenamento de token , XSS , logout e renovação. Apenas remover o segredo não resolve exposição de refresh token ou access token persistido em localStorage.

Caso 2 - Token aceito por API errada

Duas APIs confiam no mesmo issuer e chave, mas uma delas não valida audience. Um token emitido para relatórios é aceito em pagamentos. A correção é exigir audience específica e separar scopes . Em sistemas críticos, resource indicators e tokens por recurso reduzem a possibilidade de reutilização cruzada.

Os testes de contrato de segurança devem enviar tokens válidos para audiences vizinhas e esperar rejeição. Essa verificação negativa precisa existir em gateway e backend quando ambos validam tokens .

Caso 3 - Refresh token reutilizado após timeout

O cliente usa um refresh token , recebe timeout e repete a chamada. O primeiro processamento havia emitido novo token ; a repetição parece roubo e a família é revogada. A solução combina idempotência operacional, janela de tolerância controlada ou lógica de cliente que serializa renovação e trata respostas perdidas.

Uma tolerância ampla enfraquece detecção de reutilização. A decisão deve considerar risco, rede e capacidade de correlacionar tentativas. Logs precisam registrar família, token predecessor, cliente e resultado sem armazenar o valor bruto.

Caso 4 - Gateway valida, backend rejeita

O gateway aceita o token para sua própria audience e o encaminha ao backend , que espera token destinado a ele. A arquitetura precisa escolher: backend confia no contexto propagado pelo gateway em canal autenticado, ou gateway obtém um novo token para o backend usando managed identity, client credentials ou token exchange .

Encaminhar o token original só é correto quando o backend é o resource server daquela audience. A decisão deve estar documentada no contrato de segurança e testada com múltiplas APIs .

radio_button_unchecked Laboratórios de observação

Laboratório 1 - Authorization Code com PKCE

• Use um authorization server de laboratório ou simulador autorizado.
• Gere verifier aleatório e challenge S256.
• Execute o fluxo correto e registre apenas valores sintéticos.
• Repita com verifier errado, state divergente, code reutilizado e redirect URI alterada.
• Classifique cada erro pela etapa e pelo endpoint .

Laboratório 2 - validação de audience e scope

• Configure duas APIs com audiences diferentes.
• Emita token para a API A e tente usá-lo na API B.
• Teste scope ausente, expirado e issuer alternativo.
• Compare resposta externa e reason code interno.

Laboratório 3 - introspecção e cache

• Use tokens opacos de laboratório e endpoint de introspecção.
• Meça latência sem cache e com cache curto.
• Revogue o token e observe a janela até a rejeição.
• Documente a decisão entre disponibilidade e rapidez de revogação.

Laboratório 4 - rotação de refresh token

• Obtenha um refresh token sintético.
• Renove e confirme emissão de sucessor.
• Reutilize o predecessor e observe a política da família.
• Simule duas renovações concorrentes e analise o resultado.

Laboratório 5 - policy no gateway

• Configure issuer, audience e scope em gateway de laboratório.
• Teste kid desconhecido e atualização de JWKS .
• Remova headers de identidade enviados pelo cliente.
• Propague somente claims validadas e compare com autorização do backend .

radio_button_unchecked Resumo do capítulo

OAuth 2.0 é um framework de delegação. Resource owner , client , authorization server e resource server possuem responsabilidades diferentes. Authorization endpoint e token endpoint usam canais distintos, e cada artefato - code, access token , refresh token e ID token - possui destinatário e ciclo de vida próprio.

Authorization Code com PKCE é a base moderna para aplicações com usuário. PKCE protege contra interceptação, state vincula a transação, nonce pertence ao OIDC e issuer protege clientes multiemissor. Clientes públicos não possuem segredo confiável; clientes confidenciais podem usar secret, private_key_jwt ou mTLS .

Client Credentials representa a aplicação, Device Authorization atende entrada limitada e refresh tokens exigem rotação ou sender constraint. Access tokens precisam de audience e escopo mínimos. Tokens opacos favorecem controle central; JWTs favorecem validação local, mas exigem verificação completa e gestão de chaves.

PAR , JAR , JARM e RAR fortalecem solicitações e respostas; mTLS e DPoP reduzem replay ; Token Exchange controla delegação entre serviços. API Gateways aplicam validação transversal, enquanto backends preservam autorização de domínio. Segurança depende de inventário, least privilege, redirect URI exata, higiene de logs , observabilidade e testes negativos.

Próximo passo do curso

O Capítulo 17 aprofundará OpenID Connect: ID Token , UserInfo, nonce , acr, amr, autenticação federada, sessões, logout e integração segura de aplicações com provedores de identidade.

radio_button_unchecked Checklist de OAuth 2.0

• Cada cliente possui owner, tipo, redirect URIs e grants explicitamente registrados.
• Authorization Code usa PKCE S256, inclusive para clientes confidenciais.
• State é aleatório, de uso único e vinculado a issuer, redirect URI e verifier.
• Clientes públicos não dependem de client_secret.
• Redirect URIs usam correspondência exata e não contêm open redirectors.
• Implicit e password grants não são usados em novos projetos.
• Access tokens possuem audience e scopes mínimos.
• ID token não é aceito como access token .
• Refresh tokens têm rotação, sender constraint ou política equivalente.
• JWTs validam assinatura, algoritmo, issuer, audience, tipo e tempo.
• Introspection é autenticada e possui cache compatível com revogação.
• Tokens não aparecem em URL , logs , analytics ou mensagens de erro.
• mTLS ou DPoP é considerado para risco elevado de replay .
• Gateway e backend têm divisão explícita de autorização.
• Rotação de JWKS , certificados e client credentials é testada.
• Erros OAuth são correlacionáveis sem revelar detalhes sensíveis.
• Clientes, grants, consentimentos e tokens possuem processo de desligamento.

radio_button_unchecked Exercícios

• Explique por que OAuth 2.0 não é, sozinho, um protocolo de autenticação do usuário.
• Diferencie authorization code , access token , refresh token e ID token .
• Descreva as verificações do Authorization Code com PKCE .
• Explique por que state e PKCE não são substitutos um do outro.
• Classifique uma SPA e justifique por que seu client_secret não é confiável.
• Compare client_secret_basic, private_key_jwt e mTLS .
• Modele Client Credentials para um job sem usuário.
• Explique reuse detection em refresh token rotation.
• Compare token opaco com JWT em revogação e disponibilidade.
• Liste validações obrigatórias de um JWT access token .
• Explique audience e resource indicators em plataforma com múltiplas APIs .
• Compare PAR , JAR e JARM .
• Diferencie mTLS -bound token e DPoP -bound token .
• Proponha Token Exchange para três serviços preservando o usuário.
• Monte roteiro de troubleshooting para invalid_grant intermitente.

radio_button_unchecked Glossário

radio_button_unchecked Anexo A - Matriz de escolha de fluxo

radio_button_unchecked Referências técnicas

• IETF . RFC 6749 - The OAuth 2.0 Authorization Framework . 2012.
• IETF . RFC 6750 - OAuth 2.0 Bearer Token Usage. 2012.
• IETF . RFC 7009 - OAuth 2.0 Token Revocation. 2013.
• IETF . RFC 7519 - JSON Web Token ( JWT ). 2015.
• IETF . RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients. 2015.
• IETF . RFC 7662 - OAuth 2.0 Token Introspection . 2015.
• IETF . RFC 8252 - OAuth 2.0 for Native Apps. 2017.
• IETF . RFC 8414 - OAuth 2.0 Authorization Server Metadata. 2018.
• IETF . RFC 8628 - OAuth 2.0 Device Authorization Grant . 2019.
• IETF . RFC 8693 - OAuth 2.0 Token Exchange . 2020.
• IETF . RFC 8705 - OAuth 2.0 Mutual- TLS Client Authentication and Certificate-Bound Access Tokens . 2020.
• IETF . RFC 8725 - JSON Web Token Best Current Practices. 2020.
• IETF . RFC 9101 - JWT -Secured Authorization Request . 2021.
• IETF . RFC 9126 - Pushed Authorization Requests . 2021.
• IETF . RFC 9068 - JWT Profile for OAuth 2.0 Access Tokens . 2021.
• IETF . RFC 9207 - OAuth 2.0 Authorization Server Issuer Identification. 2022.
• IETF . RFC 9396 - OAuth 2.0 Rich Authorization Requests . 2023.
• IETF . RFC 9449 - OAuth 2.0 Demonstrating Proof of Possession. 2023.
• IETF . RFC 9700 - Best Current Practice for OAuth 2.0 Security. 2025.
• IETF . RFC 9701 - JWT Response for OAuth Token Introspection . 2025.
• IETF . RFC 9728 - OAuth 2.0 Protected Resource Metadata. 2025.
• IETF OAuth Working Group. The OAuth 2.1 Authorization Framework - Internet-Draft, versão consultada em 2026.
• Microsoft Learn. Azure API Management authentication, validate- jwt , validate-azure-ad- token e managed identity policies.
• Axway Documentation. OAuth 2.0 services, client authentication e token validation no API Gateway .
• OpenID Foundation. Financial-grade API Security Profile e OpenID Connect specifications, quando aplicáveis ao ecossistema.

Nota de atualização

OAuth evolui por RFCs , Best Current Practices, perfis e drafts. Antes de implantar um fluxo ou policy, valide a especificação atual, a documentação da versão do produto e o comportamento em ambiente autorizado. Trate Internet-Drafts como trabalho em progresso, não como substitutos automáticos de RFCs .