Glosario: plataforma de identidad de Microsoft
Verá estos términos cuando use nuestra documentación, el centro de autenticación de Microsoft Entra, nuestras bibliotecas de autenticación y Microsoft Graph API. Algunos términos son específicos de Microsoft, mientras que otros están relacionados con protocolos como OAuth u otras tecnologías que se usan con la plataforma de identidad de Microsoft.
Access token
Un tipo de token de seguridad emitido por un servidor de autorización y usado por una aplicación cliente para acceder a un servidor de recursos protegidos. Normalmente en forma de JSON Web Token (JWT), el token personifica la autorización concedida al cliente por el propietario del recurso para un nivel de acceso solicitado. El token contiene todas las notificaciones aplicables sobre el sujeto, lo que permite a la aplicación cliente utilizarlo como forma de credencial al acceder a un recurso determinado. Esto también elimina la necesidad de que el propietario del recurso exponga sus credenciales al cliente.
Los tokens de acceso solo son válidos durante un breve período de tiempo y no se pueden revocar. Un servidor de autorización también puede emitir un token de actualización cuando se emite el token de acceso. Normalmente, los tokens de actualización solo se proporcionan para las aplicaciones cliente confidenciales.
A veces se conoce a los tokens de acceso como "Aplicación y usuario" o "Solo aplicación", según las credenciales que se va a representar. Por ejemplo, cuando una aplicación cliente usa:
- La concesión de autorización del "código de autorización", el usuario final se autentica primero como propietario del recurso, delegando la autorización al cliente para acceder al recurso. Después, el cliente se autentica al obtener el token de acceso. El token a veces se conoce más específicamente como token "Aplicación y usuario", ya que representa tanto al usuario que ha autorizado la aplicación cliente como a la aplicación.
- La concesión de autorización de "Credenciales de cliente", el cliente proporciona la autenticación única, que funciona sin la autorización o autenticación del propietario del recurso, por lo que a veces el token puede conocerse como un token "Solo aplicación".
Consulte la referencia de tokens de acceso para más información.
Actor
Otro término para la aplicación cliente. El actor es la parte que actúa en nombre de un sujeto (propietario del recurso).
Id. de aplicación (cliente)
El id. de aplicación o el id. de cliente es un valor que la plataforma de identidad de Microsoft asigna a la aplicación al registrarla en Microsoft Entra ID. El id. de aplicación es un valor GUID que identifica de forma única la aplicación y su configuración dentro de la plataforma de identidad. El id. de aplicación se agrega al código de la aplicación y las bibliotecas de autenticación incluyen el valor en sus solicitudes a la plataforma de identidad en tiempo de ejecución de la aplicación. El id. de aplicación (cliente) no es un secreto: no lo use como contraseña u otra credencial.
Manifiesto de aplicación
Un manifiesto de aplicación es una característica que genera una representación JSON de la configuración de identidad de la aplicación, utilizada como un mecanismo para actualizar sus entidades Application y ServicePrincipal asociadas. Consulte el Manifiesto de aplicación de Microsoft Entrapara más detalles.
Objeto de aplicación
Cuando se registra o se actualiza una aplicación, el portal crea o actualiza un objeto de aplicación y un objeto de entidad de servicio correspondiente para dicho inquilino. El objeto de aplicación define globalmente la configuración de identidad de la aplicación (en todos los inquilinos a los que tiene acceso), lo que proporciona una plantilla de la que proceden los objetos de entidad de servicio correspondientes para su uso local en tiempo de ejecución (en un inquilino específico).
Para más información, consulte Objetos de aplicación y de entidad de servicio de Azure Active Directory (Azure AD).
Registro de la aplicación
Para permitir que una aplicación integre y delegue las funciones de administración de identidades y acceso a Microsoft Entra ID, debe registrarse con el inquilinode Microsoft Entra ID. Al registrar la aplicación con el identificador de Microsoft Entra, proporciona una configuración de identidad para la aplicación, lo que le permite integrarse con Microsoft Entra ID y usar características como:
- Administración sólida de inicio de sesión único mediante la administración de identidades de Microsoft Entra y la implementación del protocolo OpenID Connect
- Acceso asincrónico a recursos protegidos por aplicaciones cliente, a través del servidor de autorización de OAuth 2.0
- Marco de consentimiento para administrar el acceso del cliente a los recursos protegidos, en función de la autorización del propietario del recurso.
Consulte Tutoriales para la integración de aplicaciones con Microsoft Entra ID para más detalles.
Autenticación
El acto de solicitar a un usuario credenciales legítimas, que proporciona la base para la creación de una entidad de seguridad que se utilizará para el control de identidades y de acceso. Por ejemplo, durante una concesión de autorización de OAuth 2.0, el usuario que se autentica cumple el rol de propietario del recurso o de aplicación cliente, en función de la concesión usada.
Autorización
El acto de conceder un permiso a la entidad de seguridad autenticada para hacer algo. Hay dos casos de uso principales en el modelo de programación de Microsoft Entra:
- Durante un flujo de concesión de autorización de OAuth 2.0: cuando el propietario del recurso autoriza a la aplicación cliente, lo que permite al cliente acceder a los recursos del propietario del recurso.
- Durante el acceso a los recursos por el cliente: cuando lo implementa el servidor de recursos, el uso de los valores de notificación presentes en el token de acceso para tomar decisiones de control de acceso basadas en ellos.
Código de autorización
Valor de corta duración proporcionado por el punto de conexión de autorización a una aplicación cliente durante el flujo de concesión de código de autorización de OAuth 2.0, una de las cuatro concesiones de autorización de OAuth 2.0. También denominado código de autenticación, el código de autorización se devuelve a la aplicación cliente en respuesta a la autenticación de un propietario de recursos. El código de autenticación indica que el propietario del recurso ha delegado la autorización a la aplicación cliente para acceder a sus recursos. Como parte del flujo, el código se canjea después por un token de acceso.
Punto de conexión de autorización
Uno de los puntos de conexión implementados por el servidor de autorización, que se usa para interactuar con el propietario del recurso a fin de proporcionar una concesión de autorización durante un flujo de concesión de autorización de OAuth 2.0. Según el flujo de concesión de autorización que se utilice, puede variar la concesión real proporcionada, incluido un código de autorización o un token de seguridad.
Vea las secciones sobre los tipos de concesión de autorización y el punto de conexión de autorización de la especificación de OAuth 2.0 y la especificación de OpenIDConnect para más información.
Concesión de autorización
Una credencial que representa la autorización del propietario del recurso para acceder a sus recursos protegidos, concedida a una aplicación cliente. Una aplicación cliente puede usar uno de los cuatro tipos de concesión definidos por la plataforma de autorización OAuth 2.0 para obtener una concesión, según los requisitos o tipo de cliente: "concesión de código de autorización", "concesión de credenciales de cliente", "concesión implícita" y "concesión de credenciales de contraseña del propietario de recursos". La credencial que se devuelve al cliente es un token de acceso o un código de autorización (que se intercambia después por un token de acceso), según el tipo de concesión de autorización usado.
Las credenciales de contraseña del propietario del recurso conceden no se deben usar excepto en escenarios en los que no se pueden usar otros flujos. Si va a crear una SPA, use el flujo de código de autorización con PKCE en lugar de conceder implícitamente.
Servidor de autorización
Como se define en la plataforma de autorización OAuth 2.0, el servidor responsable de emitir los tokens de acceso al cliente después de autenticar correctamente al propietario del recurso y obtener su autorización. Una aplicación cliente interactúa con el servidor de autorización en tiempo de ejecución por medio de sus puntos de conexión de autorización y token, de acuerdo a las concesiones de autorización definidas en OAuth 2.0.
En el caso de la integración de aplicaciones de la Plataforma de identidad de Microsoft, esta última implementa el rol de servidor de autorización para aplicaciones de Microsoft Entra y las API de servicio de Microsoft, por ejemplo las API de Microsoft Graph.
Notificación
Las notificaciones son pares de nombre y valores en un token de seguridad que proporcionan aserciones realizadas por una entidad a otra. Normalmente, estas entidades son la aplicación cliente o un propietario de recursos que proporciona aserciones a un servidor de recursos. Las notificaciones retransmiten datos sobre el asunto del token, por ejemplo, el id. de la entidad de seguridad autenticada por el servidor de autorización. Las notificaciones presentes en un token pueden variar y depender de varios factores, como el tipo de token, el tipo de credencial que se usa para autenticar el asunto, la configuración de la aplicación y otros.
Para más información, consulte la referencia de tokens de acceso de plataforma de identidad de Microsoft.
Aplicación cliente
También se denomina "actor". Como se define en la plataforma de autorización OAuth 2.0, una aplicación que realiza solicitudes de recursos protegidos en nombre del propietario del recurso. Reciben permisos del propietario del recurso en forma de ámbitos. El término "cliente" no implica ninguna característica de implementación de hardware determinada (por ejemplo, si la aplicación se ejecuta en un servidor, un equipo de escritorio o en otros dispositivos).
Una aplicación cliente solicita autorización al propietario de un recurso para participar en un flujo de concesión de autorización de OAuth 2.0 y puede acceder a los datos y las API en nombre del propietario del recurso. La plataforma de autorización OAuth 2.0 define dos tipos de clientes, "confidencial" y "público", en función de la capacidad del cliente para mantener la confidencialidad de sus credenciales. Las aplicaciones pueden implementar un cliente web (confidencial) que se ejecuta en un servidor web, un cliente nativo (público) instalado en un dispositivo y un cliente basado en agente usuario (público) que se ejecuta en el explorador de un dispositivo.
Consentimiento
El proceso de un propietario de recursos que concede autorización a una aplicación cliente, para acceder a recursos protegidos bajo permisos específicos, en nombre del propietario del recurso. Según los permisos solicitados por el cliente, se le solicitará al administrador o usuario su consentimiento para permitir el acceso a los datos de la organización o individuales, respectivamente. Tenga en cuenta que en un escenario multiinquilino, la entidad de servicio de la aplicación también se registra en el inquilino del usuario que concede el consentimiento.
Consulte el marco de consentimiento para más información.
token de identificador
Un token de seguridad de OpenID Connect proporcionado por un punto de conexión de autorización del servidor de autorización, que contiene las notificaciones que pertenecen a la autenticación de un propietario de recursos de usuario final. Al igual que un token de acceso, los tokens de identificador también se representan como JSON Web Token (JWT) firmados digitalmente. Pero a diferencia de un token de acceso, las notificaciones de token de identificador no se usan para fines relacionados con el acceso a los recursos y específicamente con el control de acceso.
Consulte la referencia de tokens de identificador para más información.
Identidades administradas
Eliminan la necesidad de que los desarrolladores administren las credenciales. Las identidades administradas proporcionan una identidad que usan las aplicaciones al conectarse a los recursos que admiten la autenticación de Microsoft Entra. Las aplicaciones pueden usar la identidad administrada para obtener tokens de plataforma de identidad de Microsoft. Por ejemplo, una aplicación puede usar una identidad administrada para acceder a recursos como Azure Key Vault donde los desarrolladores pueden almacenar credenciales de forma segura o tener acceso a cuentas de almacenamiento. Para más información, vea Introducción a las identidades administradas.
Plataforma de identidad de Microsoft
La Plataforma de identidad de Microsoft es una evolución de la plataforma de desarrolladores y de servicio de identidad de Microsoft Entra. Permite a los desarrolladores crear aplicaciones que inicien sesión en todas las identidades de Microsoft, obtener tokens para llamar a Microsoft Graph, otras API de Microsoft o API que los desarrolladores hayan creado. Es una plataforma completa que consiste en un servicio de autenticación, bibliotecas, registro y configuración de aplicaciones, documentación completa para desarrolladores, ejemplos de código y otros contenidos para desarrolladores. La plataforma de identidad de Microsoft admite los protocolos estándar del sector como OAuth 2.0 y OpenID Connect.
Aplicación multiinquilino
Una clase de aplicación que permite iniciar sesión y consentir a usuarios aprovisionados en un inquilino de Microsoft Entra, incluidos inquilinos que no son aquel con el que el cliente está registrado. De forma predeterminada, las aplicaciones cliente nativas son aplicaciones multiinquilino, mientras que las aplicaciones cliente web y recurso web/API tienen la capacidad de seleccionar entre uno y varios inquilinos. Por el contrario, una aplicación web registrada como único inquilino solo permite inicios de sesión desde cuentas de usuario aprovisionadas en el mismo inquilino que donde se registra la aplicación.
Consulte Inicio de sesión de cualquier usuario de Microsoft Entra mediante el patrón de aplicación multiinquilino para más información.
Native Client
Un tipo de aplicación cliente que se instala de forma nativa en un dispositivo. Como todo el código se ejecuta en un dispositivo, se considera un cliente "público" debido a su incapacidad para almacenar credenciales de manera privada o confidencial. Vea los tipos de cliente y perfiles de OAuth 2.0 para más información.
Permisos
Una aplicación cliente obtiene acceso a un servidor de recursos mediante la declaración de las solicitudes de permiso. Existen dos tipos:
- Permisos "delegados", que especifican un acceso basado en el ámbito con autorización delegada del propietario del recurso que ha iniciado sesión y se presentan al recurso en tiempo de ejecución como notificaciones "scp" en el token de acceso del cliente. Estos indican el permiso concedido al actor por el sujeto.
- Permisos de "aplicación", que especifican acceso basado en rol bajo las credenciales o la identidad de la aplicación cliente y se presentan al recurso en tiempo de ejecución como notificaciones de "roles" en el token de acceso del cliente. Estos indican los permisos que el inquilino ha concedido al sujeto.
También se revelan durante el proceso de consentimiento , ya que proporciona al administrador o al propietario del recurso la oportunidad de conceder o denegar el acceso de cliente a los recursos en su inquilino.
Las solicitudes de permisos se configuran en la pestaña Permisos de API al seleccionar los permisos delegados y permisos de la aplicación deseados (estos últimos requiere la pertenencia al rol de administrador global). Dado que un cliente público no puede mantener credenciales con seguridad, solo puede solicitar permisos delegados, mientras que un cliente confidencial tiene la capacidad de solicitar permisos tanto delegados como de aplicación. El objeto de aplicación de cliente almacena los permisos declarados en su propiedad requiredResourceAccess.
Token de actualización
Tipo de token de seguridad emitido por un servidor de autorización. Antes de que expire un token de acceso, una aplicación cliente incluye su token de actualización asociado cuando solicita un nuevo token de acceso desde el servidor de autorización. Normalmente, los tokens de actualización tienen el formato JSON Web Token (JWT).
A diferencia de los tokens de acceso, los tokens de actualización se pueden revocar. Un servidor de autorización deniega cualquier solicitud de una aplicación cliente que incluya un token de actualización que se haya revocado. Cuando el servidor de autorización deniega una solicitud que incluye un token de actualización revocado, la aplicación cliente pierde el permiso para acceder al servidor de recursos en nombre del propietario del recurso.
Consulte los tokens de actualización para más información.
Propietario del recurso
Como se define en la plataforma de autorización OAuth 2.0, una entidad capaz de conceder acceso a un recurso protegido. Cuando el propietario del recurso es una persona, se conoce como usuario final. Por ejemplo, cuando una aplicación cliente desea acceder al buzón del usuario a través de Microsoft Graph API, requiere el permiso del propietario de los recursos del buzón de correo. Al "propietario del recurso" a veces también se le denomina el sujeto.
Cada token de seguridad representa un propietario del usuario. El propietario del recurso es lo que representan la notificación del sujeto, la notificación del identificador de objeto y los datos personales del token. Los propietarios de recursos son la entidad que concede permisos delegados a una aplicación cliente, en forma de ámbitos. Los propietarios de recursos también son los destinatarios de los roles que indican que hay permisos expandidos dentro de un inquilino o en una aplicación.
Servidor de recursos
Como se define en la plataforma de autorización OAuth 2.0, un servidor que hospeda recursos protegidos, capaz de aceptar y responder a las solicitudes de recursos protegidos de las aplicaciones cliente que presentan un token de acceso. También se conoce como servidor de recursos protegidos, o aplicación de recursos.
Un servidor de recursos expone las API y exige el acceso a sus recursos protegidos mediante ámbitos y roles, con el marco de autorización de OAuth 2.0. Por ejemplo, Microsoft Graph API, que proporciona acceso a los datos del inquilino de Microsoft Entra y a las API de Microsoft 365 que ofrecen acceso a datos, como el correo electrónico y el calendario.
Al igual que una aplicación cliente, se establece la configuración de la identidad de la aplicación de recursos a través de Registro en un inquilino de Microsoft Entra, que proporciona tanto el objeto de aplicación y como el de entidad de servicio. Algunas API proporcionadas por Microsoft, como Microsoft Graph API, han registrado previamente entidades de servicio, que están disponibles en todos los inquilinos durante el aprovisionamiento.
Roles
Al igual que los ámbitos, los roles proporcionan una forma de que un servidor de recursos controle el acceso a los recursos que protege. A diferencia de los ámbitos, los roles representan privilegios que se han concedido al sujeto más allá de la línea base (este es el motivo por el que leer su propio correo electrónico es un ámbito, mientras que ser administrador de correo electrónico que puede leer el correo electrónico de todos los usuarios es un rol).
Los roles de las aplicaciones pueden admitir dos tipos de asignaciones: la asignación de "usuario" implementa el control de acceso basado en roles para aquellos usuarios o grupos que requieren acceso al recurso, mientras que la asignación de "aplicación" implementa lo mismo para las aplicaciones cliente que requieren acceso. Un rol de aplicación se puede definir como asignable por usuario, asignable por aplicación, o ambos.
Los roles son cadenas definidas por recursos (por ejemplo, "Aprobador de gastos", "Solo lectura", "Directory.ReadWrite.All"), administradas mediante el manifiesto de aplicación del recurso y almacenadas en la propiedad appRoles del recurso. Los usuarios se pueden asignar a roles asignables de "usuario" y los permisos de aplicación cliente se pueden configurar para solicitar roles asignables de "aplicación".
Para ver una explicación detallada de los roles de aplicación expuestos por Microsoft Graph API, consulte los ámbitos de permisos de Graph API. Para obtener un ejemplo de implementación paso a paso, consulte Incorporación o eliminación de asignaciones de roles de Azure.
Ámbitos
Como los roles, los ámbitos proporcionan una forma para que un servidor de recursos controle el acceso a los recursos protegidos. Los ámbitos se utilizan para implementar el control de acceso basado en ámbitos para una aplicación cliente a la que el propietario haya otorgado acceso delegado al recurso.
Los ámbitos son cadenas definidas por recursos (por ejemplo, "Mail.Read" o "Directory.ReadWrite.All"), administradas mediante el manifiesto de aplicación del recurso, y almacenadas en la propiedad oauth2Permissions del recurso. Los permisos delegados de la aplicación cliente se pueden configurar para acceder a un ámbito.
Como procedimiento recomendado para la convención de nomenclatura, utilice un formato "resource.operation.constraint". Para ver una explicación detallada de los ámbitos expuestos por Microsoft Graph API, consulte los ámbitos de permisos de Graph API. Para conocer los ámbitos expuestos por los servicios de Microsoft 365, consulte la referencia de permisos de la API de Microsoft 365.
Token de seguridad
Un documento firmado con notificaciones, como un token de OAuth 2.0 o una aserción de SAML 2.0. En el caso de una concesión de autorización de OAuth 2.0, un token de acceso (OAuth2), un token de actualización y un token de identificador son tipos de token de seguridad, que se implementan como un JSON Web Token (JWT).
Objeto de entidad de servicio
Cuando se registra o se actualiza una aplicación, el portal crea o actualiza un objeto de aplicación y un objeto de entidad de servicio correspondiente para dicho inquilino. El objeto de aplicación define globalmente la configuración de identidad de la aplicación (en todos los inquilinos a los que se le ha concedido acceso a la aplicación asociada) y es la plantilla de la que proceden los objetos de entidad de servicio correspondientes para su uso local en tiempo de ejecución (en un inquilino específico).
Para más información, consulte Objetos de aplicación y de entidad de servicio de Azure Active Directory (Azure AD).
Inicio de sesión
Proceso de una aplicación cliente que inicia la autenticación del usuario final y captura el estado relacionado para solicitar un token de seguridad y establecer el ámbito de la sesión de la aplicación en ese estado. El estado puede incluir artefactos, como información de perfil de usuario, e información derivada de las notificaciones de tokens.
Normalmente, la función de inicio de sesión de una aplicación se utiliza para implementar el inicio de sesión único (SSO). También puede ir precedido por una función de "suscripción", como punto de entrada para que un usuario final obtenga acceso a una aplicación (al primer inicio de sesión). La función de suscripción se usa para recopilar y conservar el estado adicional específico del usuario y puede requerir el consentimiento del usuario.
Cierre de sesión
Proceso de cancelación de la autenticación de un usuario final para desasociar el estado de usuario asociado a la sesión de la aplicación cliente durante el inicio de sesión
Asunto
También se conoce como propietario de recurso.
Inquilino
Una instancia de un directorio Microsoft Entra se conoce como un inquilino de Microsoft Entra. Proporciona varias características, como:
- Un servicio de registro de aplicaciones integradas
- Autenticación de cuentas de usuario y aplicaciones registradas
- Puntos de conexión de REST necesarios para admitir diversos protocolos, como OAuth 2.0 y SAML, incluidos el punto de conexión de autorización, el punto de conexión de token y el punto de conexión "común" utilizado por aplicaciones multiinquilino.
Los inquilinos de Microsoft Entra se crean o asocian con suscripciones de Azure y Microsoft 365 durante el inicio de sesión, lo que proporciona características de administración de identidad y acceso para la suscripción. Los administradores de la suscripción de Azure también pueden crear inquilinos de Microsoft Entra adicionales. Consulte Obtención de un inquilino de Microsoft Entra para más información sobre las diversas maneras de acceder a un inquilino. Consulte Asociación o incorporación de una suscripción de Azure al inquilino de Microsoft Entra para obtener más información sobre la relación entre las suscripciones y un inquilino de Microsoft Entra.
Punto de conexión de token
Uno de los puntos de conexión implementados por el servidor de autorización para admitir concesiones de autorización de OAuth 2.0. En función de la concesión, se puede utilizar para adquirir un token de acceso (y el token de "actualización" relacionado) a un cliente, o un token de identificador cuando se usa con el protocolo OpenID Connect.
cliente basada en agente usuario
Un tipo de aplicación cliente que descarga código desde un servidor web y se ejecuta dentro de un agente usuario (por ejemplo, un explorador web), como una aplicación de página única (SPA). Como todo el código se ejecuta en un dispositivo, se considera un cliente "público" debido a su incapacidad para almacenar credenciales de manera privada o confidencial. Para más información, vea Tipos de cliente y perfiles de OAuth 2.0.
Entidad de seguridad de usuario
Similar a cómo se usa un objeto de entidad de servicio para representar una instancia de aplicación, un objeto de entidad de seguridad de usuario es otro tipo de entidad de seguridad, que representa a un usuario. El User
tipo de recurso de Microsoft Graph define el esquema de un objeto de usuario, incluidas las propiedades relacionadas con el usuario, como nombre y apellidos, nombre principal de usuario, pertenencia a roles de directorio, etc. Esto proporciona la configuración de identidad de usuario de Microsoft Entra ID para establecer una entidad de seguridad de usuario en tiempo de ejecución. La entidad de seguridad del usuario se utiliza para representar a un usuario autenticado para el inicio de sesión único, al registrar la delegación del consentimiento o tomar decisiones de control de acceso, etc.
Cliente web
Un tipo de aplicación cliente que ejecuta todo el código en un servidor web, que funciona como un cliente confidencial porque puede almacenar de forma segura sus credenciales en el servidor. Para más información, vea Tipos de cliente y perfiles de OAuth 2.0.
Identidad de carga de trabajo
Identidad usada por una carga de trabajo de software (como una aplicación, un servicio, un script o un contenedor) para autenticar otros servicios y recursos, y acceder a ellos. En Microsoft Entra ID, las identidades de carga de trabajo son aplicaciones, entidades de servicio e identidades administradas. Para más información, vea Introducción a las identidades de carga de trabajo.
Federación de identidades de carga de trabajo
Permite acceder de forma segura a los recursos protegidos de Microsoft Entra desde aplicaciones y servicios externos sin necesidad de administrar secretos (en escenarios admitidos). Para más información, vea Federación de identidades de carga de trabajo.
Pasos siguientes
Muchos de los términos de este glosario están relacionados con los protocolos OAuth 2.0 y OpenID Connect. Aunque no es necesario saber cómo funcionan los protocolos "en la conexión" para usar la plataforma de identidad, conocer algunos conceptos básicos del protocolo puede ayudarle a crear y depurar la autenticación y autorización más fácilmente en las aplicaciones: