Claims e Tokens de ID do OpenID Connect

O OpenID Connect (OIDC) adiciona uma camada de identidade sobre o OAuth 2.0. Enquanto o OAuth 2.0 gerencia a autorização (o que este aplicativo pode acessar?), o OIDC responde à questão da identidade (quem é o usuário?). O OIDC é implementado adicionando o escopo "openid" a uma solicitação do OAuth 2.0, o que faz o servidor de autorização retornar um token de ID junto com o token de acesso.

O token de ID do OIDC é um JSON Web Token (JWT) que contém declarações sobre o usuário autenticado. O JWT é assinado pelo servidor de autorização usando sua chave privada (normalmente RS256 ou ES256), e a parte confiável (o aplicativo cliente) verifica a assinatura usando as chaves públicas publicadas pelo servidor de autorização (ponto de acesso JWKS).

Declarações obrigatórias e usadas com frequência no token de ID: "sub" (sujeito, identificador exclusivo do usuário), "iss" (emissor, URL do servidor de autorização), "aud" (público-alvo, ID do cliente), "exp" (timestamp Unix de expiração), "iat" (timestamp Unix de emissão). Opcionais: "auth_time" (quando a autenticação ocorreu), "nonce" (prevenção de repetição), "at_hash" (hash do token de acesso), "acr" (classe do contexto de autenticação), "amr" (métodos de autenticação usados).

O ponto de acesso UserInfo do OIDC retorna declarações adicionais sobre o usuário autenticado quando é chamado com um token de acesso válido. Os clientes solicitam conjuntos específicos de declarações por meio de escopos: "profile" (nome, foto, localidade), "email" (email, email_verified), "address" (endereço formatado), "phone" (phone_number, phone_number_verified). A resposta do UserInfo é um objeto JSON ou JWT.

A validação do token de ID começa pela verificação da assinatura. O cliente busca o JWKS (conjunto de chaves JSON) do servidor de autorização no ponto de acesso conhecido, encontra a chave correspondente ao parâmetro "kid" (ID da chave) do cabeçalho do JWT e verifica a assinatura do JWT. Isso prova que o token foi emitido pelo servidor de autorização legítimo e não sofreu adulteração.

Após verificar a assinatura, o cliente deve validar o seguinte: "iss" deve corresponder exatamente à URL esperada do servidor de autorização (incluindo o esquema e o caminho). "aud" deve conter o próprio client_id do cliente. "exp" deve estar no futuro (tokens expirados devem ser rejeitados). "iat" deve ser razoavelmente recente. As quatro verificações são obrigatórias segundo a especificação do OIDC.

A declaração nonce impede ataques de repetição do token de ID. O cliente gera um nonce aleatório e o inclui na solicitação de autorização. O servidor de autorização incorpora o nonce ao token de ID. O cliente verifica se o nonce no token de ID corresponde ao que enviou. Isso impede que um atacante que capture um token de ID o repita para se autenticar em uma sessão diferente.

Quando o OIDC usa o fluxo implícito (response_type=id_token), o token de ID é retornado diretamente no fragmento da URL. O cliente deve validar at_hash (o hash do token de acesso) para associar o token de acesso ao token de ID. Sem a validação de at_hash, são possíveis ataques de substituição do token de acesso. Esse é outro motivo pelo qual o fluxo implícito foi descontinuado.

O OIDC define mapeamentos padrão entre escopos e declarações. O escopo "openid" é obrigatório e retorna a declaração "sub". "profile" retorna name, given_name, family_name, nickname, picture, website, locale, zoneinfo, updated_at. "email" retorna email e email_verified. Solicitar escopos desnecessários viola o princípio da divulgação mínima e pode expor dados sensíveis do usuário.

Ao implementar login do OIDC com vários provedores (por exemplo, "Entrar com Google" e "Entrar com GitHub"), são possíveis ataques de injeção de declarações. Se um atacante criar uma conta no Provedor B com o endereço de email de uma vítima que usa o Provedor A, poderá obter acesso se o aplicativo associar contas apenas pela declaração de email. Associe sempre as contas pela dupla (iss, sub), não somente pelo email.

O fluxo híbrido do OIDC (response_type=code id_token) retorna um código de autorização e um token de ID do ponto de acesso de autorização. O token de ID permite a verificação imediata da identidade, enquanto o código é trocado por tokens por meio do canal de retaguarda. Ele é usado quando o cliente precisa renderizar imediatamente as informações do usuário antes de concluir a troca de tokens pelo canal de retaguarda.

Qual combinação de declarações uma parte confiável deve validar em um token de ID do OIDC?

O OIDC adiciona um token de ID JWT assinado aos fluxos do OAuth 2.0. Valide a assinatura (JWKS), iss (correspondência exata), aud (client_id), exp (não expirado) e nonce (se enviado). O ponto de acesso UserInfo fornece declarações adicionais por meio de escopos. Associe as contas pela dupla (iss, sub), nunca somente pelo email, para impedir a injeção de declarações. O fluxo implícito foi descontinuado; use o código de autorização com PKCE para OIDC.