Conceptos de OpenID Connect/OAuth de AD FS

Se aplica a los Servicios de federación de Active Directory (AD FS) 2016 y versiones posteriores

Actores de autenticación modernos

Actor/Actriz	Descripción
Usuario final	Entidad de seguridad (usuarios, aplicaciones, servicios y grupos) que accede al recurso.
Cliente	Aplicación web, identificada por su id. de cliente. El cliente suele ser la entidad con la que interactúa el usuario final y el cliente solicita tokens desde el servidor de autorización.
Servidor de autorización/Proveedor de identidades (IdP)	El servidor de AD FS. Es responsable de comprobar la identidad de las entidades de seguridad que existen en el directorio de una organización. Emite tokens de seguridad (token de acceso de portador, token de identificador, token de actualización) tras la autenticación correcta de esas entidades de seguridad.
Servidor de recursos/ Proveedor de recursos/Usuario de confianza	Dónde reside el recurso o los datos. Confía en el servidor de autorización para autenticar y autorizar de forma segura al cliente y usa tokens de acceso de portador para asegurarse de que se puede conceder acceso a un recurso.

En el diagrama siguiente se proporciona la relación más básica entre los actores:

Tipos de aplicación

Tipo de aplicación	Descripción	Rol
Aplicación nativa	A veces se denomina cliente público. Está pensado para ser una aplicación cliente que se ejecuta en un equipo o dispositivo y con el que interactúa el usuario.	Solicita tokens del servidor de autorización (AD FS) para el acceso de usuario a los recursos. Envía solicitudes HTTP a recursos protegidos mediante el uso de los tokens como encabezados HTTP.
Aplicación de servidor (aplicación web)	Una aplicación web que se ejecuta en un servidor y es accesible para los usuarios a través de un explorador. Dado que es capaz de mantener su propio secreto de cliente o credenciales, a veces se denomina cliente confidencial.	Solicita tokens del servidor de autorización (AD FS) para el acceso de usuario a los recursos. Antes de solicitar un token, el cliente (aplicación web) debe autenticarse mediante su secreto.
API de la web	Recurso final al que accede el usuario. Piense en ello como la nueva representación de las partes confiables.	Consume tokens de acceso de portador obtenidos por los clientes.

Grupo de aplicaciones

Debe asociar un grupo de aplicaciones a cada cliente OAuth de aplicación nativa o web, o recurso de API web que esté configurado con AD FS. Configure los clientes de un grupo de aplicaciones para acceder a los recursos del mismo grupo. Un grupo de aplicaciones puede tener varios clientes y recursos.

Tokens de seguridad

La autenticación moderna usa los siguientes tipos de token:

• id_token: un token JWT emitido por el servidor de autorización (AD FS) y consumido por el cliente. Las cláusulas del token de identificación contienen información sobre el usuario para que el cliente pueda utilizarla.
• access_token: un token JWT emitido por el servidor de autorización (AD FS) y destinado a ser consumido por el recurso. La notificación "aud" o público de este token debe coincidir con el identificador del recurso o la API web.
• refresh_token: emitido por AD FS para que el cliente lo use cuando necesite actualizar el id_token y el access_token. El token es opaco para el cliente y solo lo consume AD FS.

Vigencias de token de actualización

• Inicio de sesión simple, sin KMSI, dispositivo no registrado: AD FS aplica SsoLifetime y DeviceUsageWindowInDays. El primer token de actualización tiene lifetime=DeviceUsageWindowInDays o SsoLifetime, en función del campo menor, pero no se emiten más tokens de actualización.
• Inicio de sesión de KMSI, EnableKmsi=true en la configuración de AD FS y kmsi=true pasado como parámetro: AD FS aplica KmsiLifetimeMins con DeviceUsageWindowInDays. El primer token de actualización tiene lifetime=DeviceUsageWindowInDays y cada solicitud posterior grant_type=refresh_token obtiene un nuevo token de actualización. Este proceso solo se produce con clientes nativos o cliente confidencial más la autenticación de dispositivos.
• Dispositivos registrados, autenticación de dispositivo: AD FS usa PersistentSsoLifetimeMins y DeviceUsageWindowInDays similar a KMSI. Los clientes nativos y confidenciales deben obtener nuevos tokens de actualización, en función de la autenticación del dispositivo.

Para más información, consulte la documentación del inicio de sesión único de AD FS.

Ámbitos

Al registrar un recurso en AD FS, puede configurar ámbitos para permitir que AD FS realice acciones específicas. Junto con la configuración del ámbito, debe enviar el valor del ámbito en la solicitud para que AD FS realice la acción. Por ejemplo, un administrador configura el ámbito como openid durante el registro de recursos y la aplicación (cliente) debe enviar el scope = openid en la solicitud de autenticación de AD FS para que este emita el token de ID. A continuación se detallan los ámbitos disponibles en AD FS:

• aza - Si usa extensiones de protocolo de OAuth 2.0 para clientes de agente y si el parámetro scope contiene el ámbito aza, el servidor emite un nuevo token de actualización principal. Establece el token en el refresh_token campo de la respuesta y establece la refresh_token_expires_in field duración del nuevo token de actualización principal si se aplica uno.
• openid - Permite que la aplicación solicite el uso del protocolo de autenticación de conexión openid.
• logon_cert - Permite que una aplicación solicite certificados de inicio de sesión que puede usar para iniciar sesión interactivamente en usuarios autenticados. El servidor de AD FS omite el access_token parámetro de la respuesta y, en su lugar, proporciona una cadena de certificados CMS codificada en base64 o una respuesta PKI completa de CMC. Para obtener más información, consulte MS-OAPX: extensiones de protocolo de OAuth 2.0.
• user_impersonation: solicita un token de acceso de representación de desde AD FS. Para obtener más información sobre cómo usar este ámbito, consulte Compilación de una aplicación de varios niveles mediante on-Behalf-Of (OBO) mediante OAuth con AD FS 2016.
• allatclaims : permite a la aplicación solicitar que las reclamaciones dentro del token de acceso se agreguen también al token de identificación.
• vpn_cert - Permite a una aplicación solicitar certificados VPN, que establecen conexiones VPN mediante la autenticación EAP-TLS. Esta característica ya no se admite.
• email - Permite que la aplicación solicite una notificación de correo electrónico para el usuario que ha iniciado sesión.
• profile: permite que la aplicación solicite notificaciones relacionadas con el perfil para el usuario que ha iniciado sesión.

Reclamaciones

Los tokens de seguridad (tokens de acceso e identificador) emitidos por AD FS contienen notificaciones o aserciones de información sobre el sujeto que se ha autenticado. Las aplicaciones pueden usar reclamaciones para varias tareas, entre las que se incluyen:

• Validar el token
• Identificar el inquilino del directorio del sujeto
• Mostrar información de usuario
• Determinar la autorización del sujeto

Las declaraciones presentes en cualquier token de seguridad determinado dependen del tipo de token, del tipo de credencial que se usa para autenticar al usuario y de la configuración de la aplicación.

Flujo de autenticación general de AD FS

A continuación se muestra un diagrama del flujo de alto nivel.

1. AD FS recibe la solicitud de autenticación del cliente.

2. AD FS valida el identificador de cliente en la solicitud de autenticación con el identificador de cliente obtenido durante el registro de recursos y el cliente en AD FS. Si usa un cliente confidencial, AD FS también valida el secreto de cliente proporcionado en la solicitud de autenticación. AD FS también valida el URI de redirección del cliente.

3. AD FS identifica el recurso al que el cliente quiere acceder a través del parámetro de recurso que se pasa en la solicitud de autenticación. Si usa la biblioteca cliente de MSAL, no se envía el parámetro de recurso. En su lugar, la dirección URL del recurso se envía como parte del parámetro scope: scope = [resource url]/[scope values, por ejemplo, openid].

   Si el recurso no se pasa mediante los parámetros de recurso o ámbito, AD FS usa un recurso urn:microsoft:userinfo predeterminado cuyas directivas, como, MFA, emisión o directiva de autorización, no se pueden configurar.

4. AD FS siguiente valida si el cliente tiene permisos para acceder al recurso. AD FS también valida si los ámbitos pasados en la solicitud de autenticación coinciden con los ámbitos configurados al registrar el recurso. Si el cliente no tiene los permisos o los ámbitos adecuados no se envían en la solicitud de autenticación, el flujo de autenticación finaliza.

5. Una vez que se validan los permisos y ámbitos, AD FS autentica al usuario mediante el método de autenticación configurado.

6. Si se requiere otro método de autenticación según la directiva de recursos o la directiva de autenticación global, AD FS desencadena la autenticación adicional.

7. AD FS usa la autenticación multifactor de Microsoft Entra o la autenticación multifactor de terceros para realizar la autenticación.

8. Una vez autenticado el usuario, AD FS aplica las reglas de notificación. Las reglas de notificación determinan las notificaciones enviadas al recurso como parte de los tokens de seguridad. AD FS también aplica las directivas de control de acceso que confirman que el usuario cumple las condiciones necesarias para acceder al recurso.

9. A continuación, AD FS genera el acceso y actualiza los tokens. AD FS también genera el token de identificador.

10. AD FS recibe la solicitud de autenticación.

11. Si incluye el scope = allatclaims en la solicitud de autenticación, personaliza el token de ID para incluir reclamaciones en el token de acceso en función de las reglas de reclamaciones definidas.

12. Una vez generados y personalizados los tokens necesarios, AD FS responde al cliente e incluye los tokens. La respuesta del token de identificador solo se incluye en la respuesta si la solicitud de autenticación incluye scope = openid. El cliente siempre puede obtener el token de identificador después de la autenticación mediante el punto de conexión del token.

Tipos de bibliotecas

Use dos tipos de bibliotecas con AD FS:

• Bibliotecas cliente: los clientes nativos y las aplicaciones de servidor usan bibliotecas cliente para obtener tokens de acceso para llamar a un recurso como una API web. La biblioteca de autenticación de Microsoft (MSAL) es la biblioteca cliente más reciente y recomendada cuando se usa AD FS 2019.

• Bibliotecas de middleware de servidor: las aplicaciones web usan bibliotecas de middleware de servidor para el inicio de sesión de usuario. Las API web usan bibliotecas de middleware de servidor para validar los tokens enviados por clientes nativos o por otros servidores. Open Web Interface for .NET (OWIN) es la biblioteca de middleware recomendada.

Personalización del token de identificador (notificaciones adicionales en el token de identificador)

En determinados escenarios, es posible que el cliente de la aplicación web necesite atributos adicionales en un token de ID para mejorar la funcionalidad. Configure reclamaciones adicionales en un token de identificador mediante una de las siguientes opciones:

Opción 1: Use esta opción cuando tenga un cliente público y la aplicación web no tenga un recurso al que intenta acceder. Esta opción requiere:

• response_mode se establece como form_post
• El identificador de usuario de confianza (identificador de API web) es el mismo que el identificador de cliente.

Opción 2: Usa esta opción cuando la aplicación web tiene un recurso al que intenta acceder y necesita pasar reclamaciones adicionales a través del token de identificación. Puede usar clientes públicos y confidenciales. Esta opción requiere:

• response_mode se establece como form_post

• KB4019472 está instalado en los servidores de AD FS

• El ámbito allatclaims se asigna al par cliente-RP. Puede asignar el ámbito mediante el uso de Grant-ADFSApplicationPermission. Use Set-AdfsApplicationPermission si ya se ha concedido una vez. El cmdlet de PowerShell se indica en el ejemplo siguiente:

  Grant-AdfsApplicationPermission -ClientRoleIdentifier "https://my/privateclient" -ServerRoleIdentifier "https://rp/fedpassive" -ScopeNames "allatclaims","openid"
  

Para comprender mejor cómo configurar una aplicación web en AD FS para obtener un token de identificador personalizado, consulte Tokens de identificador personalizado en AD FS 2016 o posterior.

Cierre de sesión único

El cierre de sesión único finaliza todas las sesiones de cliente que usan el identificador de sesión. AD FS 2016 y versiones posteriores admiten el cierre de sesión único para OpenID Connect/OAuth. Para obtener más información, consulte Cierre de sesión único para OpenID Connect con AD FS.

Puntos de conexión de AD FS

Punto de conexión de AD FS	Descripción
/autorizar	AD FS devuelve un código de autorización que puede usar para obtener el token de acceso.
/seña	AD FS devuelve un token de acceso que puede usar para acceder al recurso, como en la API web.
/info_usuario	AD FS devuelve la notificación del firmante.
/código de dispositivo	AD FS devuelve el código de dispositivo y el código de usuario.
/Cerrar sesión	AD FS cierra la sesión del usuario.
/Llaves	Claves públicas de AD FS usadas para firmar respuestas.
/.conocido/configuración-openid	AD FS devuelve metadatos de OAuth/OpenID Connect.