Compartir por

Uso de Microsoft Entra MFA con un proveedor externo (versión preliminar)

En este artículo se describe cómo un proveedor de autenticación externo se conecta a la autenticación multifactor (MFA) de Microsoft Entra.

Importante

El uso de un proveedor de autenticación externo está actualmente en versión preliminar. Para obtener más información sobre las versiones preliminares, consulte Términos de licencia universal para Online Services.

Con esta versión preliminar, puede utilizar un proveedor de autenticación externo para integrarse con las instancias de Microsoft Entra ID como un método de autenticación externa. Un método de autenticación externo puede satisfacer el segundo factor de un requisito de MFA para el acceso a un recurso o aplicación. Los métodos de autenticación externos requieren al menos una licencia de Microsoft Entra ID P1.

Cuando un usuario inicia sesión, se evalúan las directivas del arrendatario. Los requisitos de autenticación se determinan en función del recurso al que el usuario intenta acceder.

Es posible que se apliquen varias directivas al inicio de sesión, en función de sus parámetros. Estos parámetros incluyen usuarios y grupos, aplicaciones, la plataforma, el 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 tipo del segundo factor debe complementar el tipo de primer factor.

El administrador de inquilinos agrega métodos de autenticación externos a Microsoft Entra ID. Si un arrendatario requiere un método de autenticación externo 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.
  • Segundo factor completado con el método de autenticación externo.

Esa validación cumple el requisito de MFA para dos o más tipos de métodos:

  • Algo que sabes (conocimiento)
  • Algo que tienes (posesión)
  • Algo que eres (inherencia)

Los métodos de autenticación externos se implementan sobre OpenID Connect (OIDC). Esta implementación requiere al menos tres puntos de conexión accesibles públicamente para implementar un método de autenticación externo:

  • Un punto final 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

Este es el funcionamiento del inicio de sesión con un método de autenticación externo:

  1. 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.

  2. Microsoft Entra ID determina que se debe cumplir otro factor (por ejemplo, si una directiva de acceso condicional requiere MFA).

  3. El usuario elige el método de autenticación externo como segundo factor.

  4. Microsoft Entra ID redirige la sesión del explorador del usuario a la dirección URL del método de autenticación externo.

    Esta dirección URL se detecta a partir de la dirección URL de detección que un administrador aprovisionó cuando creó el método de autenticación externo.

    La aplicación proporciona un token expirado o casi expirado que contiene información para identificar al usuario y al inquilino.

  5. El proveedor de autenticación externo valida que el token procede de Microsoft Entra ID y comprueba el contenido del token.

  6. El proveedor de autenticación externo podría realizar una llamada a Microsoft Graph para capturar información adicional sobre el usuario.

  7. El proveedor de autenticación externo realiza cualquier acción que considere necesaria, como autenticar al usuario con una credencial.

  8. El proveedor de autenticación externo redirige al usuario de regreso a Microsoft Entra ID con un token válido, incluidas todas las afirmaciones necesarias.

  9. 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.

  10. Microsoft Entra ID valida el token con respecto a los requisitos.

  11. Si la validación se realiza correctamente, significa que el usuario cumple el requisito de MFA. Es posible que el usuario también tenga que cumplir otros requisitos de directiva.

Diagrama que muestra cómo funciona un método de autenticación externo.

Configuración de un nuevo proveedor de autenticación externa con el identificador de Entra de Microsoft

Para emitir id_token_hint, los métodos de autenticación externos necesitan una aplicación que represente la integración. Puede crear la aplicación de dos maneras:

  • En cada inquilinato que usa el proveedor externo.
  • Como una aplicación multiusuario. Para habilitar la integración para su inquilino, los administradores de roles con privilegios deben conceder consentimiento.

El uso de una aplicación multiinquilino puede reducir la posibilidad de una configuración incorrecta en cada inquilino. Los proveedores también pueden realizar cambios en los metadatos (por ejemplo, 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:

  1. Cree un inquilino de Microsoft Entra ID (si aún no tienen uno).

  2. Registre una aplicación en su inquilino.

  3. En la aplicación, en Tipos de cuenta admitidos, seleccione Cuentas en cualquier directorio organizativo (cualquier inquilino de Microsoft Entra ID - Multiinquilino).

  4. Agregue los permisos delegados openid y valores profile para Microsoft Graph.

  5. No publique ningún ámbito en esta aplicación.

  6. Agregue las direcciones URL válidas authorization_endpoint del proveedor de identidades externos a esa aplicación como direcciones URL de respuesta.

    Nota:

    En el registro de la aplicación, agregue el authorization_endpoint valor proporcionado en el documento de detección del proveedor como una dirección URL de redireccionamiento. De lo contrario, obtendrá el siguiente error: "ENTRA IDSTS50161: No se pudo validar la dirección URL de autorización del proveedor de notificaciones externas!"

El proceso de registro de aplicaciones crea una aplicación con varias propiedades. Necesitas estas propiedades 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 identificador de cliente de su aplicación.
URL de página principal La dirección URL de la página principal del proveedor de servicios no se usa para ningún propósito, pero es necesaria para registrar la aplicación.
URL de respuesta Direcciones URL de redirección válidas para el proveedor. Debe coincidir la URL del host del proveedor que se configuró para el arrendatario del proveedor. Una de las direcciones URL de respuesta registradas debe coincidir con el prefijo del valor authorization_endpoint que Microsoft Entra ID recupera para la URL del host mediante el descubrimiento de OIDC.

Otro modelo válido para admitir la integración es usar una aplicación para cada inquilino. 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:

Necesita el consentimiento del administrador para la aplicación en la entidad que usa el método de autenticación externo. Si no concede consentimiento, aparece el siguiente error cuando un administrador intenta usar el método de autenticación externo: "AADSTS900491: El principal del servicio <ID de aplicación> no encontrado."

Configuración de notificaciones opcionales

Un proveedor puede configurar más declaraciones mediante el uso de declaraciones 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 método de autenticación externo a Microsoft Entra ID

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 del 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 .

Para establecer el requisito de MFA para el inicio de sesión de usuario, los usuarios con el rol de Administrador de acceso condicional pueden crear una directiva con el permiso Requerir MFA. Actualmente no se admiten métodos de autenticación externos con puntos fuertes de autenticación.

Obtenga más información sobre cómo agregar un método de autenticación externo en el Centro de administración de Microsoft Entra.

Interacción del identificador de Entra de Microsoft con el proveedor

En las secciones siguientes se explican los requisitos del proveedor y se incluyen ejemplos de cómo interactúa microsoft Entra ID 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.

La dirección URL de detección debe usar el https esquema y debe terminar con /.well-known/openid-configuration. No se pueden incluir segmentos de ruta de acceso adicionales, cadenas de consulta ni fragmentos después de este segmento. La dirección URL de detección completa debe incluirse en la dirección URL de detección que configure al crear el método de autenticación externo.

El punto de conexión devuelve un documento JSON de metadatos del proveedor hospedado allí. El punto de conexión también debe devolver un encabezado de longitud de contenido válido. El documento de metadatos debe cumplir con OpenID Connect Discovery 1.0 (incorporando el conjunto de erratas 2) e incluir todos los campos de metadatos OIDC necesarios.

Los metadatos del proveedor deben incluir los datos enumerados en la tabla siguiente. Estos valores son necesarios para este escenario de extensibilidad. El documento de metadatos JSON puede contener más información.

Para el documento OIDC que tiene los valores de los metadatos del proveedor, consulte Metadatos del proveedor.

Valor de los metadatos Valor Comentarios
Issuer Debe ser una dirección URL HTTPS.

El valor del emisor debe coincidir carácter por carácter con el emisor configurado, el valor del emisor en el documento de descubrimiento y la iss reclamación en los tokens emitidos por el servicio del proveedor.

El emisor puede incluir un puerto o segmento de ruta de acceso, pero no debe contener parámetros de consulta ni identificadores de fragmento.
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 La ubicación donde microsoft Entra ID puede encontrar las claves públicas que necesita para comprobar las firmas emitidas por el proveedor. jwks_uri debe ser un punto de conexión HTTPS y no debe incluir parámetros de consulta ni identificadores de fragmento.

El parámetro JSON Web Key (JWK) x5c 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 normal valor . También se pueden incluir otros valores. 
https://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/v2.0",
  "jwks_uri": "https://customcaserver.azurewebsites.net/.well-known/jwks",
  "response_modes_supported": [
    "form_post"
  ],
  "response_types_supported": [
    "id_token"
  ],
  "scopes_supported": [
    "openid"
  ],
  "SigningKeys": [],
  "subject_types_supported": [
    "public"
  ]
}

https://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 las claves proporcionadas.

Ejemplos de direcciones URL y emisores de detección

En los ejemplos siguientes se muestran combinaciones válidas y no válidas de dirección URL de detección y emisor para esta integración.

Pares válidos de dirección URL de detección y emisor
  • Dirección URL de detección: https://example.com/.well-known/openid-configuration
    Emisor: https://example.com
  • Dirección URL de detección: https://example.com:8443/.well-known/openid-configuration
    Emisor: https://example.com:8443
  • Dirección URL de detección: https://example.com/tenant1/.well-known/openid-configuration
    Emisor: https://example.com/tenant1
Ejemplos de URL de descubrimiento e emisores no válidos
  • Dirección URL de detección: https://example.com/.well-known/openid-configuration
    Emisor: https://example.com:443/ (puerto HTTPS predeterminado agregado explícitamente en el emisor).
  • Dirección URL de detección: https://example.com:443/.well-known/openid-configuration
    Emisor: https://example.com/ (Incompatibilidad de puerto.)
  • Dirección URL de detección: https://example.com/.well-known/openid-configuration?client_id=0oasxuxkghOniBjlQ697
    Emisor: https://example.com (No se puede incluir una cadena de consulta en una dirección URL de detección).

Almacenamiento en caché de metadatos del proveedor

Para mejorar el rendimiento, el identificador de Entra de Microsoft almacena en caché los metadatos que devuelve 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. Recomendamos que los proveedores sigan estos pasos para renovar sus claves:

  1. Publique el certificado existente y el nuevo certificado en jwks_uri.
  2. Siga iniciando sesión con el certificado existente hasta que se actualice, expire o actualice la memoria caché del identificador de Entra de Microsoft (cada 2 días).
  3. Cambie a iniciar sesión 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 fin, como azure-activedirectory-identitymodel-extensions-for-dotnet. Para obtener más información, consulte Sustitución de claves de firma en Microsoft Entra ID.

Descubrimiento de metadatos de Identificación 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:

  • Azure global: 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

Puede usar el identificador de clave pública del token (el "kid" de JSON Web Signature (JWS)) para determinar cuál de las claves obtenidas de la propiedad jwks_uri se debe usar para validar la firma del token de Microsoft Entra ID.

Validación de tokens emitidos por Microsoft Entra ID

Para obtener información sobre cómo validar los tokens emitidos por microsoft Entra ID, consulte Validar un token de identificador. No hay pasos especiales para los consumidores de nuestros metadatos de detección.

Puede encontrar todos los detalles sobre la validación de tokens en la biblioteca de validación de tokens de Microsoft. También puede determinar estos detalles examinando 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 reclamaciones para obtener detalles sobre el usuario y su inquilino de sistema.

Nota:

Es importante validar el id_token_hint valor para asegurarse de que procede de un inquilino de Microsoft y que representa la integración. El id_token_hint valor debe validarse completamente, especialmente la firma, el emisor, la audiencia y otros valores de afirmaciones.

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. Cuando se usa este flujo, la comunicación con el proveedor se produce mediante solo el punto de conexión de autorización del proveedor.

Para informar al proveedor sobre el usuario para el que Microsoft Entra ID realiza la solicitud, Microsoft Entra ID pasa un token a través del parámetro id_token_hint.

Esta llamada se realiza a través de una POST solicitud porque se pasa una lista grande de parámetros al proveedor. Una lista grande impide el uso de exploradores que limitan la longitud de una GET solicitud.

Los parámetros de solicitud de autenticación se enumeran en la tabla siguiente.

Nota:

El proveedor debe omitir otros parámetros de la solicitud, a menos que se muestren en la tabla siguiente.

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_uri Identificador uniforme de recursos (URI) de redirección 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.
state Si se proporciona, el proveedor debe devolver state en su respuesta. Microsoft Entra ID usa state para mantener el contexto sobre la llamada.
id_token_hint Token que Microsoft Entra ID emite para el usuario y proporciona en beneficio del proveedor.
claims Un fragmento JSON que contiene las reclamaciones 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 URI de redireccionamiento deben registrarse con el proveedor fuera de banda. Los URI de redireccionamiento que puede 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 método de autenticación externo que satisface MFA

Este es un ejemplo en el que un método de autenticación externo satisface los requisitos de MFA. Este ejemplo ayuda a un proveedor a saber qué afirmaciones espera Microsoft Entra ID.

Microsoft Entra ID utiliza la combinación de acr y amr para validar que:

  • El método de autenticación usado para el segundo factor satisface el requisito de MFA.
  • El método de autenticación es un tipo diferente al que se usa 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"]
    }
  }
}

Declaraciones predeterminadas de id_token_hint

En esta sección se describe el contenido necesario del token que se pasa como id_token_hint en la solicitud realizada al proveedor. El token puede contener más declaraciones de las que se muestran en la tabla siguiente.

Reclamación Valor 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 la 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 desajuste temporal. Dado que este token no está destinado para la autenticación, no hay ninguna razón para que su validez supere significativamente la duración de la solicitud.
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 inician sesión con el mismo usuario reciben el mismo valor en la oid reclamación. Por lo tanto, la oid reclamación se puede usar en consultas a servicios en línea de Microsoft, como Microsoft Graph.
preferred_username Proporciona un valor legible para los humanos que identifica el sujeto 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 sujeto del usuario 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, como cuando se usa el token para acceder a un recurso. Se puede usar como clave en las tablas de base de datos.

Dado que el sujeto siempre está presente en los tokens que emite Microsoft Entra ID, se recomienda usar este valor en un sistema de autorización de uso general. Sin embargo, el sujeto es un identificador por pares y es único para un identificador de aplicación determinado.

Por lo tanto, si un solo usuario inicia sesión en dos aplicaciones diferentes mediante dos identificadores de cliente diferentes, esas aplicaciones reciben dos valores diferentes para la declaración del sujeto.

Es posible que desee o no este resultado, en función de los requisitos de arquitectura y privacidad.

Consulte también la oid reclamación (que sigue siendo la misma en todas las aplicaciones de un inquilino).

Para evitar que el token se use para algo distinto de una sugerencia, se emite en el estado expirado. El token está firmado y se puede comprobar mediante los metadatos de detección de identificadores de Microsoft Entra publicados.

Declaraciones 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 Reclamaciones opcionales.

Se recomienda asociar cuentas en el lado del proveedor con la cuenta en Azure mediante los oid y tid reclamos. Se garantiza que estas dos notificaciones son únicas para la cuenta en el inquilino.

Ejemplo de id_token_hint

Este es un ejemplo de id_token_hint para un miembro del 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 id_token_hint para un usuario invitado en el tenant:

{
  "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 los siguientes elementos. La lista no es exhaustiva y los proveedores deben completar otros pasos de validación como consideren adecuado.

  • Desde la solicitud:

    • Asegúrese de que el redirect_uri se publique tal como se describe en la llamada a la identidad externa de Microsoft Entra ID.
    • Asegúrese de que la dirección URL de detección configurada usa HTTPS y termina con /.well-known/openid-configuration. Asegúrese también de que no incluya parámetros de consulta ni identificadores de fragmento. Asegúrese de que el valor del emisor coincide exactamente con el documento de detección.
    • Asegúrese de que client_id tiene un valor asignado a Microsoft Entra ID, como ABCD.
    • El proveedor debe primero validar el identificador de Entra de Microsoft que id_token_hint presenta.

  • Desde las reclamaciones de id_token_hint:

    • (Opcional) Realice una llamada a Microsoft Graph para capturar otros detalles sobre este usuario. Las oid y tid reclamaciones en id_token_hint son útiles a este respecto. Para obtener más información sobre las reclamaciones proporcionadas en id_token_hint, consulte Reclamaciones predeterminadas.

  • Realice cualquier otra actividad de autenticación 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 al identificador de Entra de Microsoft, como se explica en la sección siguiente.

Procesamiento de la respuesta del proveedor por el Entra ID de Microsoft

El proveedor debe usar POST para devolver una respuesta a .redirect_uri Se deben proporcionar los parámetros siguientes en una respuesta correcta:

Parámetro Valor Descripción
id_token Token que emite el proveedor de identidades externo.
state 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 valor id_token para el usuario. Microsoft Entra ID usa los metadatos de OIDC publicados para comprobar que el token contiene las notificaciones esperadas y lleva a cabo cualquier otra validación de token que requiera OIDC.

Reclamación Valor Descripción
iss Emisor: debe coincidir con el emisor de los metadatos de detección del proveedor.
aud Audiencia: el ID de cliente de Microsoft Entra. Consulte client_id en la llamada de Microsoft Entra ID al proveedor externo de identidades.
exp Hora de expiración: se establece como de costumbre.
iat Hora 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 valor que se pasó en la solicitud.
acr Las acr afirmaciones de 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 un acr reclamación. Para obtener la lista de reclamaciones, consulte Reclamaciones admitidasacr.
amr amr Reclamaciones sobre el método de autenticación usado. Este valor se debe devolver como una matriz y solo se debe devolver una notificación de método. Para obtener la lista de reclamaciones, consulte Reclamaciones admitidasamr.
Notificaciones acr admitidas
Reclamación Notas
possessionorinherence La autenticación debe usar un factor basado en posesión o inherencia.
knowledgeorpossession La autenticación debe usar un factor basado en conocimientos o posesión.
knowledgeorinherence La autenticación debe usar un factor basado en conocimientos o inherencia.
knowledgeorpossessionorinherence La autenticación debe usar un factor basado en conocimientos, posesión o inherencia.
knowledge La autenticación debe usar un factor basado en conocimiento.
possession La autenticación debe usar un factor basado en posesión.
inherence La autenticación debe usar un factor basado en la inherencia.
Notificaciones de amr admitidas
Reclamación Notas
face Biometría con reconocimiento facial
fido FIDO2 usado
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 se cumplan los requisitos de MFA para emitir un token con declaraciones 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.

Método de reclamación Tipo Notas
face Inherencia Biometría con reconocimiento facial.
fido Posesión FIDO2 en uso. 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 Inherencia Biometría con huella digital.
hwk Posesión Prueba de posesión de una clave protegida por hardware.
iris Inherencia Biometría con examen de iris.
otp Posesión Contraseña única.
pop Posesión Prueba de posesión.
retina Inherencia Biometría del escaneo de retina.
sc Posesión Tarjeta inteligente.
sms Posesión Confirmación por texto en un número registrado.
swk Posesión Prueba de presencia de una clave protegida por software.
tel Posesión Confirmación por teléfono.
vbm Inherencia Biometría con huella de voz.

Microsoft Entra ID considera que la MFA se considera cumplida si no se encuentra ningún problema con el token y emite un token al usuario. De lo contrario, se produce un error en la solicitud del usuario.

El error se indica mediante la emisión de parámetros de respuesta de error.

Parámetro Valor Descripción
Error Un código de error ASCII, como access_denied o temporarily_unavailable

Microsoft Entra ID considera que la solicitud se realiza correctamente si id_token parameter 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.

Manejo de respuestas de error de Microsoft Entra ID

Los servicios de Microsoft Azure usan un correlationId valor 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 se comunique con el soporte técnico de Microsoft o un servicio similar, proporcione el valor del identificador de correlación. Ayuda a acceder a la telemetría y los registros más rápidos.

Por ejemplo:

ENTRA IDSTS70002: Error validating credentials. ENTRA IDSTS50012: External ID token from issuer 'https://sts.XXXXXXXXX.com/auth/realms/XXXXXXXXXmfa' failed signature verification. KeyID of token is 'A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u'

Trace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333

Correlation ID: aaaa0000-bb11-2222-33cc-444444dddddd

Timestamp: 2023-07-24 16:51:34Z

Controles personalizados y métodos de autenticación externos

En Microsoft Entra ID, los métodos de autenticación externos y los controles personalizados de acceso condicional pueden funcionar en paralelo mientras los clientes preparan y migran a métodos de autenticación externos.

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 que los administradores creen 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:

    Los controles basados en las fortalezas de autenticación, incluida la fuerza del MFA integrado, no se satisfacen con el método de autenticación externo. Las directivas solo deben configurarse con Requerir autenticación multifactor.

  • La nueva directiva se puede probar primero con un subconjunto de usuarios. El grupo de pruebas se excluye de la directiva que requiere controles personalizados y se incluye en la directiva que requiere MFA. Cuando el administrador está seguro de que el método de autenticación externo satisface la directiva que requiere MFA, el administrador puede incluir a todos los usuarios necesarios en la directiva con la aprobación de MFA. La directiva configurada para controles personalizados se puede mover a la opción Desactivado .

Soporte para la integración

Si tiene algún problema al compilar la integración de métodos de autenticación externos 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
AMF Autenticación multifactor.
Método de autenticación externa 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 OpenID Connect es un protocolo de autenticación basado en OAuth 2.0.
00001111-aaaa-2222-bbbb-3333cccc4444 Ejemplo de un appid valor integrado para un método de autenticación externo.

Contenido relacionado

  • Last updated on