Marca el intento de inicio de sesión actual como denegado. Esto impedirá que el usuario final complete
el flujo de inicio de sesión. Esto NO cancelará otros efectos secundarios relacionados con el usuario (como cambios en los metadatos)
solicitados por esta Action. El flujo de inicio de sesión se detendrá inmediatamente al
completarse esta acción y no se ejecutará ninguna Action adicional.
Solicita un desafío para la autenticación multifactor con el factor proporcionado y factores adicionales opcionales.Cuando se solicita un desafío multifactor, las Actions posteriores no se ejecutarán hasta que el usuario haya
completado ese desafío. Un usuario habrá satisfecho el desafío en cualquiera de las siguientes situaciones:
Completa correctamente el desafío para el factor predeterminado.
Completa correctamente el desafío para cualquiera de los factores opcionales descritos en additionalFactors.
Si alguno de los factores solicitados ya se ha completado correctamente en la transacción actual, se
ignorará.Si se solicita un factor que no está habilitado en el inquilino, se ignorará. Si se solicita un factor en el que el usuario
no se ha inscrito, se ignorará. Si ninguno de los factores solicitados está habilitado o inscrito, la transacción de autenticación
fallará (es decir, el inicio de sesión no se completará).
Este método hará que se muestre una pantalla de desafío del factor si el usuario todavía no ha cumplido
los requisitos del desafío. Si se proporcionan additionalFactors, el usuario tendrá la opción de
seleccionar otro factor si así lo desea.
Un tipo de factor de autenticación, como push-notification, phone, email, otp, webauthn-roaming, webauthn-platform y recovery-code.Valores permitidos: otp, email, webauthn-platform, webauthn-roaming, recovery-code
Opciones adicionales que también pueden especificar additionalFactors como una propiedad. Las opciones específicas del factor (por ejemplo, otpFallback para push-notification) deben incluirse en factor.options.
Solicita un desafío de autenticación multifactor con cualquiera de los factores proporcionados (mostrando primero una
pantalla de selección de factor).Cuando se solicita un desafío multifactor, las Actions posteriores no se ejecutarán hasta que el usuario haya
completado ese desafío. Se considerará que un usuario ha superado el desafío en cualquiera de las siguientes situaciones:
Completa correctamente el desafío para cualquiera de los factores.
Si alguno de los factores solicitados ya se completó correctamente en la transacción actual, se
ignorará.Si se solicita un factor que no está habilitado en el inquilino, se ignorará. Si se solicita un factor en el que el usuario
no se ha inscrito, se ignorará. Si ninguno de los factores solicitados está habilitado o inscrito, la transacción de autenticación
fallará (es decir, el inicio de sesión no se completará).
Este método hará que se muestre la pantalla de selección de factor si el usuario aún no ha cumplido
los requisitos del desafío. Si hay un factor preferido, es preferible usar el método api.authentication.challengeWith().
La pantalla de selección de factor no se mostrará si solo se pasa un factor o si solo uno es válido.
Solicita una inscripción en la autenticación multifactor mediante el factor proporcionado y factores adicionales opcionales.Cuando se solicita una inscripción multifactor, las Actions posteriores no se ejecutarán hasta que el usuario complete esa inscripción.Si alguno de los factores solicitados ya fue inscrito o verificado correctamente en la transacción actual, se ignorará.Si se solicita un factor que no está habilitado en el inquilino, se ignorará.
Si se solicita un factor para el que el usuario ya está inscrito, se ignorará.
Si ninguno de los factores solicitados está habilitado y aún no ha sido inscrito, la
transacción de autenticación fallará (es decir, el inicio de sesión no se completará).
Solicita una inscripción en la autenticación multifactor con cualquiera de los factores proporcionados (mostrando primero una
pantalla de selección de factor).Cuando se solicita una inscripción multifactor, las Actions posteriores no se ejecutarán hasta que el usuario haya
completado esa inscripción.Si alguno de los factores solicitados ya se inscribió correctamente en la transacción actual, se
ignorará.Si se solicita un factor que no está habilitado en el inquilino, se ignorará.
Si se solicita un factor en el que el usuario ya está inscrito, se ignorará.
Si ninguno de los factores solicitados está habilitado y aún no está inscrito, la
transacción de autenticación fallará (es decir, el inicio de sesión no se completará).
Si hay un factor preferido, se recomienda usar el método api.authentication.enrollWith().
La pantalla de selección de factor no se mostrará si solo se pasa un factor o si solo uno es válido.
Indica que se ha completado un método de autenticación personalizado en la
sesión actual. Este método estará disponible después en el array
event.authentication.methods en inicios de sesión posteriores.IMPORTANTE: Esta API solo está disponible dentro de la función onContinuePostLogin
para Actions de PostLogin. En otras palabras, puede usarse para registrar
la finalización de un método de autenticación personalizado después de redirigir al usuario con
api.redirect.sendUserTo().
Cambia el usuario principal de la transacción de inicio de sesión.En los escenarios que requieren vincular usuarios, la identidad de usuario utilizada para iniciar sesión puede dejar de
existir como un usuario independiente. Esa identidad puede pasar a ser una identidad secundaria de un usuario existente. En
esas situaciones, la función setPrimaryUser() puede usarse para indicar que debe cambiarse el sujeto del
inicio de sesión.IMPORTANTE: Vincular cuentas de forma insegura puede permitir que actores maliciosos accedan a cuentas
legítimas de usuarios.IMPORTANTE: La identidad utilizada para autenticar el inicio de sesión debe estar entre las identidades secundarias
del usuario al que hace referencia primary_user_id. De lo contrario, el inicio de sesión fallará y no se emitirán tokens.
Habilita la autenticación multifactor para este flujo de inicio de sesión. Cuando está habilitada, los usuarios deben completar el
desafío multifactor configurado. El desafío multifactor propiamente dicho se aplaza hasta el
final del flujo de inicio de sesión.
El nombre del proveedor multifactor que se va a usar o el valor "any" para usar cualquiera
de los proveedores configurados.Valores permitidos: duo, none, guardian, google-authenticator, any
Cuando provider se establece en google-authenticator o duo, se solicita MFA al usuario una vez
cada 30 días. Cuando provider se establece en guardian, la pantalla de MFA muestra la casilla de
inscripción para que los usuarios elijan si desean inscribirse o no. El valor predeterminado es false. Para obtener más información,
consulta Personalizar las páginas de autenticación multifactor.
Crea un token de sesión apto para usarse como parámetro de consulta del destino de redirección (mediante sendUserTo)
que contenga datos cuya autenticidad deba poder demostrar el endpoint de destino. El endpoint de destino
puede verificar la autenticidad e integridad de los datos comprobando la firma del JWT
mediante un secreto compartido.El secreto compartido debe almacenarse como un secret de la Action y estará disponible en
event.secrets['<secret_name>'].
Un secreto que se utilizará para firmar un JWT que se comparte con el destino de la redirección. El
valor del secreto debe almacenarse como un secret y recuperarse mediante
event.secrets['<secret_name>'].
Hace que el flujo de inicio de sesión active una redirección del navegador a la url de destino inmediatamente después de que
esta acción finalice. El método auxiliar createUrl se proporciona para simplificar la codificación de
datos como parámetro de consulta en la url de destino, de modo que el endpoint de destino pueda verificar la autenticidad y la
integridad de los datos.
Establece metadatos específicos de la aplicación para el usuario que inicia sesión.Nota: Este método no debe usarse en callbacks. Invocarlo no actualizará los metadatos de inmediato.
Puede llamar a este método varias veces a lo largo de varias Actions del mismo flujo, y el motor agrupará los
cambios y actualizará los metadatos de una sola vez antes de que se complete el flujo. Esta función solo funciona con metadatos que
estén en formato de objeto.
Establece metadatos generales para el usuario que inicia sesión.Nota: Este método no debe usarse en callbacks. Si invoca este método, los metadatos no se actualizarán de inmediato.
Puede llamarlo varias veces a lo largo de varias Actions del mismo flujo, y el motor agrupará los cambios y actualizará los metadatos de una sola vez antes de que se complete el flujo. Esta función solo funciona con metadatos que están en formato de objeto.
Recupera un registro que describe un valor almacenado en caché en la clave proporcionada,
si existe. Si se encuentra un registro, el valor almacenado en caché se puede encontrar
en la propiedad value del objeto devuelto.
Almacena o actualiza un valor de cadena en la caché para la clave especificada.Los valores almacenados en esta caché se limitan al Trigger en el que
se establecen. Están sujetos a los límites de caché de Actions.Los valores almacenados de esta forma tendrán una duración de hasta los valores
ttl o expires_at especificados. Si no se especifica ninguna duración, se usará
una duración predeterminada de 15 minutos. La duración no puede superar la duración máxima
indicada en límites de caché de Actions.Importante: Esta caché está diseñada para datos efímeros de corta duración. Es posible que los elementos no estén
disponibles en transacciones posteriores aunque aún estén dentro de la duración proporcionada.
La hora de vencimiento absoluta en milisegundos desde la época de Unix.
Aunque los registros en caché pueden eliminarse antes, nunca
permanecerán más allá del valor expires_at proporcionado.Nota: No debe proporcionarse este valor si también se
proporcionó un valor para ttl. Si se proporcionan ambas opciones, se
usará la expiración más temprana de las dos.
El valor de tiempo de vida de esta entrada de caché en milisegundos.
Aunque los valores en caché pueden eliminarse antes, nunca
permanecerán más allá del valor ttl proporcionado.Nota: No debe proporcionarse este valor si también se
proporcionó un valor para expires_at. Si se proporcionan ambas opciones, se
usará la expiración más temprana de las dos.
Destinatario de la aserción SAML (SubjectConfirmationData).
El valor predeterminado es AssertionConsumerUrl en SAMLRequest o la URL de retorno si no se envió ninguna SAMLRequest.
Si es true (valor predeterminado), para cada reclamación que no esté asignado al perfil común, Auth0 lo incluye en la aserción de salida.
Si es false, esas reclamaciones no se asignarán.
Si passthroughClaimsWithNoMapping es true y esto es false (valor predeterminado), Auth0 agrega el prefijo http://schema.auth0.com a cada reclamación que no esté asignada al perfil común.
Si es true, la reclamación se transmite tal cual.
Si es true (valor predeterminado), agrega más información al token, como el proveedor (Google, ADFS, AD, etc.) y el token de acceso, si está disponible.
Destino de la respuesta SAML. Si no se especifica, será la AssertionConsumerUrl de la SAMLRequest o la URL de devolución de llamada si no hubo ninguna SAMLRequest.
Indica si se debe firmar la respuesta SAML.
De forma predeterminada, se firmará la aserción SAML, pero no la respuesta SAML.
Si es true, se firmará la respuesta SAML en lugar de la aserción SAML.
El valor predeterminado es false.
Auth0 intentará usar cada uno de los atributos de esta matriz en orden.
Si alguno de ellos tiene un valor, usará ese valor para Subject/NameID.El orden es:
Indica opcionalmente el certificado de clave pública que se utiliza para validar las solicitudes SAML.
Si se configura, será obligatorio que las solicitudes SAML estén firmadas.
Un valor de ejemplo sería “-----BEGIN CERTIFICATE-----\nMIIC8jCCAdqgAwIBAgIJObB6jmhG0QIEMA0GCSqGSIb3DQEBBQUAMCAxHjAcBgNV\n[..all the other lines..]-----END CERTIFICATE-----\n”.
Cuando se establece en true, inferimos el NameFormat en función del nombre del atributo. Los valores de NameFormat son urn:oasis:names:tc:SAML:2.0:attrname-format:uri, urn:oasis:names:tc:SAML:2.0:attrname-format:basic y urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified.
Si se establece en false, no se establece el NameFormat del atributo en la aserción.
El valor predeterminado es true.
Si se establece en true, se infiere el xs:type del elemento. Los tipos son xs:string, xs:boolean, xs:double y xs:anyType.
Si se establece en false, todos los xs:type son xs:anyType.
El valor predeterminado es true.
De forma opcional, especifique un certificado para cifrar la aserción SAML.
El certificado debe obtenerse del proveedor de servicios.
Deben especificarse tanto el certificado como la clave pública.
Un valor de ejemplo sería “-----BEGIN CERTIFICATE-----\nMIIC8jCCAdqgAwIBAgIJObB6jmhG0QIEMA0GCSqGSIb3DQEBBQUAMCAxHjAcBgNV\n[..all the other lines..]-----END CERTIFICATE-----\n”.
Opcionalmente, especifique una clave pública para cifrar la aserción SAML.
La clave pública debe obtenerse del proveedor de servicios.
Deben especificarse tanto la clave pública como el certificado.
Un valor de ejemplo sería “-----BEGIN PUBLIC KEY-----\nnMIIC8jCCAdqgAwIBAgIJObB6jmhG0QIEMA0GCSqGSIb3DQEBBQUAMCAxHjAcBgNV\n[..all the other lines..]-----END PUBLIC KEY-----\n”.
De forma predeterminada, Auth0 usará el par de claves pública/privada asignado a tu inquilino para firmar respuestas o aserciones SAML.
En situaciones muy específicas, puede que quieras proporcionar tu propio certificado y clave privada.Debes especificar tanto el certificado como la clave privada.
Un valor de ejemplo sería “-----BEGIN CERTIFICATE-----\nMIIC8jCCAdqgAwIBAgIJObB6jmhG0QIEMA0GCSqGSIb3DQEBBQUAMCAxHjAcBgNV\n[..all the other lines..]-----END CERTIFICATE-----\n”.
De forma predeterminada, Auth0 usará el par de claves pública y privada asignado a tu inquilino para firmar respuestas o aserciones SAML.
En escenarios muy específicos, es posible que quieras proporcionar tu propio certificado y clave privada.Dado que esta clave privada es confidencial, te recomendamos usar la funcionalidad Add Secret de Actions.
Consulta este enlace para obtener más detalles: https://auth0.com/docs/customize/actions/write-your-first-action#add-a-secretSe deben especificar tanto el certificado como la clave privada.
Un valor de ejemplo sería “-----BEGIN PRIVATE KEY-----\nnMIIC8jCCAdqgAwIBAgIJObB6jmhG0QIEMA0GCSqGSIb3DQEBBQUAMCAxHjAcBgNV\n[..all the other lines..]-----END PRIVATE KEY-----\n”.
[cliente empresarial] Revoca el Token de actualización del usuario actual y marca como denegado el intento actual de intercambio del token de actualización. Esto impedirá
que el usuario final complete el flujo de intercambio del token de actualización y revocará el Token de actualización que se está usando actualmente.
El flujo de intercambio del token de actualización se detendrá inmediatamente después de completar esta acción y no se ejecutará ninguna Action adicional.Este método solo puede usarse durante el flujo de intercambio de Token de actualización, cuando event.transaction.protocol === "oauth2-refresh-token".
Una explicación comprensible para las personas sobre el rechazo del intercambio del token de actualización. Puede mostrarse
directamente en las interfaces de usuario final.
[cliente empresarial] Establece una nueva fecha de expiración absoluta para el token de actualización actual.
La expiración no puede establecerse por encima de la duración máxima del token de actualización configurada en los ajustes.
Si se llama varias veces, se usará la fecha de expiración más próxima.
Obligatorio: la nueva fecha de expiración absoluta, en milisegundos desde la época Unix, tras la cual el Token de actualización se considerará no válido.
[cliente empresarial] Establece un nuevo tiempo de expiración por inactividad para el token de actualización actual.
La expiración no puede configurarse por encima de la duración máxima absoluta del token de actualización establecida en la configuración.
Si se llama varias veces, se usará el tiempo de expiración más próximo.
Obligatorio, el nuevo tiempo de inactividad en milisegundos desde la época de Unix, después del cual el Token de actualización se considerará inválido
si no se utiliza durante este período.
[Clientes empresariales] Revoca la sesión actual del usuario y marca el intento de inicio de sesión actual como denegado. Esto impedirá
que el usuario final complete el flujo de inicio de sesión y revocará su sesión. El flujo de inicio de sesión se
detendrá inmediatamente después de completar esta acción y no se ejecutará ninguna otra Action.
El valor predeterminado es false. Si es true, el sistema finaliza la sesión y conserva los tokens de actualización. La aplicación puede seguir obteniendo tokens de acceso durante la vigencia del token de actualización.
Revoke the session while preserving refresh tokens
[cliente empresarial] Establece un nuevo momento de expiración absoluta para la sesión actual.
La expiración no se puede establecer por encima de la duración máxima de la sesión configurada en la configuración del inquilino.
Si se llama varias veces, se usará el momento de expiración más próximo.
[cliente empresarial] Establece una nueva hora de expiración por inactividad para la sesión actual.
La expiración no puede establecerse por encima de la duración máxima absoluta de la sesión configurada en los ajustes del inquilino.
Si se llama varias veces, se usará la hora de expiración más temprana.
Obligatorio: la nueva hora de expiración por inactividad en milisegundos desde la época Unix, tras la cual la sesión se considerará no válida si no hay
interacción del usuario durante este período.
[Clientes empresariales] [Acceso anticipado] Establece el modo de cookie para la sesión actual, lo que permite que sea ‘persistent’ o ‘non-persistent’ (efímera).
Esto determina cómo se maneja la cookie de sesión en el navegador:
‘persistent’: La cookie se almacenará hasta que expire o el usuario la elimine.
‘non-persistent’ (efímera): La cookie se eliminará cuando se cierre el navegador.
Si se realizan varias invocaciones a setCookieMode, solo la última surtirá efecto. Si se establece ‘non-persistent’, la cookie se eliminará cuando se cierre el navegador; sin embargo, la sesión seguirá siendo válida hasta que se alcance su tiempo de expiración absoluto o por inactividad
o hasta que se revoque mediante las API disponibles. Para obtener más información sobre los modos de cookie, consulta nuestra documentación.
Obligatorio, el modo de cookie para la sesión actual.
Puede ser ‘persistent’ o ‘non-persistent’ (efímera).Valores permitidos: persistent, non-persistent
Almacena o actualiza el valor de una clave especificada en los metadatos de la transacción.Los metadatos modificados con este método se actualizan en tiempo real en el
objeto event.transaction.metadata.
Autenticar
Administrar usuarios
Personalizar
Auth0 AI
Plataforma