OpenID Connect (OIDC)

OpenID Connect é uma camada fina de identidade construída sobre o OAuth 2.0. O OAuth responde o que este aplicativo pode fazer; o OIDC responde quem é o usuário.

• Ele padroniza como os clientes autenticam usuários e recebem declarações de identidade verificadas.
• Ele introduz o token de ID como uma asserção de autenticação assinada criptograficamente.

Antes do OIDC, os desenvolvedores usavam indevidamente tokens de acesso do OAuth para autenticação, o que causava falhas de agente confuso e de personificação.

O artefato característico do OIDC é o token de ID, um JWT assinado que descreve o evento de autenticação.

• Ele transporta declarações sobre quem iniciou sessão e quando.
• Ele deve ser consumido pelo cliente, não pelo servidor de recursos.

Nunca envie um token de ID para uma API como credencial de acesso e nunca aceite um sem validar sua assinatura e suas declarações.

Validar um token de ID significa verificar declarações específicas, não apenas a assinatura.

• O emissor iss deve corresponder ao IdP esperado.
• O público aud deve conter seu client_id.
• O token exp / iat não pode estar expirado e deve ter sido emitido recentemente.
• O sub é um identificador estável e exclusivo do usuário.
• O nonce deve corresponder ao valor enviado pelo cliente.

O OIDC reutiliza o fluxo de código de autorização, mas adiciona o escopo openid e um nonce.

• O cliente solicita o escopo openid (além dos opcionais profile e email).
• O ponto de acesso de tokens retorna um token de ID junto com o token de acesso.
• O nonce vincula o token de ID à solicitação original, impedindo a repetição.

Os provedores OIDC publicam suas chaves de assinatura em um ponto de acesso JWKS, que pode ser descoberto por meio do documento de configuração conhecido.

• Busque as chaves em jwks_uri e corresponda ao cabeçalho kid do token.
• Verifique usando o algoritmo assimétrico listado (RS256, ES256).

Rejeite o algoritmo none e nunca confie em um valor de algoritmo fornecido exclusivamente pelo token.

Para os tokens de ID, o nonce desempenha o mesmo papel que state para o redirecionamento: um valor de uso único que vincula a resposta à solicitação.

• O cliente gera um nonce aleatório e o armazena na sessão.
• O IdP o repete dentro do token de ID.
• Ao recebê-lo, o cliente verifica se o nonce corresponde e se ainda não foi usado.

Isso bloqueia a repetição de tokens e a injeção de um token criado para uma sessão diferente.

Para obter dados adicionais do perfil além do token de ID, o OIDC define o ponto de acesso UserInfo.

• O cliente o chama com o token de acesso, não com o token de ID.
• Ele retorna declarações como nome, e-mail e imagem para o sujeito autenticado.

Compare sempre o sub retornado com o sub do token de ID para impedir a substituição de declarações.

O OIDC padroniza a descoberta para que os clientes possam configurar automaticamente pontos de acesso e recursos compatíveis.

• O documento /.well-known/openid-configuration lista pontos de acesso, escopos compatíveis e algoritmos.
• Fixe ou valide o emissor; não siga cegamente a descoberta a partir de um servidor controlado por um invasor.

A descoberta simplifica a integração, mas o emissor continua sendo uma âncora de confiança que deve ser verificada.

O encerramento de sessões entre aplicativos federados é tratado pelas especificações de encerramento do OIDC.

• O encerramento pelo canal frontal usa redirecionamentos e quadros incorporados do navegador para limpar cada parte confiável.
• O encerramento pelo canal de retorno envia tokens de encerramento entre servidores, sendo mais confiável, mas exigindo pontos de acesso.

Sem um encerramento coordenado, um usuário pode sair de um aplicativo e continuar conectado a outros, o que representa um risco real de gerenciamento de sessões.

Os erros de identidade geralmente surgem quando etapas de validação são ignoradas.

• Aceitar tokens sem verificar aud (o token destinava-se a outro cliente).
• Ignorar iss, permitindo a falsificação do IdP.
• Não validar a assinatura ou aceitar alg: none.
• Confundir tokens de ID com tokens de acesso.
• Não verificar o nonce, permitindo a repetição.

Se seu objetivo é a autenticação, use OIDC, não o OAuth puro.

• Os tokens de acesso do OAuth são opacos para o cliente e não comprovam nada sobre a identidade.
• Um token de acesso pode ser válido para outro usuário ou aplicativo, levando à personificação se for usado para autenticação.
• Os tokens de ID do OIDC são asserções de identidade explicitamente vinculadas ao público.

Essa distinção impede a falha clássica de autenticação do agente confuso.

Principais conclusões:

• O OIDC adiciona uma camada de identidade ao OAuth 2.0; o token de ID é um JWT assinado que comprova a autenticação.
• Sempre valide iss, aud, exp, assinatura (por meio de JWKS) e nonce.
• Os tokens de ID são destinados ao cliente; os tokens de acesso são destinados às APIs; nunca troque suas funções.
• Use nonce contra repetições e state contra CSRF.
• Use OIDC, não o OAuth puro, quando precisar autenticar usuários.