Compartir a través de

Solicitud de un token de acceso en Azure Active Directory B2C

Importante

A partir del 1 de mayo de 2025, Azure AD B2C ya no estará disponible para ser adquirido por nuevos clientes. Obtenga más información en nuestras preguntas más frecuentes.

Un token de acceso contiene declaraciones que puede usar en Azure Active Directory B2C (Azure AD B2C) para identificar los permisos concedidos a sus 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.

En este artículo se 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 la introducción a los tokens en Azure Active Directory B2C.

Nota:

Las cadenas de API web (on-Behalf-Of) no son compatibles con Azure AD B2C : muchas arquitecturas incluyen una API web que necesita llamar a otra API web de bajada, ambas protegidas por Azure AD B2C. Este escenario es común en los 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 on-Behalf-Of funciona para las aplicaciones registradas en el identificador de Entra de Microsoft, no funciona para las aplicaciones registradas en Azure AD B2C, independientemente del inquilino (Id. de Microsoft Entra o Azure AD B2C) que emite los tokens.

Prerrequisitos

Ámbitos

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

La API web usa ámbitos para implementar el control de acceso basado en el ámbito. Por ejemplo, los usuarios de la API web podrían tener acceso de lectura y escritura, o es posible que los usuarios de la API web solo tengan acceso de lectura. Para adquirir varios permisos en la misma solicitud, puede agregar varias entradas en el parámetro de ámbito único de la solicitud, separados por espacios.

En el ejemplo siguiente se muestran ámbitos descodificados en una dirección URL:

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

En el ejemplo siguiente se muestran los á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 tu aplicación necesita un token de acceso que se pueda utilizar contra tu propio servicio o API web, representado por el mismo identificador de cliente.

Si el parámetro response_type de una /authorize solicitud incluye token, el parámetro scope debe incluir al menos un ámbito de recurso aparte de openid y offline_access que se concederá. De lo contrario, se produce un error en la /authorize solicitud.

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 una solicitud al /authorize punto de conexión para un código de autorización:

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 está utilizando un dominio personalizado, reemplace tenant-name.b2clogin.com por su dominio, como contoso.com.
  • <policy-name> : el nombre de la directiva personalizada o el flujo de usuario.
  • <application-ID> - El identificador de aplicación de la aplicación web que ha registrado para apoyar el flujo de usuarios.
  • <application-ID-URI> - El URI del identificador de la aplicación que configuró en la sección Exponer una API de la aplicación cliente.
  • <scope-name> - El nombre del ámbito que usted agregó bajo el panel Exponer una API de la aplicación cliente.
  • <redirect-uri> - El URI de redirección que especificó cuando registró la aplicación cliente.

Para obtener una sensación de cómo funciona la solicitud, pegue la solicitud en el explorador y ejecútelo.

Esta es la parte interactiva del flujo, donde se realiza la acción. Se le pedirá que complete el flujo de trabajo del flujo de usuario. Esto puede implicar escribir el nombre de usuario y la contraseña en un formulario de inicio de sesión o cualquier otro número de pasos. Los pasos que complete dependen de cómo se define 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 están 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 desea probar esta solicitud HTTP POST, puede usar cualquier cliente HTTP como Microsoft PowerShell.

Una respuesta de token correcta tiene este 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..."
}

Al usar https://jwt.ms para examinar el token de acceso que se devolvió, debería 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

  • Last updated on