> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Conozca Highly Regulated Identity, la solución Financial-Grade Identity de Auth0.

# Highly Regulated Identity

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Para usar las funciones de Highly Regulated Identity, debe tener un Enterprise Plan con el complemento Highly Regulated Identity. Consulte [Auth0 Pricing](https://auth0.com/pricing/) para obtener más información.
</Callout>

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:

* [Seguridad avanzada con OpenID Connect (FAPI)](#advanced-security-with-openid-connect-fapi-)
* [Autenticación reforzada de cliente (SCA)](#strong-customer-authentication-sca-) y [vinculación dinámica](#dynamic-linking)
* [Protección de la confidencialidad y la integridad](#confidentiality-and-integrity-protection)
* [autenticación de aplicaciones más robusto](#stronger-application-authentication)
* [Protección de los tokens de acceso con Token Binding](#protect-access-tokens-with-token-binding)
* [Flujos de aprobación personalizables para mejorar la experiencia del usuario](#customizable-approval-flows-for-better-user-experience)

<div id="advanced-security-with-openid-connect-fapi">
  ## Seguridad avanzada con OpenID Connect (FAPI)
</div>

[OpenID FAPI](https://openid.net/wg/fapi/specifications/) es un conjunto de especificaciones de seguridad y privacidad desarrollado por la <Tooltip tip="OpenID: Estándar abierto de autenticación que permite a las aplicaciones verificar la identidad de los usuarios sin recopilar ni almacenar información de inicio de sesión." cta="Ver glosario" href="/es/docs/glossary?term=OpenID">OpenID</Tooltip> 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:

* [Protección de la confidencialidad y la integridad](#confidentiality-and-integrity-protection)
* [autenticación de aplicaciones más robusto](#stronger-application-authentication)
* [Protege los tokens de acceso con Token Binding](#protect-access-tokens-with-token-binding)

Para obtener más información sobre FAPI, consulta el informe técnico de OpenID [Open Banking, Open Data, and Financial-grade APIs](https://openid.net/wordpress-content/uploads/2022/03/OIDF-Whitepaper_Open-Banking-Open-Data-and-Financial-Grade-APIs_2022-03-16.pdf) y las [especificaciones del grupo de trabajo de FAPI](https://openid.net/wg/fapi/specifications/).

<Frame>
  <img src="https://mintcdn.com/translations/eVsQcTnbClN-oB7d/docs/images/cdy7uua7fh8z/20iajPMtmICMORUfaVQH7a/ec900e1007b3faebd66eb2508f46acb0/image17.png?fit=max&auto=format&n=eVsQcTnbClN-oB7d&q=85&s=97675c68c904a2d70020c10e4fdbb6a1" alt="" width="1758" height="899" data-path="docs/images/cdy7uua7fh8z/20iajPMtmICMORUfaVQH7a/ec900e1007b3faebd66eb2508f46acb0/image17.png" />
</Frame>

<div id="strong-customer-authentication-sca">
  ## Autenticación Reforzada de Cliente (SCA)
</div>

<Frame>
  <img src="https://mintcdn.com/translations/3nS3prIggmJG9TUI/docs/images/cdy7uua7fh8z/3JDIerJcevImoIDRd7OfIy/98597a9164b66cde9ec7ddc23f3e849b/image14.png?fit=max&auto=format&n=3nS3prIggmJG9TUI&q=85&s=9b73d3b3161eafbcc1e54f6e0f1c7996" alt="" width="667" height="232" data-path="docs/images/cdy7uua7fh8z/3JDIerJcevImoIDRd7OfIy/98597a9164b66cde9ec7ddc23f3e849b/image14.png" />
</Frame>

Introducida por la [Directiva de Servicios de Pago (PSD2)](https://www.europeanpaymentscouncil.eu/sites/default/files/infographic/2018-04/EPC_Infographic_PSD2_April%202018.pdf) 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](/es/docs/customize/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](/es/docs/secure/highly-regulated-identity/transactional-authorization-with-authorization-code-flow#apply-dynamic-policy).

<div id="dynamic-linking">
  ## Vinculación dinámica
</div>

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 <Tooltip tip="OAuth 2.0: Marco de autorización que define protocolos y flujos de trabajo de autorización." cta="Ver glosario" href="/es/docs/glossary?term=OAuth">OAuth</Tooltip>. 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:

```json lines theme={null}
"authorization_details": [
 {
   "type": "one_time_payment",
   "amount": {
     "amount": 2460.46,
     "currency": "USD"
   },
   "sourceAccount": "xxxxxxxxxxx4567",
   "recipient": "Acme Travel, Inc.",
   "concept": "All Inclusive Resort Package for Two",
 }
]
```

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.

<Warning>
  No pase datos detallados de autorización de la transacción ni otros datos sensibles o regulados fuera de `authorization_details`.
</Warning>

Si el usuario confirma los detalles, la transacción avanza y Auth0 emite un <Tooltip tip="Token de acceso: Credencial de autorización, en forma de una cadena opaca o un JWT, utilizada para acceder a una API." cta="Ver glosario" href="/es/docs/glossary?term=access+token">token de acceso</Tooltip> 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](/es/docs/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-rar).

<div id="confidentiality-and-integrity-protection">
  ## Protección de la confidencialidad y la integridad
</div>

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.

<div id="protect-sensitive-data-in-the-front-channel">
  ### Proteja los datos confidenciales en el front channel
</div>

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.

<div id="pushed-authorization-requests-par">
  #### Solicitudes de autorización enviadas (PAR)
</div>

[PAR](https://datatracker.ietf.org/doc/rfc9126/) 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 <Tooltip tip="Servidor de autorización: Servidor centralizado que contribuye a definir los límites del acceso de un usuario. Por ejemplo, su servidor de autorización puede controlar los datos, las tareas y las funcionalidades disponibles para un usuario." cta="Ver glosario" href="/es/docs/glossary?term=authorization+server">servidor de autorización</Tooltip> (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)](/es/docs/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-par) y [Configurar solicitudes de autorización enviadas (PAR)](/es/docs/get-started/applications/configure-par).

<div id="jwt-secured-authorization-request-jar">
  #### Solicitud de autorización protegida con JWT (JAR)
</div>

[JAR](https://datatracker.ietf.org/doc/rfc9101/) es una extensión del protocolo OAuth2 que mejora la seguridad de las solicitudes de autorización. Para ello, utiliza un parámetro de solicitud <Tooltip tip="JSON Web Token (JWT): formato estándar de ID Token (y, a menudo, de Token de acceso) que se utiliza para representar claims de forma segura entre dos partes." cta="Ver glosario" href="/es/docs/glossary?term=JSON+Web+Token">JSON Web Token</Tooltip> (JWT) para proteger la integridad y, de forma opcional, la confidencialidad de los parámetros de la solicitud de autorización.

Para obtener más información sobre JAR, consulte [Authorization Code Flow with JWT-Secured Authorization Requests (JAR)](/es/docs/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-jar) y [Configure JWT-Secured Authorization Requests (JAR)](/es/docs/get-started/applications/configure-jar).

<div id="protect-sensitive-data-in-access-tokens">
  #### Proteja los datos sensibles en los tokens de acceso
</div>

Para proteger los detalles de autorización incluida en los tokens de acceso, Highly Regulated Identity admite el uso de [JSON Web Encryption (JWE)](https://datatracker.ietf.org/doc/html/rfc7516) 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](/es/docs/secure/tokens/access-tokens/json-web-encryption) y [Configurar JSON Web Encryption](/es/docs/get-started/apis/configure-json-web-encryption).

<div id="stronger-application-authentication">
  ## Autenticación de aplicaciones más robusta
</div>

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](http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer): 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](/es/docs/secure/application-credentials#private-key-jwt-authentication).
* [mTLS para OAuth](https://datatracker.ietf.org/doc/html/rfc8705): 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](/es/docs/get-started/authentication-and-authorization-flow/authenticate-with-mtls).

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.

<div id="protect-access-tokens-with-token-binding">
  ## Proteja los tokens de acceso con Token Binding
</div>

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](/es/docs/secure/sender-constraining/configure-sender-constraining).

<div id="customizable-approval-flows-for-better-user-experience">
  ## Flujos de aprobación personalizables para mejorar la experiencia del usuario
</div>

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](/es/docs/customize/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](/es/docs/secure/highly-regulated-identity/transactional-authorization-with-authorization-code-flow#apply-dynamic-policy).

Las nuevas plantillas de <Tooltip tip="Universal Login: su aplicación redirige a Universal Login, alojado en el Servidor de autorización de Auth0, para verificar la identidad de un usuario." cta="Ver glosario" href="/es/docs/glossary?term=Universal+Login">Universal Login</Tooltip> 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)](/es/docs/get-started/apis/configure-rich-authorization-requests).

<div id="learn-more">
  ## Más información
</div>

Para obtener información sobre cómo funciona Highly Regulated Identity de principio a fin para autorizar una transacción única, lea [Autorización transaccional con flujo de código de autorización](/es/docs/secure/highly-regulated-identity/transactional-authorization-with-authorization-code-flow).