Claims y tokens de ID de OpenID Connect

OpenID Connect (OIDC) añade una capa de identidad sobre OAuth 2.0. Mientras que OAuth 2.0 gestiona la autorización (¿a qué puede acceder esta aplicación?), OIDC responde a la pregunta de identidad (¿quién es el usuario?). OIDC se implementa añadiendo el scope "openid" a una solicitud de OAuth 2.0, lo que hace que el servidor de autorización devuelva un token de ID junto con el token de acceso.

El token de ID de OIDC es un JSON Web Token (JWT) que contiene claims sobre el usuario autenticado. El JWT está firmado por el servidor de autorización mediante su clave privada (normalmente RS256 o ES256), y la parte confiante (la aplicación cliente) verifica la firma utilizando las claves públicas publicadas por el servidor de autorización (punto de conexión JWKS).

Claims del token de ID obligatorios y de uso habitual: "sub" (subject, identificador único del usuario), "iss" (issuer, URL del servidor de autorización), "aud" (audience, ID del cliente), "exp" (marca de tiempo de expiración de Unix), "iat" (marca de tiempo de emisión de Unix). Opcionales: "auth_time" (momento en que tuvo lugar la autenticación), "nonce" (prevención de ataques de repetición), "at_hash" (hash del token de acceso), "acr" (clase de contexto de autenticación), "amr" (métodos de autenticación utilizados).

El punto de conexión UserInfo de OIDC devuelve claims adicionales sobre el usuario autenticado cuando se invoca con un token de acceso válido. Los clientes solicitan conjuntos específicos de claims mediante scopes: "profile" (nombre, imagen, configuración regional), "email" (correo electrónico, email_verified), "address" (dirección con formato), "phone" (phone_number, phone_number_verified). La respuesta de UserInfo es un objeto JSON o un JWT.

La validación del token de ID comienza verificando la firma. El cliente obtiene el JWKS (JSON Web Key Set, conjunto de claves web JSON) del servidor de autorización desde el punto de conexión conocido, encuentra la clave que coincide con el parámetro "kid" (ID de clave) de la cabecera del JWT y verifica la firma del JWT. Esto demuestra que el token fue emitido por el servidor de autorización legítimo y que no ha sido manipulado.

Después de verificar la firma, el cliente debe validar lo siguiente: "iss" debe coincidir exactamente con la URL esperada del servidor de autorización (incluidos el esquema y la ruta). "aud" debe contener el propio client_id del cliente. "exp" debe estar en el futuro (se deben rechazar los tokens caducados). "iat" debe ser razonablemente reciente. Las cuatro comprobaciones son obligatorias según la especificación de OIDC.

El claim nonce evita los ataques de repetición de tokens de ID. El cliente genera un nonce aleatorio y lo incluye en la solicitud de autorización. El servidor de autorización incorpora el nonce al token de ID. El cliente verifica que el nonce del token de ID coincida con el que envió. Esto evita que un atacante que capture un token de ID pueda reutilizarlo para autenticarse en otra sesión.

Cuando OIDC utiliza el flujo implícito (response_type=id_token), el token de ID se devuelve directamente en el fragmento de la URL. El cliente debe validar at_hash (el hash del token de acceso) para vincular el token de acceso al token de ID. Sin la validación de at_hash, son posibles los ataques de sustitución del token de acceso. Esta es otra razón por la que el flujo implícito está deprecado.

OIDC define mapeos estándar entre scopes y claims. El scope "openid" es obligatorio y devuelve el claim "sub". "profile" devuelve name, given_name, family_name, nickname, picture, website, locale, zoneinfo, updated_at. "email" devuelve email y email_verified. Solicitar scopes innecesarios infringe el principio de divulgación mínima y puede exponer datos confidenciales del usuario.

Al implementar un inicio de sesión OIDC con varios proveedores (por ejemplo, "Sign in with Google" y "Sign in with GitHub"), pueden producirse ataques de inyección de claims. Si un atacante crea una cuenta en el proveedor B con la dirección de correo electrónico de una víctima que utiliza el proveedor A, podría obtener acceso si la aplicación vincula las cuentas basándose únicamente en el claim de email. Vincule siempre las cuentas mediante el par (iss, sub), no solo mediante el correo electrónico.

El flujo híbrido de OIDC (response_type=code id_token) devuelve tanto un código de autorización como un token de ID desde el punto de conexión de autorización. El token de ID permite verificar la identidad de inmediato, mientras que el código se intercambia por tokens mediante el canal de retorno. Se utiliza cuando el cliente necesita mostrar inmediatamente la información del usuario antes de completar el intercambio de tokens mediante el canal de retorno.

¿Qué combinación de claims debe validar una parte confiante en un token de ID de OIDC?

OIDC añade un token de ID JWT firmado a los flujos de OAuth 2.0. Valide la firma (JWKS), iss (coincidencia exacta), aud (client_id), exp (no caducado) y nonce (si se envió). El punto de conexión UserInfo proporciona claims adicionales mediante scopes. Vincule las cuentas mediante el par (iss, sub), nunca solo mediante el correo electrónico, para evitar la inyección de claims. El flujo implícito está deprecado; utilice el código de autorización con PKCE para OIDC.