Autorización del usuario y consideraciones de planificación relacionadas para su implementación de IAM B2C.
Comencemos dando un paso atrás para hablar del Control de acceso. No existe una definición única y clara de Control de acceso en la industria, pero si dedica algo de tiempo a buscar y leer, verá que la mayoría de las fuentes de referencia coinciden en que es el concepto general que engloba la Autenticación, la Autorización, el Consentimiento y la Aplicación de políticas para garantizar que solo las personas y los servicios adecuados tengan acceso a sus aplicaciones y APIs. A continuación, veamos más de cerca las diferencias entre Autenticación, Autorización, Consentimiento y Aplicación de políticas. Su de Auth0 (su ) suele ser responsable de la Autenticación y el Consentimiento, y de parte o de la totalidad de la Autorización y la Aplicación de políticas. Además, una o la propia API casi siempre es quien aplica principalmente las políticas, especialmente cuando se requiere acceso contextual:
Autenticación: el proceso de determinar si un principal (un usuario o una aplicación) es quien o lo que dice ser.
Autorización: el proceso de determinar qué está permitido, en función del principal, de los permisos que se le han concedido y/o del conjunto de criterios de acceso específicos del contexto.
Consentimiento: los permisos que el usuario () ha autorizado a una aplicación a realizar en su nombre. Esto suele ser un requisito de la autorización delegada. El usuario debe dar permiso al cliente para acceder a los datos del usuario en un sistema diferente.
Aplicación de políticas: la acción de aplicar las políticas de la aplicación o la API, rechazando o permitiendo el acceso en función de la información de autenticación y/o autorización de un usuario.
En general, solemos agrupar los distintos tipos de control de acceso en tres categorías diferenciadas para que sea más fácil entender a) qué actor es responsable de almacenar la información, b) qué actor es responsable de tomar decisiones y c) cuál es responsable de aplicar las restricciones.
La primera categoría es aquella en la que se concede o se deniega el acceso a una aplicación o a una API en su totalidad. Tanto los datos necesarios para ello como el proceso de aplicación suelen definirse en el contexto del Servidor de autorización. Por ejemplo, mediante el uso de app_metadata asociado a un usuario y una Action definida en su inquilino de Auth0.
La segunda categoría es aquella en la que se concede o se deniega el acceso a un subconjunto específico de la funcionalidad de la aplicación o la API. Los datos necesarios para ello suelen almacenarse en el Servidor de autorización. Por ejemplo, mediante el uso de app_metadata en un usuario de su inquilino de Auth0, mientras que el proceso de aplicación se realiza en la propia aplicación o API. En este escenario, los datos suelen comunicarse como una o más reclamaciones personalizadas en un token de id o access.
La tercera categoría es aquella en la que se concede o se deniega el acceso en función de aquello sobre lo que el principal (sujeto) puede operar dentro del contexto de una aplicación o API. Tanto los datos necesarios para ello como el proceso de aplicación suelen definirse en el contexto de la aplicación o la API. En este escenario, los datos comunicados como una o más reclamaciones personalizadas en un token de id o access pueden consumirse con o sin datos de una fuente externa que no sea Auth0.
Además, los mecanismos de control de acceso basado en roles (RBAC) y control de acceso basado en atributos (ABAC) pueden aplicarse en cualquiera de las categorías de Control de acceso descritas anteriormente. Sea cual sea su caso de uso, hay una serie de aspectos que deberá considerar al evaluar la funcionalidad y el flujo de trabajo que necesita:
¿Hay escenarios en los que deba rechazarse el acceso a una aplicación o API completa?
¿Proporcionará APIs a las que puedan acceder aplicaciones de terceros?
¿Sus APIs también serán accedidas por sus propias aplicaciones (de primera parte)?
¿Su aplicación llamará a una API de terceros?
¿Sus aplicaciones y/o APIs deben aplicar control de acceso en función de las reclamaciones del usuario?
Auth0 admite la restricción de acceso a aplicaciones o API en función de determinadas condiciones. En algunos casos, es posible que quiera crear una Action que deniegue el acceso mediante api.access.deny() cuando, por ejemplo, un usuario intenta acceder a una aplicación o a una API en un momento no permitido (como se describe en este ejemplo) o si el usuario no contiene en su app_metadata los (s) correctos. En el caso de una aplicación que use OpenID Connect (OIDC), esto impediría la emisión del ID Token utilizado para autorizar el acceso. Del mismo modo, en el caso de una API, podría impedirse la emisión de cualquier OAuth2 Token de acceso (utilizado al llamar a la API), como se describe en este ejemplo.
En general, hemos observado que OIDC es el protocolo estándar del sector que más usan los clientes de Auth0 para la autenticación en sus aplicaciones. También hemos comprobado que, aunque OAuth2 se creó como un protocolo de delegación, se usa habitualmente en aplicaciones propias cuando hay una API que no comparte una sesión con la aplicación.
Auth0 también puede proporcionar la información necesaria para que una aplicación aplique restricciones. Para la integración a nivel de aplicación, Auth0 le permite agregar claims personalizados a un , que su aplicación puede verificar y usar después para aplicar políticas. En este caso, tendrá que decidir qué información necesita su aplicación para aplicar esas políticas. Si necesita tomar decisiones en una API en lugar de en su aplicación, probablemente tendrá que usar un en lugar de un token de ID. Continúe leyendo para obtener más información.
Al decidir qué datos incluir en su token de ID o token de acceso, tenga en cuenta el tamaño del token, especialmente si lo va a pasar en la URL. Incluso si no está pasando tokens en la URL, también deberá considerar la posibilidad de exponer PII (información de identificación personal) confidencial. La información del token no está cifrada, por lo que, aunque en general no supone un problema de seguridad que se filtre un token de ID, puede convertirse en un problema de privacidad según los datos que se incluyan en el token.
Para la integración a nivel de API, Auth0 admite tanto claims personalizados como la reconfiguración de scope, ambos en el contexto de un Token de acceso. De nuevo, deberá decidir qué información será necesaria para que su API tome decisiones de acceso, y su API tendrá que aplicarlo validando el contenido del Token de acceso.
Al decidir si debe usar permisos mediante claims personalizados o alcances, debe asegurarse de comprender la naturaleza y el propósito de los alcances. Hay una buena entrada de blog sobre ello que es fácil de leer y ayuda a aclarar el tema.
En este escenario, su inquilino de Auth0 proporciona un token como indicador de acceso autorizado a una aplicación. En el caso de las aplicaciones que utilizan OpenID Connect (OIDC), el protocolo estándar del sector que suele utilizarse con mayor frecuencia en aplicaciones orientadas al cliente, se trataría de un ID Token expresado como un JWT.
Con la extensibilidad de Action, Auth0 le permite agregar claims personalizados a un ID Token fácilmente en función de, por ejemplo, el contenido de los Metadata de un usuario. Después, su aplicación puede verificar el ID Token para comprobar que contiene los claims necesarios y, según corresponda, permitir o denegar el acceso a determinadas funcionalidades. Tenga en cuenta que, aunque el proceso para agregar claims personalizados mediante Action es sencillo, el entorno de ejecución de Action es flexible y le permite escribir código personalizado que podría tener efectos negativos.
Si está considerando agregar claims personalizados, le recomendamos almacenar cualquier dato de control de acceso que deba incluir en los claims como parte del app_metadata del usuario. En primer lugar, esto evita tener que llamar a una API externa para recuperar esos datos, lo que puede afectar negativamente al rendimiento y la escalabilidad de la secuencia de inicio de sesión. En segundo lugar, app_metadatano puede ser modificado por un usuario, por lo que este no puede eludir directamente ninguna restricción de control de acceso modificando sus propios . Además, recuerde consultar nuestra guía de prácticas recomendadas para metadatos.
Los alcances de OIDC suelen usarse para que una aplicación obtenga el consentimiento necesario para acceder de forma autorizada a los datos de un usuario durante la autenticación. Cada uno de los alcances predefinidos devuelve el conjunto de claims estándar cuando corresponde, tal como se describe en la especificación de OIDC. Los alcances que solicita una aplicación dependen de los atributos del usuario que necesite. Una vez que el usuario autoriza los alcances solicitados, los claims se devuelven en el ID Token y también están disponibles a través del endpoint /userinfo.
En este escenario, su inquilino de Auth0 puede proporcionar un OAuth2 Token de acceso, normalmente expresado como un JWT, que su API puede utilizar para restringir el acceso a determinadas partes. Además, Auth0 ofrece soporte para lo que, conceptualmente, se describe como aplicaciones propias y aplicaciones de terceros.Al actuar como Servidor de autorización, y con el consentimiento del usuario (el propietario del recurso), su inquilino de Auth0 puede utilizarse para proporcionar un Token de acceso —normalmente expresado como un JWT— a una aplicación (cliente) para que pueda acceder a un recurso protegido alojado en un en nombre del propietario del recurso. El Token de acceso emitido normalmente se envía como token Bearer en el encabezado HTTP Authorization de una solicitud a una API.Tanto si tiene una sola API como si tiene un conjunto de API de microservicios relacionadas lógicamente, puede aprovechar los Tokens de acceso que proporciona Auth0 para proteger el acceso a sus servicios. Aunque es relativamente fácil configurar esto en el Auth0 Dashboard o mediante la Auth0 Management API, es importante revisar los distintos escenarios de aplicación y diseños de API para determinar la mejor arquitectura para su sistema.
Los Tokens de acceso de OAuth2 están diseñados principalmente para proteger API expuestas públicamente; cuando se expresan como un JWT, un Token de acceso es una entidad autónoma que puede verificarse sin necesidad de realizar ninguna llamada adicional a una API de terceros. Si sus API no entran en esta categoría —es decir, si forman parte de una aplicación en sí (como cuando solo esa aplicación las invoca) o están detrás de su firewall—, protegerlas con tokens puede ser excesivo, y su flujo de trabajo actual basado en cookies (entre otros) probablemente sea suficiente.
OAuth2 se diseñó específicamente pensando en el acceso de terceros; por ejemplo, un escenario posible es que un usuario (propietario del recurso) quiera usar una aplicación (un cliente) que no pertenece a la misma organización que el servicio que proporciona los datos del usuario (el servidor de recursos). En este caso, cuando la aplicación necesita acceder a datos que pertenecen al usuario, redirige a la organización donde residen los datos del usuario, que a su vez autentica al usuario y luego le solicita que conceda a la aplicación permiso para acceder a sus datos. Esta solicitud de permiso se denomina consentimiento y es una parte importante de lo que implica ofrecer soporte para aplicaciones de terceros. Si planea integrar aplicaciones de terceros, es importante que las marque como de terceros desde el principio para que Auth0 gestione la solicitud de consentimiento del usuario.Por otro lado, si su organización posee las aplicaciones, los propios datos de usuario y las API a través de las cuales se accede a esos datos, normalmente no se requiere consentimiento, ya que todas las interacciones son de primera parte. Si solo está creando aplicaciones de primera parte, puede asegurarse de no mostrar a sus usuarios ninguna pantalla de consentimiento innecesaria permitiendo omitir el consentimiento del usuario como parte de cualquier definición de servicio de recursos.
Aunque puede configurar sus aplicaciones para que sean de primera parte y, posteriormente, configurar sus API para permitir que los clientes de primera parte omitan el consentimiento, si está usando localhost, Auth0 no puede verificar que la aplicación sea realmente una aplicación de primera parte, por lo que aun así se solicitará el consentimiento a sus usuarios. Para solucionar esta limitación, cuando haga pruebas en su máquina local durante el desarrollo, cree un nombre de host local falso y úselo en su lugar.
Al igual que con los ID Tokens, puedes agregar claims personalizados a los Tokens de acceso mediante la extensibilidad de Auth0 Action. Una vez añadidos, tu API puede verificar que un Token de acceso contenga los claims necesarios y permitir o denegar el acceso a determinadas funcionalidades, según corresponda.
Si estás considerando agregar claims personalizados, te recomendamos almacenar en el app_metadata del usuario cualquier dato de control de acceso que necesites incluir en los claims. En primer lugar, así evitas tener que llamar a una API externa para recuperar esos datos, lo que puede afectar negativamente al rendimiento y la escalabilidad. En segundo lugar, el usuario no puede modificar app_metadata, por lo que no puede eludir directamente ninguna restricción de control de acceso modificando sus propios metadatos. Recuerda también consultar nuestra guía de prácticas recomendadas para metadatos.
Los OAuth2 Scopes se suelen usar como el mecanismo mediante el cual una API puede determinar qué se pueden realizar en nombre de un usuario. Los alcances se pueden agregar por API para definir permisos de acceso específicos en el o mediante la Auth0 . Los alcances también se pueden manipular mediante la extensibilidad de Auth0 (por ejemplo, mediante una Action, como en este ejemplo). Los alcances que una aplicación solicita para acceder a una API deben corresponder a la funcionalidad para la que la aplicación necesita la autorización del usuario. Una vez autorizados los alcances solicitados, se devolverán en el token de acceso, que posteriormente dicha API podrá verificar. Un buen ejemplo de esto es cuando inicias sesión en una aplicación que usa un proveedor social para el inicio de sesión: la API del proveedor social requiere que la aplicación especifique si el usuario quiere que la aplicación publique contenido en su nombre. Esto permite al usuario aceptar o rechazar esta solicitud. Este ejemplo demuestra cómo el usuario delega permisos en la aplicación, lo cual es distinto de que la API restrinja el acceso según el de un usuario, y debe tratarse de forma diferente.
Práctica recomendadaAunque tienes la capacidad de manipular completamente los alcances del token de acceso mediante la extensibilidad de Auth0, como práctica recomendada de seguridad solo debes quitar los alcances que no estén autorizados y abstenerte de agregar alcances que no se hayan solicitado.
Aunque los alcances se usan con frecuencia como una forma de aplicar permisos de acceso para un usuario, hay situaciones en las que esto puede volverse complicado cuando se usan de esta manera. Por lo tanto, te recomendamos usar los alcances para el propósito previsto (es decir, delegar permisos a una aplicación) y usar claims personalizados para tus escenarios de control de acceso basado en roles o de otro tipo.
La Autorización detallada le permite otorgar a usuarios individuales acceso a un recurso u objeto específico en función de lo siguiente:
El rol de un usuario dentro de una organización, como editor o admin
Un atributo del usuario o del objeto, como manager para un usuario o marketing para un objeto
Una relación entre un usuario y un objeto, por ejemplo, que un usuario con acceso de visualización a una carpeta principal también tenga acceso de visualización a la carpeta secundaria
Con , puede crear un modelo de autorización para definir qué relaciones quiere usar para determinar el acceso del usuario.
Auth0 ofrece soporte nativo para el control de acceso basado en roles (RBAC). RBAC consiste en asignar permisos a los usuarios según su rol dentro de una organización y simplifica el control de acceso al ofrecer un enfoque más fácil de gestionar y menos propenso a errores.
Hay muchos escenarios en los que una aplicación sin una sesión interactiva de usuario necesita obtener un token de acceso para llamar a una API. En esos casos, debes autenticar al cliente en lugar del usuario, y 2 proporciona el tipo de concesión de credenciales de cliente para facilitar este proceso. Algunos ejemplos habituales en los que esto es necesario son:
Un trabajo cron u otro servicio que necesite comunicarse con tu API (p. ej., cuando sea necesario generar un informe diario y enviarlo por correo electrónico a un administrador).
Una API independiente que admita acceso privilegiado (p. ej., la API no se expone directamente a los usuarios, sino solo a un backend).
En ciertas arquitecturas de microservicios, en las que algunas capas de API necesitan comunicarse con otras capas de API sin la intervención de un usuario, o después de que haya expirado un token del usuario.
Una API privilegiada que quizá deba llamarse antes de que un usuario se haya autenticado (es decir, desde una Action o un script de base de datos personalizado en tu inquilino de Auth0)
Tradicionalmente, se creaba una “cuenta de servicio” especial para cubrir estos escenarios: un usuario con username y contraseña configurado para servicios que admitían casos de uso no interactivos. Ese enfoque ya no se recomienda por muchas razones, y la práctica recomendada actual es usar OAuth 2.0 Client Credentials Grant en estas situaciones.
Ofrecemos una guía de planificación en formato PDF que puede descargar y consultar para obtener más detalles sobre las estrategias que recomendamos.Guía de planificación del proyecto de IAM B2C
Autenticar
Administrar usuarios
Personalizar
Auth0 AI
Plataforma