OpenID Connect, la capa de identidad

OpenID Connect 1.0 es una capa de identidad sobre OAuth 2.0. La aplicación pide el alcance openid junto a los demás y, además del token de acceso, el servidor de autorización le entrega un token de identificación, un JWT (JSON Web Token, RFC 7519) firmado por el servidor. Dentro van afirmaciones sobre el inicio de sesión. Las obligatorias son cinco: el emisor (iss), el identificador estable de la persona dentro de ese emisor (sub), la audiencia (aud, que debe incluir el client_id de la aplicación), la fecha de vencimiento (exp) y la de emisión (iat).

Y hay un punto fino: un token de identificación es para que lo lea el cliente. No se manda a una API como si fuera un token de acceso.

La aplicación que recibe el token tiene que comprobar varias cosas, según la especificación (OpenID Connect Core, sección 3.1.3.7): que el emisor (iss) sea exactamente el del servidor en que confía; que su propio client_id esté en la audiencia (aud); que la firma sea válida; que no haya vencido (exp); y, si envió un nonce, que el token traiga el mismo.

Abre el laboratorio y compara en validaciones_id_token las columnas aud_recibido y client_id_propio. Una aplicación aceptó un token que en realidad se emitió para otra: un token de otra aplicación no debe servir de inicio de sesión aquí.

El nonce es un valor al azar que la aplicación envía al pedir el inicio de sesión y que el servidor copia dentro del token. Al recibirlo, la aplicación comprueba que el valor es el que envió. Así sabe que el token responde a su petición y no es uno viejo o de otra sesión reutilizado.

Compara nonce_recibido con nonce_enviado en cada fila. Una aplicación aceptó el token aunque los dos valores no coinciden.

Un fallo de validación casi nunca se nota en el uso normal: la persona inicia sesión y todo parece bien. Solo se ve en el registro, que es donde se compara lo recibido con lo esperado. Por eso el nonce y la audiencia se comprueban aunque «ya funcione».

El registro incluye también la hora de validación y la de vencimiento (exp): un token vencido no debe aceptarse. Una fila decide «rechazado» y es la correcta, porque el emisor recibido no es el esperado. Cuenta cuántas filas terminaron en «aceptado» cuando alguna de las comprobaciones (emisor, audiencia, nonce o vencimiento) debía haber fallado.