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

> Aprenda a identificar el flujo de OAuth 2.0 adecuado para su caso de uso.

# ¿Qué flujo de OAuth 2.0 debería usar?

El [marco de autorización de OAuth 2.0](/es/docs/authenticate/protocols/oauth) admite varios flujos (o concesiones) diferentes. <Tooltip tip="Flujo: procesos que se pueden ampliar con Actions. Cada flujo se compone de uno o más Triggers y representa la secuencia lógica por la que se mueve la información en un punto concreto del recorrido en Auth0." cta="Ver glosario" href="/es/docs/glossary?term=Flow">Flujo</Tooltip> son formas de obtener un <Tooltip tip="Flujo: procesos que se pueden ampliar con Actions. Cada flujo se compone de uno o más Triggers y representa la secuencia lógica por la que se mueve la información en un punto concreto del recorrido en Auth0." cta="Ver glosario" href="/es/docs/glossary?term=Access+Token">Token de acceso</Tooltip>. Decidir cuál se ajusta mejor a su caso de uso depende principalmente de su [tipo de aplicación](/es/docs/get-started/applications), pero también influyen otros parámetros, como el nivel de confianza del cliente o la experiencia que desea ofrecer a sus usuarios.

<div id="oauth-20-terminology">
  ## Terminología de OAuth 2.0
</div>

* **<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>**: Entidad que puede otorgar acceso a un recurso protegido. Normalmente, es el usuario final.
* **Cliente**: Aplicación que solicita acceso a un recurso protegido en nombre del Propietario del recurso.
* **<Tooltip tip="Servidor de recursos: Servidor que aloja recursos protegidos. Los servidores de recursos aceptan y responden a solicitudes de recursos protegidos." cta="Ver glosario" href="/es/docs/glossary?term=Resource+Server">Servidor de recursos</Tooltip>**: Servidor que aloja los recursos protegidos. Es la API a la que quieres acceder.
* **<Tooltip tip="Servidor de autorización: Servidor centralizado que ayuda a definir los límites del acceso de un usuario. Por ejemplo, tu 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>**: Servidor que autentica al Propietario del recurso y emite Tokens de acceso tras obtener la autorización correspondiente. En este caso, Auth0.
* **Agente de usuario**: Agente que utiliza el Propietario del recurso para interactuar con el Cliente (por ejemplo, un navegador o una aplicación nativa).

<div id="is-the-client-the-resource-owner">
  ## ¿Es el cliente el propietario del recurso?
</div>

El primer punto de decisión es si la entidad que requiere acceso a los recursos es una máquina. En el caso de la autorización entre máquinas, el cliente también es el propietario del recurso, por lo que no se requiere autorización de un usuario final. Un ejemplo es una tarea cron que usa una API para importar información a una base de datos. En este ejemplo, la tarea cron es el cliente y el propietario del recurso, ya que tiene el <Tooltip tip="ID de cliente: valor de identificación proporcionado por Auth0 a tu recurso registrado." cta="Ver glosario" href="/es/docs/glossary?term=Client+ID">ID de cliente</Tooltip> y el <Tooltip tip="Secreto del cliente: secreto que usa un cliente (aplicación) para autenticarse con el Servidor de autorización; solo deben conocerlo el cliente y el Servidor de autorización, y debe ser lo suficientemente aleatorio como para que no se pueda adivinar." cta="Ver glosario" href="/es/docs/glossary?term=Client+Secret">Secreto del cliente</Tooltip>, y los usa para obtener un Token de acceso del Servidor de autorización.

Si este caso se ajusta a tus necesidades, consulta [Flujo de credenciales de cliente](/es/docs/get-started/authentication-and-authorization-flow/client-credentials-flow) para saber cómo funciona este flujo y cómo implementarlo.

<div id="is-the-client-a-web-app-executing-on-the-server">
  ## ¿Es el cliente una aplicación web que se ejecuta en el servidor?
</div>

Si el cliente es una aplicación web tradicional que se ejecuta en un servidor, el flujo que debe usar es Authorization Code Flow. Con este flujo, el cliente puede obtener un token de acceso y, opcionalmente, un <Tooltip tip="Refresh Token: Token que se usa para obtener un nuevo token de acceso sin obligar a los usuarios a volver a iniciar sesión." cta="Ver glosario" href="/es/docs/glossary?term=Refresh+Token">Token de actualización</Tooltip>. Se considera la opción más segura, ya que el token de acceso se envía directamente al servidor web que aloja al cliente, sin pasar por el navegador del usuario ni exponerse a ese riesgo.

Si este caso se ajusta a sus necesidades, consulte [Authorization Code Flow](/es/docs/get-started/authentication-and-authorization-flow/authorization-code-flow) para obtener más información sobre cómo funciona este flujo y cómo implementarlo.

<div id="is-the-client-absolutely-trusted-with-user-credentials">
  ## ¿Se confía plenamente en el cliente para gestionar las credenciales del usuario?
</div>

Este punto de decisión puede dar lugar al flujo Resource Owner Password Credentials Grant. En este flujo, se pide al usuario final que introduzca sus credenciales (identificador/contraseña), normalmente mediante un formulario interactivo. Esta información se envía al backend y, desde allí, a Auth0. Por lo tanto, es imprescindible confiar plenamente en el cliente para manejar esta información.

Esta concesión solo debe usarse cuando no sea posible utilizar flujos basados en redirección (como el [Authorization Code Flow](/es/docs/get-started/authentication-and-authorization-flow/authorization-code-flow)). Si este es su caso, para obtener más información sobre cómo funciona este flujo y cómo implementarlo, consulte [Resource Owner Password Flow](/es/docs/get-started/authentication-and-authorization-flow/resource-owner-password-flow).

<div id="is-the-client-a-single-page-app">
  ## ¿El cliente es una aplicación de una sola página?
</div>

Si el cliente es una aplicación de una sola página (SPA), es decir, una aplicación que se ejecuta en un navegador con un lenguaje de scripting como JavaScript, hay dos opciones de grant: Authorization Code Flow con Proof Key for Code Exchange (PKCE) e Implicit Flow with Form Post. En la mayoría de los casos, recomendamos usar Authorization Code Flow con PKCE porque el Token de acceso no queda expuesto en el lado del cliente y este flujo puede devolver [Tokens de actualización](/es/docs/secure/tokens/refresh-tokens).

Para obtener más información sobre cómo funciona este flujo y cómo implementarlo, consulta [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/es/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce). El [SDK de Auth0 para aplicaciones de una sola página](/es/docs/libraries/auth0-single-page-app-sdk) proporciona una API de alto nivel para implementar Authorization Code Flow con PKCE en las SPA.

Si tu SPA no necesita un Token de acceso, puedes usar Implicit Flow with Form Post. Para obtener más información sobre cómo funciona este flujo y cómo implementarlo, consulta [Implicit Flow with Form Post](/es/docs/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post).

<div id="is-the-client-a-nativemobile-app">
  ## ¿El cliente es una aplicación nativa o móvil?
</div>

Si la aplicación es nativa, use el **Authorization Code Flow with Proof Key for Code Exchange (PKCE)**.

Para obtener más información sobre cómo funciona este flujo y cómo implementarlo, consulte [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/es/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce).

<div id="i-have-an-application-that-needs-to-talk-to-different-resource-servers">
  ## Tengo una aplicación que necesita comunicarse con distintos servidores de recursos
</div>

Si una sola aplicación necesita tokens de acceso para distintos servidores de recursos, se deben realizar varias llamadas a `/authorize` (es decir, varias ejecuciones del mismo o de distintos <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">flujos de autorización</Tooltip>). Cada autorización usará un valor distinto para `audience`, lo que dará como resultado un token de acceso diferente al final del flujo. Para obtener más información, consulta la [Especificación de información de audiencia de OAuth 2.0](https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00#section-3).

<div id="can-i-try-the-endpoints-before-i-implement-my-application">
  ## ¿Puedo probar los endpoints antes de implementar mi aplicación?
</div>

¡Claro! Puedes usar nuestra [extensión Authentication API Debugger](/es/docs/customize/extensions/authentication-api-debugger-extension). Encontrarás instrucciones detalladas para cada endpoint `/grant` en nuestra [referencia de la API de autenticación](https://auth0.com/docs/api/authentication).

* Para el endpoint Authorize, ve a [Authorize Application](https://auth0.com/docs/api/authentication#authorize-application) y lee el párrafo «Test this endpoint» del grant que quieras probar.
* Para el <Tooltip tip="Endpoint de token: endpoint del Servidor de autorización que se utiliza para solicitar tokens mediante programación." cta="Ver glosario" href="/es/docs/glossary?term=Token+endpoint">endpoint de token</Tooltip>, ve a [Get Token](https://auth0.com/docs/api/authentication#get-token) y lee la sección «Test this endpoint» del grant que quieras probar.

<div id="does-the-client-application-need-to-challenge-users-for-authentication-without-browser-interaction">
  ## ¿La aplicación cliente necesita solicitar autenticación a los usuarios sin interacción del navegador?
</div>

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Client-Initiated Backchannel Authentication se encuentra actualmente en acceso anticipado. Para habilitar CIBA, póngase en contacto con su gerente técnico de cuenta.
</Callout>

Client-Initiated Backchannel Authentication (CIBA) es un estándar de 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 para implementar un flujo de autenticación alternativo a [OpenID Connect](https://openid.net/developers/how-connect-works/). CIBA se diferencia del flujo estándar de OpenID Connect en que:

* La aplicación cliente inicia el proceso de autenticación en nombre del usuario final.
* No se necesita un navegador para la interacción del usuario.
* Hay comunicación directa entre la aplicación cliente y el proveedor de OpenID.

CIBA es útil cuando el usuario no puede confiar en la aplicación cliente, la aplicación cliente no dispone de navegador o el usuario no está frente a la aplicación que requiere autenticación. Estos son algunos ejemplos en los que se pueden usar flujos de CIBA:

* **Registro de usuarios en una terminal de punto de venta:** En escenarios de click and collect, un usuario puede autenticarse en un quiosco público y confirmar su presencia.
* **Autenticación en un centro de llamadas o en el mostrador de atención:** Un agente del centro de llamadas puede iniciar un flujo de autenticación para autenticar a quien llama, normalmente mediante una aplicación móvil personalizada en un teléfono inteligente.
* **Autenticación en un dispositivo sin capacidad de entrada:** Por ejemplo, un altavoz inteligente (u otro dispositivo conectado) puede usar un servicio de backend para ponerse en contacto con el usuario para autenticarse, normalmente mediante una aplicación móvil personalizada en un teléfono inteligente.

CIBA define dos dispositivos:

* **Dispositivo de consumo**: El dispositivo que ayuda al usuario a consumir un servicio.
* **Dispositivo de autenticación**: El dispositivo en el que el usuario se autenticará y otorgará su consentimiento.

Para obtener más información, consulte [Client-Initiated Backchannel Authentication Flow](/es/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow).