Condividi tramite

Richiedere un token di accesso in Azure Active Directory B2C

Importante

A partire dal 1° maggio 2025, Azure AD B2C non sarà più disponibile per l'acquisto per i nuovi clienti. Altre informazioni sono disponibili nelle domande frequenti.

Un token di accesso contiene attestazioni che è possibile usare in Azure Active Directory B2C (Azure AD B2C) per identificare le autorizzazioni concesse per le API. Per chiamare un server di risorse, la richiesta HTTP deve includere un token di accesso. Un token di accesso viene indicato come access_token nelle risposte di Azure AD B2C.

Questo articolo illustra come richiedere un token di accesso per un'applicazione Web e un'API Web. Per altre informazioni sui token in Azure AD B2C, vedere la panoramica dei token in Azure Active Directory B2C.

Annotazioni

Le catene di API Web (on-Behalf-Of) non sono supportate da Azure AD B2C : molte architetture includono un'API Web che deve chiamare un'altra API Web downstream, entrambe protette da Azure AD B2C. Questo scenario è comune nei client che dispongono di un back-end api Web, che a sua volta chiama un altro servizio. Questo scenario di API Web concatenato può essere supportato usando la concessione di credenziali bearer JWT OAuth 2.0, altrimenti nota come flusso on-Behalf-Of. Tuttavia, il flusso on-Behalf-Of non è attualmente implementato in Azure AD B2C. Anche se on-Behalf-Of funziona per le applicazioni registrate in Microsoft Entra ID, non funziona per le applicazioni registrate in Azure AD B2C, indipendentemente dal tenant (Microsoft Entra ID o Azure AD B2C) che emette i token.

Prerequisiti

Ambiti

Gli ambiti consentono di gestire le autorizzazioni per le risorse protette. Quando viene richiesto un token di accesso, l'applicazione client deve specificare le autorizzazioni desiderate nel parametro di ambito della richiesta. Ad esempio, per specificare il Valore del campo di read per l'API con l'URI dell'ID dell'app di https://contoso.onmicrosoft.com/api, l'ambito risultante sarà https://contoso.onmicrosoft.com/api/read.

Gli ambiti vengono usati dall'API Web per implementare il controllo degli accessi in base all'ambito. Ad esempio, gli utenti dell'API Web potrebbero avere accesso in lettura e scrittura oppure gli utenti dell'API Web potrebbero avere accesso in sola lettura. Per acquisire più autorizzazioni nella stessa richiesta, è possibile aggiungere più voci nel singolo parametro di ambito della richiesta, separate da spazi.

L'esempio seguente mostra gli ambiti decodificati in un URL:

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

L'esempio seguente mostra gli ambiti codificati in un URL:

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

Se si richiedono più ambiti rispetto a quanto concesso per l'applicazione client, la chiamata ha esito positivo se viene concessa almeno un'autorizzazione. L'attestazione scp nel token di accesso risultante viene popolata con solo le autorizzazioni concesse correttamente.

Ambiti di OpenID Connect

Lo standard OpenID Connect specifica diversi valori di ambito speciali. Gli ambiti seguenti rappresentano l'autorizzazione per accedere al profilo dell'utente:

  • openid : richiede un token ID.
  • offline_access: richiede un token di aggiornamento usando flussi del codice di autorizzazione.
  • 00000000-0000-0000-0000-000000000000 - L'uso dell'ID client come ambito indica che l'app necessita di un token di accesso che può essere usato con il proprio servizio o API Web, rappresentato dallo stesso ID client.

Se il parametro response_type in una /authorize richiesta include token, il parametro scope deve includere almeno un ambito di risorsa diverso da openid e offline_access che verrà concesso. La richiesta /authorize fallisce altrimenti.

Richiedere un token

Per richiedere un token di accesso, è necessario un codice di autorizzazione. Di seguito è riportato un esempio di richiesta all'endpoint /authorize per un codice di autorizzazione:

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

Sostituire i valori nella stringa di query come indicato di seguito:

  • <tenant-name> - Nome del tenant di Azure AD B2C. Se si usa un dominio personalizzato, sostituire tenant-name.b2clogin.com con il dominio, ad esempio contoso.com.
  • <policy-name> - Nome del criterio personalizzato o del flusso utente.
  • <application-ID> - Identificatore dell'applicazione Web registrata per supportare il flusso utente.
  • <application-ID-URI> - L'URI dell'identificatore dell'applicazione che hai impostato nel pannello Esporre un'API dell'applicazione client.
  • <scope-name> - Il nome dell'ambito che hai aggiunto nella sezione Esporre un'API dell'applicazione client.
  • <redirect-uri> - URI di reindirizzamento immesso quando è stata registrata l'applicazione client.

Per ottenere un'impressione del funzionamento della richiesta, incollare la richiesta nel browser ed eseguirla.

Questa è la parte interattiva del flusso, in cui si esegue un'azione. Ti viene chiesto di completare il flusso di lavoro dell'utente. Ciò potrebbe comportare l'immissione del nome utente e della password in un modulo di accesso o di qualsiasi altro numero di passaggi. I passaggi completati dipendono dalla modalità di definizione del flusso utente.

La risposta con il codice di autorizzazione dovrebbe essere simile a questo esempio:

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

Dopo aver ricevuto correttamente il codice di autorizzazione, è possibile usarlo per richiedere un token di accesso. I parametri si trovano nel corpo della richiesta 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...

Se si vuole testare questa richiesta HTTP POST, è possibile usare qualsiasi client HTTP, ad esempio Microsoft PowerShell.

Una risposta con esito positivo del token è simile alla seguente:

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

Quando si usa https://jwt.ms per esaminare il token di accesso restituito, dovrebbe essere visualizzato un aspetto simile all'esempio seguente:

{
  "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]

Passaggi successivi