Desarrollo OAuth
Carga el ejemplo público para ver la solicitud y su respuesta antes de introducir tus datos.
Introduce valores sin codificar. Se conserva exactamente la URI registrada.
Todo se procesa en esta pestaña. Las entradas no se envían ni se guardan.
response_type=code · flujo de código de autorización
Conserva el verifier para la petición de tokens. Solo el challenge entra en la URL; el informe excluye el verifier.
Un parámetro key=value sin codificar por línea. No repitas campos reservados.
Introduce valores o carga el ejemplo.
Un puerto distinto o una barra al final del callback puede impedir el inicio de sesión. Aquí puedes comparar la URL de autorización OAuth con sus parámetros decodificados. Así resulta más fácil separar un error de configuración de un signo más que se haya convertido en espacio.
Si ya tienes una respuesta de prueba, pégala en la vista de callback e introduce por separado el state que guardaste para esa transacción. Los nombres repetidos siguen siendo filas independientes. Que un texto se pueda analizar no significa que su código o identidad sean válidos.
La URL de autorización OAuth incorpora solo el challenge S256 y su método. El verifier permanece en su campo y tiene un botón de copia independiente para la posterior petición de tokens. El informe tampoco incluye ese verifier, de modo que cada valor conserva su función.
Si state aparece en la consulta y en el fragmento, la tabla conserva ambas filas con su origen. Incluso dos valores iguales se consideran ambiguos. El primer valor coincidente no puede ocultar un segundo parámetro inesperado.
Comprueba esquema, puerto, ruta, barra final y consulta del URI de redireccionamiento. No codifiques previamente la dirección completa. Los parámetros adicionales se escriben como líneas key=value sin codificar; un & dentro del valor sigue siendo contenido.
La generación usa 32 bytes aleatorios independientes para state y verifier. También cambia nonce cuando scope contiene openid. Revisa los campos afectados antes de aplicar y conserva el verifier para esa misma transacción. Cambiar un permiso no regenera las credenciales.
El modo automático espera 350 ms después del último cambio. Desactívalo para usar el botón de ejecución o Ctrl/Cmd+Enter. Un resultado desactualizado no se puede exportar. Cambiar de vista conserva las entradas; el state esperado del callback es un campo independiente.
El redirect_uri completo se trata como un único valor. Los parámetros existentes del endpoint se decodifican de forma estricta y se reconstruyen junto a los campos. Un signo más literal pasa a %2B; los espacios usan codificación de formulario.
Se aceptan verificadores de 43 a 128 caracteres permitidos. No se recortan espacios ni se decodifica Base64 antes de calcular el hash. Desactivar PKCE elimina challenge y método de la dirección, pero conserva el verifier introducido.
Puedes pegar una URL completa, ?query, #fragment o solo la consulta. %252F se convierte en %2F, no en una barra. Se conservan nombres vacíos, valores vacíos y parámetros repetidos en su orden original para revisar cada dato recibido.
El parámetro state puede faltar, estar vacío, repetirse, quedar sin comparar, coincidir o ser distinto. También se señalan mezclas de código de autorización y error. La tabla añade 50 filas cada vez; el informe siempre contiene todos los parámetros.
Cambiar el esquema, puerto, ruta o barra final puede señalar otro destino. Registra en el proveedor la dirección que realmente usarás. La herramienta conserva el texto como valor del parámetro, pero no puede consultar la configuración registrada de tu cliente.
State vuelve como parámetro del callback y se compara con el valor original de la transacción. Nonce está vinculado a un ID token y se comprueba después de validar ese token. Encontrar nonce en un callback pegado no sustituye esa validación.
El secreto autentica al cliente en el endpoint de tokens. PKCE también vincula el código con su verifier original. Las recomendaciones actuales aconsejan PKCE para clientes confidenciales. Comprueba que el proveedor admite S256.
Sí, es un identificador público. client_secret y code_verifier desempeñan otras funciones y no deben formar parte de la consulta de autorización. La herramienta bloquea esos nombres y permite copiar el verifier por separado.
OAuth autoriza el acceso a recursos. OpenID Connect añade autenticación de usuario y un ID token. Incluye openid en scope y nonce según los requisitos del proveedor. Tu aplicación sigue siendo responsable de validar el token devuelto.
¿Has detectado un error de cálculo o validación?
Contrasta la URL de autorización OAuth con los datos registrados del cliente y analiza después el callback con el state guardado para esa transacción.