Escenarios de aplicaciones y flujos de OpenID Connect/OAuth de AD FS

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

Flujo de concesión implícita

Para las aplicaciones de página única (AngularJS, Ember.js, React.js, etc.), AD FS admite el flujo de concesión implícita de OAuth 2.0. El flujo implícito se describe en la especificación de OAuth 2.0. Su principal ventaja es que permite que la aplicación obtenga tokens de AD FS sin realizar un intercambio de credenciales del servidor backend. Este flujo permite a la aplicación iniciar la sesión del usuario, mantener la sesión y obtener tokens para otras API web en el código JavaScript del cliente. Hay algunas consideraciones de seguridad importantes que se deben tener en cuenta al usar el flujo implícito, específicamente en torno al cliente.

Si quieres usar el flujo implícito y AD FS para agregar la autenticación a tu aplicación de JavaScript, sigue los pasos generales que se indican a continuación.

Diagrama de protocolo

En el diagrama siguiente se muestra el aspecto del flujo de inicio de sesión implícito completo. En las secciones siguientes se describe cada paso con más detalle.

Solicitar un token de identificador y un token de acceso

Para iniciar sesión inicialmente el usuario en la aplicación, puede enviar una solicitud de autenticación de OpenID Connect y obtener un id_token y un token de acceso desde el punto de conexión de AD FS.

// Line breaks for legibility only

https://adfs.contoso.com/adfs/oauth2/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=id_token+token
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&scope=openid
&response_mode=fragment
&state=12345

En este punto, se le pide al usuario que escriba sus credenciales y que complete la autenticación. Una vez autenticado el usuario, el punto de conexión de autorización de AD FS devuelve una respuesta a la aplicación en el redirect_uri indicado mediante el método especificado en el parámetro response_mode.

Respuesta correcta

Una respuesta correcta, cuando response_mode=fragment and response_type=id_token+token se usa, tiene este aspecto:

// Line breaks for legibility only

GET https://localhost/myapp/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZEstZnl0aEV...
&token_type=Bearer
&expires_in=3599
&scope=openid
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZstZnl0aEV1Q...
&state=12345

Tokens de actualización

La concesión implícita no proporciona tokens de actualización. Tanto id_tokens como access_tokens expiran después de un breve período de tiempo, por lo que la aplicación debe estar preparada para actualizar estos tokens periódicamente. Para actualizar cualquier tipo de token, puede realizar la misma solicitud de iframe oculta que en la sección anterior, mediante el parámetro para controlar el prompt=none comportamiento de la plataforma de identidad. Si desea recibir un nuevo id_token, asegúrese de usar response_type=id_token.

Flujo de concesión de código de autorización

Puede usar la concesión de código de autorización de OAuth 2.0 en aplicaciones web para obtener acceso a recursos protegidos, como las API web. El flujo de código de autorización de OAuth 2.0 se describe en la sección 4.1 de la especificación de OAuth 2.0. Se usa para realizar la autenticación y la autorización en la mayoría de los tipos de aplicaciones, incluidas las aplicaciones web y las aplicaciones instaladas de forma nativa. El flujo permite que las aplicaciones adquieran de forma segura access_tokens que se pueden usar para acceder a los recursos que confían en AD FS.

Diagrama de protocolo

En un nivel alto, el flujo de autenticación de una aplicación nativa tiene un aspecto similar al siguiente:

Solicitud de un código de autorización

El flujo de código de autorización comienza con el cliente que dirige al usuario al punto de conexión /authorize. En esta solicitud, el cliente indica los permisos que debe adquirir del usuario:

// Line breaks for legibility only

https://adfs.contoso.com/adfs/oauth2/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=query
&resource=https://webapi.com/
&scope=openid
&state=12345

En este punto, se le pide al usuario que escriba sus credenciales y que complete la autenticación. Una vez autenticado el usuario, AD FS devuelve una respuesta a la aplicación en el indicado redirect_urimediante el método especificado en el response_mode parámetro .

Respuesta correcta

Una respuesta correcta, cuando se usa response_mode=query, tiene este aspecto:

GET https://adfs.contoso.com/common/oauth2/nativeclient?
code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&state=12345

Solicitar un token de acceso

Ahora que ha adquirido un parámetro authorization_code y que el usuario le ha concedido permiso, puede canjear el código por un parámetro access_token para el recurso deseado. Canjee el código mediante el envío de una solicitud POST al punto de conexión /token:

// Line breaks for legibility only

POST /adfs/oauth2/token HTTP/1.1
Host: https://adfs.contoso.com/
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&code=OAAABAAAAiL9Kn2Z27UubvWFPbm0gLWQJVzCTE9UkP3pSx1aXxUjq3n8b2JRLk4OxVXr...
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&grant_type=authorization_code
&client_secret=JqQX2PNo9bpM0uEihUPzyrh    // NOTE: Only required for confidential clients (web apps)

Respuesta correcta

Una respuesta de token correcta tiene este aspecto:

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "token_type": "Bearer",
    "expires_in": 3599,
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "refresh_token_expires_in": 28800,
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD...",
}

Uso del token de acceso

GET /v1.0/me/messages
Host: https://webapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...

Actualización del flujo de concesión de tokens

Los parámetros access_token tienen una duración corta y deben actualizarse cuando expiren para seguir teniendo acceso a los recursos. Para hacerlo, puedes enviar otra solicitud POST al punto de conexión /token y proporcionar el parámetro refresh_token en lugar del código esta vez. Los tokens de actualización son válidos para todos los permisos para los que el cliente ya ha recibido tokens de acceso.

Los tokens de actualización no tienen una duración especificada. Normalmente, las duraciones de este tipo de tokens son relativamente largas. Sin embargo, en algunos casos, los tokens de actualización expiran, se revocan o carecen de privilegios suficientes para realizar la acción deseada. Su aplicación debe esperar y controlar los errores que devuelve el punto de conexión de emisión de tokens correctamente.

Aunque los tokens de actualización no se revocan cuando se usan para adquirir nuevos tokens de acceso, se espera que descarte el token de actualización anterior. La especificación OAuth 2.0 dice: "El servidor de autorización puede emitir un nuevo token de actualización, en cuyo caso el cliente DEBE descartar el token de actualización anterior y reemplazarlo por el nuevo token de actualización. El servidor de autorización PUEDE revocar el token de actualización anterior después de emitir un nuevo token de actualización al cliente". AD FS emite tokens de actualización cuando la nueva duración del token de actualización es mayor que la vigencia anterior del token de actualización. Para ver información adicional sobre la duración del token de actualización de AD FS, consulte Configuración de inicio de sesión único de AD FS.

// Line breaks for legibility only

POST /adfs/oauth2/token HTTP/1.1
Host: https://adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&refresh_token=OAAABAAAAiL9Kn2Z27UubvWFPbm0gLWQJVzCTE9UkP3pSx1aXxUjq...
&grant_type=refresh_token
&client_secret=JqQX2PNo9bpM0uEihUPzyrh      // NOTE: Only required for confidential clients (web apps)

Respuesta correcta

Una respuesta de token correcta tiene este aspecto:

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "token_type": "Bearer",
    "expires_in": 3599,
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "refresh_token_expires_in": 28800,
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD...",
}

Compatibilidad con la clave de prueba para intercambio de código (PKCE) de OAuth

Los clientes públicos de OAuth que usan la concesión de código de autorización son vulnerables a los ataques de interceptación de código de autorización, como se describe en RFC 7636. Para mitigar estos ataques, a partir de Windows Server 2019, AD FS admite la clave de prueba para El intercambio de código (PKCE) para el flujo de concesión de código de autorización de OAuth.

La especificación de compatibilidad de PKCE agrega más parámetros a las solicitudes de token de acceso y autorización de OAuth 2.0. En el diagrama siguiente se muestra un esquema del proceso PKCE cuando un cliente se pone en contacto con AD FS en Windows Server 2019.

En la sección denominada A, el cliente crea y registra un secreto denominado code_verifier y deriva una versión transformada del secreto denominado t(code_verifier), también conocido como code_challenge. A continuación, el cliente envía el secreto en la solicitud de autorización de OAuth 2.0 junto con el método de t_m transformación.

En la sección denominada B, el punto de conexión de autorización responde de la forma habitual, pero registra el secreto t(code_verifier) y el método de transformación.

En la sección con la etiqueta C, el cliente envía el código de autorización en la solicitud de token de acceso como de costumbre, pero incluye el secreto generado en la code_verifier sección A.

En la sección con la etiqueta D, AD FS transforma el code_verifiersecreto y lo compara con el secreto de la t(code_verifier) sección B. Si sus valores no son iguales, AD FS deniega el acceso.

Cómo elegir varios proveedores de autenticación para la misma directiva de reglas en Windows Server 2019

AD FS ya admite la activación de la autenticación adicional basada en las directivas de reglas de notificación (RP). Puede establecer estas directivas para un rp determinado o a nivel global. Puede establecer una directiva de autenticación adicional para un rp determinado abriendo PowerShell como administrador y ejecutando el cmdlet Set-AdfsRelyingPartyTrust , pasando el parámetro AdditionalAuthenticationRules o AdditionalAuthenticationRulesFile . Para establecerlo globalmente, un administrador puede usar el cmdlet Set-AdfsAdditionalAuthenticationRule . Establecer directivas adicionales le permite usar más de un proveedor de autenticación para la misma aplicación.

Las reglas de notificación proporcionan la opción de seleccionar el proveedor de autenticación para la autenticación adicional, lo que resulta beneficioso en situaciones en las que los clientes cambian entre proveedores o necesitan un proveedor distinto para determinadas aplicaciones. A partir de Windows Server 2019, puede usar reglas de notificaciones para decidir qué otro proveedor de autenticación invocar para la autenticación adicional. Esta característica es útil en dos escenarios:

• Los usuarios pasan de un proveedor de autenticación a otro. A medida que incorporan usuarios a un proveedor de autenticación más reciente, estos pueden utilizar grupos para controlar qué proveedor de autenticación adicional utiliza el servicio.

• Los usuarios necesitan un proveedor de autenticación adicional específico para determinadas aplicaciones, pero también necesitan usar un método diferente para otras aplicaciones.

Puede configurar estas opciones ejecutando el siguiente comando desde otras directivas de autenticación:

Set-AdfsAdditionalAuthenticationRule -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = "http://schemas.microsoft.com/claims/multipleauthn" );' 

Para configurar esta regla, debe emitir la notificación http://schemas.microsoft.com/claims/authnmethodsproviders desde otras políticas de autenticación. El valor de esta notificación debe ser la variable Name del proveedor de autenticación.

También puede modificar la configuración de esta regla para ayudar a los usuarios a pasar de un proveedor de autenticación a otro. Por ejemplo, supongamos que desea modificar un grupo que administra para usar la autenticación multifactor (MFA) de Microsoft Entra y un grupo para usar certificados como proveedor de autenticación adicional.

Si desea realizar un seguimiento del número de personas que se registran para la autenticación de certificados y MFA, puede ejecutar un comando como este, con los valores reemplazados por los valores pertinentes para su organización:

'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

 c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-608905689-872870963-3921916988-12345"] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "AzureMfaAuthentication"); 

not exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value=="S-1-5-21-608905689-872870963-3921916988-12345"]) => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "CertificateAuthentication");’ 

A continuación, puede establecer la primera aplicación, denominada AppA, para usar MFA como proveedor de autenticación adicional mediante la ejecución de este comando:

Set-AdfsRelyingPartyTrust -TargetName AppA -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "AzureMfaAuthentication");' 

Por último, puede establecer la segunda aplicación, denominada AppB, para usar certificados como proveedor de autenticación adicional mediante la ejecución de este comando:

Set-AdfsRelyingPartyTrust -TargetName AppB -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "CertificateAuthentication");' 

Los administradores también pueden hacer reglas para permitir más de un proveedor de autenticación adicional. En este caso, AD FS muestra los proveedores de métodos de autenticación emitidos y un usuario puede elegir cualquiera de ellos. Para permitir varios proveedores de autenticación adicionales, deben emitir varias notificaciones mediante el valor http://schemas.microsoft.com/claims/authnmethodsproviders.

Si la evaluación de notificaciones no devuelve ninguno de los proveedores de autenticación, AD FS revierte y muestra una lista que contiene todos los proveedores de autenticación adicionales configurados por el administrador en AD FS. A continuación, el usuario debe seleccionar manualmente el proveedor de autenticación adecuado.

Si el proveedor de autenticación que prefiere no está en la lista, puede ejecutar el siguiente cmdlet para ver todos los proveedores admitidos:

(Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider

El valor que usa para la http://schemas.microsoft.com/claims/authnmethodsproviders notificación debe ser uno de los nombres de proveedor devueltos por la lista de proveedores devueltos por AD FS.

AD FS no admite el desencadenamiento de un proveedor de autenticación adicional determinado mientras el RP usa directivas de control de acceso en AD FS Windows Server 2016. Al mover una aplicación fuera de una directiva de control de acceso, AD FS copia la directiva correspondiente de la directiva de control de acceso a AdditionalAuthenticationRules y IssuanceAuthorizationRules. Si un administrador quiere usar un proveedor de autenticación específico, debe dejar de usar la directiva de control de acceso y, en su lugar, modificar AdditionalAuthenticationRules.

On-Behalf-Of flow

El flujo con derechos delegados de OAuth 2.0 sirve para el caso de uso en el que una aplicación invoca una API de servicio o web, que a su vez necesita llamar a otra API de servicio o web. La idea es propagar la identidad y los permisos del usuario delegado a través de la cadena de solicitud. Para que el servicio de nivel intermedio realice solicitudes autenticadas en el servicio de bajada, debe proteger un token de acceso de AD FS, en nombre del usuario.

Diagrama de protocolo

Supongamos que un usuario se autentica en una aplicación mediante el flujo de concesión de código de autorización de OAuth 2.0 descrito en la sección anterior. En este punto, la aplicación tiene un token de acceso para la API A (token A) con las notificaciones y el consentimiento del usuario para acceder a la API web de nivel intermedio (API A). Asegúrese de que el cliente solicita user_impersonation ámbito en el token. Ahora, la API A debe realizar una solicitud autenticada a la API web de bajada (API B).

Los pasos siguientes constituyen el flujo con derechos delegados y se explican con la ayuda del diagrama siguiente.

1. La aplicación cliente realiza una solicitud a la API A con el token A. (Al configurar el flujo de OBO en AD FS, asegúrese de que el ámbito user_impersonation está seleccionado y de que los clientes solicitan user_impersonation ámbito en la solicitud).
2. La API A se autentica en el punto de conexión de emisión de tokens de AD FS y solicita un token para acceder a la API B. (Al configurar este flujo en AD FS, asegúrese de que la API A también está registrada como una aplicación de servidor con un identificador de cliente que tenga el mismo valor que el identificador de recurso en la API A).
3. El punto de conexión de emisión de tokens de AD FS valida las credenciales de la API A con el token A y emite el token de acceso para la API B (token B).
4. El token B se establece en el encabezado de autorización de la solicitud a la API B.
5. La API B devuelve los datos del recurso protegido.

Solicitud de token de acceso de servicio a servicio

Para solicitar un token de acceso, realice una solicitud HTTP POST al punto de conexión del token de AD FS con los parámetros descritos en las secciones siguientes.

Primer caso: solicitud de token de acceso con un secreto compartido

Para un secreto compartido, una solicitud de token de acceso de servicio a servicio contiene los parámetros siguientes:

Example

A continuación se HTTP POST solicita un token de acceso y un token de actualización.

// Line breaks for legibility only

POST /adfs/oauth2/token HTTP/1.1
Host: adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&client_id=https://webapi.com/
&client_secret=BYyVnAt56JpLwUcyo47XODd
&assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIm…
&resource=https://secondwebapi.com/
&requested_token_use=on_behalf_of
&scope=openid

Segundo caso: solicitud de token de acceso con un certificado

Una solicitud de token de acceso entre servicios con un certificado contiene los parámetros siguientes:

Observe que los parámetros son casi los mismos. Este ejemplo es similar a la solicitud por secreto compartido, salvo que el parámetro client_secret se reemplaza por dos parámetros: client_assertion_type y client_assertion.

Example

El siguiente HTTP POST solicita un token de acceso para la API web con un certificado.

// Line breaks for legibility only

POST /adfs/oauth2/token HTTP/1.1
Host: https://adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&client_id= https://webapi.com/
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6Imd4OHRHeXN5amNS…
&resource=https://secondwebapi.com/
&requested_token_use=on_behalf_of
&scope= openid

Respuesta del token de acceso de servicio a servicio

Una respuesta correcta es una respuesta JSON OAuth 2.0 que tiene los parámetros siguientes.

Ejemplo de respuesta correcta

En el ejemplo siguiente se muestra una respuesta correcta a una solicitud de un token de acceso para la API web.

{
  "token_type": "Bearer",
  "scope": openid,
  "expires_in": 3269,
  "access_token": "eyJ0eXAiOiJKV1QiLCJub25jZSI6IkFRQUJBQUFBQUFCbmZpRy1t"
  "id_token": "aWRfdG9rZW49ZXlKMGVYQWlPaUpLVjFRaUxDSmhiR2NpT2lKU1V6STFOa"
  "refresh_token": "OAQABAAAAAABnfiG…"
  "refresh_token_expires_in": 28800,
}

Uso del token de acceso para acceder al recurso protegido

Ahora, el servicio de nivel intermedio puede usar el token adquirido en el ejemplo de respuesta anterior para realizar solicitudes autenticadas a la API web de nivel inferior. Establezca el token en el encabezado Autorización.

Example

GET /v1.0/me HTTP/1.1
Host: https://secondwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJub25jZSI6IkFRQUJBQUFBQUFCbmZpRy1tQ…

Flujo de concesión de credenciales de cliente

Puede usar la concesión de credenciales de cliente de OAuth 2.0 especificada en RFC 6749 para acceder a los recursos hospedados en web mediante la identidad de una aplicación. Este tipo de concesión se usa principalmente para las interacciones entre servidores que se deben ejecutar en segundo plano, sin la interacción inmediata con un usuario. Estos tipos de aplicaciones suelen denominarse demonios o cuentas de servicio.

El flujo de concesión de credenciales de cliente de OAuth 2.0 permite que un servicio web (cliente confidencial) use sus propias credenciales para autenticarse al llamar a otro servicio web, en lugar de suplantar a un usuario. En este escenario, el cliente suele ser un servicio web de nivel intermedio, un servicio de demonio o un sitio web. Para obtener un mayor nivel de garantía, AD FS también permite al servicio de llamada usar un certificado (en lugar de un secreto compartido) como credencial.

Diagrama de protocolo

En el diagrama siguiente se muestra el flujo de concesión de credenciales de cliente.

Solicitar un token

Para obtener un token mediante la concesión de credenciales de cliente, envíe una POST solicitud al punto de conexión de /token AD FS, como se muestra en las secciones siguientes.

Primer caso: solicitud de token de acceso con un secreto compartido

POST /adfs/oauth2/token HTTP/1.1
// Line breaks for legibility only

Host: https://adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&client_secret=qWgdYAmab0YSkuL1qKv5bPX
&grant_type=client_credentials

Segundo caso: solicitud de token de acceso con un certificado

POST /adfs/oauth2/token HTTP/1.1

// Line breaks for legibility only

Host: https://adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

&client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6Imd4OHRHeXN5amNScUtqRlBuZDdSRnd2d1pJMCJ9.eyJ{a lot of characters here}M8U3bSUKKJDEg
&grant_type=client_credentials

Uso de un token

Ahora que has adquirido un token, úsalo para realizar solicitudes al recurso. Cuando el token expire, repite la solicitud al punto de conexión /token para adquirir un token de acceso nuevo.

GET /v1.0/me/messages
Host: https://webapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...

Flujo de concesión de credenciales de contraseña del propietario del recurso (no recomendado)

La concesión de credenciales de contraseña del propietario del recurso (ROPC) permite a una aplicación iniciar la sesión del usuario mediante el control directo de su contraseña. El flujo ROPC requiere un alto grado de confianza y exposición del usuario. Debe usar este flujo solo cuando no pueda usar otros flujos que sean más seguros.

Diagrama de protocolo

En el diagrama siguiente se muestra el flujo de ROPC.

Solicitud de autorización

El flujo de ROPC es una solicitud única: envía la identificación del cliente y las credenciales del usuario al IDP y, a cambio, recibe los tokens. El cliente debe solicitar la dirección de correo electrónico (UPN) y la contraseña del usuario antes de hacerlo. Inmediatamente después de que una solicitud se realice correctamente, el cliente deberá liberar de manera segura las credenciales del usuario de la memoria. Nunca deben guardarse.

// Line breaks and spaces are for legibility only

POST /adfs/oauth2/token HTTP/1.1
Host: https://adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope= openid
&username=myusername@contoso.com
&password=SuperS3cret
&grant_type=password

Respuesta de autenticación correcta

En el ejemplo siguiente se muestra una respuesta de token correcta:

{
    "token_type": "Bearer",
    "scope": "openid",
    "expires_in": 3599,
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIn...",
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "refresh_token_expires_in": 28800,
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDR..."
}

Puede usar el token de actualización para adquirir nuevos tokens de acceso y tokens de actualización mediante el mismo flujo descrito en la sección flujo de concesión de código de autenticación de este artículo.

Flujo de código de dispositivo

La concesión de código de dispositivo permite a los usuarios iniciar sesión en dispositivos con restricciones de entrada, como un televisor inteligente, un dispositivo IoT o una impresora. Para habilitar este flujo, el dispositivo exige al usuario visitar una página web en el explorador o en otro dispositivo para iniciar sesión. Una vez que el usuario inicia sesión, el dispositivo puede obtener tokens de acceso y actualizar los tokens según sea necesario.

Diagrama de protocolo

Todo el flujo de código del dispositivo es similar al que se muestra en el diagrama siguiente. Cada uno de los pasos se describe más adelante en este artículo.

Solicitud de autorización de dispositivo

El cliente debe primero realizar una comprobación con el servidor de autenticación para obtener un código de usuario y dispositivo que se usa para iniciar la autenticación. El cliente recopila esta solicitud desde el punto de conexión /devicecode. En esta solicitud, el cliente también debe incluir los permisos que necesita obtener por parte del usuario. Desde el momento en que se envía esta solicitud, el usuario solo tiene 15 minutos para iniciar sesión (el valor habitual de expires_in), por lo que solo debe realizar esta solicitud cuando el usuario haya indicado que está listo para iniciar sesión.

// Line breaks are for legibility only

POST https://adfs.contoso.com/adfs/oauth2/devicecode
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
scope=openid

Respuesta de autorización de dispositivo

Una respuesta correcta es un objeto JSON que contenga la información necesaria para permitir que el usuario inicie sesión.

Autenticación del usuario

Una vez que el cliente recibe el user_code y verification_uri, muestra estos detalles al usuario, instruyéndolas para iniciar sesión con su teléfono móvil o explorador de PC. Además, el cliente puede usar un código QR o un mecanismo similar para mostrar el parámetro verfication_uri_complete, con lo que el parámetro user_code se escribirá automáticamente. Mientras el usuario se autentica en verification_uri, el cliente debe sondear el punto de conexión /token del token solicitado mediante el valor de device_code.

POST https://adfs.contoso.com /adfs/oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type: urn:ietf:params:oauth:grant-type:device_code
client_id: 00001111-aaaa-2222-bbbb-3333cccc4444
device_code: GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8

Respuesta de autenticación correcta

Una respuesta de token correcta puede incluir estos parámetros:

Contenido relacionado

Consulta Desarrollo de AD FS para obtener una lista completa de los artículos de tutoriales, que te proporcionan instrucciones paso a paso sobre el uso de los flujos relacionados.