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

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

El marco de autorización de OAuth 2.0 admite varios flujos (o concesiones) diferentes. Flujo son formas de obtener un Token de acceso. Decidir cuál se ajusta mejor a su caso de uso depende principalmente de su tipo de aplicación, pero también influyen otros parámetros, como el nivel de confianza del cliente o la experiencia que desea ofrecer a sus usuarios.

​

Terminología de OAuth 2.0

• Propietario del recurso: 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.
• Servidor de recursos: Servidor que aloja los recursos protegidos. Es la API a la que quieres acceder.
• Servidor de autorización: 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).

​

¿Es el cliente el propietario del recurso?

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 ID de cliente y el Secreto del cliente, 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 para saber cómo funciona este flujo y cómo implementarlo.

​

¿Es el cliente una aplicación web que se ejecuta en el servidor?

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 Token de actualización. 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 para obtener más información sobre cómo funciona este flujo y cómo implementarlo.

​

¿Se confía plenamente en el cliente para gestionar las credenciales del usuario?

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

​

¿El cliente es una aplicación de una sola página?

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.

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). El SDK de Auth0 para aplicaciones de una sola página 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.

​

¿El cliente es una aplicación nativa o móvil?

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

​

Tengo una aplicación que necesita comunicarse con distintos servidores de recursos

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 flujos de autorización). 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.

​

¿Puedo probar los endpoints antes de implementar mi aplicación?

¡Claro! Puedes usar nuestra extensión Authentication API Debugger. Encontrarás instrucciones detalladas para cada endpoint /grant en nuestra referencia de la API de autenticación.

• Para el endpoint Authorize, ve a Authorize Application y lee el párrafo «Test this endpoint» del grant que quieras probar.
• Para el endpoint de token, ve a Get Token y lee la sección «Test this endpoint» del grant que quieras probar.

​

¿La aplicación cliente necesita solicitar autenticación a los usuarios sin interacción del navegador?

Client-Initiated Backchannel Authentication se encuentra actualmente en acceso anticipado. Para habilitar CIBA, póngase en contacto con su gerente técnico de cuenta.

Client-Initiated Backchannel Authentication (CIBA) es un estándar de la OpenID Foundation para implementar un flujo de autenticación alternativo a OpenID Connect. 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.