> ## 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.

> Conoce los distintos flujos que se utilizan para la autenticación y autorización de aplicaciones y APIs.

# Flujos de autenticación y autorización

Auth0 usa el [protocolo OpenID Connect (OIDC)](/es/docs/authenticate/protocols/openid-connect-protocol) y el [framework de autorización OAuth 2.0](/es/docs/authenticate/protocols/oauth) para autenticar usuarios y obtener su autorización para acceder a recursos protegidos. Con Auth0, puedes admitir fácilmente distintos flujos en tus propias aplicaciones y APIs sin preocuparte por las especificaciones de OIDC/<Tooltip tip="OAuth 2.0: Framework de autorización que define protocolos y flujos de trabajo de autorización." cta="Ver glosario" href="/es/docs/glossary?term=OAuth+2.0">OAuth 2.0</Tooltip> ni por otros aspectos técnicos de la [autenticación y la autorización](/es/docs/get-started/identity-fundamentals/authentication-and-authorization).

Admitimos escenarios para aplicaciones del lado del servidor, móviles, de escritorio, del lado del cliente, de máquina a máquina y de dispositivos.

Si no estás seguro de qué flujo usar, podemos ayudarte a decidir. Para obtener más información, lee [¿Qué flujo de OAuth 2.0 debo usar?](/es/docs/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use).

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Durante la ejecución de varios flujos, tu aplicación también debe autenticarse ante el Servidor de autorización. Para obtener más información sobre la autenticación de aplicaciones, lee [Credenciales de la aplicación](/es/docs/secure/application-credentials).
</Callout>

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Según las políticas de acceso a APIs que configures para una API en la aplicación, es posible que debas crear los client grants correspondientes para tu aplicación. Para obtener más información, lee [Acceso de aplicaciones a APIs: políticas y client grants](/es/docs/get-started/applications/application-access-to-apis-client-grants).
</Callout>

<div id="authorization-code-flow">
  ## Flujo de código de autorización
</div>

Dado que las aplicaciones web tradicionales son aplicaciones del lado del servidor, en las que el código fuente no está expuesto públicamente, pueden usar el flujo de código de autorización, mediante el cual se intercambia un código de autorización por un token.

* [Flujo de código de autorización](/es/docs/get-started/authentication-and-authorization-flow/authorization-code-flow)
* [Agregar el inicio de sesión mediante el flujo de código de autorización](/es/docs/get-started/authentication-and-authorization-flow/authorization-code-flow/add-login-auth-code-flow)
* [Llamar a una API mediante el flujo de código de autorización](/es/docs/get-started/authentication-and-authorization-flow/authorization-code-flow/call-your-api-using-the-authorization-code-flow)

<div id="authorization-code-flow-with-proof-key-for-code-exchange-pkce">
  ## flujo de código de autorización with Proof Key for Code Exchange (PKCE)
</div>

Durante la autenticación, las aplicaciones móviles y nativas pueden usar el flujo de código de autorización, pero requieren medidas de seguridad adicionales. Además, las aplicaciones de página única presentan retos particulares. Para mitigarlos, OAuth 2.0 ofrece una versión del flujo de código de autorización que utiliza Proof Key for Code Exchange (PKCE).

* [flujo de código de autorización with Proof Key for Code Exchange (PKCE)](/es/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce)
* [Agregar inicio de sesión con flujo de código de autorización with PKCE](/es/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce/add-login-using-the-authorization-code-flow-with-pkce)
* [Llamar a una API con flujo de código de autorización with PKCE](/es/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce/call-your-api-using-the-authorization-code-flow-with-pkce)

<div id="authorization-code-flow-with-enhanced-privacy-protection">
  ## Flujo de código de autorización con protección reforzada de la privacidad
</div>

Durante el proceso de autenticación y autorización, algunos casos de uso, como la [autorización transaccional](/es/docs/secure/highly-regulated-identity/transactional-authorization-with-authorization-code-flow), intercambian información contextual que puede contener datos sensibles. Para proteger los datos y otra información confidencial, puede usar distintas mejoras del protocolo para el flujo de código de autorización:

* [Authorization Code Flow with Rich Authorization Requests (RAR)](/es/docs/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-rar)
* [Authorization Code Flow with Pushed Authorization Requests (PAR)](/es/docs/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-par)
* [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)
* [JSON Web Encryption (JWE)](/es/docs/secure/tokens/access-tokens/json-web-encryption)

<div id="implicit-flow-with-form-post">
  ## Flujo implícito con Form Post
</div>

Como alternativa al flujo de código de autorización, OAuth 2.0 ofrece el flujo implícito, pensado para <Tooltip tip="Cliente público: cliente (aplicación) que no puede almacenar credenciales de forma segura. Algunos ejemplos incluyen una aplicación nativa de escritorio o móvil y una aplicación web del lado del cliente basada en JavaScript (como una aplicación de una sola página (SPA))." cta="Ver glosario" href="/es/docs/glossary?term=Public+Clients">clientes públicos</Tooltip> o aplicaciones que no pueden almacenar de forma segura <Tooltip tip="Cliente público: cliente (aplicación) que no puede almacenar credenciales de forma segura. Algunos ejemplos incluyen una aplicación nativa de escritorio o móvil y una aplicación web del lado del cliente basada en JavaScript (como una aplicación de una sola página (SPA))." cta="Ver glosario" href="/es/docs/glossary?term=Client+Secrets">secretos del cliente</Tooltip>. Si bien ya no se considera una práctica recomendada para solicitar <Tooltip tip="Token de acceso: credencial de autorización, en forma de cadena opaca o JWT, que se utiliza para acceder a una API." cta="Ver glosario" href="/es/docs/glossary?term=Access+Tokens">Tokens de acceso</Tooltip>, al usarlo con el modo de respuesta Form Post sí ofrece un flujo de trabajo más ágil si la aplicación solo necesita un <Tooltip tip="Token de ID: credencial destinada al propio cliente, en lugar de para acceder a un recurso." cta="Ver glosario" href="/es/docs/glossary?term=ID+token">token de ID</Tooltip> para autenticar al usuario.

* [Flujo implícito con Form Post](/es/docs/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post)
* [Agregar el inicio de sesión mediante el flujo implícito con Form Post](/es/docs/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post/add-login-using-the-implicit-flow-with-form-post)
* [Autenticar SPAs con cookies](/es/docs/manage-users/cookies/spa-authenticate-with-cookies)

<div id="hybrid-flow">
  ## Flujo híbrido
</div>

Las aplicaciones que pueden almacenar de forma segura el Secreto del cliente pueden beneficiarse del uso del Flujo híbrido, que combina características del flujo de código de autorización y del flujo implícito con Form Post para permitir que su aplicación tenga acceso inmediato a un token de ID, al tiempo que posibilita la obtención segura de tokens de acceso y <Tooltip tip="Token de actualización: token que se usa para obtener un Token de acceso renovado sin obligar a los usuarios a volver a iniciar sesión." cta="Ver glosario" href="/es/docs/glossary?term=refresh+tokens">tokens de actualización</Tooltip>. Esto puede ser útil en situaciones en las que su aplicación necesita acceder de inmediato a información sobre el usuario, pero debe realizar cierto procesamiento antes de obtener acceso a recursos protegidos durante un período prolongado.

* [Flujo híbrido](/es/docs/get-started/authentication-and-authorization-flow/hybrid-flow)
* [Llamar a una API mediante el flujo híbrido](/es/docs/get-started/authentication-and-authorization-flow/hybrid-flow/call-api-hybrid-flow)

<div id="client-credentials-flow">
  ## Flujo de credenciales del cliente
</div>

Con las aplicaciones de máquina a máquina (M2M), como CLI, demonios o servicios que se ejecutan en el backend, el sistema autentica y autoriza la aplicación en lugar de a un usuario. En este escenario, los esquemas de autenticación típicos, como identificador + contraseña o los inicios de sesión mediante redes sociales, no tienen sentido. En su lugar, las aplicaciones M2M usan el flujo de credenciales del cliente (definido en OAuth 2.0 RFC 6749, sección 4.4).

* [Flujo de credenciales del cliente](/es/docs/get-started/authentication-and-authorization-flow/client-credentials-flow)
* [Llamar a una API con el flujo de credenciales del cliente](/es/docs/get-started/authentication-and-authorization-flow/client-credentials-flow/call-your-api-using-the-client-credentials-flow)

<div id="device-authorization-flow">
  ## Flujo de autorización de dispositivos
</div>

En los dispositivos con capacidades de entrada limitadas que se conectan a internet, en lugar de autenticar directamente al usuario, el dispositivo le pide que acceda a un enlace desde su computadora o smartphone y autorice el dispositivo. Esto evita una mala experiencia de usuario en dispositivos que no tienen una forma sencilla de introducir texto. Para ello, las aplicaciones para dispositivos usan el <Tooltip tip="Flujo de autorización: concesión de autorización (o flujo de trabajo) especificada en el marco de OAuth 2.0." cta="Ver glosario" href="/es/docs/glossary?term=Authorization+Flow">flujo de autorización</Tooltip> de dispositivos (definido en OAuth 2.0). Para aplicaciones móviles/nativas.

* [Flujo de autorización de dispositivos](/es/docs/get-started/authentication-and-authorization-flow/device-authorization-flow)
* [Llamar a una API mediante el flujo de autorización de dispositivos](/es/docs/get-started/authentication-and-authorization-flow/device-authorization-flow/call-your-api-using-the-device-authorization-flow)

<div id="resource-owner-password-flow">
  ## Flujo de contraseña del propietario del recurso
</div>

Aunque no lo recomendamos, las aplicaciones de alta confianza pueden usar el flujo de contraseña del <Tooltip tip="Propietario del recurso: entidad (como un usuario o una aplicación) capaz de otorgar acceso a un recurso protegido." cta="Ver glosario" href="/es/docs/glossary?term=Resource+Owner">propietario del recurso</Tooltip>, que solicita a los usuarios que proporcionen credenciales (identificador y contraseña), normalmente mediante un formulario interactivo. El flujo de contraseña del propietario del recurso solo debe usarse cuando no se pueden usar flujos basados en redirección (como el [flujo de código de autorización](/es/docs/get-started/authentication-and-authorization-flow/authorization-code-flow)).

* [Flujo de contraseña del propietario del recurso](/es/docs/get-started/authentication-and-authorization-flow/resource-owner-password-flow)
* [Llamar a la API mediante el flujo de contraseña del propietario del recurso](/es/docs/get-started/authentication-and-authorization-flow/resource-owner-password-flow/call-your-api-using-resource-owner-password-flow)

<div id="client-initiated-backchannel-authentication-flow">
  ## Flujo de autenticación de backchannel iniciado por el cliente
</div>

Con el flujo de autenticación de backchannel iniciado por el cliente (CIBA), en lugar de autenticar directamente al usuario, el backend de la aplicación cliente inicia un flujo de autenticación para pedirle al usuario que se autentique. La autenticación en sí se realiza en un dispositivo de autenticación independiente, normalmente un teléfono inteligente que ejecuta una aplicación personalizada.

* [Flujo de autenticación de backchannel iniciado por el cliente](/es/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow)
* [Autenticación del usuario con CIBA](/es/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/user-authentication-with-ciba)
* [Autorización del usuario con CIBA](/es/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/user-authorization-with-ciba)

<div id="custom-token-exchange">
  ## Custom Token Exchange
</div>

Custom Token Exchange (CTE) permite a las aplicaciones intercambiar tokens de identidad existentes por tokens de Auth0 mediante la invocación del endpoint `/oauth/token`, tal como se define en [RFC 8693](https://datatracker.ietf.org/doc/html/rfc8693). Por ejemplo, puede usar Custom Token Exchange para intercambiar tokens de Auth0 y acceder a otra audiencia en nombre del usuario. Para obtener más información sobre los casos de uso de Custom Token Exchange, consulte [Ejemplos de casos de uso](/es/docs/authenticate/custom-token-exchange/cte-example-use-cases).

Al asociar un [perfil de Custom Token Exchange](/es/docs/authenticate/custom-token-exchange/configure-custom-token-exchange) con una Action que contiene lógica personalizada, puede implementar flujos de identidad altamente personalizados intercambiando un token de seguridad por otro, todo ello sin perder el control sobre la lógica de autorización.