El inicio de sesión integrado para aplicaciones web utiliza autenticación entre orígenes, a menos que configures un dominio personalizado para tu tenant. La autenticación entre orígenes utiliza cookies de terceros para permitir transacciones de autenticación seguras entre distintos orígenes.
El directorio de ejemplo de la biblioteca auth0.js es una aplicación lista para usar que puede ayudarte a probar auth0.js de forma rápida y sencilla. Para ejecutarla, sigue estos pasos:
Descarga las dependencias ejecutando npm install desde la raíz de este proyecto
Por último, ejecuta npm start desde la raíz de este proyecto y luego abre en el navegador la aplicación que se está ejecutando en el servidor de Node, probablemente en http://localhost:3000/example.
Configura tu aplicación de Auth0 para el inicio de sesión integrado
Al implementar el inicio de sesión integrado, la biblioteca usará solicitudes entre orígenes dentro de iframes ocultos para realizar la autenticación. Para garantizar que esto pueda hacerse de forma segura, Auth0 necesita conocer los dominios donde alojarás tus aplicaciones.Agrega el dominio al campo Allowed Web Origins. Puedes encontrar este campo en la sección de Application Settings de tu Dashboard.
Hay dos parámetros obligatorios que deben pasarse en el objeto options al instanciar webAuth, y varios más que son opcionales.
Parámetro
Obligatorio
Descripción
domain
obligatorio
(String) El dominio de tu cuenta de Auth0 (p. ej., myaccount.auth0.com)
clientID
obligatorio
(String) Tu ID de cliente de Auth0
redirectUri
opcional*
(String) El redirectUri predeterminado que se utilizará. De forma predeterminada, es una cadena vacía (ninguno). Si no proporcionas aquí un valor global de redirectUri, tendrás que proporcionar un valor de redirectUri para cada método que uses.
scope
opcional
(String) El predeterminado que usa la aplicación. El uso de scopes puede permitirte devolver claims específicos para campos concretos de tu solicitud. Debes consultar nuestra documentación sobre scopes para obtener más detalles.
audience
opcional
(String) La audiencia predeterminada que se utilizará para solicitar acceso a la API.
responseType
opcional*
(String) El responseType predeterminado que se utilizará. Puede ser cualquier lista separada por espacios de los valores code, token, id_token. El valor predeterminado es 'token', a menos que se proporcione un redirectUri, en cuyo caso será 'code'. Si no proporcionas un valor global de responseType, tendrás que proporcionar un valor de responseType para cada método que uses.
responseMode
opcional
(String) Esta opción se omite de forma predeterminada. Puede establecerse en 'form_post' para enviar el token o código al 'redirectUri' mediante POST. Los valores admitidos son query, fragment y form_post.
leeway
opcional
(Integer) Un valor en segundos; margen permitido para compensar la desincronización del reloj con respecto a los tiempos de expiración del ID Token.
_disableDeprecationWarnings
opcional
(Boolean) Desactiva las advertencias de obsolescencia; el valor predeterminado es false.
Debido a problemas de desincronización del reloj, es posible que ocasionalmente te encuentres con el error The token was issued in the future. El parámetro leeway puede usarse para permitir unos segundos de margen en los tiempos de expiración del ID Token y evitar que esto ocurra.
Scope
El valor predeterminado de scope en auth0.js v9 es openid profile email.
Ejecutar Auth0.js de forma local
Si no especificas al menos el scope indicado arriba al inicializar auth0.js y ejecutas tu sitio web desde http://localhost o http://127.0.0.1, al llamar al método getSSOData() se mostrará el siguiente error en la consola del navegador:Consent required. When using getSSOData, the user has to be authenticated with the following scope: openid profile emailEsto no ocurrirá cuando ejecutes tu aplicación en producción o si especificas el scope openid profile email. Puedes obtener más información en el documento Consentimiento del usuario y aplicaciones de terceros.
El método authorize() puede usarse para iniciar sesión mediante o conexiones sociales, como se muestra en los ejemplos a continuación. Este método invoca el endpoint /authorize de la Authentication API y puede recibir distintos parámetros a través del objeto options.
Parámetro
Obligatorio
Descripción
audience
opcional
(String) La audiencia predeterminada que se usará para solicitar acceso a la API.
connection
opcional
(String) Especifica la conexión que se usará, en lugar de mostrar todas las conexiones disponibles para la aplicación.
scope
opcional
(String) Los scopes para los que deseas solicitar autorización. Deben estar separados por espacios. Puedes solicitar cualquiera de los scopes estándar de OIDC relacionados con el usuario, como profile y email, claims personalizados que deben ajustarse a un formato con espacio de nombres, o cualquier scope compatible con la API de destino (por ejemplo, read:contacts). Incluye offline_access para obtener un .
responseType
opcional
(String) Puede ser cualquier lista de valores separada por espacios entre code, token, id_token. Su valor predeterminado es 'token', a menos que se proporcione un redirectUri, en cuyo caso será 'code'.
clientID
opcional
(String) Tu ID de cliente de Auth0.
redirectUri
opcional
(String) La URL a la que Auth0 redirigirá el navegador una vez que se haya concedido la autorización al usuario.
state
opcional
(String) Un valor arbitrario que debe mantenerse entre redirecciones. Es útil para mitigar ataques CSRF y para cualquier información contextual (por ejemplo, una URL de retorno) que puedas necesitar una vez finalizado el proceso de autenticación. Para obtener más información, consulta State Parameter. auth0.js, cuando se usa en aplicaciones de una sola página, gestiona automáticamente la generación y validación de state si no se especifica.
prompt
opcional
(String) Un valor de login forzará que se muestre la página de inicio de sesión independientemente de la sesión actual. Un valor de none intentará omitir las pantallas de inicio de sesión si ya existe una sesión (consulta la documentación de autenticación silenciosa para más detalles).
Para el inicio de sesión alojado, se debe llamar al método /authorize().webAuth.authorize({//Cualquier opción adicional puede ir aquí});Para los inicios de sesión sociales, será necesario especificar el parámetro connection:webAuth.authorize({connection: 'twitter'});
Para la autenticación mediante ventana emergente se puede usar el método popup.authorize. La autenticación mediante ventana emergente no puede utilizarse en páginas de inicio de sesión alojadas. Normalmente, este tipo de autenticación se usa en aplicaciones de una sola página para no perder el estado actual al hacer una redirección de página completa.Autorización predeterminada mediante ventana emergente (Universal Login):
webAuth.popup.authorize({ responseType: 'token' redirectUri: 'https://{yourApp}/popup_response_handler.html' //Aquí pueden ir opciones adicionales}, function(err, authResult) { //hacer algo});
Y para iniciar sesión con redes sociales mediante una ventana emergente usando authorize:
Gestión de los resultados de autenticación con ventana emergente
Al usar la autenticación con ventana emergente, tendrás que proporcionar un redirectUri en el que la página de destino comunique los resultados de la autorización al callback mediante el método webAuth.popup.callback. Una implementación sencilla sería algo así:
Un manejador ideal contendría solo esta funcionalidad mínima (es decir, que evite recargar toda la aplicación solo para procesar la respuesta).Tendrás que añadir el redirectUri a la lista de Allowed Callback URLs en la página de configuración de la aplicación del Dashboard.
El inicio de sesión integrado para aplicaciones web usa la autenticación entre orígenes, a menos que configure un dominio personalizado para su tenant. La autenticación entre orígenes utiliza cookies de terceros para permitir transacciones de autenticación seguras entre distintos orígenes.
El método login puede utilizarse para el inicio de sesión integrado mediante autenticación entre orígenes en conexiones de base de datos, usando /co/authenticate.
Parámetro
Obligatorio
Descripción
username
opcional
(String) El nombre de usuario que se usará para la autenticación. Debe proporcionarseusername o email.
email
opcional
(String) El correo electrónico que se usará para la autenticación. Debe proporcionarseusername o email.
password
obligatorio
(String) La contraseña que se usará para la autenticación.
realm
obligatorio
(String) El nombre de la conexión de base de datos con la que se autenticará.
El método crossOriginVerification() puede utilizarse para facilitar la autenticación entre orígenes a los clientes que tienen deshabilitadas las cookies de terceros en sus navegadores. Puedes consultar más información sobre su uso en el documento de autenticación entre orígenes.
El método buildAuthorizeUrl puede usarse para construir la URL /authorize a fin de iniciar una nueva transacción. Usa este método si quieres implementar autenticación basada en el navegador (pasiva).El parámetro state es un valor opaco que Auth0 te devolverá. Este método ayuda a prevenir ataques CSRF y debe especificarse si rediriges a la URL tú mismo en lugar de llamar a webAuth.authorize(). Para obtener más información, consulta State Parameter.
Inicio de sesión único con autenticación integrada
Las aplicaciones con inicio de sesión integrado deben cumplir dos criterios para poder tener (SSO).
Ambas aplicaciones que intentan usar SSO deben ser aplicaciones propias. El SSO con aplicaciones de terceros no funcionará.
Deben usar dominios personalizados, y tanto las aplicaciones que vayan a tener SSO como el tenant de Auth0 deben estar en el mismo dominio. Tradicionalmente, los dominios de Auth0 tienen el formato foo.auth0.com, pero los dominios personalizados te permiten usar el mismo dominio para cada una de las aplicaciones en cuestión, así como para tu tenant de Auth0, lo que evita el riesgo de ataques CSRF.
Nuestra recomendación es usar Universal Login en lugar de configurar SSO en escenarios de inicio de sesión integrado. Universal Login es la forma más fiable y estable de realizar SSO, y es la única manera de hacerlo si debes usar varios dominios para tus aplicaciones o aplicaciones de terceros.
La autenticación permite a los usuarios iniciar sesión recibiendo un código de un solo uso por correo electrónico o mensaje de texto. El proceso requiere que inicies el flujo sin contraseña, generando y enviando un código al usuario (o un código dentro de un enlace) y, a continuación, validando sus credenciales mediante el método de verificación. Esto puede presentarse en forma de una pantalla de inicio de sesión que solicite su correo electrónico o número de teléfono y el código que acabas de enviarle. También puede implementarse como un enlace sin contraseña en lugar de un código enviado al usuario. Bastaría con que hicieran clic en el enlace de su correo electrónico o mensaje de texto para que este llame a tu endpoint y verifique estos datos automáticamente usando el mismo método de verificación (solo que sin que el usuario tenga que introducir manualmente un código).Para usar la autenticación sin contraseña, deberás inicializar auth0.js con un redirectUri y establecer responseType: 'token'.
El primer paso para la autenticación sin contraseña con auth0.js es el método passwordlessStart, que admite varios parámetros dentro de su objeto options:
Parameter
Required
Description
connection
obligatorio
(String) Especifica cómo enviar el código o el enlace al usuario. El valor debe ser email o sms.
send
obligatorio
(String) El valor debe ser code o link. Si es null, se enviará un enlace.
phoneNumber
opcional
(String) El número de teléfono del usuario al que se enviará un código o enlace por SMS.
email
opcional
(String) El correo electrónico del usuario al que se enviará un código o enlace por correo electrónico.
Ten en cuenta que, para iniciar el proceso de autenticación sin contraseña, debes enviar exactamente uno de los parámetros opcionales phoneNumber y email.
webAuth.passwordlessStart({ connection: 'email', send: 'code', email: 'foo@bar.com' }, function (err,res) { // manejar errores o continuar });
Si envías un código, tendrás que pedirle al usuario que lo introduzca. Procesarás el código y autenticarás al usuario con el método passwordlessLogin, que tiene varios parámetros que pueden enviarse en su objeto options:
Parámetro
Obligatorio
Descripción
connection
obligatorio
(String) Especifica cómo se envía el código/enlace al usuario. El valor debe ser email o sms, y debe coincidir con el valor pasado a passwordlessStart.
verificationCode
obligatorio
(String) El código enviado al usuario, ya sea como código o integrado en un enlace.
phoneNumber
opcional
(String) El número de teléfono del usuario al que se envió el código o enlace por SMS.
email
opcional
(String) El correo electrónico del usuario al que se envió el código o enlace por correo electrónico.
Al igual que con passwordlessStart, debe enviarse exactamente uno de los parámetros opcionales phoneNumber o email para verificar la transacción sin contraseña.Para usar passwordlessLogin, las opciones redirectUri y responseType deben especificarse al inicializar WebAuth por primera vez.
webAuth.passwordlessLogin({ connection: 'email', email: 'foo@bar.com', verificationCode: '389945' }, function (err,res) { // gestionar errores o continuar });
Extrae el authResult y obtén información del usuario
Una vez completada la autenticación, puedes usar el método parseHash para analizar el fragmento hash de una URL cuando se redirige al usuario de vuelta a tu aplicación y extraer así el resultado de una respuesta de autenticación de Auth0. Puedes hacerlo en una página de callback que luego redirija a tu aplicación principal o directamente en la propia página, según convenga en cada caso.El método parseHash recibe un objeto options que contiene los siguientes parámetros:
Parámetro
Obligatorio
Descripción
state
opcional
(String) Un valor opaco que la aplicación añade a la solicitud inicial y que Auth0 incluye al redirigir de vuelta a la aplicación. auth0.js usa este valor para evitar ataques CSRF.
opcional
(String) Se utiliza para verificar el ID Token
hash
opcional
(String) El hash de la URL (si no se proporciona, se usará window.location.hash de forma predeterminada)
El contenido del objeto authResult que devuelve parseHash depende de los parámetros de autenticación que se hayan utilizado. Puede incluir:
Elemento
Descripción
accessToken
Un para la API especificada por audience
expiresIn
Una cadena que contiene el tiempo de expiración (en segundos) del accessToken
idToken
Un JWT de ID Token que contiene información del perfil del usuario
webAuth.parseHash({ hash: window.location.hash }, function(err, authResult) { if (err) { return console.log(err); } webAuth.client.userInfo(authResult.accessToken, function(err, user) { // Ahora tienes la información del usuario });});
Como se muestra arriba, se puede llamar al método client.userInfo pasando el accessToken devuelto. Este hará una solicitud al endpoint /userinfo y devolverá el objeto user, que contiene la información del usuario, con un formato similar al del ejemplo siguiente.
Ahora puede hacer otras cosas con esta información según las necesidades de su aplicación, como obtener toda la información del perfil del usuario con la , como se describe a continuación.
De forma predeterminada (y si responseType contiene id_token), auth0.js generará un nonce aleatorio cuando llames a webAuth.authorize, lo almacenará en el almacenamiento local y lo recuperará en webAuth.parseHash. El comportamiento predeterminado debería funcionar en la mayoría de los casos, pero en algunos escenarios puede ser necesario que el desarrollador controle el nonce.
Si quieres usar un nonce generado por el desarrollador, debes proporcionarlo como una opción tanto en webAuth.authorize como en webAuth.parseHash.
webAuth.authorize({<Tooltip tip="Nonce: Arbitrary number issued once in an authentication protocol to detect and prevent replay attacks." cta="View Glossary" href="/docs/glossary?term=nonce">nonce</Tooltip>: '1234', responseType: 'token id_token'}); webAuth.parseHash({nonce: '1234'}, callback);Si llamas a webAuth.checkSession en lugar de webAuth.authorize, solo tienes que especificar tu nonce personalizado como una opción en checkSession:
webAuth.checkSession({ nonce: '1234',}, function (err, authResult) { ...});
El método webAuth.checkSession verificará automáticamente que la claim nonce del ’ devuelto sea la misma que la opción.
Cuando Auth0.js se usa para el inicio de sesión integrado, utiliza el endpoint /co/authenticate, que puede generar los siguientes errores:
Las descripciones de los errores están pensadas para que las personas puedan entenderlas. La descripción no debe ser analizada por ningún código y puede cambiar en cualquier momento.
Status
Code
Description
400
invalid_request
Cuerpo de la solicitud no válido. Se requieren todos y únicamente client_id, credential_type, username, otp y realm.
401
unauthorized_client
No se permite el inicio de sesión entre orígenes.
400
unsupported_credential_type
Parámetro de tipo de credencial desconocido.
400
invalid_request
Realm desconocido: non-existent-connection.
403
access_denied
Correo electrónico o contraseña incorrectos.
403
access_denied
Error de autenticación
403
blocked_user
Usuario bloqueado
401
password_leaked
Este intento de inicio de sesión se ha bloqueado porque la contraseña que estás usando ya se había visto comprometida en una filtración de datos (no en esta aplicación).
429
too_many_attempts
Tu cuenta se ha bloqueado tras varios intentos consecutivos de inicio de sesión. Te hemos enviado una notificación a través de tu método de contacto preferido con instrucciones para desbloquearla.
429
too_many_attempts
Hemos detectado un comportamiento sospechoso en el inicio de sesión y se bloquearán los siguientes intentos. Ponte en contacto con el administrador.
Además, también puedes recibir un error 403 genérico sin una propiedad error ni error_description. El cuerpo de la respuesta simplemente incluiría algo similar a lo siguiente:
Origin https://test.app is not allowed.
Para cerrar la sesión de un usuario, usa el método logout(). Este método acepta un objeto de opciones que puede incluir los siguientes parámetros.Si se incluye el parámetro clientID, la URL returnTo proporcionada debe figurar en las Allowed Logout URLs de la aplicación en el Dashboard de Auth0. Sin embargo, si no se incluye el parámetro clientID, la URL returnTo debe figurar en las Allowed Logout URLs configuradas a nivel de cuenta en el Dashboard de Auth0.
webAuth.logout({ returnTo: 'some url here', clientID: 'some client ID here'});
El método checkSession te permite obtener un nuevo token de Auth0 para un usuario que ya está autenticado con Auth0 en tu dominio. El método acepta cualquier parámetro válido de OAuth2 que normalmente se enviaría a authorize. Si los omites, usará los que se proporcionaron al inicializar Auth0.La llamada a checkSession puede usarse para obtener un nuevo token para la API que se especificó como la al inicializar webAuth:
webAuth.checkSession({}, function (err, authResult) { // err si el parseHash automático falla ...});
Consulta Extraer el AuthResult y obtener la información del usuario para conocer el formato de authResult.O bien, se puede obtener el token para una API distinta de la usada al inicializar webAuth especificando un audience y un scope:
webAuth.checkSession( { audience: `https://mydomain/another-api/˜`, scope: 'read:messages' }, function (err, authResult) { // err si el parseHash automático falla ...});
Ten en cuenta que checkSession() activa cualquier regla que hayas configurado, por lo que deberías revisar tus reglas en el Dashboard antes de usarla.La redirección real a /authorize se produce dentro de un iframe, por lo que no recargará tu aplicación ni te redirigirá fuera de ella.Sin embargo, el navegador debe tener habilitadas las cookies de terceros. De lo contrario, checkSession() no podrá acceder a la sesión actual del usuario (lo que hace imposible obtener un nuevo token sin mostrar nada al usuario). Lo mismo ocurrirá si los usuarios tienen la ITP de Safari habilitada.Recuerda añadir la URL desde la que se origina la solicitud de autorización a la lista de Allowed Web Origins de tu aplicación de Auth0 en el Dashboard, dentro de Settings de tu aplicación.
Si se trata de una conexión social y estás usando claves de desarrollo de Auth0, la llamada a checkSession siempre devolverá login_required.
En algunos escenarios con varias aplicaciones, en los que se desea Single Logout (cuando un usuario cierra sesión en una aplicación, también debe cerrarse en las demás), una aplicación puede configurarse para consultar periódicamente a Auth0 mediante checkSession() y comprobar si existe una sesión. Si la sesión no existe, puedes cerrar la sesión del usuario en la aplicación. El mismo método de sondeo puede utilizarse para implementar autenticación silenciosa en un escenario de inicio de sesión único (SSO).El intervalo de sondeo entre comprobaciones con checkSession() debe ser de al menos 15 minutos entre llamadas para evitar posibles problemas futuros con la limitación de tasa de esta llamada.
Si quieres configurar la funcionalidad de restablecimiento de contraseña, usarás el método changePassword y pasarás un objeto options con un parámetro connection y otro email.
La Management API ofrece funciones que te permiten vincular y desvincular cuentas de usuario independientes de distintos proveedores, así como actualizar los metadatos del usuario. Para obtener más información, consulta Vinculación de cuentas de usuario.Para empezar, primero debes obtener un que pueda utilizarse para llamar a la Management API. Puedes hacerlo especificando la audiencia https://{yourDomain}/api/v2/ al inicializar auth0.js; en ese caso, obtendrás el token de acceso como parte del flujo de autenticación.Si usas dominios personalizados, tendrás que crear una nueva instancia de webAuth con tu dominio de Auth0 en lugar del dominio personalizado para usarla en las llamadas a la Management API, ya que esta solo funciona con dominios de Auth0.También puedes hacerlo con checkSession():Debes especificar los permisos concretos que necesitas. Puedes solicitar los siguientes permisos:
read:current_user
update:current_user_identities
create:current_user_metadata
update:current_user_metadata
delete:current_user_metadata
create:current_user_device_credentials
delete:current_user_device_credentials
Una vez que tengas el token de acceso, puedes crear una nueva instancia de auth0.Management pasándole el dominio de Auth0 de la cuenta y el token de acceso.
Para obtener los datos del perfil del usuario, utiliza el método getUser() con userId y un callback como parámetros. El método devuelve el perfil del usuario. Ten en cuenta que el userID requerido aquí será el mismo que se obtuvo mediante el método client.userInfo.
auth0Manage.getUser(userId, cb);
Al actualizar los metadatos del usuario, primero deberá crear un objeto userMetadata y luego llamar al método patchUserMetadata, pasándole el ID del usuario y el objeto userMetadata que haya creado. Los valores de este objeto sobrescribirán los valores existentes que tengan la misma clave o agregarán otros nuevos para las claves que aún no existan en los metadatos del usuario. Para obtener más información, consulte Metadata.
auth0Manage.patchUserMetadata(userId, userMetadata, cb);
Vincular cuentas de usuario permitirá que una persona pueda autenticarse con cualquiera de sus cuentas y, sin importar cuál use, siga accediendo al mismo perfil al iniciar sesión. Auth0 trata todas estas cuentas como perfiles independientes de forma predeterminada, así que, si quieres que las cuentas de un usuario estén vinculadas, esta es la forma de hacerlo.El método linkUser acepta dos parámetros: el userId principal y el ID Token del usuario secundario (el token obtenido después de iniciar sesión con esta identidad). El ID de usuario en cuestión es el identificador único de la cuenta de usuario principal. El ID debe pasarse con el prefijo del proveedor, por ejemplo, auth0|1234567890 o facebook|1234567890, al usar este método. Consulta User Account Linking para obtener más información.
auth0Manage.linkUser(userId, secondaryUserToken, cb);Después de vincular las cuentas, la segunda cuenta dejará de existir como una entrada independiente en la base de datos de usuarios y solo se podrá acceder a ella como parte de la cuenta principal.
Cuando las cuentas están vinculadas, los metadatos de la cuenta secundaria no se fusionan con los de la cuenta principal y, si en algún momento se desvinculan, la cuenta secundaria tampoco conservará los metadatos de la cuenta principal cuando vuelva a quedar separada.
Authenticate
Manage Users
Customize
Auth0 AI
Platform