Referencia del proveedor de métodos externos de autenticación multifactor de Microsoft Entra (versión preliminar)
En este tema se describe cómo un proveedor de autenticación externo se conecta a la autenticación multifactor (MFA) de Microsoft Entra. Un proveedor de autenticación externo puede integrarse con los inquilinos de Microsoft Entra ID como un método de autenticación externo (EAM). Un EAM puede satisfacer el segundo factor de un requisito de MFA para el acceso a un recurso o aplicación. EAM requiere al menos una licencia Microsoft Entra ID P1.
Cuando un usuario inicia sesión, se evalúan las directivas de inquilino. Los requisitos de autenticación se determinan en función del recurso al que el usuario intenta acceder.
Se pueden aplicar varias directivas al inicio de sesión, en función de sus parámetros. Estos parámetros incluyen usuarios y grupos, aplicaciones, plataforma, nivel de riesgo de inicio de sesión, etc.
En función de los requisitos de autenticación, es posible que el usuario tenga que iniciar sesión con otro factor para cumplir el requisito de MFA. El segundo factor debe complementar el tipo de primer factor.
El administrador de inquilinos agrega los EAM al identificador de Microsoft Entra. Si un inquilino requiere un EAM para MFA, el inicio de sesión se considera que cumple el requisito de MFA después de que Microsoft Entra ID valide ambos:
- El primer factor completado con el identificador de Entra de Microsoft
- El segundo factor completado con el EAM
Esa validación cumple el requisito de MFA para dos o más tipos de métodos de:
- Algo que sabes (conocimiento)
- Algo que tienes (posesión)
- Algo que eres (inherencia)
Los EAM se implementan sobre Open ID Connect (OIDC). Esta implementación requiere al menos tres puntos de conexión accesibles públicamente:
- Un punto de conexión de detección de OIDC, tal como se describe en Detección de metadatos del proveedor
- Un punto de conexión de autenticación OIDC válido
- Dirección URL en la que se publican los certificados públicos del proveedor
Veamos más detenidamente cómo funciona el inicio de sesión con un EAM:
- Un usuario intenta iniciar sesión con un primer factor, como una contraseña, en una aplicación protegida por el identificador de Entra de Microsoft.
- Microsoft Entra ID determina que debe cumplirse otro factor. Por ejemplo, una directiva de acceso condicional requiere MFA.
- El usuario elige el EAM como segundo factor.
- Microsoft Entra ID redirige la sesión del explorador del usuario a la dirección URL de EAM:
- Esta dirección URL se detecta a partir de la dirección URL de detección aprovisionada por un administrador cuando creó el EAM.
- La aplicación proporciona un token expirado o casi expirado que contiene información para identificar al usuario y al inquilino.
- El proveedor de autenticación externo valida que el token procede de Microsoft Entra ID y comprueba el contenido del token.
- El proveedor de autenticación externa puede realizar opcionalmente una llamada a Microsoft Graph para capturar información adicional sobre el usuario.
- El proveedor de autenticación externa realiza cualquier acción que considere necesaria, como autenticar al usuario con alguna credencial.
- El proveedor de autenticación externa redirige al usuario a Microsoft Entra ID con un token válido, incluidas todas las notificaciones necesarias.
- Microsoft Entra ID valida que la firma del token procede del proveedor de autenticación externo configurado y, a continuación, comprueba el contenido del token.
- Microsoft Entra ID valida el token con respecto a los requisitos.
- El usuario cumplió el requisito de MFA si la validación se realiza correctamente. Es posible que el usuario también tenga que cumplir otros requisitos de directiva.
Configuración de un nuevo proveedor de autenticación externa con el identificador de Microsoft Entra
Se requiere una aplicación que represente la integración para que los EAM emitan el id_token_hint. La aplicación se puede crear de dos maneras:
- Creado en cada inquilino que usa el proveedor externo.
- Se crea como una aplicación multiinquilino. Los administradores de roles con privilegios deben conceder consentimiento para habilitar la integración para su inquilino.
Una aplicación multiinquilino reduce la posibilidad de una configuración incorrecta en cada inquilino. También permite a los proveedores realizar cambios en metadatos como direcciones URL de respuesta en un solo lugar, en lugar de requerir que cada inquilino realice los cambios.
Para configurar una aplicación multiinquilino, el administrador del proveedor debe:
Cree un inquilino de Id. de Microsoft Entra si aún no tiene uno.
Registre una aplicación en su inquilino.
Establezca los tipos de cuenta admitidos de la aplicación en: Cuentas de cualquier directorio organizativo (cualquier inquilino de Id. de Microsoft Entra: multiinquilino).
Agregue los permisos delegados
openidyprofiledel perfil de Microsoft Graph a la aplicación.No publique ningún ámbito en esta aplicación.
Agregue las direcciones URL válidas del proveedor de identidades externos authorization_endpoint a esa aplicación como direcciones URL de respuesta.
Nota:
El authorization_endpoint proporcionado en el documento de detección del proveedor debe agregarse como dirección URL de redireccionamiento en el registro de la aplicación. De lo contrario, obtendrá el siguiente error: ENTRA IDSTS50161: No se pudo validar la dirección URL de autorización del proveedor de notificaciones externos
El proceso de registro de aplicaciones crea una aplicación con varias propiedades. Estas propiedades son necesarias para nuestro escenario.
| Propiedad | Descripción |
|---|---|
| Id. de objeto | El proveedor puede usar el identificador de objeto con Microsoft Graph para consultar la información de la aplicación. El proveedor puede usar el identificador de objeto para recuperar y editar la información de la aplicación mediante programación. |
| Id. de solicitud | El proveedor puede usar el identificador de aplicación como ClientId de su aplicación. |
| URL de página principal | La dirección URL de la página principal del proveedor no se usa para nada, pero es necesaria como parte del registro de la aplicación. |
| Direcciones URL de respuesta | Direcciones URL de redirección válidas para el proveedor. Uno debe coincidir con la dirección URL del host del proveedor que se estableció para el inquilino del proveedor. Una de las direcciones URL de respuesta registradas debe coincidir con el prefijo del authorization_endpoint que Microsoft Entra ID recupera a través de la detección de OIDC para la dirección URL del host. |
Una aplicación para cada inquilino también es un modelo válido para admitir la integración. Si usa un registro de inquilino único, el administrador de inquilinos debe crear un registro de aplicación con las propiedades de la tabla anterior para una aplicación de un solo inquilino.
Nota:
El consentimiento del administrador de la aplicación es necesario en el inquilino que usa EAM. Si no se concede el consentimiento, aparece el siguiente error cuando un administrador intenta usar EAM: AADSTS900491: No se encuentra la entidad de servicio <Identificador de aplicación>.
Configuración de notificaciones opcionales
Un proveedor puede configurar más notificaciones mediante notificaciones opcionales para id_token.
Nota:
Independientemente de cómo se cree la aplicación, el proveedor debe configurar notificaciones opcionales para cada entorno de nube. Si se usa una aplicación multiinquilino para Azure global y Azure para la Administración Pública de EE. UU., cada entorno de nube requiere una aplicación y un identificador de aplicación diferentes.
Adición de un identificador de EAM a Microsoft Entra
La información del proveedor de identidades externo se almacena en la directiva de métodos de autenticación de cada inquilino. La información del proveedor se almacena como un método de autenticación de tipo externalAuthenticationMethodConfiguration.
Cada proveedor tiene una entrada en el objeto de lista de la directiva. Cada entrada debe indicar:
- Si el método está habilitado
- Los grupos incluidos que pueden usar el método
- Los grupos excluidos que no pueden usar el método
Los administradores de acceso condicional pueden crear una directiva con la concesión requerir MFA para establecer el requisito de MFA para el inicio de sesión de usuario. Actualmente no se admiten métodos de autenticación externos con puntos fuertes de autenticación.
Para obtener más información sobre cómo agregar un método de autenticación externo en el Centro de administración de Microsoft Entra, consulte Administrar un método de autenticación externo en Microsoft Entra ID (versión preliminar).
Interacción del identificador de Entra de Microsoft con el proveedor
En las secciones siguientes se explican los requisitos del proveedor e incluyen ejemplos para la interacción del identificador de Entra de Microsoft con un proveedor.
Detección de metadatos del proveedor
Un proveedor de identidades externo debe proporcionar un punto de conexiónde detección de OIDC. Este punto de conexión se usa para obtener más datos de configuración. Dirección URL completa, incluida .oidc-configuration/conocido, debe incluirse en la dirección URL de detección configurada cuando se crea el EAM.
El punto de conexión devuelve un documento JSON de metadatos del proveedor hospedado allí. El punto de conexión también debe devolver el encabezado de longitud de contenido válido.
En la tabla siguiente se enumeran los datos que deben estar presentes en los metadatos del proveedor. Estos valores son necesarios para este escenario de extensibilidad. El documento de metadatos JSON puede contener más información.
Para el documento OIDC con los valores de Metadatos del proveedor, consulte Metadatos del proveedor.
| Valor de los metadatos | Valor | Comentarios |
|---|---|---|
| Emisor | Esta dirección URL debe coincidir con la dirección URL de host usada para la detección y la notificación iss en los tokens emitidos por el servicio del proveedor. | |
| authorization_endpoint | Punto de conexión con el que se comunica Microsoft Entra ID para la autorización. Este punto de conexión debe estar presente como una de las direcciones URL de respuesta para las aplicaciones permitidas. | |
| jwks_uri | Donde Microsoft Entra ID puede encontrar las claves públicas necesarias para comprobar las firmas emitidas por el proveedor. [!NOTE] El parámetro x5c JSON Web Key (JWK) debe estar presente para proporcionar representaciones X.509 de claves proporcionadas. |
|
| scopes_supported | openid | También se pueden incluir otros valores, pero no son necesarios. |
| response_types_supported | ID_token | También se pueden incluir otros valores, pero no son necesarios. |
| subject_types_supported | ||
| id_token_signing_alg_values_supported | Microsoft admite RS256 | |
| claim_types_supported | normal | Esta propiedad es opcional, pero si está presente, debe incluir el valor normal; También se pueden incluir otros valores. |
http://customcaserver.azurewebsites.net/v2.0/.well-known/openid-configuration
{
"authorization_endpoint": "https://customcaserver.azurewebsites.net/api/Authorize",
"claims_supported": [
"email"
],
"grant_types_supported": [
"implicit"
],
"id_token_signing_alg_values_supported": [
"RS256"
],
"issuer": "https://customcaserver.azurewebsites.net",
"jwks_uri": "http://customcaserver.azurewebsites.net/.well-known/jwks",
"response_modes_supported": [
"form_post"
],
"response_types_supported": [
"id_token"
],
"scopes_supported": [
"openid"
],
"SigningKeys": [],
"subject_types_supported": [
"public"
]
}
http://customcaserver.azurewebsites.net/.well-known/jwks
{
"keys": [
{
"kty": "RSA",
"use": "sig",
"kid": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
"x5t": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
"n": "jq277LRoE6WKM0awT3b...vt8J6MZvmgboVB9S5CMQ",
"e": "AQAB",
"x5c": [
"cZa3jz...Wo0rzA="
]
}
]
}
Nota:
El parámetro JWK x5c debe estar presente para proporcionar representaciones X.509 de claves proporcionadas.
Almacenamiento en caché de metadatos del proveedor
Para mejorar el rendimiento, el proveedor almacena en caché los metadatos de Microsoft Entra ID devueltos por el proveedor, incluidas las claves. El almacenamiento en caché de metadatos del proveedor impide una llamada de detección cada vez que Microsoft Entra ID se comunica con un proveedor de identidades externo.
Esta caché se actualiza cada 24 horas (un día). Este es el modo en que se recomienda que un proveedor reversión de sus claves:
- Publique el certificado existente y el nuevo certificado en "jwks_uri".
- Siga firmando con el certificado existente hasta que se actualice, expire o actualice la memoria caché del identificador de Entra de Microsoft (cada 2 días).
- Cambie a firma con Nuevo certificado.
No publicamos programaciones para las sustituciones de claves. El servicio dependiente debe estar preparado para controlar las reversiones inmediatas y periódicas. Se recomienda usar una biblioteca dedicada creada para este propósito, como azure-activedirectory-identitymodel-extensions-for-dotnet. Para obtener más información, consulte Sustitución de claves de firma en Microsoft Entra ID.
Detección de metadatos de Id. de Microsoft Entra
Los proveedores también deben recuperar las claves públicas de Id. de Microsoft Entra para validar los tokens emitidos por el identificador de Microsoft Entra.
Puntos de conexión de detección de metadatos de Microsoft Entra ID:
- Global Azure:
https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration - Azure para la Administración Pública de Estados Unidos:
https://login.microsoftonline.us/common/v2.0/.well-known/openid-configuration - Microsoft Azure operado por 21Vianet:
https://login.partner.microsoftonline.cn/common/v2.0/.well-known/openid-configuration
Con el identificador de clave pública del token (el "niño" de la firma web JSON (JWS)), se puede determinar cuál de las claves recuperadas de la propiedad jwks_uri debe usarse para validar la firma del token de id. de Microsoft Entra.
Validación de tokens emitidos por el identificador de Entra de Microsoft
Para obtener información sobre cómo validar los tokens emitidos por Microsoft Entra ID, consulte Validación y token de identificador. No hay pasos especiales para los consumidores de nuestros metadatos de detección.
La biblioteca de validación de tokens de Microsoft tiene todos los detalles sobre los detalles de la validación de tokens que se documentan o se pueden determinar al examinar el código fuente. Para ver un ejemplo, consulte Ejemplos de Azure.
Una vez que la validación se realiza correctamente, puede trabajar con la carga de notificaciones para obtener detalles del usuario y su inquilino.
Nota:
Es importante validar id_token_hint para asegurarse de que es de un inquilino de Microsoft y que representa la integración. id_token_hint debe validarse completamente, especialmente la firma, el emisor y la audiencia, así como los demás valores de notificación.
Llamada de Id. de Microsoft Entra al proveedor de identidades externo
Microsoft Entra ID usa el flujo implícito de OIDC para comunicarse con el proveedor de identidades externo. Con este flujo, la comunicación con el proveedor se realiza exclusivamente mediante el punto de conexión de autorización del proveedor. Para informar al proveedor del usuario para el que Microsoft Entra ID realiza la solicitud, el identificador de Microsoft Entra pasa un token a través del parámetro id_token_hint.
Esta llamada se realiza a través de una solicitud POST porque la lista de parámetros pasados al proveedor es grande. Una lista grande impide el uso de exploradores que limitan la longitud de una solicitud GET.
Los parámetros de solicitud de autenticación se enumeran en la tabla siguiente.
Nota:
A menos que aparezcan en la tabla siguiente, el proveedor debe omitir otros parámetros de la solicitud.
| Parámetro de consulta de autenticación | Valor | Descripción |
|---|---|---|
| scope | openid | |
| response_type | Id_token | Valor utilizado para el flujo implícito. |
| response_mode | form_post | Usamos el formulario POST para evitar problemas con direcciones URL grandes. Esperamos que todos los parámetros se envíen en el cuerpo de la solicitud. |
| client_id | Identificador de cliente proporcionado a Microsoft Entra ID por el proveedor de identidades externo, como ABCD. Para obtener más información, consulte Descripción del métodode autenticación externo. | |
| redirect_url | Identificador uniforme de recursos (URI) de redireccionamiento al que el proveedor de identidades externo envía la respuesta (id_token_hint). | |
| Consulte el ejemplo después de esta tabla. | ||
| nonce | Cadena aleatoria generada por el identificador de Entra de Microsoft. Puede ser el identificador de sesión. Si se proporciona, debe devolverse en la respuesta a Microsoft Entra ID. | |
| estado | Si se pasa, el proveedor debe devolver el estado en su respuesta. Microsoft Entra ID usa el estado para mantener el contexto sobre la llamada. | |
| id_token_hint | Token emitido por el identificador de Entra de Microsoft para el usuario final y pasado para beneficiarse del proveedor. | |
| claims | Blob JSON que contiene las notificaciones solicitadas. Para más detalles sobre el formato de este parámetro, consulte el parámetro de solicitud de reclamaciones de la documentación de OIDC, y un ejemplo después de esta tabla. | |
| client-request-id | Un valor GUID | Un proveedor puede registrar este valor para ayudar a solucionar problemas. |
Ejemplo de un URI de redirección
Los identificadores uniformes de recursos (URI) de redirección deben registrarse con el proveedor fuera de banda. Los URI de redireccionamiento que se pueden enviar son:
- Azure Global:
https://login.microsoftonline.com/common/federation/externalauthprovider - Azure para la Administración Pública de Estados Unidos:
https://login.microsoftonline.us/common/federation/externalauthprovider - Microsoft Azure operado por 21Vianet:
https://login.partner.microsoftonline.cn/common/federation/externalauthprovider
Ejemplo de un EAM que satisface MFA
Este es un ejemplo de una autenticación en la que EAM satisface MFA. Este ejemplo ayuda a un proveedor a saber qué notificaciones espera Microsoft Entra ID.
Microsoft Entra ID usa la combinación de los valores acr y amr para validar:
- El método de autenticación usado para el segundo factor satisface el requisito de MFA
- El método de autenticación difiere en "type" del método usado para completar el primer factor para el inicio de sesión en Microsoft Entra ID
{
"id_token": {
"acr": {
"essential": true,
"values":["possessionorinherence"]
},
"amr": {
"essential": true,
"values": ["face", "fido", "fpt", "hwk", "iris", "otp", "pop", "retina", "sc", "sms", "swk", "tel", "vbm"]
}
}
}
Notificaciones de Id_token_hint predeterminadas
En esta sección se describe el contenido necesario del token pasado como id_token_hint en la solicitud realizada al proveedor. El token puede contener más notificaciones que en la tabla siguiente.
| Notificación | Value | Descripción |
|---|---|---|
| iss | Identifica el servicio de token de seguridad (STS) que construye y devuelve el token, y el inquilino de Microsoft Entra ID en el que se autenticó el usuario. La aplicación debe usar la parte del GUID de la notificación para restringir el conjunto de inquilinos que pueden iniciar sesión en la aplicación, si procede. El emisor debe coincidir con la dirección URL del emisor de los metadatos JSON de detección de OIDC para el inquilino donde el usuario inició sesión. | |
| aud | La audiencia debe establecerse en el identificador de cliente del proveedor de identidades externo para el id. de Microsoft Entra. | |
| exp | La hora de expiración se establece para que expire un breve tiempo después del tiempo de emisión, suficiente para evitar problemas de asimetría de tiempo. Dado que este token no está pensado para la autenticación, no hay ninguna razón para que su validez agote la solicitud por mucho. | |
| iat | Establezca el tiempo de emisión como de costumbre. | |
| tid | El identificador de inquilino es para anunciar el inquilino al proveedor. Representa el inquilino de Id. de Entra de Microsoft del que procede el usuario. | |
| oid | Identificador inmutable de un objeto en la plataforma de identidad de Microsoft. En este caso, es una cuenta de usuario. También se puede usar para realizar comprobaciones de autorización de forma segura y como clave en tablas de base de datos. Este ID identifica de forma exclusiva al usuario en todas las aplicaciones. Dos aplicaciones diferentes que registran al mismo usuario reciben el mismo valor en la demanda oid. Por lo tanto, el oid se puede usar en consultas a servicios en línea de Microsoft, como Microsoft Graph. | |
| preferred_username | Proporciona un valor en lenguaje natural que identifica al firmante del token. No se asegura que este valor sea único en un inquilino y se debe usar solo con fines de visualización. | |
| sub | Identificador del firmante del usuario final en el emisor. Entidad de seguridad sobre la que el token declara información como, por ejemplo, el usuario de una aplicación. Este valor es inmutable y no se puede reasignar ni volver a usar. Se puede usar para realizar comprobaciones de autorización de forma segura, por ejemplo, cuando el token se usa para acceder a un recurso, y se puede usar como clave en tablas de base de datos. Dado que el firmante siempre está presente en los tokens que emite Microsoft Entra ID, se recomienda usar este valor en un sistema de autorización de propósito general. El asunto es, sin embargo, un identificador en pares (es único para un id. de aplicación determinado). Por lo tanto, si un mismo usuario inicia sesión en dos aplicaciones diferentes utilizando dos identificadores de cliente distintos, esas aplicaciones recibirán dos valores diferentes para la declaración de asunto. Esto puede ser o no deseable dependiendo de los requisitos de arquitectura y privacidad. Véase también la reivindicación oid (que sí permanece igual en todas las aplicaciones dentro de un inquilino). |
Para evitar que se use para algo distinto de una sugerencia, el token se emite como expirado. El token está firmado y se puede comprobar mediante los metadatos de detección de identificadores de Microsoft Entra publicados.
Notificaciones opcionales de Microsoft Entra ID
Si un proveedor necesita notificaciones opcionales de Microsoft Entra ID, puede configurar las siguientes notificaciones opcionales para id_token: given_name, family_name, preferred_username, upn. Para obtener más información, consulte Conjunto de notificaciones opcionales.
Uso recomendado de notificaciones
Microsoft recomienda asociar cuentas en el lado del proveedor con la cuenta de Azure AD mediante las notificaciones oid y tid. Se garantiza que estas dos notificaciones son únicas para la cuenta en el inquilino.
Ejemplo de un id_token_hint
Este es un ejemplo de un id_token_hint para un miembro de directorio:
{
"typ": "JWT",
"alg": "RS256",
"kid": "C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w"
}.{
"ver": "2.0",
"iss": "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0",
"sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA",
"aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
"exp": 1536093790,
"iat": 1536093791,
"nbf": 1536093791,
"name": "Test User 2",
"preferred_username": "testuser2@contoso.com"
"oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
}.
Este es un ejemplo de la sugerencia de id_token para un usuario invitado en el inquilino:
{
"typ": "JWT",
"alg": "RS256",
"kid": "C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w"
}.{
"ver": "2.0",
"iss": "https://login.microsoftonline.com/9122040d-6c67-4c5b-b112-36a304b66dad/v2.0",
"sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA",
"aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
"exp": 1536093790,
"iat": 1536093791,
"nbf": 1536093791,
"name": "External Test User (Hotmail)",
"preferred_username": "externaltestuser@hotmail.com",
"oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
}.
Acciones sugeridas para proveedores de identidades externos
Se recomienda que los proveedores de identidades externos completen estos pasos. La lista no es exhaustiva y los proveedores deben completar otros pasos de validación a medida que se ajusten.
- Desde la solicitud:
- Asegúrese de que el redirect_uri se publica en la llamada id. de Microsoft Entra al proveedor de identidades externo.
- Asegúrese de que el client_id tiene un valor asignado a Microsoft Entra ID, como ABCD.
- El proveedor debe validar primero el id_token_hint que le presenta Microsoft Entra ID.
- Desde las notificaciones del id_token_hint:
- Opcionalmente, pueden realizar una llamada a Microsoft Graph para capturar otros detalles sobre este usuario. Las notificaciones oid y tid en el id_token_hint son útiles en este sentido. Para obtener más información sobre las notificaciones proporcionadas en el id_token_hint, consulte Notificaciones de id_token_hint predeterminadas.
- A continuación, lleve a cabo cualquier otra actividad de autenticación que se cree para el producto del proveedor.
- Según el resultado de las acciones del usuario y otros factores, el proveedor construiría y enviaría una respuesta de nuevo a Microsoft Entra ID, como se explica en la sección siguiente.
Procesamiento del identificador de Entra de Microsoft de la respuesta del proveedor
El proveedor debe volver a ENVIAR una respuesta al redirect_uri. Se deben proporcionar los parámetros siguientes en una respuesta correcta:
| Parámetro | Valor | Descripción |
|---|---|---|
| ID_token | Token emitido por el proveedor de identidades externo. | |
| estado | El mismo estado que se pasó en la solicitud, si existe. De lo contrario, este valor no debe estar presente. |
Si se ejecuta correctamente, el proveedor emitiría un id_token para el usuario. Microsoft Entra ID usa los metadatos de OIDC publicados para comprobar que el token contiene las notificaciones esperadas y realiza cualquier otra validación del token que requiere OIDC.
| Notificación | Value | Descripción |
|---|---|---|
| iss | Emisor: debe coincidir con el emisor de los metadatos de detección del proveedor. | |
| aud | Audiencia: identificador de cliente de Microsoft Entra ID. Consulte client_id en la llamada de id. de Entra de Microsoft al proveedor de identidades externo. | |
| exp | Hora de expiración: se establece como de costumbre. | |
| iat | Tiempo de emisión: se establece como de costumbre. | |
| sub | Asunto: debe coincidir con el sub del id_token_hint enviado para iniciar esta solicitud. | |
| nonce | El mismo nonce que se pasó en la solicitud. | |
| acr | Notificaciones acr para la solicitud de autenticación. Este valor debe coincidir con uno de los valores de la solicitud enviada para iniciar esta solicitud. Solo se debe devolver una notificación acr. Para obtener la lista de notificaciones, consulte Notificaciones acr admitidas. | |
| amr | Notificaciones de amr para el método de autenticación usado en la autenticación. Este valor se debe devolver como una matriz y solo se debe devolver una notificación de método. Para obtener la lista de notificaciones, consulte Notificaciones amr admitidas. |
Notificaciones acr admitidas
| Notificación | Notas |
|---|---|
| posesiónorinherence | La autenticación debe tener lugar con un factor basado en posesión o inherencia. |
| knowledgeorpossession | La autenticación debe realizarse con un conocimiento o factor basado en posesión. |
| knowledgeorinherence | La autenticación debe tener lugar con un conocimiento o factor basado en la inherencia. |
| knowledgeorpossessionorinherence | La autenticación debe tener lugar con un conocimiento o posesión o factor basado en la inherencia. |
| Conocimiento | La autenticación debe realizarse con el factor basado en conocimiento. |
| Posesión | La autenticación debe realizarse con el factor basado en posesión. |
| inherence | La autenticación debe realizarse con un factor basado en la inherencia. |
Notificaciones de amr admitidas
| Notificación | Notas |
|---|---|
| face | Biometría con reconocimiento facial |
| fido | Se usó FIDO2 |
| Fpt | Biometría con huella digital |
| Hwk | Prueba de posesión de la clave protegida por hardware |
| Iris | Biometría con examen de iris |
| otp | Contraseña de un solo uso |
| pop | Prueba de posesión |
| Retina | Biometría del examen de retina |
| sc | Tarjeta inteligente |
| sms | Confirmación por texto al número registrado |
| swk | Confirmación de la presencia de una clave protegida por software |
| tel | Confirmación por teléfono |
| vbm | Biometría con huella de voz |
Microsoft Entra ID requiere que MFA esté satisfecho para emitir un token con notificaciones de MFA. Como resultado, solo los métodos con un tipo diferente pueden satisfacer el requisito de segundo factor. Como se mencionó anteriormente, los diferentes tipos de método que se pueden usar para satisfacer el segundo factor son conocimiento, posesión e inherencia.
Microsoft Entra ID valida la asignación de tipos en función de la tabla siguiente.
| Claim (método) | Tipo | Notas |
|---|---|---|
| face | Inherence | Biometría con reconocimiento facial |
| fido | Posesión | Se usó FIDO2. Algunas implementaciones también pueden requerir biometría, pero el tipo de método de posesión se asigna porque es el atributo de seguridad principal. |
| Fpt | Inherence | Biometría con huella digital |
| Hwk | Posesión | Prueba de posesión de la clave protegida por hardware |
| Iris | Inherence | Biometría con examen de iris |
| otp | Posesión | Contraseña de un solo uso |
| pop | Posesión | Prueba de posesión |
| Retina | Inherence | Biometría del examen de retina |
| sc | Posesión | Tarjeta inteligente |
| sms | Posesión | Confirmación por texto al número registrado |
| swk | Posesión | Prueba de presencia de una clave protegida por software |
| tel | Posesión | Confirmación por teléfono |
| vbm | Inherence | Biometría con huella de voz |
Si no se encuentra ningún problema con el token, Microsoft Entra ID considera que MFA está satisfecho y emite un token al usuario final. De lo contrario, se produce un error en la solicitud del usuario final.
El error se indica mediante la emisión de parámetros de respuesta de error.
| Parámetro | Valor | Descripción |
|---|---|---|
| Error | Código de error ASCII, como access_denied o temporarily_unavailable. |
Microsoft Entra ID considera que la solicitud se realiza correctamente si el parámetro id_token está presente en la respuesta y si el token es válido. De lo contrario, la solicitud se considera incorrecta. Microsoft Entra ID produce un error en el intento de autenticación original debido al requisito de la directiva de acceso condicional.
Microsoft Entra ID abandona el estado del intento de autenticación por su parte unos 5 minutos después del redireccionamiento al proveedor.
Control de respuestas de errores de Id. de Microsoft Entra
Los servicios de Microsoft Azure usan un correlationId para correlacionar las llamadas entre varios sistemas internos y externos. Actúa como un identificador común de toda la operación o flujo que potencialmente implica varias llamadas HTTP. Cuando se produce un error durante cualquiera de las operaciones, la respuesta contiene un campo denominado Id. de correlación.
Cuando llegue al soporte técnico de Microsoft o a un servicio similar, proporcione el valor de este identificador de correlación, ya que ayuda a acceder a la telemetría y los registros más rápidos.
Por ejemplo:
ENTRA IDSTS70002: error al validar las credenciales. ENTRA IDSTS50012: El token de identificación externo del emisor 'https://sts.XXXXXXXXX.com/auth/realms/XXXXXXXXXmfa' falló la verificación de la firma. El token de KeyID es 'A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u' Id. de seguimiento: 0000aaaa-11bb-cccc-dd22-eeeeee333333 Id. de correlación: aaaa0000-bb11-2222-33cc-444444dddddd Marca de tiempo: 2023-07-24 16:51:34Z
Controles personalizados y EAM
En Microsoft Entra ID, los EAM y los controles personalizados de acceso condicional pueden funcionar en paralelo mientras los clientes están preparados para migrar y migrar a EAM.
Los clientes que actualmente usan una integración con un proveedor externo mediante controles personalizados pueden seguir usándolas y las directivas de acceso condicional configuradas para administrar el acceso. Se recomienda a los administradores crear un conjunto paralelo de directivas de acceso condicional durante el período de migración:
Las directivas deben usar la concesión de control Requerir autenticación multifactor en lugar de la concesión de control personalizado.
Nota:
La EAM no satisface los controles basados en los puntos fuertes de autenticación, incluido el nivel de MFA integrado. Las directivas solo deben configurarse con Requerir autenticaciónmultifactor. Estamos trabajando activamente para admitir EAM con puntos fuertes de autenticación.
La nueva directiva se puede probar primero con un subconjunto de usuarios. El grupo de pruebas se excluiría de la directiva que requiere los controles personalizados e incluirse en la directiva que requiere MFA. Una vez que el administrador esté seguro de que la política que requiere MFA es satisfecha por el EAM, puede incluir a todos los usuarios requeridos en la política con la concesión de MFA, y la política configurada para controles personalizados puede pasar a Desactivado.
Compatibilidad con la integración
Si tiene algún problema al compilar la integración de EAM con microsoft Entra ID, es posible que el proveedor de soluciones independientes (ISV) de Ingeniería de experiencia del cliente de Microsoft (CxE) pueda ayudar. Para interactuar con el equipo de ISV de CxE, envíe una solicitud de ayuda.
Referencias
Glosario
| Término | Descripción |
|---|---|
| MFA | Autenticación multifactor. |
| EAM | Un método de autenticación externo es un método de autenticación de un proveedor distinto del identificador de Entra de Microsoft que se usa como parte de la autenticación de un usuario. |
| OIDC | Open ID Connect es un protocolo de autenticación basado en OAuth 2.0. |
| 00001111-aaaa-2222-bbbb-3333cccc4444 | Ejemplo de un appid integrado para un método de autenticación externo. |
Pasos siguientes
Para obtener más información sobre cómo configurar un EAM en el Centrode administración de Microsoft Entra, consulte Administrar un método de autenticación externo en Microsoft (versión preliminar).