Conceptos de OpenID Connect/OAuth en AD FS

Artículo
06/09/2023
Se aplica a:

✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

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

Actores de autenticación modernos

Actor	Descripción
Usuario final	Entidad de seguridad (usuarios, aplicaciones, servicios y grupos) que necesitan acceder al recurso.
Cliente	Aplicación web, identificada por su identificador de cliente. El cliente suele ser la parte con la que interactúa el usuario final y solicita tokens del servidor de autorización.
Servidor de autorización/Proveedor de identidades (IdP)	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	Lugar donde residen el recurso o los datos. Confía en el servidor de autorización para autenticar y autorizar al cliente de forma segura y usa tokens de acceso de portador para garantizar que se puede conceder el 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	Role
Aplicación nativa	A veces se denomina cliente público. Está pensada para ser una aplicación cliente que se ejecuta en un equipo o dispositivo y con la 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, usando 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 o credencial de cliente, 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 web	Recurso final al que accede el usuario. Piense en él como la nueva representación de los usuarios de confianza.	Consume tokens de acceso de portador obtenidos por los clientes.

Grupo de aplicaciones

Debe asociar un grupo de aplicaciones a cada cliente de OAuth en aplicación web o nativo, o recurso de API web que se haya configurado con AD FS. Configure los clientes de un grupo de aplicaciones para que accedan a los recursos del mismo grupo. Un grupo de aplicaciones puede contener 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 notificaciones del token de identificador contienen información sobre el usuario para que el cliente pueda usarlo.
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 audiencia 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 AD FS lo puede consumir.

Vigencia del 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 grant_type=refresh_token posterior obtiene un nuevo token de actualización. Este proceso solo se produce con clientes nativos o con el cliente confidencial y la autenticación de dispositivos.
Dispositivos registrados, autenticación de dispositivos: AD FS usa PersistentSsoLifetimeMins y DeviceUsageWindowInDays, como KMSI. Los clientes nativos y confidenciales deben obtener nuevos tokens de actualización (basados en la autenticación del dispositivo).

Para más información, consulte la documentación de 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 administración debe configurar el ámbito como openid durante el registro de recursos y la aplicación (cliente) debe enviar scope = openid en la solicitud de autenticación para que AD FS emita el token del identificador. 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 campo refresh_token de la respuesta y refresh_token_expires_in field, en la 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 usted puede usar para iniciar sesión de manera interactiva en los usuarios autenticados. El servidor de AD FS omite el parámetro access_token de la respuesta y, en su lugar, proporciona una cadena de certificados CMS codificada en base 64 o una respuesta de PKI completa de CMC. Para 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 más información sobre cómo usar este ámbito, consulte Compilación de una aplicación de varios niveles con representación (OBO) mediante OAuth con AD FS 2016.
allatclaims: permite que la aplicación solicite también las que notificaciones del token de acceso se agreguen al token de identificador.
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 por 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.

Notificaciones

Los tokens de seguridad (tokens de identificación y acceso) que emite AD FS contienen notificaciones o aserciones de información sobre el usuario que se ha autenticado. Las aplicaciones pueden usar notificaciones para varias tareas, como:

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

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

Flujo de autenticación de AD FS de alto nivel

A continuación se muestra un diagrama del flujo general.

AD FS recibe la solicitud de autenticación del cliente.
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.
AD FS identifica el recurso al que el cliente quiere acceder mediante parámetro de recurso pasado en la solicitud de autenticación. Si usa la biblioteca cliente de MSAL, el parámetro de recurso no se envía. En su lugar, se envía la dirección URL del recurso como parte del parámetro scope: scope = [URL del recurso]/[valores del ámbito, como openid].

Si el recurso no se pasa mediante el parámetro resource o scope, AD FS usa un recurso predeterminado urn:microsoft:userinfo, cuyas directivas (como MFA, emisión o directiva de autorización) no se pueden configurar.
A continuación, AD FS comprueba si el cliente tiene los permisos para acceder al recurso. AD FS también comprueba si los ámbitos pasados en la solicitud de autenticación coinciden con los configurados al registrar el recurso. Si el cliente no tiene permiso o si no se envían en la solicitud de autenticación los ámbitos correctos, el flujo de autenticación finaliza.
Una vez comprobados los permisos y los ámbitos, AD FS autentica al usuario mediante el método de autenticación configurado.
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.
AD FS usa la autenticación multifactor de Microsoft Entra o la autenticación multifactor de terceros para la autenticación.
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.
A continuación, AD FS genera el acceso y actualiza los tokens. AD FS también genera el token de identificador.
AD FS recibe la solicitud de autenticación.
Si se incluye scope = allatclaims en la solicitud de autenticación, el token de identificador se personaliza para incluir notificaciones en el token de acceso en función de las reglas de notificación definidas.
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

Con AD FS se pueden usar dos tipos de bibliotecas:

Bibliotecas cliente: los clientes nativos y las aplicaciones de servidor usan bibliotecas cliente para adquirir los 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 la recomendada con AD FS 2019.
Bibliotecas de middleware de servidores: Las aplicaciones web usan bibliotecas de middleware de servidor para el inicio de sesión de usuario. Las API de web utilizan bibliotecas de middleware de servidor para comprobar los tokens que se envían mediante clientes nativos u 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 la aplicación web (cliente) necesite notificaciones adicionales en un token de identificador para ayudar en la funcionalidad. Configure las notificaciones adicionales en un token de identificador mediante una de las siguientes opciones:

Opción 1: esta opción se usa con los clientes públicos cuando la aplicación web no tiene 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.

Diagram of AD FS customize token option one.

Opción 2: esta opción se usa cuando la aplicación web tiene un recurso al que intenta acceder y necesita pasar notificaciones adicionales mediante el token de identificador. Puede usar clientes tanto públicos como 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 cliente: par RP. Puede asignar el ámbito mediante Grant-ADFSApplicationPermission. Use Set-AdfsApplicationPermission si ya se le 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"
```

Diagram of AD FS customize token option two.

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

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
/authorize	AD FS devuelve un código de autorización que puede usar para obtener el token de acceso.
/token	AD FS devuelve un token de acceso que puede usar para acceder al recurso, como en la API web.
/userinfo	AD FS devuelve la notificación del firmante.
/devicecode	AD FS devuelve el código de dispositivo y el código de usuario.
/logout	AD FS cierra la sesión del usuario.
/keys	Claves públicas de AD FS usadas para firmar las respuestas.
/.well-known/openid-configuration	AD FS devuelve los metadatos de OAuth/OpenID Connect.

Compartir vía