Información general sobre tókenes y notificaciones
Un proveedor de identidades centralizado es especialmente útil para las aplicaciones que tienen usuarios repartidos por todo el mundo que no inician sesión necesariamente desde la red de la empresa. La Plataforma de identidad de Microsoft autentica a los usuarios y proporciona tokens de seguridad, como los tokens de acceso, los tokens de actualizacióny los tokens de id. Los tokens de seguridad permiten a una aplicación cliente acceder a recursos protegidos en un servidor de recursos.
- Token de acceso: un token de acceso es un token de seguridad emitido por un servidor de autorización como parte de un flujo de OAuth 2.0. Contiene información sobre el usuario y el recurso para el que está previsto el token. La información se puede usar para tener acceso a las API web y a otros recursos protegidos. Los recursos validan los tokens de acceso para conceder acceso a una aplicación cliente. Para obtener más información, consulte Tokens de acceso de la plataforma de identidad de Microsoft.
- Token de actualización: como los tokens de acceso solo son válidos durante un breve período de tiempo, los servidores de autorización a veces emiten un token de actualización al mismo tiempo que se emite el de acceso. La aplicación cliente puede intercambiar este token de actualización por un nuevo token de acceso cuando es necesario. Para obtener más información, consulte Tokens de actualización de la plataforma de identidad de Microsoft.
- Token de identificador : los tokens de identificador se envían a la aplicación cliente como parte de un flujo de OpenID Connect. Se pueden enviar junto o en lugar de un token de acceso. El cliente usa los tokens de id. para autenticar al usuario. Para obtener más información sobre cómo emite la Plataforma de identidad de Microsoft los tokens de id., consulte Tokens de id. en la Plataforma de identidad de Microsoft.
Muchas aplicaciones empresariales usan SAML para autenticar a los usuarios. Para obtener más información sobre la aserción SAML, consulte Referencia de tokens SAML.
Validar tokens
La validación del token corresponde a la aplicación para la que se generó el token, la aplicación web en la que inició sesión el usuario o la API web que se está llamando. El servidor de autorización firma el token con una clave privada. El servidor de autorización publica la clave pública correspondiente. Para validar un token, la aplicación comprueba la firma utilizando la clave pública del servidor de autorización a fin de validar que la firma se creó con la clave privada. Para obtener más información, consulta el artículo Protección de aplicaciones y API mediante la validación de notificaciones.
Se recomienda usar las bibliotecas de Microsoft Authenticator (MSAL) compatibles siempre que sea posible. Esto implementa la adquisición, actualización y validación de tokens automáticamente. También implementa la detección compatible con estándares de la configuración de inquilinos y las claves mediante el documento de detección conocido de OpenID del inquilino. MSAL es compatible con muchas arquitecturas y plataformas de aplicación distintas, incluidas .NET, JavaScript, Java, Python, Android e iOS.
Los tokens son válidos solo durante un período de tiempo limitado, por lo que el servidor de autorización proporciona con frecuencia un par de tokens. Se proporciona un token de acceso, que accede a la aplicación o al recurso protegido. Se proporciona un token de actualización, que se usa para actualizar el token de acceso cuando este está próximo a expirar.
Los tokens de acceso se pasan a una API web en el encabezado de Authorization como un token de portador. Una aplicación puede proporcionar un token de actualización al servidor de autorización. Si el acceso del usuario a la aplicación no se ha revocado, recibe un nuevo token de acceso y un nuevo token de actualización. Cuando el servidor de autorización recibe el token de actualización, emite otro token de acceso únicamente si el usuario aún está autorizado.
Instancias de JSON Web Token y notificaciones
La Plataforma de identidad de Microsoft implementa los tokens de seguridad como instancias de JSON Web Tokens (JWT) que contienen notificaciones. Dado que los JWT se usan como tokens de seguridad, esta forma de autenticación se denomina a veces autenticación de JWT.
Una notificación proporciona aserciones sobre una entidad, como una aplicación cliente o un propietario de recursos, a otra entidad, como un servidor de recursos. También se puede hacer referencia a una notificación como una notificación de JWT o de JSON Web Token.
Las notificaciones son pares de nombres o valores que retransmiten datos sobre el firmante del token. Por ejemplo, una notificación puede contener datos sobre la entidad de seguridad autenticada por el servidor de autorización. Las notificaciones presentes en un token específico dependen de muchas cosas, entre las que se incluyen el tipo de token, el tipo de credencial usada para autenticar al firmante y la configuración de la aplicación.
Las aplicaciones pueden usar notificaciones para las siguientes tareas:
- Validar el token
- Identificar el inquilino del firmante del token
- Mostrar información de usuario
- Determinar la autorización del firmante
Una notificación consta de pares clave-valor que proporcionan los siguientes tipos de información:
- El servidor de tokens de seguridad que generó el token
- La fecha en la que se generó el token.
- Firmante (como el usuario, pero no demonios)
- La audiencia, que es la aplicación para la que se generó el token.
- La aplicación (el cliente) que solicitó el token
Puntos de conexión y emisores de tokens
Microsoft Entra ID admite dos configuraciones de inquilino: una configuración de recursos diseñada para uso interno y administra empleados e invitados empresariales, y una configuración de cliente optimizada para aislar a los consumidores y asociados en un directorio restringido orientado a externos. Aunque el servicio de identidad subyacente es idéntico para las configuraciones de inquilino, los dominios de inicio de sesión y la entidad emisora de tokens para los inquilinos externos son diferentes. Esto permite a las aplicaciones mantener separados los flujos de trabajo de personal e identificador externo si es necesario.
Los inquilinos de personal de Microsoft Entra se autentican en login.microsoftonline.com con tokens emitidos por sts.windows.net. Los tokens de inquilino del personal suelen ser intercambiables entre inquilinos y aplicaciones multiinquilino, siempre y cuando las relaciones de confianza subyacentes permitan esta interoperabilidad. Los inquilinos externos de Microsoft Entra usan puntos de conexión con inquilinos del formulario {tenantname}.ciamlogin.com. Las aplicaciones registradas en inquilinos externos deben tener en cuenta esta separación para recibir y validar los tokens correctamente.
Cada inquilino de Microsoft Entra publica metadatos conocidos compatibles con estándares. Este documento contiene información sobre el nombre del emisor, los puntos de conexión de autenticación y autorización, los ámbitos admitidos y las notificaciones. Para los inquilinos externos, el documento está disponible públicamente en: https://{tenantname}.ciamlogin.com/{tenantid}/v2.0/.well-known/openid-configuration. Este punto de conexión devuelve un valor de emisor https://{tenantid}.ciamlogin.com/{tenantid}/v2.0.
Flujos de autorización y códigos de autenticación
En función de cómo se compile el cliente, puede usar uno o varios de los flujos de autenticación admitidos por la Plataforma de identidad de Microsoft. Los flujos admitidos pueden generar varios tokens y códigos de autorización, y requieren distintos tokens para que funcionen. En la tabla siguiente se proporciona información general.
| Flujo | Requiere | token de identificador | Access token | Token de actualización | Código de autorización |
|---|---|---|---|---|---|
| Flujo de código de autorización | x | x | x | x | |
| Flujo implícito | x | x | |||
| Flujo de OIDC híbrido | x | x | |||
| Redención de token de actualización | Token de actualización | x | x | x | |
| Flujo en nombre de | Access token | x | x | x | |
| Credenciales de cliente | x (solo aplicación) |
Los tokens emitidos a través del flujo implícito tienen una limitación de longitud porque se pasan al explorador a través de la dirección URL, donde response_mode es query o fragment. Algunos exploradores tienen un límite en el tamaño de la dirección URL que se puede colocar en la barra del explorador y producen un error cuando es demasiado larga. Como resultado, estos tokens no tienen notificaciones groups o wids.
Consulte también
Pasos siguientes
- Para obtener información sobre los conceptos básicos de la autenticación y la autorización, vea Autenticación frente a autorización.