Richiedere un token di accesso in Azure Active Directory B2C

  • Articolo

Un token di accesso contiene attestazioni che è possibile usare in Azure Active Directory B2C (Azure AD B2C) per identificare le autorizzazioni concesse alle API. Per chiamare un server di risorse, la richiesta HTTP deve includere un token di accesso. Un token di accesso è 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.

Nota

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 hanno un back-end dell'API Web, che a sua volta chiama un altro servizio. Questo scenario di API Web concatenate può essere supportato tramite la concessione di credenziali del bearer token JWT di OAuth 2.0, nota anche come flusso On-Behalf-Of. Il flusso On-Behalf-Of, tuttavia, 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 (ID Microsoft Entra o Azure AD B2C) che emette i token.

Prerequisiti

Ambiti

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

Vengono usati dall'API Web per implementare il controllo degli accessi in base all'ambito. Ad esempio, gli utenti dell'API Web possono avere accesso sia in lettura sia in scrittura oppure possono avere solo accesso in lettura. Per acquisire più autorizzazioni nella stessa richiesta, è possibile aggiungere più voci nell'unico parametro ambito della richiesta, separato da spazi.

Nell'esempio seguente vengono illustrati gli ambiti decodificati in un URL:

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

Nell'esempio seguente vengono illustrati 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 quelli concessi per l'applicazione client, la chiamata ha esito positivo se viene concessa almeno un'autorizzazione. L'attestazione scp del token di accesso risultante viene popolata con solo le autorizzazioni concesse.

Ambiti di OpenID Connect

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

  • openid - Richiede un token ID.
  • offline_access - Richiede un token di aggiornamento mediante i flussi del codice di autorizzazione.
  • 00000000-0000-0000-0000-0000000000000- 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 richiesta /authorize include token, il parametro ambito deve includere almeno un ambito delle risorse diverso da openid e offline_access che verrà concesso. In caso contrario, la richiesta /authorize ha esito negativo.

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>: il nome del flusso utente o dei criteri personalizzati.
  • <application-ID>: l'identificatore applicazione dell'applicazione Web registrata per supportare il flusso utente.
  • <application-ID-URI> - URI dell'identificatore dell'applicazione impostato in Esporre un pannello API dell'applicazione client.
  • <scope-name> - Nome dell'ambito aggiunto in Esporre un pannello API dell'applicazione client.
  • <redirect-uri>: l'URI di reindirizzamento immesso al momento della registrazione dell'applicazione client.

Per avere un'idea del funzionamento della richiesta, incollare la richiesta nel browser ed eseguirla.

Questa è la parte interattiva del flusso, in cui si esegue un'azione. Viene chiesto di completare il flusso di lavoro del flusso utente. Ciò potrebbe comportare l'immissione del nome utente e della password in un modulo di accesso o in 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...

Per testare questa richiesta HTTP POST, è possibile usare qualsiasi client HTTP, ad esempio Microsoft PowerShell o Postman.

Una risposta di token con esito positivo ha un aspetto simile al 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, verrà visualizzato un testo 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