Solicitud de token de acceso en Azure Active Directory B2C

  • Artículo

Un token de acceso contiene notificaciones que puede usar en Azure Active Directory B2C (Azure AD B2C) para identificar los permisos concedidos a las API. Para llamar a un servidor de recursos, la solicitud HTTP debe incluir un token de acceso. Un token de acceso se indica como access_token en las respuestas de Azure AD B2C.

Este artículo muestra cómo solicitar un token de acceso para una aplicación web y una API web. Para más información sobre los tokens en Azure AD B2C, consulte Información general de tokens de Azure Active Directory B2C.

Nota:

Las cadenas de API web (en nombre de) no son compatibles con Azure AD B2C: muchas arquitecturas incluyen una API web que necesita llamar a otra API web de nivel inferior, ambas protegidas mediante Azure AD B2C. Este escenario es común en clientes que tienen un back-end de API web, que a su vez llama a otro servicio. Este escenario de API web encadenadas puede admitirse mediante la concesión de credenciales de portador JWT de OAuth 2.0, también conocido como flujo "en nombre de". Sin embargo, el flujo "en nombre de" no está implementado actualmente en Azure AD B2C. Aunque "en nombre de" funciona para las aplicaciones registradas en Microsoft Entra ID, no funciona para las aplicaciones registradas en Azure AD B2C, independientemente del inquilino (Microsoft Entra ID o Azure AD B2C) que emita los tokens.

Requisitos previos

Ámbitos

Los ámbitos proporcionan una manera de administrar permisos para los recursos protegidos. Cuando se selecciona un token de acceso, la aplicación cliente debe especificar los permisos que desea en el parámetro scope de la solicitud. Por ejemplo, para determinar el Valor de ámbito de read de la API que tiene el identificador URI de id. de aplicación de https://contoso.onmicrosoft.com/api, el ámbito sería https://contoso.onmicrosoft.com/api/read.

La API web utiliza los ámbitos para implementar el control de acceso basado en el ámbito. Por ejemplo, los usuarios de la API web pueden tener ambos accesos de lectura y de escritura, o pueden tener solo acceso de lectura. Para adquirir varios permisos en la misma solicitud, puede agregar varias entradas en el parámetro scope único de la solicitud, separadas por espacios.

El ejemplo siguiente muestra ámbitos descodificados en una dirección URL:

scope=https://contoso.onmicrosoft.com/api/read openid offline_access

El ejemplo siguiente muestra ámbitos codificados en una dirección URL:

scope=https%3A%2F%2Fcontoso.onmicrosoft.com%2Fapi%2Fread%20openid%20offline_access

Si solicita más ámbitos que los que se conceden para la aplicación cliente, la llamada se realiza correctamente si se concede al menos un permiso. La notificación scp del token de acceso resultante se rellena solo con los permisos que se concedieron correctamente.

Ámbitos de OpenID Connect

El estándar OpenID Connect especifica varios valores de ámbito especiales. Los ámbitos siguientes representan el permiso para acceder al perfil del usuario:

  • openid: solicita un token de identificador.
  • offline_access: solicita un token de actualización con flujos de código de autenticación.
  • 00000000-0000-0000-0000-000000000000: el uso del identificador de cliente como ámbito indica que la aplicación necesita un token de acceso que se puede usar con su propio servicio o API web, representado por el mismo identificador de cliente.

Si el parámetro response_type de una solicitud de /authorize incluye token, el parámetro scope debe incluir al menos un ámbito de recurso (distinto de openid y offline_access) para su concesión. En caso contrario, se produce un error en la solicitud /authorize.

Solicitud de un token

Para solicitar un token de acceso, necesita un código de autorización. A continuación se muestra un ejemplo de solicitud de código de autorización al punto de conexión /authorize:

GET https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/authorize?
client_id=<application-ID>
&nonce=anyRandomValue
&redirect_uri=https://jwt.ms
&scope=<application-ID-URI>/<scope-name>
&response_type=code

Reemplace los valores de la cadena de consulta de la siguiente manera:

  • <tenant-name>: el nombre de su inquilino de Azure AD B2C. Si usa un dominio personalizado, reemplace tenant-name.b2clogin.com por el dominio, por ejemplo, contoso.com.
  • <policy-name>: el nombre de su directiva o flujo de usuarios personalizados.
  • <application-ID>: el identificador de la aplicación web que ha registrado para admitir el flujo de usuario.
  • <application-ID-URI>: El URI del identificador de la aplicación que estableció en la hoja Exponer una API de la aplicación cliente.
  • <scope-name>: El nombre del ámbito que ha agregado en la hoja Exponer una API de la aplicación cliente.
  • <redirect-uri>: el identificador URI de redirección que especificó al registrar la aplicación cliente.

Para hacerse una idea de cómo funciona la solicitud, péguela en el explorador y ejecútela.

Esta es la parte interactiva del flujo, en la que el usuario lleva a cabo la acción. Se le pedirá que complete el flujo de trabajo del flujo de usuario. Esto puede suponer escribir su nombre de usuario y contraseña en un formulario de inicio de sesión o cualquier otro número de pasos. Los pasos que complete dependerán de cómo se defina el flujo de usuario.

La respuesta con el código de autorización debe ser similar a este ejemplo:

https://jwt.ms/?code=eyJraWQiOiJjcGltY29yZV8wOTI1MjAxNSIsInZlciI6IjEuMC...

Después de recibir correctamente el código de autorización, puede usarlo para solicitar un token de acceso. Los parámetros se encuentran en el cuerpo de la solicitud HTTP POST:

POST <tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/token HTTP/1.1
Host: <tenant-name>.b2clogin.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&client_id=<application-ID>
&scope=<application-ID-URI>/<scope-name>
&code=eyJraWQiOiJjcGltY29yZV8wOTI1MjAxNSIsInZlciI6IjEuMC...
&redirect_uri=https://jwt.ms
&client_secret=2hMG2-_:y12n10vwH...

Si quiere probar esta solicitud HTTP POST, puede usar cualquier cliente HTTP, como Microsoft PowerShell o Postman.

Una respuesta correcta del token tiene el siguiente aspecto:

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ilg1ZVhrN...",
    "token_type": "Bearer",
    "not_before": 1549647431,
    "expires_in": 3600,
    "expires_on": 1549651031,
    "resource": "f2a76e08-93f2-4350-833c-965c02483b11",
    "profile_info": "eyJ2ZXIiOiIxLjAiLCJ0aWQiOiJjNjRhNGY3ZC0zMDkxLTRjNzMtYTcyMi1hM2YwNjk0Z..."
}

Cuando se usa https://jwt.ms para examinar el token de acceso devuelto, debe ver algo similar al ejemplo siguiente:

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "X5eXk4xyojNFum1kl2Ytv8dl..."
}.{
  "iss": "https://contoso0926tenant.b2clogin.com/c64a4f7d-3091-4c73-a7.../v2.0/",
  "exp": 1549651031,
  "nbf": 1549647431,
  "aud": "f2a76e08-93f2-4350-833c-965...",
  "oid": "1558f87f-452b-4757-bcd1-883...",
  "sub": "1558f87f-452b-4757-bcd1-883...",
  "name": "David",
  "tfp": "B2C_1_signupsignin1",
  "nonce": "anyRandomValue",
  "scp": "read",
  "azp": "38307aee-303c-4fff-8087-d8d2...",
  "ver": "1.0",
  "iat": 1549647431
}.[Signature]

Pasos siguientes