Recursos · 43
OAuth e OpenID Connect: verifique uma integração de ponta a ponta.
Separe o login, a delegação e as permissões de dados e, em seguida, teste redirecionamentos, tokens, sessões e revogação. O guia
Atualizado · 4 min
O que este guia ajuda a alcançar
- Separar identidade de autorização
- Rejeitar redirecionamentos e tokens não intencionais
- Testar negações com o mesmo cuidado que os sucessos
- Verificar a remoção de acesso após a saída ou incidente
Verificação rápida
- Qual provedor e emissor são esperados?
- O URI de redirecionamento está registrado corretamente?
- Um token de ID está sendo usado incorretamente como token de acesso?
- Cada recurso verifica a propriedade?
- Qual acesso sobrevive à revogação?
Método passo a passo
- 1
Desenhar o fluxo implantado
Identificar cliente público ou confidencial, navegador, servidor de autorização, API e provedor OIDC. Registrar por onde os códigos e tokens trafegam, quem os armazena e quais funções são concedidas. Um diagrama de vendas não estabelece a implantação real.
Entregável: fluxo, limites de confiança e proprietários de componentes.
- 2
Verificar a transação de login.
Usar o fluxo de código com PKCE apropriado para o cliente. Verificar S256, vinculação de transação, redirecionamentos registrados e proteção contra solicitações falsificadas. Testar URI inesperado, verificador incorreto, código reproduzido e emissor inesperado. A RFC 9700 separa os requisitos e recomendações por tipo de cliente.
Entregável: resultados de testes de permissão e negação.
- 3
Validar o token correto.
A API valida seu token de acesso de acordo com o formato e as regras do provedor: assinatura ou introspecção, emissor, público-alvo, expiração e permissões. O cliente OIDC valida separadamente o token de identidade. Uma assinatura válida não estabelece que o token pertence a esta API.
Entregável: contrato de validação e testes de público-alvo e expiração.
- 4
Verificar permissões de negócios
Testar um objeto pertencente a outra conta, uma função inferior, um campo privado e uma operação administrativa. Um escopo ou gateway autenticado não substitui as verificações do lado do servidor no recurso solicitado. Usar contas e dados de teste autorizados.
Entregável: matriz de função, objeto, operação e negação esperada.
- 5
Exercitar expiração e revogação
Separar sessão local, sessão do provedor, token de acesso e token de atualização. Testar saída, perda de dispositivo, alteração de função, rotação da chave de assinatura e indisponibilidade do provedor. Documentar o tempo de acesso residual em vez de presumir que o logout revoga tudo imediatamente.
Entregável: linha do tempo de remoção de acesso e exceções.
- 6
Observar sem expor segredos
Registrar referência de transação, decisão de validação, categoria de erro e versão de configuração. Excluir códigos, tokens e segredos. Preparar diagnóstico, desligamento da integração e reversão para uma configuração validada; reproduzir testes após alterações de provedor.
Entregável: procedimento operacional e verificações de regressão.
Exemplo prático fictício
Situação ilustrativa
Situação ilustrativa: dois clientes usam um provedor de identidade. Um token válido para o primeiro é apresentado à API do segundo cliente.
Decisão e evidências esperadas
A API rejeita o público-alvo errado, registra um rastreamento sem token e não retorna dados. A negação se torna um teste de regressão.
Distinguir os mecanismos
| Mecanismo | Finalidade | Verificação ou limitação |
|---|---|---|
| OAuth 2.0 | Delegar acesso a recursos | Permissões de objetos no servidor |
| OpenID Connect | Estabelecer identidade por meio de um token de ID validado | Validação de emissor, público-alvo e transação |
| Sessão do aplicativo | Manter o login do aplicativo | Expiração, invalidação e proteção de sessão |
Indicadores de gestão
| Indicador | O que mede | Primeira ação |
|---|---|---|
| Corrigir negações | Casos proibidos realmente bloqueados | Corrigir toda aceitação inesperada |
| Atraso na revogação | Tempo até que o acesso relevante desapareça | Verificar sessões e tokens separadamente |
| Falhas de validação | Rejeições por causa e versão | Separar ataques de erros de configuração |
Erros comuns
- Confundir autenticação com autorização
- Aceitar qualquer público-alvo após verificar a assinatura
- Registrar URIs de redirecionamento amplo
- Registrar tokens para facilitar Depuração
Perguntas frequentes
O PKCE substitui todos os controles?
Não. Ele protege a troca de código no fluxo pretendido; a validação de token, redirecionamentos, autorização de negócios e sessões ainda precisam ser verificados.
Um JWT é uma permissão?
JWT é um formato. As declarações só se tornam utilizáveis após a validação e aplicação das suas regras de API.
A validação deve ser construída do zero?
Prefira uma biblioteca mantida e documentação do provedor e, em seguida, teste sua configuração. Uma biblioteca correta ainda pode ser configurada incorretamente.
Referências oficiais
As referências apoiam o método. Adapte as verificações ao seu contexto; elas não são uma certificação. Os títulos das referências originais e os documentos de origem podem estar em outro idioma.
