# OIDC Discovery: O Documento openid-configuration > 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. Source: https://ronutz.com/pt-BR/learn/oidc-discovery Updated: 2026-06-29 Related tools: https://ronutz.com/pt-BR/tools/oidc --- ## Para que serve o discovery Uma relying party precisa saber muito sobre um provedor antes de poder usá-lo: para onde enviar o usuário para se autenticar, onde trocar um código por tokens, onde buscar as chaves que verificam a assinatura de um token, e o que o provedor de fato suporta. O OpenID Connect Discovery permite que a relying party descubra tudo isso automaticamente, em vez de tê-lo fixado no código. O provedor publica um documento JSON em um caminho fixo, /.well-known/openid-configuration sob sua URL de issuer, e a relying party o lê para se configurar. O decodificador OIDC lê esse mesmo documento e o resume no issuer, nos endpoints e nas capacidades, com algumas verificações nos campos relevantes à segurança. ## Os metadados e os endpoints O campo issuer é o identificador do provedor, e ele deve corresponder exatamente à claim iss que aparece nos tokens que o provedor emite. Essa ligação importa: uma relying party confirma que um token veio do provedor que ela configurou comparando o iss do token com o issuer descoberto. O documento então lista os endpoints que a relying party usará. O authorization_endpoint é para onde o usuário é enviado para se autenticar. O token_endpoint é onde a relying party troca um código de autorização por tokens. O userinfo_endpoint retorna claims adicionais sobre o usuário quando chamado com um access token. O jwks_uri é o endpoint mais crítico para a segurança: é onde o provedor publica suas chaves públicas de assinatura, como um JWK Set. Uma relying party busca as chaves de lá e as usa para verificar a assinatura de cada ID token, selecionando a chave certa pelo kid no cabeçalho do token. Outros endpoints também podem aparecer, como end_session_endpoint para logout e endpoints de introspecção ou revogação para gestão de tokens. ## As capacidades Vários campos anunciam o que o provedor suporta, cada um um array. response_types_supported e grant_types_supported descrevem quais fluxos estão disponíveis. subject_types_supported diz se os valores de sub são públicos ou pairwise (pairwise dá a cada relying party um sub diferente para o mesmo usuário, por privacidade). scopes_supported e claims_supported listam o que uma relying party pode solicitar e esperar. Dois campos de capacidade têm peso de segurança particular, e o decodificador os verifica. ## Por que o algoritmo none é perigoso O campo id_token_signing_alg_values_supported lista os algoritmos que o provedor usará para assinar ID tokens. Um provedor saudável lista algoritmos assimétricos como RS256 ou ES256, que permitem a uma relying party verificar com uma chave pública do JWKS. Se essa lista inclui none, o provedor está anunciando que emitirá ID tokens sem assinatura, e o decodificador sinaliza isso. Um ID token sem assinatura não carrega prova de quem o emitiu, então qualquer um poderia forjar um; uma relying party que aceitasse um token com alg none estaria confiando em uma declaração não autenticada. O algoritmo none tem sido a base de vulnerabilidades reais de bypass de autenticação, em que um atacante remove a assinatura e troca o alg para none na esperança de que o verificador aceite. Um provedor não deveria oferecê-lo, e uma relying party nunca deveria aceitá-lo. ## Por que o PKCE S256 importa O campo code_challenge_methods_supported diz se o provedor suporta PKCE (Proof Key for Code Exchange) e quais métodos. O PKCE protege o fluxo de código de autorização contra interceptação do código, vinculando o código a um segredo que o cliente gera, e é essencial para clientes públicos como aplicações de página única e móveis que não conseguem guardar um segredo de cliente. O método recomendado é o S256, que envia um hash SHA-256 do segredo em vez do segredo em si. O decodificador sinaliza um provedor que não anuncia nenhum método PKCE, e separadamente sinaliza um que oferece PKCE mas sem o S256, já que o S256 é o método a preferir. ## Discovery mais JWKS é como a verificação funciona Juntando tudo: o discovery diz à relying party o issuer a esperar e o jwks_uri de onde buscar as chaves, e o JWKS fornece as chaves públicas. Com isso, a relying party pode fazer a verificação que este decodificador deliberadamente não faz: buscar as chaves atuais do provedor, selecionar a que corresponde ao kid do token, e checar a assinatura do ID token, depois confirmar o issuer, a audiência e o restante. O decodificador lê o documento de discovery para que você possa inspecionar e raciocinar sobre a configuração de um provedor; a relying party usa esse mesmo documento, mais as chaves ao vivo, para de fato estabelecer confiança.