OpenID Connect y OAuth 2.0: identidad frente a delegación

OAuth 2.0 (RFC 6749) es un marco de delegación: una aplicación cliente obtiene un token de acceso para llamar a una API en nombre de una persona o de sí misma. El destinatario de ese token es la API (el servidor de recursos), que comprueba quién lo emitió, para quién es, qué alcances lleva y si sigue vigente. El token de acceso no le dice al cliente, de forma estándar, quién es la persona.

OpenID Connect Core 1.0, de la OpenID Foundation, añade el token de identidad. Su destinatario es el cliente, no una API: su audiencia (aud) es el identificador del cliente, y lleva como mínimo el emisor (iss), el sujeto (sub), la audiencia, el vencimiento (exp) y la hora de emisión (iat). El cliente lo pide incluyendo el alcance openid, y con un valor de un solo uso (nonce) ata la respuesta a su propia solicitud.

La regla de diseño sale sola: el token de identidad sirve para iniciar sesión en el cliente y no se manda a una API; el token de acceso sirve para la API y no prueba un inicio de sesión.

Un cliente que no pide el alcance openid no está usando OpenID Connect: no recibe token de identidad, no tiene nonce que comprobar ni audiencia propia. Si aun así «inicia sesión» porque consiguió un token de acceso y le preguntó a una API quién es el usuario, ha construido su propia autenticación sobre algo que no fue diseñado para eso, y hereda cualquier error de esa API.

Abre el laboratorio y lee clientes.txt, fijándote en los alcances que pide cada cliente y en la última columna.

Una API que no comprueba la audiencia acepta cualquier token firmado por el IdP: uno emitido para otra API, o un token de identidad que era para un cliente. El efecto de diseño es que todo token del IdP se convierte en una llave de todas las APIs, y la separación entre clientes y alcances deja de existir en la práctica.

Lee api-inventario.txt y el extracto de registro-api-inventario.txt.

OpenID Connect Core es explícito: el único identificador estable de una persona es el par emisor más sujeto (iss y sub). El sub es único dentro del emisor y no se reasigna nunca. El correo, el teléfono o el nombre de usuario pueden cambiar, y un emisor puede dar el mismo correo a otra persona con el tiempo; la especificación pide no usarlos como identificador único.

Un cliente que vincula cuentas por correo funciona bien hasta el día en que un correo se recicla. Ese día, la persona nueva hereda la cuenta, el historial y los permisos de la anterior, sin que nadie haya tocado un permiso.

Lee vinculos-tablero.txt y su nota final.

La corrección no es avisar a RR. HH. de que no reasigne correos, ni pedir a la persona nueva que avise. Es cambiar la llave del vínculo para que un cambio de correo no pueda mover una identidad a otra cuenta.