Proveedor de identidad único: Autorización

Obtén información sobre cómo autorizar usuarios para Organizaciones en arquitecturas de múltiples inquilinos.

Al pensar en la autorización, normalmente debes considerar cómo determinas qué puede hacer una persona y cómo comunicas esta información a tus aplicaciones y/o API. Según las aplicaciones que tengas, una o ambas cuestiones pueden afectarte. En nuestros escenarios de arquitectura, ofrecemos orientación de propósito general sobre Autorización B2B, cuya revisión recomendamos junto con la orientación que se proporciona aquí.

• Los ID Tokens suelen usarse para transmitir información de autorización del usuario a las aplicaciones mediante claims personalizados, que pueden agregarse con la extensibilidad de Rules. Los claims agregados pueden permitirte presentar una interfaz de usuario en la que los usuarios no puedan intentar hacer algo para lo que no tienen permiso. La información de autorización en un ID Token también proporciona a cualquier backend de la aplicación una forma de impedir que los usuarios eludan los controles del frontend en aplicaciones web tradicionales.

Práctica recomendada

Puedes aprovechar el control de acceso basado en roles de Auth0 (RBAC) mediante la funcionalidad Auth0 Authorization Core para definir permisos de acceso, que pueden aplicarse automáticamente a los Tokens de acceso. Para obtener más información, consulta Habilitar el control de acceso basado en roles para API.

La funcionalidad RBAC de Auth0 también puede proporcionar información que puedes agregar como claims personalizados a los tokens de identidad (y a los tokens de acceso, si prefieres aplicarlos manualmente). Auth0 Organizations puede aprovechar la capacidad RBAC de Auth0 mediante uno o más roles asignados por membresía. Para obtener más información, consulta Agregar roles a los miembros de una organización.

• Las API que proporcionan acceso público a servicios de recursos compartidos suelen estar protegidas mediante mecanismos de control de acceso. Para este fin, Auth0 ofrece la capacidad de crear un token bearer de autorización, o un OAuth 2 token de acceso, que puede transmitir información de autorización del usuario a una API, normalmente mediante el uso de control de acceso basado en roles (RBAC) de Auth0 para aplicar uno o más roles asignados por membresía o agregando claims personalizados mediante la extensibilidad de Rules. También puedes aprovechar la capacidad RBAC de Auth0 para ajustar automáticamente el claim scope de un token de acceso. Luego, las API pueden usar esta información para aplicar el nivel adecuado de control de acceso, lo que permite que tu API aplique reglas de política sin tener que hacer una consulta adicional para obtener información sobre el usuario.
• En ciertos casos, quizá quieras implementar políticas a nivel de aplicación en el Tenant de Auth0; esto te permite aplicar políticas a toda una gama de aplicaciones y servicios de recursos (API) sin necesidad de modificar cada uno de ellos por separado. Normalmente, esto se implementa mediante la extensibilidad de Rules.

Práctica recomendada

Auth0 Organizations proporciona a Auth0 Rules acceso a información centrada en la organización, a la que se puede acceder al autenticar a un usuario. Esta información está disponible a través del objeto organization incluido en el objeto context de Rules. El objeto organization también proporciona acceso a cualquier metadato aprovisionado en una definición de organización en Auth0. Para obtener más información, consulta Desarrollo personalizado para organizaciones.

​

Claims del token de ID

Normalmente, se pueden agregar claims a los tokens de identidad, como se explica en nuestra guía de prácticas recomendadas sobre claims del ID Token. Al usar la funcionalidad de Auth0 Organizations, se agrega automáticamente un claim org_id a cualquier token de identidad emitido para usuarios que pertenecen a una organización (para ver un ejemplo, consulta Work with Tokens and Organizations). Los SDK de Auth0 validan este parámetro. También puedes agregar información adicional asociada a una Organización de Auth0 mediante un claim personalizado en el token de identidad:

context.idToken['http://travel0.net/multifactor'] = context.multifactor;

Nota: Si ha configurado su inquilino para admitir nombres de organización en la Authentication API, el claim org_name se incluye automáticamente en los tokens de ID. Para obtener más información, consulte Usar nombres de organización en la Authentication API.

​

Aserción SAML

Si bien la funcionalidad Organización de Auth0 no admite aplicaciones compatibles con SAML, una aserción SAML generada por un Proveedor de identidad (IdP) de origen se puede configurar para rellenar claims estándar o personalizados en un token de identidad consumido posteriormente. Por ejemplo, podría definir la sección mappings de una conexión empresarial SAML:

{ 
  "user_id": [
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn",
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
  ],
  "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
  "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
  "given_name": [
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
  ], 
  "family_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname",
  "groups": "http://schemas.xmlsoap.org/claims/Group"
}

En este ejemplo, a cada campo se le asignará un valor en el objeto user dentro de una Rule, que luego se asignará a claims estándar en un token de identidad o podrá asignarse mediante claims personalizadas. Para obtener más información sobre cómo personalizar las asignaciones de SAML, consulta Conecta tu aplicación con proveedores de identidad SAML: Configura las asignaciones.

​

Claims del token de acceso

Además de cualquier otro claim que agregue a su token de acceso para tomar decisiones de control de acceso (consulte nuestra guía general de Claims del token de acceso como práctica recomendada), normalmente querrá comunicar la organización a la que pertenece el usuario.

Al igual que ocurre con el token de identidad, al usar la funcionalidad Auth0 Organizations, el claim org_id se agrega automáticamente a cualquier token de acceso (para ver un ejemplo, consulte Trabajar con tokens y organizaciones) emitido para usuarios que pertenecen a una organización. También puede agregar información adicional asociada a una Organización de Auth0 añadiendo un claim personalizado al token de acceso:

context.accessToken['http://travel0.net/multifactor'] = context.multifactor;

Nota: Si ha configurado su inquilino para admitir nombres de organizaciones en la Authentication API, el claim org_name se incluye automáticamente en los tokens de acceso. Para obtener más información, consulte Usar nombres de organizaciones en Authentication API.

Como alternativa, podría crear una audiencia de API única para cada organización, lo que daría como resultado una definición de API única en Auth0. Aunque este mecanismo puede mitigar la necesidad de usar extensibilidad personalizada con Rule, la complejidad que introduce puede ser difícil de gestionar. A continuación, se muestra una comparación sencilla:

Enfoque	Ventajas	Desventajas
Audiencia de API única	Compatibilidad lista para usar para el acceso de máquina a máquina de una sola organización. La audiencia es un claim estándar en un token de acceso. El procesamiento del Token de actualización no requiere lógica adicional de organización.	Debe automatizar la creación de una API para cada organización. Es posible que sea necesario crear roles independientes si usa RBAC. Debe automatizar el aprovisionamiento de Roles para Membership. La implementación de la API debe procesar múltiples audiencias.
Claim personalizado	Simplifica la configuración del Tenant de Auth0.	Se necesita código personalizado en una Rule para agregar la organización al token de acceso.

​

Roles

La funcionalidad Auth0 Organizations también admite control de acceso basado en roles (RBAC) mediante la funcionalidad Authorization Core asociada a un Tenant de Auth0. RBAC se aplica a nivel de membresía de la Organización de Auth0.

Puede habilitar Auth0 Authorization Core RBAC para una API, lo que hará que el claim scope predeterminado en los tokens de acceso se modifique automáticamente y que se agregue de forma predeterminada el claim permission (para ver un ejemplo, consulte Trabajar con tokens y organizaciones). También puede agregar información de roles a los tokens de identidad como claims personalizadas accediendo al objeto authorization disponible en el objeto context de Rules. Para obtener más información, consulte Casos prácticos de Rules con Authorization: agregar roles de usuario a los tokens.

​

Control de acceso

La aplicación de políticas a nivel de recurso es responsabilidad de las aplicaciones y/o API de su sistema. Si intenta aplicar políticas en un Servidor de autorización centralizado, como su Tenant de Auth0, pronto se encontrará con un sistema de control complejo, difícil de mantener y comprender. En cambio, su Servidor de autorización centralizado puede garantizar que se incluya en los tokens la información adecuada sobre un usuario, para que sus aplicaciones y API dispongan de la información necesaria para tomar decisiones sobre la aplicación de políticas. Como mínimo, en situaciones en las que haya demasiada información para incluirla en un solo token (por ejemplo, permisos a nivel de recurso) o en las que la información cambie con la suficiente frecuencia como para quedar desactualizada si se consulta directamente en el token, sus aplicaciones y API deberían poder buscar la información correcta.

Por otro lado, cierta aplicación de políticas de alto nivel puede gestionarse de forma centralizada. Por ejemplo, al usar un contexto de Tenant de Auth0, hay situaciones en las que podría implementar una Rule que reduzca la necesidad de que cada aplicación y/o API aplique las mismas restricciones. Entre ellas se incluyen:

• bloquear el acceso a usuarios desde una dirección IP determinada
• implementar requisitos específicos en torno a la MFA contextual o MFA adaptativa
• restringir el inicio de sesión únicamente a usuarios que hayan verificado su correo electrónico
• restringir el acceso a una determinada audiencia de API, de modo que un usuario no pueda obtener un token de acceso para ninguna otra audiencia de API o no pueda obtener un token de acceso para esa audiencia en determinadas circunstancias. En este caso, si está creando una audiencia de API personalizada para cada organización, su Rule también debe garantizar que el usuario que se autentica pertenezca a la organización que coincida con la audiencia de API correspondiente.

El acceso a la Management API de Auth0 no está restringido por organización; el acceso a la Management API de Auth0 se realiza mediante un token de acceso asignado para su uso en un contexto de máquina a máquina y no puede limitarse mediante una Organización de Auth0. Por lo tanto, no proporcione a sus clientes acceso directo a su instancia de la Management API de Auth0. Si sus clientes deben administrar aspectos de su organización, como las cuentas de usuario (consulte Administración de perfiles), debería crear su propia aplicación y/o API independiente para este fin.