Saltar al contenido principal
Auth0 usa el protocolo OpenID Connect (OIDC) y el framework de autorización OAuth 2.0 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/ ni por otros aspectos técnicos de la autenticación y la autorización. 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?.
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.
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.

​
Flujo de código de autorización

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 with Proof Key for Code Exchange (PKCE)

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 con protección reforzada de la privacidad

Durante el proceso de autenticación y autorización, algunos casos de uso, como la autorización transaccional, 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:

​
Flujo implícito con Form Post

Como alternativa al flujo de código de autorización, OAuth 2.0 ofrece el flujo implícito, pensado para o aplicaciones que no pueden almacenar de forma segura . Si bien ya no se considera una práctica recomendada para solicitar , 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 para autenticar al usuario.

​
Flujo híbrido

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 . 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 de credenciales del cliente

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 autorización de dispositivos

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 de dispositivos (definido en OAuth 2.0). Para aplicaciones móviles/nativas.

​
Flujo de contraseña del propietario del recurso

Aunque no lo recomendamos, las aplicaciones de alta confianza pueden usar el flujo de contraseña del , 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).

​
Flujo de autenticación de backchannel iniciado por el cliente

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.

​
Custom Token Exchange

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. 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. Al asociar un perfil de 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.