Herramientas de desarrollo · JWT decodificador
Token de ID versus token de acceso: por qué OpenID Connect JWT no es una clave API
· Antecedentes
jwt oauth autenticación
Ambos pueden ser JWT del mismo proveedor, pero responden preguntas diferentes. Esta publicación explica qué contiene un token de identificación y un token de acceso, quién debe consumirlos y cómo diferenciarlos mediante decodificación.
La API rechaza un token que parece perfectamente válido, porque nunca estuvo destinado a la API.
Una API puede rechazar un token bien formado y firmado correctamente porque esa credencial se emitió para otro consumidor y propósito. "Es un JWT" describe un posible formato, no permiso para enviarlo a todas partes. Los tokens de identificación y los tokens de acceso responden a diferentes preguntas en un flujo de identidad.
ToolAcre puede exponer patrones de encabezado y carga útil que admiten la depuración, pero no puede autenticar el token ni validar un perfil de OpenID Connect. La clasificación final debe provenir del contrato del proveedor, el flujo de emisión y el resultado de la verificación confiable en lugar de una inspección visual.
Las reclamaciones de tokens de identificación pueden sugerir el uso de identidad; este decodificador genérico no valida un perfil OpenID Connect
Un token de identificación comunica información de autenticación al cliente que solicitó el inicio de sesión. Dependiendo del perfil, los reclamos visibles pueden incluir un nonce, tiempo de autenticación, métodos de autenticación o un hash relacionado con otro token. Esos campos no son concesiones de autorización de API genéricas.
El descodificador trata `auth_time` como un campo con forma de tiempo y muestra otros nombres como específicos de la aplicación, a menos que estén entre sus siete principales. No valida nonce, `at_hash`, `amr` ni la semántica de la audiencia del cliente. Una carga útil de identidad legible no es confiable hasta que el cliente la valida correctamente.
Los tokens de acceso pueden ser JWT u opacos; sólo los JWT de tres partes se ajustan a este decodificador
Un token de acceso autoriza llamadas a un servidor de recursos bajo un sistema de autorización. Puede ser un JWT o una cadena opaca. Sólo la forma firmada de tres partes se ajusta a la ruta de ToolAcre; un token opaco no tiene una estructura general del lado del cliente para decodificar y no debe forzarse a través de esta herramienta.
Un token de acceso JWT puede transportar información de audiencia y alcance, pero esos valores necesitan verificación autenticada y política de recursos. El panel del navegador no implementa un servidor de recursos y no puede determinar si un ámbito permite una operación particular.
Tokens de actualización: generalmente opacos, nunca deben decodificarse y nunca deben enviarse a una API
Un token de actualización admite la obtención de credenciales de acceso de reemplazo según las reglas del proveedor. Por lo general, es opaco y no está destinado a API de recursos. También es una credencial de alto valor, por lo que pegarla en un decodificador genera un riesgo sin un beneficio de diagnóstico confiable.
No infieras que cada valor en forma de token debe ser decodificado. Utilice herramientas del proveedor y registros controlados para errores de actualización. La advertencia explícita de ToolAcre contra los tokens de producción se aplica con especial fuerza aquí, y su analizador de tres segmentos no ofrece ninguna operación de actualización.
Las audiencias difieren: el ID del cliente en un token de ID versus el recurso en un token de acceso
La audiencia es una pista importante porque el consumidor objetivo difiere. Un token de identificación suele estar dirigido al cliente, mientras que un token de acceso está dirigido a un recurso. Los identificadores y representaciones exactos dependen del proveedor y el perfil, por lo que este artículo no inventa un patrón de cadena universal.
Un encabezado `typ` también puede proporcionar una etiqueta explícita, pero sigue siendo información controlada por token hasta la verificación. ToolAcre advierte sólo cuando una cadena `typ` difiere de `JWT`; no reconoce todas las etiquetas de perfil ni las convierte en una decisión de autorización.
Ejemplo resuelto: comparar campos visibles sin tratarlos como prueba del tipo de token
Decodifica dos ejemplos sintéticos: uno que incluye afirmaciones de autenticación orientadas al cliente y otro que incluye una audiencia y un alcance de recursos. Registre las diferencias en `aud`, `typ` y los nombres de carga útil. El ejercicio enseña qué preguntarle al emisor, no cómo probar la identidad de cualquiera de los ejemplos.
Un token fabricado puede copiar las mismas etiquetas y un token real puede usar convenciones específicas del proveedor. Confirme el tipo de la respuesta de emisión y la documentación, luego valídelo con el consumidor previsto. La salida del decodificador es evidencia de respaldo, nunca la autoridad decisiva.
Lo que esto no cubre: los flujos de OAuth que emiten estos tokens, que son un tema aparte.
Esta comparación no explica el código de autorización, el dispositivo u otros flujos que emiten tokens. Tampoco cubre los pasos de validación específicos del proveedor, la introspección opaca del token de acceso o la rotación de actualización. Esos temas dependen del ecosistema y la implementación seleccionados.
Mantenga la pregunta de depuración inmediata limitada: ¿qué credencial recibió el cliente, quién es su consumidor previsto y qué componente confiable la valida? Responder esas tres preguntas evita que una forma genérica JWT borre las funciones del protocolo.
Conclusión: mire aud y escriba antes de enviar: el decodificador ToolAcre JWT le permite verificar qué tipo de token tiene
Mire la audiencia y escriba antes de enviar un token, pero no confíe en ninguno de los campos hasta que la verificación sea exitosa. Un token de identificación pertenece al límite de validación de su cliente; un token de acceso pertenece a su servidor de recursos. Un token de actualización pertenece al proceso de actualización del proveedor, no a una API.
ToolAcre ayuda a leer ejemplos seguros de tres partes y no pretende clasificarlos ni validarlos. Úselo para detectar posibles errores y luego deje que el flujo documentado y el verificador configurado de forma independiente establezcan el propósito real de la credencial.