Personalización de tokens
Como desarrollador, la interacción principal con Microsoft Entra ID es solicitar un token para identificar al usuario. También se solicita un token para obtener autorización para llamar a una API web. El token de API web determina qué puede hacer esa API cuando se proporciona una solicitud determinada. En este artículo, obtendrá información sobre la información que puede recibir en tokens y cómo puede personalizar los tokens. Estos Confianza cero procedimientos recomendados para desarrolladores mejoran la flexibilidad y el control, al tiempo que aumentar la seguridad de las aplicaciones con privilegios mínimos.
Las razones para personalizar los tokens de aplicación dependen del proceso que usa para aplicar la autorización más pormenorizada en las aplicaciones y las API. Por ejemplo, puede tener diferentes roles de usuario, niveles de acceso y funcionalidades en la aplicación que dependen de información de tokens.
La API de Microsoft Graph proporciona un conjunto sólido de información y datos de directorios en Microsoft 365. Puede desarrollar un sistema de autorización detallado y enriquecido mediante la compilación de los datos de Microsoft Graph. Por ejemplo, puede acceder a la información de la pertenencia a grupos del usuario, además de los datos detallados del perfil, SharePoint y Outlook, para usarlos en las decisiones de autorización. También puede incluir datos de autorización en el token de Microsoft Entra ID.
Autorización a nivel de aplicación
Es posible que los profesionales de TI agreguen autorización de nivel de aplicación sin personalizar el token ni hacer que el desarrollador agregue ningún código.
Los profesionales de TI pueden impedir que los tokens se emitan en cualquier aplicación del inquilino mediante la marca de asignación de usuario necesaria para asegurarse de que solo un conjunto de usuarios pueda iniciar sesión en la aplicación. Sin esta marca, todos los usuarios de un inquilino podrán acceder a la aplicación. Con esta marca, solo los usuarios y grupos asignados podrán acceder a la aplicación. Cuando un usuario asignado accede a la aplicación, la aplicación recibe un token. Si el usuario no tiene una asignación, la aplicación no recibe un token. Recuerde controlar siempre correctamente las solicitudes de token que no reciben tokens.
Métodos de personalización de tokens
Hay dos maneras de personalizar tokens: notificaciones opcionales y asignación de notificaciones.
Notificaciones opcionales
Las notificaciones opcionales especifican qué notificaciones desea que Microsoft Entra ID envíe a la aplicación en los tokens. Estas notificaciones opcionales sirven para:
- Seleccionar más notificaciones para incluirlas en los tokens para la aplicación.
- Cambiar el comportamiento de notificaciones que la Plataforma de identidad de Microsoft devuelve en tokens.
- Agregar notificaciones personalizadas para la aplicación y acceder a ellas.
Las notificaciones opcionales dependen del objeto de registro de aplicación con un esquema definido. Se aplican a la aplicación independientemente de dónde se ejecute. Al escribir una aplicación multiinquilino, las notificaciones opcionales funcionan bien porque son coherentes en todos los inquilinos de Microsoft Entra ID. Por ejemplo, una dirección IP no es específica del inquilino, mientras que una aplicación tiene una dirección IP.
De forma predeterminada, los usuarios invitados de un inquilino también pueden iniciar sesión en la aplicación. Si desea bloquear a los usuarios invitados, opte por la notificación opcional (acct). Si es 1, el usuario tiene una clasificación de invitado. Si desea bloquear invitados, bloquee los tokens con acct==1.
Directivas de asignación de notificaciones
En Microsoft Entra ID, los objetos de directiva representan conjuntos de reglas en algunas o todas las aplicaciones de una organización. Una directiva de asignación de notificaciones modifica las notificaciones que envía Microsoft Entra ID para aplicaciones específicas.
La asignación de notificaciones se usa para información específica del inquilino que no tiene ningún esquema (por ejemplo, EmployeeID, DivisionName). La asignación de notificaciones se aplica en el nivel de entidad de servicio que controla el administrador de inquilinos. La asignación de notificaciones corresponde a la aplicación empresarial o a la entidad de servicio de esa aplicación. Cada inquilino puede tener su propia asignación de notificaciones.
Si va a desarrollar una aplicación de línea de negocio, puede examinar específicamente lo que hace el inquilino (qué notificaciones específicas tiene el inquilino disponible que puede usar en el token). Por ejemplo, si una organización tiene la propiedad de nombre de división de un usuario (no un campo estándar en microsoft Entra ID) en su Active Directory local, puede usar Microsoft Entra Connect para sincronizarla con Microsoft Entra ID.
Puede usar uno de los atributos de extensión estándar para contener esa información. Puede definir el token con una notificación de nombre de división que pueda redactar a partir de la extensión correspondiente (incluso si no se aplica en todos los inquilinos). Por ejemplo, una organización coloca su nombre de división en el atributo de extensión 13.
Con la asignación de notificaciones, puede hacer que funcione para otro inquilino que coloque su nombre de división en el atributo 7.
Plan de la personalización de tokens
El token que personalice depende del tipo de aplicación: aplicación cliente o API. No hay ninguna diferencia en lo que puede hacer para personalizar el token. Lo que puede incluir en el token es lo mismo para cada uno de ellos. El token que elija personalizar depende del token que consume la aplicación.
Personalización de tokens de identificador
Si va a desarrollar una aplicación cliente, personalice el token de identidad, porque es el token que solicita para identificar al usuario. Los tokens pertenecen a la aplicación cuando la notificación de audiencia (aud) del token coincide con el id. de cliente de la aplicación. Para una aplicación cliente que llama a las API, pero no las implementa, asegúrese de personalizar solo el token de identificador de la aplicación.
Azure Portal y Microsoft Graph API permiten personalizar también el token de acceso de la aplicación, pero esas personalizaciones no tienen ningún efecto. No puede personalizar un token de acceso para una API que no posee. Recuerde que la aplicación no debe intentar descodificar ni inspeccionar un token de acceso que la aplicación cliente recibe como autorización para llamar a una API.
Personalización de tokens de acceso
Si va a desarrollar una API, personaliza el token de acceso porque la API recibe tokens de acceso como parte de la llamada del cliente a la API.
Las aplicaciones cliente siempre personalizan el token de identidad que reciben para identificar al usuario. Las API personalizan los tokens de acceso que recibe la API como parte de la llamada a la API.
Grupos y roles de aplicación
Una de las técnicas de autorización más comunes es basar el acceso en la pertenencia a grupos o los roles asignados de un usuario. Configurar notificaciones de grupo y roles de aplicación en tokens muestra cómo configurar las aplicaciones con definiciones de roles de aplicación y asignar grupos de seguridad a roles de aplicación. Estos métodos ayudan a mejorar la flexibilidad y el control, al tiempo que aumentan la seguridad de confianza cero de la aplicación con privilegios mínimos.
Pasos siguientes
- Asignación de notificaciones de usuario de colaboración B2B describe el soporte del Microsoft Entra ID para personalizar las notificaciones que se emiten en el token del lenguaje de marcado de aserción de seguridad (SAML) para los usuarios de colaboración B2B.
- Personalice las notificaciones de token SAML de la aplicación cuando un usuario se autentique en una aplicación mediante la Plataforma de identidad de Microsoft con el protocolo SAML 2.0.
- En el artículo Protección de API se describen los procedimientos recomendados para proteger la API mediante su registro, la definición de permisos y del consentimiento, y la aplicación del acceso para lograr los objetivos de confianza cero.
- Procedimientos recomendados de autorización le ayuda a implementar los mejores modelos de autorización, permisos y consentimiento para las aplicaciones.
- Use los procedimientos recomendados de desarrollo para la administración de identidad y acceso de confianza cero en el ciclo de vida de desarrollo de las aplicaciones para crear aplicaciones seguras.