Validar el token de identidad y el de acceso

El token de identidad de OpenID Connect es para el cliente: su aud es el client_id de la aplicación que pidió el inicio de sesión. Según OpenID Connect Core 1.0, el cliente comprueba que el emisor (iss) es exactamente el esperado, que su propio client_id está en aud, la firma con el algoritmo esperado y las claves del emisor, que no venció (exp) y que el nonce coincide con el del inicio.

El token de acceso es para la API. Cuando es un JWT, RFC 9068 define su perfil: lleva el tipo at+jwt en la cabecera para que nadie lo confunda con otro JWT, su aud nombra a la API, y la API debe rechazar lo que no sea de ese tipo, no venga de su emisor, no la nombre como destinataria o esté vencido. Usar un token de identidad para llamar a una API, o aceptar un token de acceso como prueba de inicio de sesión, mezcla dos cosas que el estándar separa a propósito.

OpenID Connect Core es tajante en esto: la única forma estable y única de identificar a una persona es la pareja emisor y sujeto (iss y sub). El sujeto no se reasigna dentro de un emisor. El correo, el teléfono o el nombre de usuario sí pueden cambiar o reutilizarse con el tiempo, y por eso la especificación dice que no se usen como identificador único. Una aplicación que elige la cuenta local por el correo hereda cualquier descuido del proveedor sobre ese dato.

Abre validar_identidad.py y mira qué reclamo usa cuenta_local.

Las bibliotecas de JWT suelen comprobar el destinatario solo si se les dice cuál esperar, y casi todas permiten apagarlo con una opción. Apagarla para que «deje de dar errores» significa aceptar como inicio de sesión un token emitido para otra aplicación del mismo proveedor. En validar_identidad.py la llamada a jwt.decode pasa el emisor y el algoritmo, pero no pasa a quién debe ir dirigido el token.

Ahora la API. Lee api_tokens.py: qué destinatarios acepta y si mira el tipo de token. Después recorre tokens-presentados.txt buscando el que no tiene forma de token de acceso (mira la cabecera, el aud y los reclamos que trae o no trae), y confírmalo en peticiones-api.txt.

El equipo de la API propone tres cambios y solo hay tiempo para uno esta semana. Solo uno de ellos impide que un token de identidad vuelva a entrar como si fuera de acceso. Vuelve a la cabecera, al aud y a la hora de vencimiento del token que encontraste en la tarea anterior, y a las líneas de api_tokens.py que lo dejaron pasar.