Autorización transaccional con el Flujo de código de autorización

Obtén información sobre cómo Highly Regulated Identity permite la autorización transaccional con el Flujo de código de autorización.

Highly Regulated Identity permite la autorización transaccional con el Flujo de código de autorización al aplicar una autenticación multifactor (MFA) reforzada para autorizar una transacción. La MFA reforzada solicita al usuario un segundo factor de autenticación para autorizar explícitamente los detalles de la transacción de una operación puntual, lo que resulta útil en casos de uso que requieren seguridad de nivel financiero:

• Proteger operaciones sensibles realizadas desde tus propios servicios, como aprobar transferencias bancarias, acceder al historial de operaciones y cambiar las credenciales de acceso.
• Proteger operaciones sensibles solicitadas desde servicios de terceros, como aprobar pagos digitales y permitir acceso por única vez para la verificación de cuentas.

Este artículo te guía por todo el proceso de aprobación de una transferencia bancaria. El mismo flujo de autorización transaccional se puede aplicar a otros casos de uso.

Debes configurar la autorización transaccional para cada API. Una vez activada, se aplica a los alcances y a authorization_details.types de esa API.

​

Requisitos previos

No transfiera datos detallados de autorización de la transacción ni otros datos sensibles o regulados fuera de authorization_details.

Antes de comenzar, siga las instrucciones de Configurar solicitudes de autorización enriquecidas para registrar authorization_details.types para su API o Resource Server.

​

Flujo de principio a fin

El siguiente diagrama muestra el flujo de principio a fin de la autorización transaccional con SCA contextual. Hay cuatro fases principales:

1. Redirija de forma segura al usuario a Auth0 con los detalles de la transacción. En este paso, evite revelar información confidencial en el canal frontal (por ejemplo, el navegador).
2. Aplique una política dinámica después de que el usuario se autentique. Con Actions, puede decidir dinámicamente los siguientes pasos en función de los detalles de la transacción y de otra información que pueda obtener de fuentes como API externas. Para obtener más información, consulte Aplicar una política dinámica.
3. Solicite al usuario un segundo factor de autenticación y muestre los detalles de la transacción para que los apruebe explícitamente. Este paso depende del factor de autenticación que haya elegido aplicar mediante Actions.
4. Obtenga el token de acceso y continúe con la operación confidencial. Su API valida los detalles de la transacción aprobados asociados al token de acceso.

A continuación, veremos cada fase en detalle en las secciones siguientes.

​

Comunicar los detalles de la transacción y redirigir a Auth0

El usuario accede por primera vez a su aplicación web después de autenticarse con Auth0. Siguiendo nuestro caso de uso de ejemplo, el usuario solicita luego una transferencia de dinero a uno de sus contactos.

Para cumplir con los estándares de seguridad de nivel financiero, Highly Regulated Identity utiliza Pushed Authorization Requests (PAR) para ocultar los detalles de la transacción al navegador. En lugar de enviar parámetros de consulta a través del navegador al endpoint /authorize, PAR envía los parámetros directamente desde el backend a un endpoint especial, /par, mediante una solicitud POST. Para obtener información sobre cómo configurarlo, consulte Configure Pushed Authorization Requests.

En el cuerpo de la solicitud PAR, los detalles de la transacción se envían como parte del objeto JSON authorization_details:

"authorization_details": [
 {
   "type": "money_transfer",
   "instructedAmount": {
     "amount": 150,
     "currency": "USD"
   },
   "sourceAccount": "xxxxxxxxxxx1234",
   "destinationAccount": "xxxxxxxxxxx9876",
   "beneficiary": "Hanna Herwitz",
   "subject": "A Lannister Always Pays His Debts"
 }
]

Usa Actions para inspeccionar authorization_details y determinar qué factores de autenticación usar según la transacción. Para obtener más información sobre authorization_details y cómo usarlo junto con PAR, consulta Flujo de código de autorización con solicitudes de autorización enriquecidas.

Si quieres cumplir los requisitos de conformidad de FAPI 1 Advanced Security, también debes usar criptografía de clave pública para autenticar el backend ante el endpoint /par o /token. Esto es más seguro que enviar un Secreto del cliente. Auth0 ofrece los siguientes métodos de autenticación con criptografía de clave pública:

• Private Key JWT
• TLS mutuo (mTLS) para OAuth

Después de recibir una respuesta satisfactoria a tu solicitud PAR, redirige al usuario al endpoint /authorize de tu inquilino de Auth0. Agrega el parámetro request_uri recibido en la respuesta PAR y client_id como los únicos parámetros de consulta, lo que oculta de forma efectiva cualquier información confidencial del navegador.

​

Aplicar una política dinámica

Cuando el usuario inicia sesión sin usar SSO y el navegador accede al endpoint /authorize de tu inquilino de Auth0, Auth0 intentará autenticar al usuario. En nuestro ejemplo de aprobación de una transferencia bancaria, Auth0 ya ha autenticado al usuario para que acceda a tu aplicación web. Sin embargo, cuando un tercero redirige al usuario, por ejemplo, para realizar un pago digital, Auth0 le muestra una pantalla de inicio de sesión. Para obtener más información sobre el flujo de autenticación, consulta la documentación de Authenticate.

Una vez que Auth0 haya autenticado correctamente al usuario, ejecuta las Actions posteriores al inicio de sesión, que exponen detalles de la transacción, como información sobre el usuario, la aplicación, los factores de autenticación utilizados y más, en el objeto de evento post-login. Dentro del objeto de evento post-login, la propiedad event.transaction.requested_authorization_details contiene detalles sobre la solicitud de autorización recibida en el paso anterior.

Usa el objeto de evento post-login para decidir cómo quieres proceder con la transacción. Por ejemplo, puedes enviar los detalles de la transacción a un motor de riesgo externo y, después de evaluar el nivel de riesgo, determinar si debes solicitar autenticación reforzada mediante SMS, como se muestra en el siguiente ejemplo de código.

exports.onExecutePostLogin = async (event, api) => {
  if (event.transaction?.requested_authorization_details.some(e => e.type === 'money_transfer')) {
      const axios = require('axios');

      //detalles para contactar el motor de evaluación de riesgos
      const risk_url = 'https://risk.example.org/score';
      const risk_options = {
        headers: {
          'Content-Type': 'application/json'
        }
      };

      const tx_data = {
        email: event.user.email,
        authorization_details: event.transaction?.requested_authorization_details
      };

      //enviar detalles de la operación al motor de evaluación de riesgos
      var risk = await axios.post(risk_url, tx_data, risk_options);

      //si es una operación de riesgo, usar push para autorizar
      if (risk.data.score >= 2) {
        api.authentication.challengeWith({ type: 'push-notification', options: {otpFallback: false}});

      }
    }
};

​

Desafíe al usuario para que apruebe los detalles de la transacción

Puede personalizar qué factor de autenticación usar en función de los factores que el usuario tenga inscritos, los factores ya satisfechos por la sesión y/o sus propias preferencias. También puede ofrecer alternativas para que el usuario elija. Para obtener más información, lea Personalizar la selección de MFA en New Universal Login.

Además, para SMS, correo electrónico y WebAuthn, puede personalizar la pantalla de consentimiento que Auth0 presenta al usuario con la información que quiera mostrar de authorization_details y otros detalles de la transacción. Para obtener más información, lea Configurar solicitudes de autorización enriquecidas. En el caso de las notificaciones push, esto no se aplica, ya que la aplicación móvil es la que muestra los detalles de la transacción al usuario final.

Las siguientes secciones explican los distintos factores de autenticación que puede configurar para la autorización transaccional.

​

Notificaciones push

Envía una notificación push al dispositivo móvil inscrito de un usuario mientras Auth0 le muestra la pantalla de espera de autenticación multifactor (MFA) en el dispositivo de consumo (por ejemplo, el portátil donde se originó la transacción).

En el caso de las notificaciones push, la aplicación móvil es responsable de mostrar al usuario los detalles de la transacción para que la apruebe de forma explícita. Al enviar una notificación push, puedes deshabilitar la opción de recurrir al ingreso manual de un OTP agregando la opción otpFallback: false.

Para mostrar authorization_details al usuario, la aplicación móvil debe recuperarlos del parámetro txlnkid. El SDK de Auth0 Guardian pasa el parámetro txlnkid del inquilino a la aplicación móvil mediante una notificación push.

Después de que la aplicación móvil reciba la notificación push a través del SDK de Guardian, puede obtener los detalles de consentimiento, que incluyen authorization_details, desde la API de Consent de Auth0:

iOS

let device: AuthenticationDevice = // el objeto que obtuviste al inscribirte
if let consentId = notification.transactionLinkingId {
    Guardian
        .consent(forDomain: {yourTenantDomain}, device: device)
        .fetch(consentId: consentId, notificationToken: notification.transactionToken)
        .start{result in
            switch result {
            case .success(let payload):
                let authorizationDetails = payload.requestedDetails.authorizationDetails
            case .failure(let cause):
                // algo salió mal
        }
    }
}

Android

if (notification.getTransctionLinkingId() != null) {
    guardian
      .fetchConsent(notification, enrollment)
      .start(new Callback<Enrollment> {
        @Override
        void onSuccess(RichConsent consentDetails) {
          List<Map<String, Object>> authorizationDetails = consentDetails
                .getRequestedDetails()
                .getAuthorizationDetails();
        }

        @Override
        void onFailure(Throwable exception) {
          if (exception instanceof GuardianException) {
            GuardianException guardianException = (GuardianException) exception;
            if (guardianException.isResourceNotFound()) {
              // no hay ningún consentimiento asociado con la transacción
            }
          }
          // algo salió mal
        }
      });
}

Desde la Action de post-login, puedes llamar a api.multifactor.enable() antes de api.authentication.challengeWith() para quitar la opción de recordar este dispositivo y obligar al usuario a validar el desafío push en todas las transacciones. Para obtener más información, consulta Desencadenadores de Action: post-login - objeto de API.

Una vez que el usuario apruebe o rechace la operación, la aplicación móvil puede aprobar o rechazar el desafío de MFA. La transacción avanza a la fase de Completar la operación.

Para verificar la identidad del usuario que abre la notificación push, puedes agregar autenticación biométrica a la aplicación móvil. Para obtener más información, consulta Configurar WebAuthn con Device Biometrics para MFA.

​

SMS, correo electrónico o WebAuthn

También puedes configurar el teléfono, el correo electrónico o WebAuthn como factores de autenticación para desafiar al usuario. Para estos factores de autenticación, Auth0 muestra al usuario la pantalla de espera de MFA correspondiente. Después de que el usuario valida el desafío en la pantalla de espera de MFA, Auth0 le muestra los detalles de la transacción para su aprobación explícita. Recuerda que debes configurar solicitudes de autorización enriquecidas para que el paso de aprobación funcione correctamente.

Para el factor de autenticación por teléfono, Auth0 envía un código de verificación al usuario por SMS o llamada de voz. La siguiente captura de pantalla muestra la pantalla de espera de MFA después de que Auth0 enviara el código por SMS:

Desde Actions, puedes llamar a api.multifactor.enable('any', { allowRememberBrowser: false }) antes de api.authentication.challengeWith para quitar la opción de recordar este dispositivo y obligar al usuario a validar el desafío push en todas las transacciones.

A continuación, el usuario recibe el SMS con el código de verificación.

Después de que el usuario introduce el código de verificación en la pantalla de espera de MFA, Auth0 le muestra los detalles de la transacción en una pantalla de consentimiento. Una vez que el usuario aprueba o rechaza los detalles de la transacción, la transacción pasa a la fase Completar la operación.

El correo electrónico y WebAuthn usan el mismo flujo de aprobación de transacciones y pantallas similares de espera de MFA y aprobación explícita.

Según PSD2, el correo electrónico no es un factor de autenticación válido para la autenticación reforzada de clientes. Te recomendamos usar otro factor de autenticación para desafiar a los usuarios y cumplir con PSD2.

​

Sin desafío

Si no se somete al usuario a un segundo factor de autenticación, Auth0 le muestra la pantalla de consentimiento para obtener su aprobación explícita de los detalles de la transacción.

​

Completa la operación

Para completar la operación, Auth0 utiliza el estándar Flujo de código de autorización. Si se aprueba la transacción, el navegador del usuario se redirige a tu aplicación con un código de autorización, que luego se intercambia por un token de acceso cifrado mediante JSON Web Encryption. El token de acceso contiene los authorization_details que enviaste originalmente. El siguiente ejemplo de código muestra el contenido de un token de acceso descifrado:

{
 "iss": "https://my_tenant.auth0.com/",
 "sub": "auth0|me",
 "aud": "https://myapi.zewobnak.com",
 "iat": 1683661385,
 "exp": 1683747785,
 "azp": "my_client",
 "transaction_linking_id": "ce4842e8-2894-418a-b1f9-39a330cd4911",
 "authorization_details": [
   {
     "type": "money_transfer",
     "instructedAmount": {
       "amount": 150,
       "currency": "USD"
     },
     "sourceAccount": "xxxxxxxxxxx1234",
     "destinationAccount": "xxxxxxxxxxx9876",
     "beneficiary": "Hanna Herwitz",
     "subject": "A Lannister Always Pays His Debts",
   }
 ]
}

Pase el token de acceso a la API que facilita la transferencia de dinero. A continuación, la API comprueba authorization_details del token de acceso para verificar los detalles de la transacción, como el importe, el remitente, el destino, entre otros. Una vez verificados, la transferencia de dinero se ejecuta correctamente y debería ver la pantalla de aprobación.

Si la transacción se rechaza en cualquier paso, el navegador del usuario muestra el código de error access_denied.