# Decodificador OIDC > Cole um ID token do OpenID Connect ou um documento .well-known/openid-configuration e decodifique: as claims principais, claims de perfil, endpoints e capacidades, com verificações de claims obrigatórias, algoritmo de assinatura, nonce e PKCE. - Tool: https://ronutz.com/pt-BR/tools/oidc - Family: Identidade e tokens --- ## O que faz Cole um ID token do OpenID Connect ou o documento `.well-known/openid-configuration` de um provedor, e a ferramenta o decodifica. Para um ID token, ela lê as claims principais de identidade, as claims de perfil padrão e os hashes de vínculo, e executa um conjunto de verificações de segurança. Para um documento de discovery, ela apresenta os endpoints e as capacidades do provedor. Ela detecta automaticamente qual dos dois você colou, e tudo roda no seu navegador. ## OIDC em um parágrafo O OpenID Connect é uma camada de identidade construída sobre o OAuth 2.0. O OAuth responde "o que este aplicativo tem permissão de fazer"; o OIDC acrescenta "e quem é o usuário". Ele faz isso fazendo o provedor emitir um **ID token**, um JWT assinado que afirma quem entrou, junto com o access token do OAuth. Como um ID token é um JWT, a ferramenta o decodifica pelo mesmo núcleo de JWT usado em outras partes do site, e então o interpreta com o significado específico do OIDC. ## O ID token e suas verificações As claims principais identificam o token: `iss` (quem o emitiu), `sub` (o identificador estável do usuário), `aud` (o cliente para o qual foi emitido) e as claims de tempo. Além dessas, o OIDC adiciona claims que vale entender: `nonce`, um valor que o cliente gera e o provedor devolve para que um token reproduzido possa ser detectado; `at_hash` e `c_hash`, que vinculam o ID token ao access token e ao código de autorização para que não possam ser trocados; `amr`, os métodos de autenticação usados (valores como `pwd`, `otp` ou `mfa`, registrados na RFC 8176); e claims de perfil padrão como `name` e `email`. As verificações de segurança da ferramenta olham exatamente o que um cliente cuidadoso olharia: que as claims obrigatórias estão presentes, que o algoritmo de assinatura é sólido em vez de `none` ou fraco, que há um nonce presente, e que a audiência é a que você espera. ## O documento de discovery O documento `.well-known/openid-configuration` é como um provedor se anuncia. Ele lista os endpoints de que um cliente precisa (autorização, token, userinfo e o `jwks_uri` onde ficam as chaves de assinatura), os scopes e os tipos de resposta que ele suporta, os algoritmos com que assinará os ID tokens e os métodos de code challenge do PKCE que aceita. Lê-lo diz num relance o que um provedor suporta e se ele anuncia proteções modernas como o PKCE `S256`. ## Como usar Cole um ID token para decodificar suas claims e ver a avaliação de segurança, ou cole um documento de discovery para ler os endpoints e as capacidades de um provedor. A decodificação é uma leitura pura do que o token ou o documento contém; ela não contata o provedor. ## Standards and references - [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html) - ID token claims, the auth flows, nonce / aud / azp, at_hash / c_hash - [OpenID Connect Discovery 1.0](https://openid.net/specs/openid-connect-discovery-1_0.html) - the .well-known/openid-configuration document fields and requirements - [RFC 6749 - The OAuth 2.0 Authorization Framework](https://www.rfc-editor.org/rfc/rfc6749) - the OAuth 2.0 layer OIDC builds on: scopes, grants, the token endpoint - [RFC 7519 - JSON Web Token (JWT)](https://www.rfc-editor.org/rfc/rfc7519) - the JWT container an ID token uses: registered claims, NumericDate - [RFC 8176 - Authentication Method Reference Values](https://www.rfc-editor.org/rfc/rfc8176) - the amr values (pwd, otp, mfa, hwk, ...) carried in an ID token - [RFC 7636 - Proof Key for Code Exchange (PKCE)](https://www.rfc-editor.org/rfc/rfc7636) - PKCE and the S256 code challenge method advertised in discovery ## Related reading - [As Claims do ID Token, e o Que uma Relying Party Verifica](https://ronutz.com/pt-BR/learn/id-token-claims.md): As claims dentro de um ID token OIDC: as obrigatórias iss, sub, aud, exp e iat; o nonce que impede repetição; azp quando há múltiplas audiências; acr e amr para a força da autenticação; auth_time; e as claims de vínculo at_hash e c_hash, com a validação que uma relying party realiza em cada uma. - [O fluxo authorization code do OIDC](https://ronutz.com/pt-BR/learn/oidc-authorization-code-flow.md): O fluxo authorization code é a forma recomendada de um app obter um ID token: o usuário é redirecionado ao provedor de identidade para logar, o app recebe um código de curta duração, e o troca em um token endpoint de back-channel pelos tokens. Manter o token fora do navegador é o objetivo inteiro. - [OIDC Discovery: O Documento openid-configuration](https://ronutz.com/pt-BR/learn/oidc-discovery.md): Como o documento .well-known/openid-configuration permite a uma relying party descobrir automaticamente os endpoints e capacidades de um provedor, o que significam os campos issuer, jwks_uri e de algoritmo de assinatura, por que anunciar o algoritmo none é perigoso, e por que o suporte a PKCE S256 importa. - [OIDC vs OAuth 2.0: Autenticação vs Autorização](https://ronutz.com/pt-BR/learn/oidc-vs-oauth.md): Por que o OAuth 2.0 é sobre autorização e o OpenID Connect é sobre autenticação, a diferença entre um access token e um ID token, por que usar OAuth puro como mecanismo de login é um antipadrão conhecido, e como saber qual token é qual. - [OpenID Connect: Uma Camada de Identidade sobre o OAuth 2.0](https://ronutz.com/pt-BR/learn/oidc-overview.md): O que o OpenID Connect adiciona ao OAuth 2.0, o ID token no centro de tudo, os papéis de relying party e provedor, como o fluxo de código de autorização entrega um ID token, e por que um ID token é apenas um JWT que você pode decodificar e ler.