Saltar al contenido principal
Auth0 es un proveedor certificado de OpenID Connect (OIDC). Como parte de los esfuerzos de Auth0 por mejorar la seguridad y la interoperabilidad basada en estándares, implementamos nuevas funcionalidades exclusivamente en flujos de autenticación que cumplen estrictamente las especificaciones de OIDC. Explicaremos las diferencias entre el pipeline compatible con OIDC y los pipelines heredados, y ofreceremos sugerencias sobre cómo adaptar sus aplicaciones existentes. Esta información está dirigida a desarrolladores y administradores de TI que gestionan integraciones de Auth0 en sus aplicaciones mediante el marco de autorización OAuth 2.0. No es aplicable si usa o WS-Federation. Todos los flujos de autenticación se describen mediante solicitudes HTTP, en lugar de hacerlo en el contexto de una implementación concreta de lenguaje o biblioteca. Todas las funcionalidades nuevas están dirigidas únicamente al pipeline compatible con OIDC, y todas las versiones heredadas de los SDK de Auth0 están obsoletas, no reciben actualizaciones para nuevas funcionalidades ni para problemas de seguridad no críticos, y con el tiempo dejarán de estar disponibles. Además, toda la documentación, las bibliotecas y los ejemplos fuera de esta guía se aplican únicamente al pipeline compatible con OIDC. Por ello, recomendamos encarecidamente adoptar el pipeline compatible con OIDC, incluso si no necesita aprovechar ninguna funcionalidad nueva en el futuro inmediato.

​
Aplicar la pipeline compatible con OIDC

Según la antigüedad de su inquilino, puede tener distintas opciones para aplicar la pipeline compatible con OIDC.

​
Nuevos inquilinos

Si crea un nuevo inquilino mediante el , la pipeline compatible con OIDC se usa de forma predeterminada. Esta es la configuración predeterminada del Dashboard desde principios de 2019.
Es posible que haya deshabilitado manualmente la opción OIDC Conformant; en ese caso, debe seguir nuestras instrucciones para inquilinos anteriores.

​
Inquilinos antiguos

Si quiere aplicar al mismo tiempo todos los cambios descritos en esta guía para una aplicación concreta, de modo que pueda detectar todos los cambios incompatibles durante la configuración en lugar de en tiempo de ejecución, debe hacer lo siguiente:
  1. Vaya a Dashboard > Applications > Applications y seleccione la aplicación que desee.
  2. Desplácese hasta Advanced Settings y vaya a la pestaña OAuth.
  3. Active el interruptor OIDC Conformant y haga clic en Save Changes.
Si quiere usar la pipeline compatible con OIDC para cada solicitud de autenticación y su aplicación necesita llamar a una API con un , inicie la solicitud al endpoint /social con un parámetro audience. Si quiere usar la pipeline compatible con OIDC para cada solicitud de autenticación y su aplicación no necesita llamar a una API, use el siguiente parámetro audience:

​
Diferencias

Al habilitar el pipeline compatible con OIDC, se aplican los siguientes cambios al pipeline heredado.

​
APIs

Las aplicaciones y las API (recursos) deben definirse como entidades independientes en Auth0. Para obtener más información, consulte Adopción compatible con OIDC: API.

​
Tokens de acceso

  • Las API deben protegerse con tokens de acceso en lugar de . Para obtener más información sobre las diferencias, consulta Tokens.
  • Se puede devolver un conjunto definido de claims estándar sobre los usuarios en los ID Tokens o en la respuesta de /userinfo.
  • Los claims personalizados deben ajustarse a un formato con nombre. Para obtener más información, consulta Create Namespaced Custom Claims.
  • Las respuestas de /userinfo cumplirán con la especificación OIDC, al igual que el contenido de los tokens de ID
  • Los alcances pueden usarse para solicitar claims estándar o permisos personalizados de API.
Para obtener más información, consulta OIDC-Conformant Adoptions: Access Tokens.

​
Flujos de autorización

  • Flujo de código de autorización: Existen diferencias estructurales en la solicitud de autenticación, la respuesta de autenticación, la solicitud de intercambio de código, la respuesta de intercambio de código, la estructura del ID Token y la estructura del token de acceso.
  • Flujo de credenciales de cliente: Se habilitó un nuevo flujo que permite que las aplicaciones se autentiquen por sí mismas (en lugar de hacerlo en nombre de un usuario) para obtener acceso a una API de forma programática y segura.
  • Flujo implícito: Existen diferencias estructurales en la solicitud de autenticación, la respuesta de autenticación, la estructura del ID Token y la estructura del token de acceso. En concreto:
    • response_type=token solo devuelve un token de acceso. Para obtener un ID Token, use response_type=id_token o response_type=token id_token.
    • Los ID Token se firmarán de forma asimétrica con RS256.
    • Se rechazarán las solicitudes de autenticación realizadas sin un parámetro nonce. Para obtener más información, consulte Mitigue los ataques de repetición al usar el flujo implícito.
    • Ya no se devolverán tokens de actualización cuando se use el Flujo implícito para la autenticación.
  • Flujo de contraseña del propietario del recurso: Existen diferencias estructurales en la solicitud de autenticación, la respuesta de autenticación, la estructura del ID Token y la estructura del token de acceso. En concreto:

​
Delegación

  • Obsoleto: endpoint /delegation, excepto cuando se utiliza para obtener tokens de API de terceros.
  • Las aplicaciones compatibles con OIDC no pueden ser el origen ni el destino de las solicitudes de delegación.
Para obtener más información, consulta Adopción compatible con OIDC: Delegación.

​
Endpoints

  • Obsoleto: endpoint /tokeninfo
  • Deshabilitado: el endpoint /oauth/access_token (se usa para la autenticación social desde aplicaciones móviles nativas).
  • Obsoleto: endpoint /ssodata
  • Obsoleto: el endpoint /delegation, excepto cuando se usa para obtener tokens de API de terceros.

​
Tokens de actualización

  • ya no se devolverán al usar el Flujo implícito para la autenticación.
  • Los tokens de actualización pueden usarse en aplicaciones confidenciales, pero la puede aumentar la seguridad en la mayoría de los flujos y siempre debe usarse en aplicaciones públicas cuando se utiliza el Flujo de código de autorización con PKCE. Para obtener información sobre las aplicaciones confidenciales, consulte Confidential and Public Applications. Para obtener más información sobre la rotación de tokens de actualización, consulte Refresh Token Rotation.
  • Al obtener nuevos tokens, debe usar el endpoint /oauth/token.
  • El parámetro device ya no es necesario al solicitar un token de actualización mediante el scope offline_access en las solicitudes de autenticación.
Para obtener más información, consulte OIDC-Conformation Adoption: Refresh Tokens.

​
Inicio de sesión único (SSO)

  • El solo puede realizarse desde las páginas de inicio de sesión de Auth0, lo que significa que debe usar .
  • Para determinar si los usuarios han iniciado sesión mediante SSO, debe usar autenticación silenciosa. Para obtener más información, consulte Configure Silent Authentication.
  • Obsoleto: el endpoint /ssodata y el método getSSOData() de Lock/auth0.js.
Para obtener más información, consulte OIDC-Conformant Adoption: Single Sign-On.

​
Funcionalidades adicionales