Cole metadados do provedor, não segredos ou tokens de produção. A análise não contata o provedor nem confirma registro do cliente ou redirecionamentos permitidos.
Funciona localmente no seu navegadorUse Authorization Code com PKCE em clientes web e móveis. Este verificador local não confirma o registro no provedor, listas permitidas de redirect URI, política de consentimento nem o comportamento real dos tokens.
Cole o JSON retornado por /.well-known/openid-configuration, clique em Inspecionar configuração OIDC e leia os achados: a página nomeia os campos dos quais um cliente público com Authorization Code depende e separa problemas bloqueantes de pontos a revisar. Os campos de client ID e redirect URI são opcionais e apenas tornam essa revisão local mais específica.
O botão PKCE sorteia 48 bytes aleatórios, resume com SHA-256 e mostra o verificador de código, o desafio S256 e um valor state. Tudo roda nesta aba pela API Web Crypto; os metadados colados não são enviados ao VoriTools nem ao provedor de identidade.
O inspetor lê os campos dos quais um cliente de navegador ou celular depende: issuer, authorization_endpoint e token_endpoint precisam ser URLs absolutas — HTTPS em produção e HTTP apenas em endereços de loopback — e jwks_uri precisa ser anunciado para que as assinaturas dos tokens possam ser verificadas. response_types_supported precisa incluir code e grant_types_supported precisa incluir authorization_code para o fluxo Authorization Code.
O campo de maior peso em um cliente público é code_challenge_methods_supported. Sem PKCE, um código de autorização capturado no celular ou por um esquema de URL próprio pode ser trocado por quem o interceptou; por isso um anúncio que só oferece plain, ou que omite o campo, é tratado aqui como bloqueante, e não como aviso.
Gerar conjunto PKCE pega 48 bytes aleatórios de crypto.getRandomValues, codifica em base64url e mostra o verificador de 64 caracteres. O desafio S256 é o base64url do resumo SHA-256 desse verificador — 43 caracteres — e o valor state são 24 bytes aleatórios, 32 caracteres, para comparar quando o provedor devolver o redirect com o código.
Use S256: o desafio vai na requisição de autorização, o verificador fica no cliente até a requisição de token, e um código capturado no meio não pode ser trocado. O método plain envia o próprio verificador na URL; por isso um documento que só aceita plain encerra esta inspeção com um achado bloqueante.
O documento é lido exatamente como foi colado. A página não sabe se o provedor registrou o seu cliente, se o redirect URI está na lista permitida, qual tela de consentimento o usuário vê nem se os endpoints se comportam como anunciam; isso exige uma requisição de autorização real contra o provedor.
Um resultado sem achados significa que os metadados copiados são coerentes para um cliente público, não que a integração funcione. Fluxos reais, validade dos tokens e renovação ainda precisam ser testados no provedor, e a checagem do redirect URI aqui é apenas um lembrete local de correspondência exata.