Aprenda a ejecutar el flujo híbrido para que su aplicación pueda usar un token de ID para acceder a la información del usuario y, al mismo tiempo, obtener un código de autorización que pueda intercambiarse por un Token de acceso.
Este tutorial le ayudará a llamar a su propia API con el Flujo híbrido. Si desea obtener más información sobre cómo funciona este flujo y por qué debería usarlo, consulte Flujo híbrido.
Auth0 facilita que su aplicación implemente el Flujo de código de autorización mediante:
Authentication API: Si prefiere crear su propia solución, siga leyendo para aprender a llamar directamente a nuestra API.
Agregue una URL de callback permitida: {https://yourApp/callback}.
Asegúrese de que los Tipos de concesión de su aplicación incluyan Implícito y Código de autorización. Para saber cómo hacerlo, consulte Actualizar tipos de concesión.
Si desea que su aplicación pueda usar Tokens de actualización, asegúrese de que los Tipos de concesión de la aplicación incluyan Token de actualización. Para saber cómo hacerlo, consulte Actualizar tipos de concesión. Para obtener más información sobre los Tokens de actualización, consulte Tokens de actualización.
Si desea que su API reciba Tokens de actualización para poder obtener tokens nuevos cuando caduquen los anteriores, habilite Permitir acceso sin conexión.
Ten en cuenta que, para autorizar a un usuario al llamar a una API personalizada, debes:
incluir un parámetro
incluir alcances adicionales compatibles con la API de destino
Nombre del parámetro
Descripción
response_type
Indica el tipo de credencial que devolverá Auth0 (code o token). Para este flujo, el valor debe incluir code, pero también puede incluir id_token, token o id_token token. En concreto, id_token devuelve un ID Token y token devuelve un Token de acceso.
response_mode
Especifica el método con el que deben devolverse los parámetros de respuesta. Por motivos de seguridad, el valor debe ser form_post. En este modo, los parámetros de respuesta se codificarán como valores de formulario HTML que se transmiten mediante el método HTTP POST y se codifican en el cuerpo con el formato application/x-www-form-urlencoded.
La URL a la que Auth0 redirigirá el navegador después de que el usuario haya concedido la autorización. El código de autorización estará disponible en el parámetro de URL code. Debes especificar esta URL como una URL de callback válida en la configuración de la aplicación.
Advertencia: Según la especificación OAuth 2.0, Auth0 elimina todo lo que aparece después del hash e ignora cualquier fragmento.
scope
Especifica los alcances para los que quieres solicitar autorización, que determinan qué claims (o atributos del usuario) quieres que se devuelvan. Deben separarse con un espacio. Puedes solicitar cualquiera de los alcances estándar de OpenID Connect (OIDC) sobre usuarios, como profile o email, claims personalizados que cumplan con un formato con espacio de nombres, o cualquier alcance compatible con la API de destino (por ejemplo, read:contacts). Incluye offline_access para obtener un Token de actualización (asegúrate de que el campo Allow Offline Access esté habilitado en la configuración de la aplicación).
audience
El identificador único de la API a la que tu aplicación quiere acceder. Usa el valor de Identifier en la pestaña Settings de la API que creaste como parte de los requisitos previos de este tutorial.
state
(recomendado) Una cadena alfanumérica arbitraria y opaca que tu aplicación agrega a la solicitud inicial y que Auth0 incluye al redirigir de vuelta a tu aplicación. Para ver cómo usar este valor para evitar ataques de falsificación de solicitudes entre sitios (CSRF), consulta Mitigate CSRF Attacks With State Parameters.
(opcional) ID de la organización que se usará al autenticar a un usuario. Si no se proporciona, y tu aplicación está configurada para Display Organization Prompt, el usuario podrá introducir el nombre de la organización al autenticarse.
invitation
(opcional) ID del ticket de invitación de la organización. Al invitar a un miembro a una Organización, tu aplicación debe gestionar la aceptación de la invitación reenviando los pares clave-valor invitation y organization cuando el usuario acepte la invitación.
Como ejemplo, tu fragmento HTML para la URL de autorización al agregar el inicio de sesión a tu aplicación podría verse así:
Cuando decodifique y analice su , observará un claim adicional, c_hash, que contiene un hash del code. Este claim es obligatorio cuando se emite un token de ID al mismo tiempo que un code, y debe validarlo:
Con el algoritmo hash especificado en el claim alg del encabezado del ID Token, calcule el hash de los octetos de la representación ASCII del code.
Codifique en Base64url la mitad izquierda del hash.
Compruebe que el resultado coincida con el valor de c_hash.
Ahora que tiene un código de autorización, debe canjearlo por tokens. Con el código de autorización extraído (code) en el paso anterior, deberá enviar una solicitud POST a la URL del token.El que reciba en este paso es el que debe usar para llamar a su API. Asegúrese de mantenerlo separado del token de acceso que recibió en el paso anterior de este tutorial.
El Secreto del cliente de tu aplicación. Puedes encontrar este valor en la configuración de la aplicación. Para obtener más información sobre los métodos de autenticación de aplicaciones disponibles, consulta Credenciales de la aplicación.
redirect_uri
La URL de callback válida configurada en la configuración de la aplicación. Debe coincidir exactamente con el valor de redirect_uri que se pasó a la URL de autorización en el paso anterior de este tutorial. Ten en cuenta que debe estar codificada en formato URL.
Los tokens de actualización deben almacenarse de forma segura, ya que permiten que un usuario permanezca autenticado prácticamente de forma indefinida.
Para llamar a su API desde una aplicación web estándar (o en casos similares en los que las credenciales de la aplicación pueden almacenarse de forma segura), la aplicación debe enviar el Token de acceso obtenido como Bearer Token en el encabezado Authorization de la solicitud HTTP.
Ya recibió un token de actualización si ha estado siguiendo este tutorial y completó lo siguiente:
configuró su API para permitir acceso sin conexión
incluyó el scope offline_access al iniciar la solicitud de autenticación a través del endpoint de autorización.
Puede usar el para obtener un nuevo token de acceso. Normalmente, un usuario solo necesitará un nuevo token de acceso después de que caduque el anterior o cuando obtenga acceso a un nuevo recurso por primera vez. Es una mala práctica llamar al endpoint para obtener un nuevo token de acceso cada vez que llame a una API, y Auth0 aplica límites de tasa que restringen la cantidad de solicitudes al endpoint que pueden ejecutarse con el mismo token desde la misma IP.Para actualizar su token, haga una solicitud POST al endpoint /oauth/token de la Authentication API con grant_type=refresh_token.
(opcional) Una lista de permisos de scope solicitados, delimitada por espacios. Si no se envía, se usarán los alcances originales; de lo contrario, puedes solicitar un conjunto reducido de alcances. Ten en cuenta que debe estar codificado para URL.
Si todo sale bien, recibirás una respuesta HTTP 200 con una carga útil que contiene un nuevo access_token, su duración en segundos (expires_in), los valores de scope otorgados y token_type. Si el scope del token inicial incluía openid, la respuesta también incluirá un nuevo id_token:
Puede usar Rules para cambiar los alcances que se devuelven en los tokens de acceso y/o agregar claims a los tokens de acceso y a los ID Tokens. (Para obtener más información sobre Rules, consulte Auth0 Rules.) Para ello, agregue la siguiente Rule, que se ejecutará después de que el usuario se autentique:
exports.onExecutePostLogin = async (event, api) => { // Agregar claims personalizados al Token de acceso y al ID Token api.accessToken.setCustomClaim('https://foo/bar', 'value'); api.idToken.setCustomClaim('https://fiz/baz', 'some other value'); // Modificar el scope del Token de acceso api.accessToken.addScope('foo'); api.accessToken.addScope('bar');};
Los alcances estarán disponibles en el token una vez que se hayan ejecutado todas las Rules.
Auth0 devuelve la información del perfil en un formato estructurado de claims, tal como lo define la especificación OpenID Connect (OIDC). Esto significa que los claims personalizados agregados a los ID tokens o a los tokens de acceso deben ajustarse a las directrices y restricciones para evitar posibles conflictos.
Autenticar
Administrar usuarios
Personalizar
Auth0 AI
Plataforma