Saltar al contenido principal
Con la autenticación escalonada, las aplicaciones que permiten acceder a distintos tipos de recursos pueden requerir que los usuarios se autentiquen con un mecanismo más sólido para acceder a información confidencial o realizar determinadas transacciones. Por ejemplo, se puede permitir que un usuario acceda a vistas con datos confidenciales o restablezca su contraseña solo después de confirmar su identidad mediante (MFA). Para implementar la autenticación escalonada en su aplicación web, creará una Action que solicite al usuario autenticarse con MFA cuando la aplicación web lo requiera, comprobará las claims del para verificar MFA si el usuario intenta acceder a una página restringida y, a continuación, volverá a solicitar MFA al usuario si no está incluido en la claim.

Validar tokens de ID para MFA

Cuando un usuario inicia sesión, recibe un token de ID que contiene información relevante sobre la sesión del usuario en forma de claims. El claim relevante es amr (authentication methods reference), que es un array JSON de cadenas que indica el método de autenticación utilizado durante el inicio de sesión. Debe estar presente en la carga útil del token de ID y debe contener el valor mfa. Sus valores pueden incluir cualquiera de los Authentication Method Reference Values predefinidos. Como puede contener claims distintos de mfa, al validarlo debe comprobar tanto que exista como que su contenido incluya el valor mfa. Si un usuario intenta acceder a una página restringida y el token muestra que no se ha autenticado con MFA, puede volver a activar la autenticación, que ha configurado para activar MFA mediante una Action. Una vez que el usuario proporciona el segundo factor, se genera un nuevo token de ID que contiene el claim amr y se envía a la aplicación.
  1. Obtenga el token de ID.
  2. Verifique la firma del token, que se utiliza para comprobar que el remitente del token es quien dice ser y para asegurarse de que el mensaje no se haya modificado en tránsito.
  3. Valide los siguientes claims:
ClaimDescripción
expExpiración del token
issEmisor del token
audDestinatario previsto del token
amrSi amr no existe en la carga útil o no contiene el valor mfa, el usuario no inició sesión con MFA. Si amr existe en la carga útil y contiene el valor mfa, entonces el usuario sí inició sesión con MFA.

Excepciones del claim amr

El claim amr es obligatorio, excepto en los siguientes casos de uso:
  1. En los flujos de inicio de sesión alojados, el claim amr solo se incluye en el token de ID después de que el usuario supere correctamente una verificación de MFA. Si la aplicación usa autenticación silenciosa o Tokens de actualización para los tokens de ID recién emitidos, el claim amr no estará presente porque el usuario ya completó previamente el inicio de sesión con MFA.
  2. Los tokens emitidos por la API de MFA no contienen el claim amr. El claim amr indica los métodos de autenticación utilizados cuando el usuario recibe el ID Token. En el proceso de autenticación de la API de MFA, la aplicación controla el flujo de autenticación y puede exigir MFA según sea necesario.
En los ejemplos siguientes, puede comparar los posibles valores incluidos en la carga útil de un token de ID cuando un usuario se ha autenticado con MFA frente a cuando no lo ha hecho.

Ejemplo: valores con MFA

Ejemplo: valores sin MFA

Escenario: Datos salariales con notificaciones push

En el siguiente escenario, una aplicación web autentica a un usuario con username y contraseña. Algunos usuarios quieren acceder a una pantalla específica que muestra datos salariales, por lo que deben autenticarse con el factor de notificación push de Guardian.

Requisitos previos

Para este escenario, debe configurar los siguientes elementos en el Dashboard:

Crear una Action

Cree una Action que solicite al usuario autenticarse con MFA cuando la aplicación web lo solicite. Vaya a Dashboard > Actions > Flows y cree una Action que contenga el siguiente contenido:
exports.onExecutePostLogin = async (event, api) => {
 const CLIENTS_WITH_MFA = ['REPLACE_WITH_{yourClientId}'];
 // ejecutar solo para los clientes especificados
 if (CLIENTS_WITH_MFA.includes(event.client.client_id)) {
 // solicitar MFA solo si la aplicación web lo indicó en la solicitud de autenticación
 if (event.transaction?.acr_values.includes('http://schemas.openid.net/pape/policies/2007/06/multi-factor')) {
 api.multifactor.enable('any', { allowRememberBrowser: false });
 }
 }
}
  • La variable CLIENTS_WITH_MFA contiene los de las aplicaciones a las que quieres aplicar esta Action. Puedes eliminar esto (y la condición if que aparece a continuación) si no lo necesitas.
  • La propiedad event.transaction.acr_values es un arreglo de cadenas que contiene las referencias de clase del contexto de autenticación (acr). Es una propiedad opcional que solo existe cuando la aplicación la incluye en la solicitud de autenticación al . En este ejemplo, nuestra aplicación web la incluirá en la solicitud de autenticación, pero solo cuando un usuario que todavía no se haya autenticado con MFA intente acceder a información salarial. Cuando nuestra aplicación web la incluya, establecerá el valor http://schemas.openid.net/pape/policies/2007/06/multi-factor, lo que indica que queremos que el Servidor de autorización exija MFA, y el valor de la propiedad api.multifactor que configuramos en nuestro código pedirá al usuario que complete MFA con cualquiera de los métodos disponibles que se hayan configurado en el inquilino. Para obtener más información sobre el método api.multifactor.enable(), consulta Action Triggers: objeto API de post-login.
  • La directiva http://schemas.openid.net/pape/policies/2007/06/multi-factor define un mecanismo de autenticación en el que el usuario final se autentica ante el proveedor de proporcionando más de un factor de autenticación, o MFA. Para obtener más información, consulta OpenID Provider Authentication Policy Extension 1.0.

Configurar la aplicación

Configure la aplicación para comprobar que el usuario se haya autenticado con MFA cuando intente acceder a la página de información salarial restringida. (Cuando un usuario se autentica con MFA, los claims del token de ID contienen el claim amr con el valor mfa.) Si el usuario ya se ha autenticado con MFA, la aplicación web mostrará la página restringida; de lo contrario, la aplicación web enviará una nueva solicitud de autenticación que incluye el parámetro acr_values con el siguiente valor: http://schemas.openid.net/pape/policies/2007/06/multi-factorque activará la Action. La aplicación web de este escenario usa Flujo de Código de Autorización para autenticarse, por lo que la solicitud es la siguiente: Una vez que el usuario se autentica con MFA, la aplicación web recibe el código de autorización, que debe intercambiarse por el nuevo token de ID, que ahora debería incluir la claim amr con el valor mfa. Para obtener más información sobre cómo intercambiar el código por un token de ID, consulte Agregar inicio de sesión mediante el Flujo de Código de Autorización.

Validar token de ID

En este escenario, realice las validaciones con el código de ejemplo de JSON Web Token, que verifica la firma del token (jwt.verify), decodifica el token, comprueba si la carga útil contiene amr y, de ser así, muestra los resultados en la consola.

Más información