Compartir por

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 procedimientos recomendados para desarrolladores de Confianza cero mejoran la flexibilidad y el control, al tiempo que aumentan la seguridad de las aplicaciones con privilegios mínimos.

Las razones para personalizar los tokens de aplicación dependen del proceso que use para impulsar la autorización más granular 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, los datos detallados del perfil, SharePoint y Outlook para usarlos en las decisiones de autorización. Puede incluir datos de autorización en el token de Microsoft Entra ID.

Autorización de nivel de aplicación

Es posible que los profesionales de TI agreguen autorización de nivel de aplicación sin personalización de tokens ni adiciones de código.

Los profesionales de TI pueden impedir que los tokens se emitan a cualquier aplicación en el entorno con el flag de asignación de usuario requerida. Este enfoque garantiza que solo un conjunto de usuarios pueda iniciar sesión en la aplicación. Sin esta marca, todos los usuarios de un inquilino pueden acceder a la aplicación. Con esta marca, solo los usuarios y grupos asignados pueden 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: reclamaciones opcionales y asignación de reclamaciones.

Reclamaciones opcionales

Las notificaciones opcionales especifican qué notificaciones desea que Microsoft Entra ID envíe a la aplicación en tokens. Las notificaciones opcionales sirven para:

  • Seleccione más reclamaciones para incluir en los tokens de aplicación.
  • Cambie el comportamiento de las afirmaciones que devuelve en las fichas la plataforma de identidad de Microsoft.
  • Agregar y acceder a reclamaciones personalizadas para tu aplicación.

Las reclamaciones opcionales se asocian con el objeto de registro de la aplicación con un esquema definido. Se aplican a la aplicación independientemente de dónde se estaba ejecutando. Al escribir una aplicación multitenant, las declaraciones opcionales funcionan bien porque son coherentes en todos los tenants 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, active la afirmació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 reclamaciones

En microsoft Entra ID, los objetos de directiva representan conjuntos de reglas en aplicaciones individuales o en todas las aplicaciones de una organización. Una directiva de asignación de declaraciones modifica las declaraciones que emite el identificador de Microsoft Entra en tokens para aplicaciones específicas.

El mapeo de reclamaciones se utiliza para información específica de tenant que no tiene esquema (por ejemplo, EmployeeID, DivisionName). La asignación de reclamaciones se aplica en el nivel de entidad de servicio que controla el administrador del arrendatario. El mapeo de declaraciones corresponde a la aplicación empresarial o al principal de servicio de esa aplicación. Cada inquilino puede tener su propio mapeo de declaraciones.

Al desarrollar una aplicación de línea de negocio, examine específicamente lo que hace su entidad (qué afirmaciones específicas tiene disponibles la entidad que puede usar en su 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, use Microsoft Entra Connect para sincronizarlo con el identificador de Microsoft Entra.

Para contener esa información, use uno de los atributos de extensión estándar. Defina su token con una reclamación de nombre de la división que pueda formar desde la extensión correspondiente (incluso si no se aplica en todos los arrendatarios). Por ejemplo, una organización coloca su nombre de división en el atributo de extensión 13.

Con el mapeo de afirmaciones, puede hacer que funcione para otro cliente que coloque su nombre de división en el atributo siete.

Planeamiento 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 colocar en el token es igual para todos. El token que elija personalizar depende del token que consume la aplicación.

Personalizar tokens de ID

Si va a desarrollar una aplicación cliente, personaliza el token de identificador porque es el token que solicita para identificar al usuario. Un token pertenece a la aplicación cuando la declaración de audiencia (aud) del token coincide con el identificador 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

Al 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 identificador 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 aplicaciones

Una de las técnicas de autorización más comunes es basar el acceso en la pertenencia a grupos de un usuario o roles asignados. Configurar reclamaciones de grupo y roles de aplicación en tokens muestra cómo configurar tus aplicaciones con definiciones de roles de aplicación y asignar grupos de seguridad a los 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

  • Last updated on