Introducción a los tokens en Azure Active Directory B2C

Azure Active Directory B2C (Azure AD B2C) emite diferentes tipos de tokens de seguridad a medida que procesa cada flujo de autenticación. En este artículo se describe el formato, las características de seguridad y el contenido de cada tipo de token.

Tipos de token

Azure AD B2C admite los protocolos OAuth 2.0 y OpenID Connect, que usan tokens para la autenticación y el acceso seguro a los recursos. Todos los tokens usados en Azure AD B2C son tokens web JSON (JWT) que contienen aserciones de información sobre el portador y el asunto del token.

Los siguientes tokens se usan en comunicación con Azure AD B2C:

• Token de identificación: JWT que contiene las notificaciones que puede usar para identificar usuarios en la aplicación. Este token se envía de forma segura en solicitudes HTTP para la comunicación entre dos componentes de la misma aplicación o servicio. Puede usar las notificaciones en un token de identificación como considere oportuno. Normalmente se usan para mostrar información de la cuenta o para tomar decisiones de control de acceso en una aplicación. Los tokens de identificador emitidos por Azure AD B2C están firmados, pero no están cifrados. Cuando la aplicación o la API reciben un token de identificador, debe validar la firma para demostrar que el token es auténtico. La aplicación o la API también deben validar algunas declaraciones en el token para demostrar que es válido. Según los requisitos del escenario, las notificaciones validadas por una aplicación pueden variar, pero la aplicación debe realizar algunas validaciones de notificaciones comunes en cada escenario.

• Token de acceso: un JWT que contiene afirmaciones que puedes usar para identificar los permisos concedidos a tus API. Los tokens de acceso están firmados, pero no están cifrados. Los tokens de acceso se usan para proporcionar acceso a las API y los servidores de recursos. Cuando la API recibe un token de acceso, debe validar la firma para demostrar que el token es auténtico. Su API también debe validar algunos reclamos en el token para demostrar que es válido. Según los requisitos del escenario, las notificaciones validadas por una aplicación pueden variar, pero la aplicación debe realizar algunas validaciones de notificaciones comunes en cada escenario.

• Token de actualización : los tokens de actualización se usan para adquirir nuevos tokens de identificador y tokens de acceso en un flujo de OAuth 2.0. Proporcionan a la aplicación acceso a largo plazo a los recursos en nombre de los usuarios sin necesidad de interacción con esos usuarios. Los tokens de actualización son opacos para la aplicación. Azure AD B2C los emite y solo se puede inspeccionar e interpretar mediante Azure AD B2C. Son de larga duración, pero la aplicación no debe escribirse con la expectativa de que un token de actualización dure durante un período de tiempo específico. Los tokens de actualización se pueden invalidar en cualquier momento por diversos motivos. La única manera de que la aplicación sepa si un token de actualización es válido es intentar canjearlo mediante la realización de una solicitud de token a Azure AD B2C. Al canjear un token de actualización por un nuevo token de acceso, recibe un nuevo token de actualización en la respuesta del token. Guarde el nuevo token de actualización. Reemplaza el token de actualización que usó anteriormente en la solicitud. Esta acción ayuda a garantizar que los tokens de actualización sigan siendo válidos durante tanto tiempo como sea posible. Las aplicaciones de página única que usan el flujo de código de autorización con PKCE siempre tienen una duración de token de actualización de 24 horas. Obtenga más información sobre las implicaciones de seguridad de los tokens de actualización en el explorador.

Puntos de conexión

Una aplicación registrada recibe tokens y se comunica con Azure AD B2C mediante el envío de solicitudes a estos puntos de conexión:

• https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/authorize
• https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/token

Los tokens de seguridad que la aplicación recibe de Azure AD B2C pueden proceder de los puntos de conexión /authorize o /token. Cuando se adquieren tokens de identificador desde el:

• punto de conexión /authorize, el procedimiento se realiza con el flujo implícito, que se usa a menudo para los usuarios que inician sesión en aplicaciones web basadas en JavaScript. Sin embargo, si la aplicación usa MSAL.js 2.0 o posterior, no habilite la concesión de flujo implícita en el registro de la aplicación, ya que MSAL.js 2.0+ admite el flujo de código de autorización con PKCE.
• punto de conexión /token, el procedimiento se realiza utilizando el flujo de código de autorización, que mantiene el token oculto al explorador.

Reclamaciones

Al usar Azure AD B2C, tiene un control específico sobre el contenido de los tokens. Puede configurar flujos de usuario y directivas personalizadas para enviar determinados conjuntos de datos de usuario en declaraciones necesarias para su aplicación. Estas reclamaciones pueden incluir propiedades estándar como displayName y emailAddress. Tus aplicaciones pueden usar estas afirmaciones para autenticar de forma segura a los usuarios y las solicitudes.

Las notificaciones de tokens de identificador no se devuelven en ningún orden concreto. Se pueden agregar nuevas notificaciones en tokens de identificador en cualquier momento. No se debe interrumpir la aplicación cuando se agreguen nuevas notificaciones. También puede incluir atributos de usuario personalizados en sus afirmaciones.

En la tabla siguiente se enumeran las afirmaciones que puede esperar encontrar en fichas de identificador y fichas de acceso emitidas por Azure AD B2C.

Configuración

Las siguientes propiedades se usan para administrar las duraciones de los tokens de seguridad emitidos por Azure AD B2C:

• Duración de los tokens de acceso e ID (minutos): la duración de los tokens de portador de OAuth 2.0 que se utilizan para obtener acceso a un recurso protegido. El valor predeterminado es 60 minutos. El mínimo (inclusivo) es de 5 minutos. El máximo (inclusivo) es de 1440 minutos.

• Duración del token de actualización (días): período de tiempo máximo antes del cual se puede usar un token de actualización para adquirir un nuevo token de acceso o identificador. El período de tiempo también abarca la adquisición de un nuevo token de actualización si a su aplicación se le ha concedido el ámbito offline_access. El valor predeterminado es 14 días. El mínimo (inclusivo) es un día. El máximo (inclusivo) es de 90 días.

• Duración de la ventana deslizante del token de actualización (días): una vez transcurrido este período de tiempo, el usuario se ve obligado a volver a autenticarse, independientemente del período de validez del token de actualización más reciente adquirido por la aplicación. Solo se puede proporcionar si el interruptor está establecido en Bounded. Debe ser mayor o igual que el valor de duración del token de actualización (días). Si el interruptor está establecido en Sin expiracion, no puedes proporcionar un valor específico. El valor predeterminado es de 90 días. El mínimo (inclusivo) es un día. El máximo (inclusivo) es de 365 días.

Los siguientes casos de uso se habilitan mediante estas propiedades:

• Permitir que un usuario permanezca conectado a una aplicación móvil indefinidamente, siempre y cuando el usuario esté activo continuamente en la aplicación. Puede establecer la duración de la ventana deslizante del token de actualización (días) en sin expiración en el flujo de inicio de sesión del usuario.
• Cumpla los requisitos de seguridad y cumplimiento del sector estableciendo las duraciones adecuadas del token de acceso.

Esta configuración no está disponible para los flujos de usuario de restablecimiento de contraseña.

Compatibilidad

Las siguientes propiedades se usan para administrar la compatibilidad con tokens:

• Notificación del emisor (iss): esta propiedad identifica el inquilino de Azure AD B2C que emitió el token. El valor predeterminado es https://<domain>/{B2C tenant GUID}/v2.0/. El valor de https://<domain>/tfp/{B2C tenant GUID}/{Policy ID}/v2.0/ incluye las identificaciones tanto del inquilino de Azure AD B2C como del flujo de usuario usado en la solicitud de token. Si la aplicación o biblioteca necesita que Azure AD B2C sea compatible con la especificación openID Connect Discovery 1.0, use este valor.

• Notificación de asunto (sub): esta propiedad identifica la entidad para la que el token valida la información. El valor predeterminado es ObjectID, que rellena la sub notificación en el token con el identificador de objeto del usuario. El valor de No compatible solo se proporciona para la compatibilidad con versiones anteriores. Se recomienda cambiar a ObjectID tan pronto como pueda.

• Notificación que representa el identificador de directiva : esta propiedad identifica el tipo de notificación en el que se rellena el nombre de directiva usado en la solicitud de token. El valor predeterminado es tfp. El valor de acr solo se proporciona para la compatibilidad con versiones anteriores.

Paso a través

Cuando se inicia un recorrido del usuario, Azure AD B2C recibe un token de acceso de un proveedor de identidades. Azure AD B2C usa ese token para recuperar información sobre el usuario. Habilite una notificación en el flujo de usuario para pasar el token a través de las aplicaciones que registre en Azure AD B2C. La aplicación debe usar un flujo de usuario recomendado para aprovechar las ventajas de pasar el token como una notificación.

Actualmente, Azure AD B2C solo admite el paso del token de acceso de los proveedores de identidades de OAuth 2.0, que incluyen Facebook y Google. Para todos los demás proveedores de identidad, la reclamación se devuelve en blanco.

Validación

Para validar un token, la aplicación debe comprobar tanto la firma como las declaraciones del token. Muchas bibliotecas de código abierto están disponibles para validar JWT, en función del lenguaje que prefiera. Se recomienda explorar esas opciones en lugar de implementar su propia lógica de validación.

Validación de la firma

Un JWT contiene tres segmentos, un encabezado, un cuerpo y una firma. El segmento de firma se puede usar para validar la autenticidad del token para que la aplicación pueda confiar en él. Los tokens de Azure AD B2C se firman mediante algoritmos de cifrado asimétrico estándar del sector, como RSA 256.

El encabezado del token contiene información sobre la clave y el método de cifrado usados para firmar el token:

{
        "typ": "JWT",
        "alg": "RS256",
        "kid": "GvnPApfWMdLRi8PDmisFn7bprKg"
}

El valor de la afirmación alg es el algoritmo que se usó para firmar el token. El valor de la notificación kid es la clave pública que se usó para firmar el token. En cualquier momento, Azure AD B2C puede firmar un token mediante cualquiera de un conjunto de pares de claves públicas y privadas. Azure AD B2C rota los posibles conjuntos de claves periódicamente. La aplicación debe escribirse para controlar esos cambios clave automáticamente. Una frecuencia razonable para comprobar las actualizaciones de las claves públicas usadas por Azure AD B2C es cada 24 horas. Para controlar los cambios de clave inesperados, la aplicación debe estar preparada para volver a recuperar las claves públicas si recibe un valor de kid inesperado.

Azure AD B2C tiene un punto de conexión de metadatos de OpenID Connect. Con este punto de conexión, las aplicaciones pueden solicitar información sobre Azure AD B2C en tiempo de ejecución. Esta información incluye puntos de conexión, contenido de tokens y claves de firma de tokens. El tenant de Azure AD B2C contiene un documento de metadatos JSON para cada política. El documento de metadatos es un objeto JSON que contiene varios fragmentos útiles de información. Los metadatos contienen jwks_uri, que proporciona la ubicación del conjunto de claves públicas que se usan para firmar tokens. Esta ubicación se proporciona aquí, pero es mejor capturar la ubicación dinámicamente mediante el documento de metadatos y el análisis jwks_uri:

https://contoso.b2clogin.com/contoso.onmicrosoft.com/b2c_1_signupsignin1/discovery/v2.0/keys

El documento JSON ubicado en esta dirección URL contiene toda la información de clave pública que se usa en un momento determinado. La aplicación puede usar la kid declaración en el encabezado JWT para seleccionar la clave pública en el documento JSON que se usa para firmar un token determinado. A continuación, puede realizar la validación de firmas mediante la clave pública correcta y el algoritmo indicado.

El documento de metadatos de la directiva B2C_1_signupsignin1 en el inquilino contoso.onmicrosoft.com se encuentra en:

https://contoso.b2clogin.com/contoso.onmicrosoft.com/b2c_1_signupsignin1/v2.0/.well-known/openid-configuration

Para determinar qué directiva se usó para firmar un token (y dónde ir a solicitar los metadatos), tiene dos opciones. En primer lugar, el nombre de la directiva se incluye en la notificación tfp (predeterminada) o acr (según la configuración) del token. Las notificaciones se pueden analizar fuera del cuerpo del JWT; para ello, descodifique la descodificación en base 64 del cuerpo y deserialice la cadena JSON resultante. La notificación tfp o acr es el nombre de la directiva que se usó para emitir el token. La otra opción consiste en codificar la directiva en el valor del state parámetro al emitir la solicitud y, a continuación, descodificarla para determinar qué directiva se usó. Cualquiera de los métodos es válido.

Azure AD B2C usa el algoritmo RS256, que se basa en la especificación RFC 3447 . La clave pública consta de dos componentes: el módulo RSA (n) y el exponente público rsa (e). Puede convertir programáticamente los valores de n y e en un formato de certificado para la validación de tokens.

Una descripción de cómo realizar la validación de firmas está fuera del ámbito de este documento. Muchas bibliotecas de código abierto están disponibles para ayudarle a validar un token.

Validar reclamaciones

Cuando las aplicaciones o la API reciben un token de ID, también deben realizar varias comprobaciones en las reclamaciones del token de ID. Se deben comprobar las siguientes afirmaciones:

• audience: comprueba que está previsto que el token de identificador se proporcione a su aplicación.
• no antes y la hora de expiración : comprueba que el token de identificador no ha expirado.
• emisor : comprueba que Azure AD B2C emitió el token a la aplicación.
• nonce: una estrategia para mitigar los ataques de reproducción de tokens.

Para obtener una lista completa de las validaciones que debe realizar la aplicación, consulte la especificación de OpenID Connect.

Contenido relacionado

Obtenga más información sobre cómo usar tokens de acceso.