Desenvolvimento OAuth
Carregue o exemplo público para comparar a solicitação e o retorno antes de inserir seus próprios valores.
Digite valores sem codificação. A URI cadastrada é preservada exatamente.
Tudo é processado nesta aba. As entradas não são enviadas nem salvas.
response_type=code · fluxo de código de autorização
Guarde o verifier para a solicitação de token. Só o challenge entra na URL; o relatório exclui o verifier.
Um parâmetro key=value sem codificação por linha. Não repita campos reservados.
Digite valores ou carregue o exemplo.
Um detalhe no endereço de retorno pode interromper o login: uma porta diferente, uma barra final ou um sinal de mais convertido em espaço. Ao comparar a URL de autorização OAuth com a tabela decodificada, você consegue ver quais valores foram realmente montados para a solicitação.
Para investigar um teste já realizado, cole o retorno na visualização de callback e informe separadamente o state guardado naquela transação. Nomes repetidos continuam em linhas distintas. Um texto analisado corretamente não comprova que o código recebido ou a identidade sejam válidos.
A URL de autorização OAuth recebe somente o challenge S256 e o método. O verifier permanece no campo de entrada e pode ser copiado por um botão próprio para a futura solicitação de token. O relatório também exclui o verifier, evitando misturar o valor privado com os parâmetros enviados.
Quando state aparece na consulta e no fragmento, as duas linhas mantêm a origem e a ordem. Mesmo valores iguais são tratados como ambíguos. Assim, um primeiro resultado que coincide não esconde outro parâmetro que não deveria estar ali.
Confira esquema, porta, caminho, barra final e consulta do URI de redirecionamento. Não codifique o endereço inteiro antes de inseri-lo. Parâmetros adicionais usam uma linha key=value sem codificação; um & dentro do valor continua sendo parte do conteúdo.
O botão usa 32 bytes aleatórios independentes para state e verifier. Também substitui nonce quando scope contém openid. Revise os campos alterados antes de aplicar e guarde o verifier da mesma transação. Mudar um escopo não gera valores novos automaticamente.
No modo automático, o cálculo ocorre 350 ms após a última alteração. Ao desativá-lo, use o botão de execução ou Ctrl/Cmd+Enter. Um resultado desatualizado não pode ser exportado. As visualizações preservam as entradas, mas o state esperado do callback é informado em um campo independente.
O redirect_uri completo é tratado como um único valor. Parâmetros que já existem no endpoint passam por decodificação estrita e são reconstruídos com os campos. O sinal + literal de um valor adicional vira %2B; espaços seguem a codificação de formulário.
O verifier aceita de 43 a 128 caracteres permitidos. Não há remoção de espaços nem decodificação Base64 anterior ao hash. Desligar PKCE remove challenge e método da URL, mas preserva o verifier digitado para comparação ou uso posterior.
São aceitos URL completa, ?query, #fragment ou apenas a consulta. %252F vira %2F, e não uma barra. Nomes vazios, valores vazios e parâmetros repetidos mantêm sua ordem original, sem serem sobrescritos em um objeto.
O parâmetro state pode estar ausente, vazio, repetido, sem comparação, igual ou diferente. Misturar código de autorização com error também gera um aviso. A tabela mostra 50 linhas por vez; o relatório exportado sempre contém todos os parâmetros da análise.
Um esquema, porta, caminho ou barra final diferente pode apontar para outro destinatário. Cadastre no provedor o endereço que será realmente usado. Esta página preserva o texto como valor de parâmetro, mas não consegue consultar o cadastro do seu cliente.
State volta nos parâmetros do callback e é comparado ao valor original da transação. Nonce está ligado ao ID token e deve ser conferido depois da validação desse token. Encontrar nonce em um callback colado não substitui essa verificação.
O segredo autentica o cliente no endpoint de token. PKCE também liga o código ao verifier original. As recomendações atuais indicam PKCE para clientes confidenciais. Mesmo com o padrão S256 habilitado aqui, confirme o suporte do provedor.
Sim, ele é um identificador público. client_secret e code_verifier têm outras funções e não devem entrar na consulta de autorização. A ferramenta bloqueia esses nomes e oferece uma cópia separada do verifier.
OAuth autoriza acesso a recursos. OpenID Connect acrescenta autenticação do usuário e um ID token. Inclua openid no scope e nonce conforme os requisitos do provedor. A aplicação continua responsável por validar o token retornado.
Encontrou um erro no cálculo ou na validação?
Compare a URL de autorização OAuth com o cadastro do cliente e confira o callback usando o state que você guardou para aquela transação específica.