Conozca Highly Regulated Identity, la solución Financial-Grade Identity de Auth0.
Para usar las funciones de Highly Regulated Identity, debe tener un Enterprise Plan con el complemento Highly Regulated Identity. Consulte Auth0 Pricing para obtener más información.
Highly Regulated Identity (HRI) es la solución Financial-Grade Identity™ de Auth0 para proteger operaciones con datos sensibles y servicios importantes para su empresa. Dirigida inicialmente a sectores altamente regulados, como finanzas y salud, Highly Regulated Identity eleva el nivel de seguridad para proteger una amplia variedad de casos de uso de los clientes, incluidos, entre otros, transferencias de dinero, pagos digitales y acceso a historiales médicos. También puede usar Highly Regulated Identity para otras operaciones sensibles que requieren seguridad reforzada, como aprobar cambios en credenciales administrativas, proteger el acceso privilegiado a un portal web y más.Para proteger las operaciones sensibles de su empresa, Highly Regulated Identity ofrece:
OpenID FAPI es un conjunto de especificaciones de seguridad y privacidad desarrollado por la Foundation. Las API que cumplen los estándares FAPI se clasifican como «de nivel financiero», lo que significa que ofrecen mecanismos robustos de autenticación y autorización que ayudan a proteger el acceso a datos y servicios financieros, así como a otros datos y servicios sensibles.Auth0 es un proveedor FAPI certificado. Para obtener más información sobre las mejoras de seguridad que incorporamos para cumplir los estándares FAPI, consulta las siguientes secciones:
Introducida por la Directiva de Servicios de Pago (PSD2) de la Unión Europea, la Autenticación Reforzada de Cliente (SCA) exige el uso de al menos dos factores de autenticación distintos de los tres siguientes:
Algo que el usuario sabe (por ejemplo, una contraseña)
Algo que el usuario posee (por ejemplo, un dispositivo)
Algo inherente al usuario (por ejemplo, una huella dactilar)
Los factores de autenticación deben ser independientes, de modo que si uno se ve comprometido, no ponga en riesgo a los demás. La SCA se está convirtiendo rápidamente en el estándar mundial para proteger datos y servicios sensibles.Para ayudarle a cumplir con la SCA, Auth0 ofrece varios factores de autenticación que permiten inscribir a los usuarios y plantear desafíos durante una transacción de inicio de sesión. Highly Regulated Identity aprovecha los siguientes factores de autenticación para proteger sus transacciones:
Notificaciones push móviles
SMS
Correo electrónico
WebAuthn
Con Actions, puede determinar dinámicamente qué factores de autenticación usar. Esto le brinda la flexibilidad de personalizar la lógica de su código. Por ejemplo, puede agregar un segundo factor de autenticación para pagos superiores a 10 USD. Para obtener más información, consulte Aplicar una política dinámica.
La PSD2 exige que los proveedores de servicios de pago implementen la vinculación dinámica junto con la autenticación reforzada de cliente. La vinculación dinámica presenta al usuario los detalles de la transacción para su validación y aprobación explícitas, y vincula de forma unívoca la autorización con los detalles de la transacción. Esto garantiza una buena experiencia de usuario y ayuda a cumplir los requisitos normativos.Para habilitar la vinculación dinámica, puede usar Rich Authorization Requests (RAR) para pasar datos detallados de autorización de la transacción al endpoint de autorización de . El siguiente ejemplo de código muestra un objeto JSON authorization_details, que contiene información como el tipo de pago, el importe, la divisa y el destinatario:
A authorization_details se le asigna una referencia de transacción única, que Auth0 utiliza para pedir al usuario que realice una autenticación reforzada:
Use notificaciones push para mostrar los detalles de la transacción y obtener la aprobación en un dispositivo distinto, como una aplicación de teléfono móvil.
Use SMS, correo electrónico o WebAuthn para confirmar los detalles en el dispositivo que originó la transacción, después de que el usuario complete el segundo factor de autenticación.
No pase datos detallados de autorización de la transacción ni otros datos sensibles o regulados fuera de authorization_details.
Si el usuario confirma los detalles, la transacción avanza y Auth0 emite un asociado con el authorization_details ya aprobado. Los desarrolladores también pueden agregar la referencia de transacción única al token de acceso. Como resultado, sus servidores API podrán validar más adelante los detalles de la transacción aprobada al recibir y procesar solicitudes de API.Para obtener más información sobre RAR, lea Authorization Code Flow with Rich Authorization Requests.
Los detalles de autorización pueden incluir números de cuenta, importes monetarios, nombres de comercios y otra información muy sensible que se transmite en URL o tokens de acceso no seguros. Para proteger los datos sensibles frente al acceso no autorizado y la manipulación, Highly Regulated Identity ofrece una protección integral de la confidencialidad y la integridad.
Proteja los datos confidenciales en el front channel
Para proteger los datos confidenciales en el front channel, como un navegador web, Highly Regulated Identity ofrece las siguientes soluciones como parte del perfil de seguridad avanzado FAPI 1.
PAR introduce un nuevo endpoint que permite a los clientes enviar directamente la carga útil de una solicitud de autorización de OAuth 2.0 al (es decir, Auth0 en este caso). Esto evita pasar los parámetros de autorización por el front channel no seguro (es decir, el navegador), lo que reduce el riesgo de que un intermediario acceda sin autorización a esos parámetros.Para obtener más información sobre PAR, consulte Flujo de código de autorización con solicitudes de autorización enviadas (PAR) y Configurar solicitudes de autorización enviadas (PAR).
Proteja los datos sensibles en los tokens de acceso
Para proteger los detalles de autorización incluida en los tokens de acceso, Highly Regulated Identity admite el uso de JSON Web Encryption (JWE) para cifrar la carga útil de los tokens de acceso. Esto protege los tokens de acceso ante filtraciones de datos del lado de la aplicación y frente a la inspección no autorizada de las llamadas a la API por parte de intermediarios.Para obtener más información sobre JWE, consulte JSON Web Encryption y Configurar JSON Web Encryption.
Para mejorar la seguridad de autenticación de su aplicación, Highly Regulated Identity ofrece dos alternativas como parte del perfil de seguridad FAPI 1 Advanced Security:
Private Key JWT: requiere generar un par de claves pública y privada para usarlo como credencial con la que autenticar una aplicación. Ya está disponible para los clientes del plan Enterprise. Para obtener más información, consulte Autenticación con Private Key JWT.
mTLS para OAuth: requiere registrar un certificado X.509 estándar vinculado a una aplicación en su inquilino. El certificado puede estar emitido por una CA o ser autofirmado. Siguiendo los procedimientos estándar de mTLS, la clave privada correspondiente al certificado se usa del lado del cliente para establecer el túnel mTLS al enviar solicitudes a los endpoints de su inquilino de Auth0. Como resultado, Auth0 puede autenticar la aplicación sin transmitir secretos por la red. Para obtener más información, consulte mTLS para OAuth.
Con Private Key JWT y OAuth 2.0 mTLS, puede rotar credenciales sin tiempo de inactividad manteniendo temporalmente dos claves y/o certificados activos al mismo tiempo para una aplicación determinada.
La compatibilidad con mTLS también permite usar Token Binding o Sender Constraining. Token Binding asocia la huella digital del certificado de cliente utilizado para establecer el túnel mTLS con un token de acceso. Cuando el cliente consume una API mediante el token de acceso vinculado al certificado, el servidor de la API puede verificar si el cliente también está usando el certificado de cliente asociado. Como resultado, incluso si el token de acceso se ve comprometido, los actores maliciosos que no conocen el certificado de cliente siguen sin poder acceder a los recursos protegidos.Nota: Token Binding funciona de forma independiente del método de autenticación de la aplicación y no requiere el registro previo del certificado de cliente. Para obtener más información, lea Configurar Sender Constraining.
Flujos de aprobación personalizables para mejorar la experiencia del usuario
Al diseñar soluciones del mundo real con seguridad de grado financiero, es importante tener en cuenta la experiencia del usuario. Aplicar el mismo flujo de autenticación a todas las transacciones no es tan eficaz como ajustarlo dinámicamente según los detalles de la transacción y los casos de uso.Puede personalizar su flujo de autenticación con Actions. Por ejemplo, después de que el usuario inicie sesión, puede inspeccionar los detalles de la transacción recibidos mediante RAR, enumerar los factores de autenticación del usuario que ya están inscritos y validados, y usar servicios externos, como motores de evaluación de riesgos, para determinar cuál es el siguiente factor de autenticación que debe utilizarse. Para obtener más información, lea Aplicar una política dinámica.Las nuevas plantillas de también le permiten personalizar los atributos que se muestran en la pantalla de aprobación de la transacción según el tipo de transacción y otros detalles de autorización. Para obtener más información, lea Configurar Rich Authorization Requests (RAR).
Autenticar
Administrar usuarios
Personalizar
Auth0 AI
Plataforma
