Condividi tramite

Tipi di applicazione che possono essere usati in 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.

Azure Active Directory B2C (Azure AD B2C) supporta l'autenticazione per varie architetture di applicazioni moderne. Tutti si basano sui protocolli standard del settore OAuth 2.0 o OpenID Connect. Questo articolo descrive i tipi di applicazioni che è possibile compilare, indipendentemente dal linguaggio o dalla piattaforma preferita. Consente anche di comprendere gli scenari generali prima di iniziare a creare applicazioni.

Ogni applicazione che usa Azure AD B2C deve essere registrata nel tenant di Azure AD B2C usando il portale di Azure. Il processo di registrazione dell'applicazione raccoglie e assegna valori, ad esempio:

  • ID applicazione che identifica in modo univoco l'applicazione.
  • URL di risposta che può essere usato per indirizzare le risposte verso la tua applicazione.

Ogni richiesta inviata ad Azure AD B2C specifica un flusso utente (un criterio predefinito) o un criterio personalizzato che controlla il comportamento di Azure AD B2C. Entrambi i tipi di criteri consentono di creare un set di esperienze utente altamente personalizzabile.

L'interazione di ogni applicazione segue un modello generale simile:

  1. L'applicazione indirizza l'utente all'endpoint 2.0 per eseguire un criterio.
  2. L'utente completa la politica in base alla definizione della politica.
  3. L'applicazione riceve un token di sicurezza dall'endpoint 2.0.
  4. L'applicazione usa il token di sicurezza per accedere a informazioni protette o a una risorsa protetta.
  5. Il server di risorse convalida il token di sicurezza per verificare che sia possibile concedere l'accesso.
  6. L'applicazione aggiorna periodicamente il token di sicurezza.

Questi passaggi possono variare leggermente in base al tipo di applicazione che si sta creando.

Applicazioni Web

Per le applicazioni Web (tra cui .NET, PHP, Java, Ruby, Python e Node.js) ospitate in un server Web e accessibili tramite un browser, Azure AD B2C supporta OpenID Connect per tutte le esperienze utente. Nell'implementazione di Azure AD B2C di OpenID Connect, l'applicazione Web avvia le esperienze utente inviando richieste di autenticazione all'ID Microsoft Entra. Il risultato della richiesta è un oggetto id_token. Questo token di sicurezza rappresenta l'identità dell'utente. Fornisce inoltre informazioni sull'utente sotto forma di attestazioni:

// Partial raw id_token
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtyaU1QZG1Cd...

// Partial content of a decoded id_token
{
    "name": "John Smith",
    "email": "john.smith@gmail.com",
    "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"
    ...
}

Altre informazioni sui tipi di token e attestazioni disponibili per un'applicazione sono disponibili nelle informazioni di riferimento sui token di Azure AD B2C.

In un'applicazione Web ogni esecuzione di un criterio esegue questi passaggi generali:

  1. L'utente passa all'applicazione Web.
  2. L'applicazione Web reindirizza l'utente ad Azure AD B2C che indica i criteri da eseguire.
  3. L'utente completa la politica.
  4. Azure AD B2C restituisce un oggetto id_token al browser.
  5. L'oggetto id_token viene inviato all'URI di reindirizzamento.
  6. Viene id_token convalidato e viene impostato un cookie di sessione.
  7. All'utente viene restituita una pagina sicura.

La convalida dell'oggetto id_token utilizzando una chiave di firma pubblica ricevuta dall'ID Microsoft Entra è sufficiente per verificare l'identità dell'utente. Questo processo imposta anche un cookie di sessione che può essere usato per identificare l'utente nelle richieste di pagina successive.

Per visualizzare questo scenario in azione, provare uno degli esempi di codice di accesso dell'applicazione Web nella sezione Introduzione.

Oltre a facilitare l'accesso semplice, un'applicazione Web potrebbe anche dover accedere a un servizio Web back-end. In questo caso, l'applicazione Web può eseguire un flusso OpenID Connect leggermente diverso e acquisire i token usando i codici di autorizzazione e i token di aggiornamento. Questo scenario è illustrato nella sezione API Web seguente.

Applicazioni a pagina singola

Molte applicazioni Web moderne vengono compilate come applicazioni a pagina singola sul lato client ("SPA"). Gli sviluppatori li scrivono usando JavaScript o un framework SPA, ad esempio Angular, Vue o React. Queste applicazioni vengono eseguite in un Web browser e presentano caratteristiche di autenticazione diverse rispetto alle applicazioni Web sul lato server tradizionali.

Azure AD B2C offre due opzioni per consentire alle applicazioni a pagina singola di accedere agli utenti e ottenere token per accedere ai servizi back-end o alle API Web:

Flusso del codice di autorizzazione (con PKCE)

Il flusso del codice di autorizzazione OAuth 2.0 (con PKCE) consente all'applicazione di scambiare un codice di autorizzazione per i token ID per rappresentare i token utente autenticati e i token di accesso necessari per chiamare le API protette. Inoltre, restituisce i token di aggiornamento che forniscono l'accesso a lungo termine alle risorse per conto degli utenti senza richiedere l'interazione con tali utenti.

Questo approccio è stato consigliato . La presenza di token di aggiornamento a durata limitata consente all'applicazione di adattarsi alle limitazioni moderne della privacy dei cookie del browser, ad esempio Safari ITP.

Per sfruttare questo flusso, l'applicazione può utilizzare una libreria di autenticazione che lo supporta, ad esempio MSAL.js 2.x.

Applicazioni a pagina singola - Autenticazione

Flusso di concessione implicita

Alcune librerie, ad esempio MSAL.js 1.x, supportano solo il flusso di concessione implicita oppure l'applicazione viene implementata per l'uso del flusso implicito. In questi casi, Azure AD B2C supporta il flusso implicito OAuth 2.0. Il flusso di concessione implicita consente all'applicazione di ottenere i token ID e Access . A differenza del flusso del codice di autorizzazione, il flusso di concessione implicita non restituisce un token di aggiornamento.

Questo flusso di autenticazione non include scenari di applicazione che usano framework JavaScript multipiattaforma, ad esempio Electron e React-Native. Questi scenari richiedono ulteriori funzionalità per l'interazione con le piattaforme native.

Avvertimento

Microsoft consiglia di non usare il flusso di concessione implicita. Il modo consigliato per supportare le applicazioni a livello di servizio è il flusso del codice di autorizzazione OAuth 2.0 (con PKCE). Alcune configurazioni di questo flusso richiedono un livello di attendibilità molto elevato nell'applicazione e comportano rischi che non sono presenti in altri flussi. Si consiglia di usare questo flusso solo quando non è possibile usare altri flussi più sicuri. Per altre informazioni, vedere i problemi di sicurezza relativi al flusso di concessione implicita.

API per il Web

È possibile usare Azure AD B2C per proteggere i servizi Web, ad esempio l'API Web RESTful dell'applicazione. Le API Web possono usare OAuth 2.0 per proteggere i dati autenticando le richieste HTTP in ingresso usando token. Il chiamante di un'API Web aggiunge un token nell'intestazione di autorizzazione di una richiesta HTTP:

GET /api/items HTTP/1.1
Host: www.mywebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6...
Accept: application/json
...

L'API Web può quindi usare il token per verificare l'identità del chiamante API e per estrarre informazioni sul chiamante dalle attestazioni codificate nel token. Altre informazioni sui tipi di token e attestazioni disponibili per un'app sono disponibili nelle informazioni di riferimento sui token di Azure AD B2C.

Un'API Web può ricevere token da molti tipi di client, tra cui applicazioni Web, applicazioni desktop e per dispositivi mobili, applicazioni a pagina singola, daemon lato server e altre API Web. Ecco un esempio del flusso completo per un'applicazione Web che chiama un'API Web:

  1. L'applicazione Web esegue una politica e l'utente completa l'esperienza dell'utente.
  2. Azure AD B2C restituisce un token (OpenID Connect) id_token e un codice di autorizzazione al browser.
  3. Il browser invia il codice di autorizzazione id_token all'URI di reindirizzamento.
  4. Il server Web convalida id_token e imposta un cookie di sessione.
  5. Il server Web chiede ad Azure AD B2C di specificare un oggetto access_token fornendo il codice di autorizzazione, l'ID client dell'applicazione e le credenziali client.
  6. access_token e refresh_token vengono restituiti al server Web.
  7. L'API Web viene chiamata con access_token nell'intestazione di autorizzazione.
  8. L'API Web convalida il token.
  9. I dati sicuri vengono restituiti all'applicazione Web.

Per altre informazioni sui codici di autorizzazione, i token di aggiornamento e i passaggi per ottenere i token, vedere il protocollo OAuth 2.0.

Per informazioni su come proteggere un'API Web usando Azure AD B2C, vedere le esercitazioni sulle API Web nella sezione Introduzione.

Applicazioni per dispositivi mobili e native

Le applicazioni installate nei dispositivi, ad esempio applicazioni per dispositivi mobili e desktop, spesso devono accedere ai servizi back-end o alle API Web per conto degli utenti. È possibile aggiungere esperienze di gestione delle identità personalizzate alle applicazioni native e chiamare in modo sicuro i servizi back-end usando Azure AD B2C e il flusso del codice di autorizzazione OAuth 2.0.

In questo flusso, l'applicazione esegue i criteri e riceve un authorization_code da Microsoft Entra ID dopo che l'utente completa i criteri. Rappresenta authorization_code l'autorizzazione dell'applicazione per chiamare i servizi back-end per conto dell'utente attualmente connesso. L'applicazione può quindi scambiare authorization_code in secondo piano per un access_token e un refresh_token. L'applicazione può usare access_token per autenticarsi a un'API Web back-end nelle richieste HTTP. Può anche utilizzare il refresh_token per ottenere un nuovo access_token quando uno precedente scade.

Demoni/applicazioni lato server

Le applicazioni che contengono processi a esecuzione prolungata o che operano senza la presenza di un utente necessitano anche di un modo per accedere a risorse protette, ad esempio le API Web. Queste applicazioni possono autenticare e ottenere token usando le identità (anziché l'identità delegata di un utente) e usando il flusso di credenziali client OAuth 2.0. Il flusso delle credenziali client non è lo stesso di on-behalf-flow e on-behalf-flow non deve essere usato per l'autenticazione da server a server.

Per Azure AD B2C, il flusso delle credenziali client OAuth 2.0 è attualmente disponibile in anteprima pubblica. Tuttavia, è possibile configurare il flusso di credenziali client usando l'ID Microsoft Entra e l'endpoint di Microsoft Identity Platform /token (https://login.microsoftonline.com/your-tenant-name.onmicrosoft.com/oauth2/v2.0/token) per un'applicazione Microsoft Graph o una propria applicazione. Per altre informazioni, consultare l'articolo di riferimento sui token di Microsoft Entra.

Tipi di applicazioni non supportati

Catene di API Web (flusso per conto di)

Molte architetture includono un'API Web che deve chiamare un'altra API Web downstream, in cui entrambe sono protette da Azure AD B2C. Questo scenario è comune nei client nativi che dispongono di un back-end api Web e chiama un servizio online Microsoft, ad esempio l'API Microsoft Graph.

Questo scenario di API Web concatenato può essere supportato usando la concessione di credenziali di connessione JWT OAuth 2.0, nota anche come flusso on-behalf-of. Tuttavia, il flusso "delegato da" non è, al momento, implementato in Azure AD B2C.

Passaggi successivi

Scopri di più sui criteri predefiniti forniti dai flussi utente in Azure Active Directory B2C.