Saltar al contenido principal
El protocolo OpenID Connect admite un parámetro prompt=none en la solicitud de autenticación que permite a las aplicaciones indicar que el no debe mostrar ninguna interacción con el usuario (como autenticación, consentimiento o ). Auth0 devolverá a la aplicación la respuesta solicitada o devolverá un error si el usuario todavía no está autenticado o si se requiere algún tipo de consentimiento o pantalla antes de continuar. El uso del Flujo implícito en las SPA plantea desafíos de seguridad que requieren estrategias de mitigación explícitas. Puede usar el Flujo de código de autorización con PKCE junto con la autenticación silenciosa para renovar las sesiones en las SPA.
Los avances recientes en los controles de privacidad de los usuarios en los navegadores afectan negativamente a la experiencia de usuario al impedir el acceso a cookies de terceros; por lo tanto, los flujos basados en navegador deben usar la rotación de tokens de actualización, que proporciona un método seguro para usar tokens de actualización en las SPA y, al mismo tiempo, ofrecer a los usuarios finales acceso continuo a los recursos sin la interrupción de la UX causada por tecnologías de privacidad del navegador como ITP.

​
Inicie solicitudes de autenticación silenciosa

Para iniciar una solicitud de autenticación silenciosa, agregue el parámetro prompt=none al redirigir a un usuario al endpoint /authorize de la API de autenticación de Auth0. (Los parámetros concretos de la solicitud de autenticación variarán según las necesidades específicas de su aplicación). Por ejemplo: El parámetro prompt=none hace que Auth0 envie inmediatamente un resultado al redirect_uri especificado (URL de callback), mediante el response_mode especificado, con una de estas dos respuestas posibles: éxito o error.
Cualquier rules aplicable se ejecutará como parte del proceso de autenticación silenciosa.

​
Modos de respuesta

El parámetro response_mode determina cómo Auth0 envía la respuesta de autorización a tu aplicación. Para la autenticación silenciosa, puedes usar:
ModoMétodo de entregaCaso de uso
queryCadena de consulta (?code=...)Flujo de código de autorización con manejo del lado del servidor
fragmentFragmento de URL (#access_token=...)Flujo implícito (heredado)
web_messageAPI postMessage()Recomendado para SPA: no requiere navegación de página
Al usar web_message, Auth0 renderiza una página HTML dentro de un iframe oculto que usa la API de mensajería web de HTML5 para comunicar el resultado a tu aplicación. Esto permite la autenticación silenciosa sin redirecciones de página visibles ni pérdida de estado.
Para usar response_mode=web_message, debes agregar la URL de tu aplicación al campo Allowed Web Origins en la configuración de la aplicación. Para obtener más detalles sobre todos los modos de respuesta, consulta OAuth 2.0 Authorization Framework.

​
Respuestas de autenticación correctas

Si el usuario ya había iniciado sesión en Auth0 y no se requieren otras pantallas interactivas, Auth0 responderá exactamente igual que si el usuario se hubiera autenticado manualmente a través de la página de inicio de sesión. El formato de la respuesta depende del response_mode utilizado:
Al usar response_mode=web_message con Flujo de código de autorización con PKCE (response_type=code), Auth0 devuelve una página HTML que envía el código de autorización a su aplicación:
<script>
  window.parent.postMessage({
    type: 'authorization_response',
    response: {
      code: 'SplX...GT',
      state: 'your_state_value'
    }
  }, 'https://yourApp.com');
</script>
Su aplicación (o SDK) escucha este mensaje y canjea el code por tokens. Si el usuario no tiene una sesión válida, Auth0 envía un error en su lugar:
<script>
  window.parent.postMessage({
    type: 'authorization_response',
    response: {
      error: 'login_required',
      error_description: 'Login required',
      state: 'your_state_value'
    }
  }, 'https://yourApp.com');
</script>
Estas respuestas tienen un formato idéntico al de un inicio de sesión realizado directamente sin el parámetro prompt=none. La única diferencia es que, con prompt=none, la respuesta es inmediata y no requiere ninguna interacción del usuario.

​
Respuestas de error

Si el usuario no había iniciado sesión mediante (SSO) o su sesión de SSO había caducado, Auth0 devuelve un error con el mismo response_mode. Para los modos basados en redirecciones (fragment o query): 
GET https://your_callback_url/
    #error=ERROR_CODE&
    error_description=ERROR_DESCRIPTION&
    state=...
Para el modo web_message, el error se envía mediante postMessage(), como se muestra en el ejemplo anterior. Los posibles valores de ERROR_CODE están definidos en la especificación de OpenID Connect:
RespuestaDescripción
login_requiredEl usuario no había iniciado sesión en Auth0, por lo que no es posible realizar la autenticación silenciosa. Este error puede producirse según cómo estén configurados los ajustes de Administración de sesiones de inicio de sesión a nivel del inquilino; en concreto, puede producirse una vez transcurrido el período establecido en la opción Solicitar inicio de sesión después de. Consulta Configurar ajustes de duración de la sesión para obtener más información.
consent_requiredEl usuario había iniciado sesión en Auth0, pero debe otorgar su consentimiento para autorizar la aplicación.
interaction_requiredEl usuario había iniciado sesión en Auth0 y ha autorizado la aplicación, pero debe ser redirigido a otro lugar antes de que se pueda completar la autenticación; por ejemplo, al usar una regla de redirección.
Si se devuelve cualquiera de estos errores, se debe redirigir al usuario a la página de inicio de sesión de Auth0 sin el parámetro prompt=none para que se autentique.

​
Renovar tokens vencidos

Puede realizar una solicitud de autenticación silenciosa para obtener tokens nuevos, siempre que el usuario siga teniendo una sesión válida en Auth0. El método checkSession de auth0.js usa una solicitud silenciosa de tokens en combinación con response_mode=web_message para las SPA, de modo que la solicitud se realice en un iframe oculto. En las SPA, Auth0.js procesa el resultado (ya sea el token o el code de error) y pasa la información mediante una función callback proporcionada por la aplicación. Esto evita cualquier interrupción en la experiencia de usuario (sin actualizar la página ni perder el estado).
Consulte Renovar tokens al usar Safari para conocer otras limitaciones importantes y soluciones alternativas relacionadas con el navegador Safari.

​
Expiración del Token de acceso

Los son opacos para las aplicaciones. Esto significa que las aplicaciones no pueden inspeccionar el contenido de los Tokens de acceso para determinar su fecha de expiración. Hay dos opciones para determinar cuándo expira un Token de acceso:
  • Leer el parámetro de respuesta expires_in que devuelve Auth0.
  • Ignorar por completo las fechas de expiración. En su lugar, renueve el Token de acceso si su API rechaza una solicitud de la aplicación (por ejemplo, con un 401).
En el caso del Flujo implícito, Auth0 devuelve el parámetro expires_in como parámetro hash después de una autenticación correcta. En el Flujo de código de autorización con PKCE, se devuelve al servidor backend al realizar el intercambio del código de autorización. El parámetro expires_in indica durante cuántos segundos será válido el Token de acceso y puede usarse para anticipar su expiración.

​
Respuesta de error

Puede recibir la respuesta de error timeout, que indica que se agotó el tiempo de espera durante la ejecución de la comunicación web_message. Este error suele estar asociado con el uso de la autenticación entre orígenes como mecanismo de respaldo. Para resolverlo, asegúrese de agregar todas las URL desde las que desea realizar la autenticación silenciosa en el campo Allowed Web Origins de su aplicación mediante el .

​
Sondeo con checkSession()

En algunos escenarios con varias aplicaciones, en los que se desea el cierre de sesión único (cuando un usuario cierra sesión en una aplicación, también debe cerrarla en las demás), una aplicación puede configurarse para consultar periódicamente a Auth0 mediante checkSession() y verificar si existe una sesión. Si la sesión no existe, puede cerrar la sesión del usuario en la aplicación. Este mismo método de sondeo también puede usarse para implementar autenticación silenciosa en un escenario de inicio de sesión único (SSO). El intervalo de sondeo entre llamadas a checkSession() debe ser de al menos 15 minutos para evitar posibles problemas futuros con la limitación de frecuencia de esta llamada.

​
Autenticación silenciosa con MFA

En algunos escenarios, es posible que quiera evitar solicitar al usuario la autenticación multifactor (MFA) cada vez que inicie sesión desde el mismo navegador. Para ello, configure una regla para que la MFA se produzca solo una vez por sesión. Esto resulta útil al realizar autenticación silenciosa (prompt=none) para renovar tokens de acceso de corta duración en una SPA durante la sesión de un usuario, sin tener que depender de configurar allowRememberBrowser en true. 
exports.onExecutePostLogin = async (event, api) => {
  const authMethods = event.authentication?.methods || []

  const completedMfa = !!authMethods.find((method) => method.name === 'mfa')

  if (!completedMfa) {
    api.multifactor.enable('any', { allowRememberBrowser: true })
  }
};
Para obtener más información, consulta Cambiar la frecuencia de las solicitudes de autenticación.

​
Más información