Configurare il flusso delle credenziali client OAuth 2.0 in Azure Active Directory B2C

2025-06-23

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.

Prima di iniziare, utilizza il selettore Scegli un tipo di criterio nella parte superiore di questa pagina per scegliere il tipo di criterio che si sta configurando. Azure Active Directory B2C offre due metodi per definire il modo in cui gli utenti interagiscono con le applicazioni: tramite flussi utente predefiniti o tramite criteri personalizzati completamente configurabili. I passaggi necessari in questo articolo sono diversi per ogni metodo.

Il flusso di concessione delle credenziali client OAuth 2.0 consente a un'app (client riservato) di usare le proprie credenziali, invece di rappresentare un utente, per eseguire l'autenticazione quando si chiama una risorsa Web, ad esempio l'API REST. Questo tipo di concessione viene comunemente usato per le interazioni da server a server che devono essere eseguite in background, senza l'interazione immediata con un utente. Questo tipo di applicazioni viene spesso definito daemon o account di servizio.

Nel flusso delle credenziali client, le autorizzazioni vengono concesse direttamente all'applicazione stessa da un amministratore. Quando l'app presenta un token a una risorsa, la risorsa impone che l'app stessa disponga dell'autorizzazione per eseguire un'azione poiché non è coinvolto alcun utente nell'autenticazione. Questo articolo illustra i passaggi necessari per autorizzare un'applicazione a chiamare un'API e come ottenere i token necessari per chiamare tale API.

Annotazioni

Questa funzionalità è disponibile nella versione di anteprima pubblica.

Panoramica della registrazione dell'app

Per consentire all'app di accedere con le credenziali client, quindi chiamare un'API Web, registrare due applicazioni nella directory di Azure AD B2C.

La registrazione dell'applicazione consente all'app di accedere con Azure AD B2C. Il processo di registrazione dell'app genera un ID applicazione, noto anche come ID client, che identifica in modo univoco l'app. Si crea anche un segreto client, che l'app usa per acquisire in modo sicuro i token.
La registrazione dell'API Web consente all'app di chiamare un'API Web sicura. La registrazione include gli ambiti dell'API Web. Gli ambiti consentono di gestire le autorizzazioni per le risorse protette, ad esempio l'API Web. Quindi, si concedono le autorizzazioni dell'applicazione agli ambiti dell'API Web. Quando viene richiesto un token di accesso, l'app specifica il .default parametro scope della richiesta. Azure AD B2C restituisce gli ambiti dell'API Web concessi all'app.

L'architettura e le registrazioni dell'app sono illustrate nel diagramma seguente:

Schema di una web app con web A P I call registrazioni e token.

Passaggio 1: Registrare l'app per le API Web

In questo passaggio si registra l'API Web (App 2) con i relativi ambiti. Successivamente, si concede all'applicazione (App 1) l'autorizzazione per tali ambiti. Se si dispone già di una registrazione dell'app di questo tipo, ignorare questo passaggio, quindi passare a quello successivo, Passaggio 1.1 Definire i ruoli dell'API Web (ambiti).

Per creare la registrazione dell'app per le API Web (ID app: 2), seguire questa procedura:

Accedi al portale di Azure.
Assicurarsi di usare la directory che contiene il tenant di Azure AD B2C. Selezionare l'icona Directory e sottoscrizioni nella barra degli strumenti del portale.
Nelle impostazioni del portale | Directory + sottoscrizioni, trova la directory di Azure AD B2C nell'elenco Nome directory e seleziona Cambia.
Nel portale di Azure cercare e selezionare Azure AD B2C.
Selezionare l'opzione Registrazioni appe quindi selezionare Nuova registrazione.
In Nome immettere un nome per l'applicazione, ad esempio my-api1. Lasciare i valori predefiniti per URI di reindirizzamento e Tipi di account supportati.
Selezionare Registrazione.
Al termine della registrazione dell'app, selezionare Panoramica.
Registrare il valore ID applicazione (client) per usarlo in un secondo momento quando si configura l'applicazione Web.

Passaggio 1.1 Definire i ruoli dell'API Web (ambiti)

In questo passaggio si configura l'URI dell'ID applicazione dell'API Web, quindi si definiscono i ruoli dell'app. I ruoli dell'app, usati dagli ambiti OAuth 2.0 e definiti in una registrazione dell'applicazione che rappresenta l'API. L'applicazione usa l'URI dell'ID applicazione con l'ambito .default . Per definire i ruoli dell'app, attenersi alla seguente procedura:

Selezionare l'API Web creata, ad esempio my-api1.
In Gestisci selezionare Esporre un'API.
Accanto a URI ID applicazione selezionare il collegamento Imposta. Sostituire il valore predefinito (GUID) con un nome univoco (ad esempio, api) e quindi selezionare Salva.
Copiare l'URI dell'ID applicazione. Lo screenshot seguente mostra come copiare l'URI dell'ID applicazione.
In Gestisci selezionare Manifesto per aprire l'editor del manifesto dell'applicazione. Nell'editor, individua l'impostazione e definisci i appRoles ruoli dell'app destinati a applications. Ogni definizione di ruolo dell'app deve avere un identificatore univoco globale (GUID) per il relativo id valore. Generare un nuovo GUID eseguendo new-guidil comando in Microsoft PowerShell o in un generatore di GUID online. La value proprietà di ogni definizione di ruolo dell'app viene visualizzata nell'ambito, l'attestazione scp . La value proprietà non può contenere spazi. L'esempio seguente illustra due ruoli dell'app, lettura e scrittura:
```
"appRoles": [
{
  "allowedMemberTypes": ["Application"],
  "displayName": "Read",
  "id": "d6a15e20-f83c-4264-8e61-5082688e14c8",
  "isEnabled": true,
  "description": "Readers have the ability to read tasks.",
  "value": "app.read"
},
{
  "allowedMemberTypes": ["Application"],
  "displayName": "Write",
  "id": "204dc4ab-51e1-439f-8c7f-31a1ebf3c7b9",
  "isEnabled": true,
  "description": "Writers have the ability to create tasks.",
  "value": "app.write"
}],
```
Nella parte superiore della pagina, seleziona Salva per salvare le modifiche del manifesto.

Passaggio 2: Registrare un'applicazione

Per consentire all'app di accedere con Azure AD B2C usando il flusso delle credenziali client, è possibile usare un'applicazione esistente o registrarne una nuova (App 1).

Se stai utilizzando un'app esistente, assicurati che l'app accessTokenAcceptedVersion sia impostata su 2:

Nel portale di Azure cercare e selezionare Azure AD B2C.
Selezionare Registrazioni app e quindi selezionare l'app esistente dall'elenco.
Nel menu a sinistra, in Gestisci, seleziona Manifesto per aprire l'editor del manifesto.
Individuare l'elemento e impostarne il accessTokenAcceptedVersion valore su 2.
Nella parte superiore della pagina, seleziona Salva per salvare le modifiche.

Per creare una nuova registrazione dell'app Web, attenersi alla seguente procedura:

Nel portale di Azure cercare e selezionare Azure AD B2C
Selezionare l'opzione Registrazioni appe quindi selezionare Nuova registrazione.
Immettere un nome per l'applicazione. Ad esempio, ClientCredentials_app.
Lasciare invariati gli altri valori e quindi selezionare Registra.
Registrare l'ID applicazione (client) da usare in un passaggio successivo.

Passaggio 2.1 Creare un segreto client

Creare un segreto client per l'applicazione registrata. L'app usa il segreto client per dimostrare la propria identità quando richiede i token.

In Gestisci, selezionare Certificati e segreti.
Selezionare Nuova chiave segreta del client.
Nella casella Descrizione immettere una descrizione per il segreto client (ad esempio, clientsecret1).
In Scadenzaselezionare una durata per la quale il segreto è valido, quindi selezionare Aggiungi.
Registrare il valore del segreto. Questo valore viene usato per la configurazione in un passaggio successivo.

Passaggio 2.2 Concedere all'app le autorizzazioni per l'API Web

Per concedere le autorizzazioni all'app (App 1), procedi nel seguente modo:

Selezionare Registrazioni app e quindi selezionare l'app creata (App 1).
In Gestisci selezionare Autorizzazioni API.
In Autorizzazioni configurate selezionare Aggiungi un'autorizzazione.
Selezionare la scheda Le mie API.
Selezionare l'API (App 2) a cui concedere l'accesso all'applicazione Web. Ad esempio, immettere my-api1.
Seleziona Autorizzazione applicazione.
In Autorizzazione espandere app e quindi selezionare gli ambiti definiti in precedenza, ad esempio app.read e app.write.
Selezionare Aggiungi autorizzazioni.
Selezionare Concedi consenso amministratore per <il nome> del tenant.
Selezionare Sì.
Selezionare Aggiorna e quindi verificare che Concesso per ... sia visualizzato in Stato per entrambi gli ambiti.

Passaggio 3: Ottenere un token di accesso

Non sono disponibili azioni specifiche per abilitare le credenziali client per i flussi utente o i criteri personalizzati. Sia i flussi utente di Azure AD B2C che i criteri personalizzati supportano il flusso delle credenziali client. Se non è già stato fatto, creare un flusso utente o un criterio personalizzato. Quindi, utilizza la tua applicazione di sviluppo API preferita per generare una richiesta di autorizzazione. Costruire una chiamata come questo esempio con le informazioni seguenti come corpo della richiesta POST:

https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy>/oauth2/v2.0/token

Sostituire <tenant-name> con il nome del tenant di Azure AD B2C. Ad esempio: contoso.b2clogin.com.
Sostituisci <policy> con il nome completo del flusso utente o con i criteri personalizzati. Si noti che tutti i tipi di flussi utente e criteri personalizzati supportano il flusso delle credenziali client. È possibile usare qualsiasi flusso utente o criterio personalizzato oppure crearne uno nuovo, ad esempio l'iscrizione o l'accesso.

Chiave	Valore
tipo_di_concessione	`client_credentials`
ID cliente	L'ID client del passaggio 2 Registrare un'applicazione.
segreto_cliente	Il valore Segreto client del passaggio 2.1 Creare un segreto client.
scopo	L'URI dell'ID applicazione del passaggio 1.1: Definire i ruoli dell'API Web (ambiti) e `.default`. Ad esempio `https://contoso.onmicrosoft.com/api/.default`, o `https://contoso.onmicrosoft.com/00001111-aaaa-2222-bbbb-3333cccc4444/.default`.

La richiesta POST effettiva è simile all'esempio seguente:

Richiesta:

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

grant_type=client_credentials
&client_id=11112222-bbbb-3333-cccc-4444dddd5555
&client_secret=FyX7Q~DuPJ...
&scope=https%3A%2F%2Fcontoso.onmicrosoft.com%2Fapi%2F.default

Risposta:

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IlBFcG5OZDlnUkNWWUc2dUs...",
    "token_type": "Bearer",
    "not_before": 1645172292,
    "expires_in": 3600,
    "expires_on": 1645175892,
    "resource": "11112222-bbbb-3333-cccc-4444dddd5555"
}

Informazioni sulle attestazioni del token di accesso restituito. Nella tabella seguente sono elencate le attestazioni correlate al flusso delle credenziali client.

Richiesta di rimborso	Descrizione	Valore
`aud`	Identifica il destinatario del token.	L'ID client dell'API.
`sub`	L'entità servizio associata all'applicazione che ha avviato la richiesta.	È l'entità servizio della `client_id` richiesta di autorizzazione.
`azp`	Parte autorizzata: l'entità a cui è stato rilasciato il token di accesso.	ID client dell'applicazione che ha avviato la richiesta. È lo stesso valore specificato nella `client_id` richiesta di autorizzazione.
`scp`	Set di ambiti esposti dall'API dell'applicazione (delimitatore di spazio).	Nel flusso delle credenziali client, la richiesta di autorizzazione richiede l'ambito `.default` , mentre il token contiene l'elenco degli ambiti esposti (e consentiti dall'amministratore dell'app) dall'API. Ad esempio: `app.read app.write`.

Passaggio 3.1 Ottenere un token di accesso con script

Usare lo script di PowerShell seguente per testare la configurazione:

$appId = "<client ID>"
$secret = "<client secret>"
$endpoint = "https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy>/oauth2/v2.0/token"
$scope = "<Your API id uri>/.default"
$body = "grant_type=client_credentials&scope=" + $scope + "&client_id=" + $appId + "&client_secret=" + $secret

$token = Invoke-RestMethod -Method Post -Uri $endpoint -Body $body

Utilizza il seguente script cURL per testare la configurazione:

curl --location --request POST 'https://<your-tenant>.b2clogin.com/<your-tenant>.onmicrosoft.com/<policy>/oauth2/v2.0/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--form 'grant_type="client_credentials"' \
--form 'client_id="<client ID>"' \
--form 'client_secret="<client secret>"' \
--form 'scope="<Your API id uri>/.default"'

Passaggio 4: Personalizzare il token

Questa funzionalità è disponibile solo per i criteri personalizzati. Per i passaggi di installazione, selezionare Criteri personalizzati nel selettore precedente.

I criteri personalizzati consentono di estendere il processo di emissione dei token. Per personalizzare il percorso utente delle credenziali client OAuth 2.0, segui le indicazioni su come configurare un percorso utente con credenziali client. Quindi, nel JwtIssuer profilo tecnico, aggiungi i ClientCredentialsUserJourneyId metadati con un riferimento al percorso utente che hai creato.

Nell'esempio seguente viene illustrato come aggiungere il ClientCredentialsUserJourneyId al profilo tecnico dell'autorità emittente del token.

<TechnicalProfile Id="JwtIssuer">
  <Metadata>
    <Item Key="ClientCredentialsUserJourneyId">ClientCredentialsJourney</Item>
  </Metadata>
</TechnicalProfile>

L'esempio seguente mostra un percorso utente con credenziali client. Sono necessari il primo e l'ultimo passaggio di orchestrazione.

<UserJourneys>
  <UserJourney Id="ClientCredentialsJourney">
    <OrchestrationSteps>
      <!-- [Required] Do the client credentials -->
      <OrchestrationStep Order="1" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="ClientCredSetupExchange" TechnicalProfileReferenceId="ClientCredentials_Setup" />
        </ClaimsExchanges>
      </OrchestrationStep>

      <!-- [Optional] Call a REST API or claims transformation -->
      <OrchestrationStep Order="2" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="TokenAugmentation" TechnicalProfileReferenceId="TokenAugmentation" />
        </ClaimsExchanges>
      </OrchestrationStep>

      <!-- [Required] Issue the access token -->
      <OrchestrationStep Order="3" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys>