Tipi di applicazione che possono essere usati in Active Directory B2C

  • Articolo

Azure Active Directory B2C (Azure AD B2C) supporta l'autenticazione per varie architetture di applicazioni moderne. Tutte le architetture sono basate sui protocolli standard OAuth 2.0 o OpenID Connect. Questo articolo descrive i tipi di applicazioni che è possibile compilare, indipendentemente dal linguaggio o dalla piattaforma preferita. Illustra anche gli scenari generali per iniziare a compilare applicazioni.

Ogni app che usa Azure AD B2C deve essere registrata in un tenant di Azure AD B2C tramite il portale di Azure. Il processo di registrazione dell’applicazione raccoglie e assegna alcuni valori, tra cui:

  • Un ID applicazione che identifica l'applicazione in modo univoco.
  • Un URL di risposta che può essere usato per indirizzare le risposte all'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.

Ogni interazione di un'applicazione segue un modello generale simile al seguente:

  1. L'applicazione indirizza l'utente all'endpoint 2.0 per l'esecuzione dei criteri.
  2. L'utente completa i criteri in base alla relativa definizione.
  3. L'applicazione riceve un token di sicurezza dall’endpoint v2.0.
  4. L'applicazione usa il token di sicurezza per accedere a informazioni protette o a una risorsa protetta.
  5. Il server delle 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 presentare lievi differenze a seconda del tipo di applicazione che si sta compilando.

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 eseguendo richieste di autenticazione a Microsoft Entra ID. Il risultato della richiesta è un id_token. Questo token di sicurezza rappresenta l'identità dell'utente e fornisce 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": "d9674823-dffc-4e3f-a6eb-62fe4bd48a58"
    ...
}

Per altre informazioni sui tipi di token e attestazioni disponibili per un'applicazione, vedere Azure AD B2C: informazioni di riferimento sui token.

Nelle applicazioni Web, ogni esecuzione di criteri include i passaggi generali seguenti:

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

La convalida dell'oggetto id_token usando una chiave di firma pubblica ricevuta da Microsoft Entra ID è 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 osservare il funzionamento di questo scenario, provare uno degli esempi di codice di accesso per applicazioni 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ò seguire un flusso di OpenID Connect leggermente diverso e acquisire i token usando codici di autorizzazione e token di aggiornamento. Questo scenario è illustrato di seguito nella sezione API Web.

Applicazioni a pagina singola

Molte applicazioni Web moderne vengono compilate come applicazioni a pagina singola sul lato client. 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 hanno caratteristiche di autenticazione diverse rispetto alle applicazioni Web lato server tradizionali.

Azure AD B2C offre due opzioni che consentono alle applicazioni a pagina singola di concedere l'accesso agli utenti e ottenere i token per l'accesso a servizi back-end o API Web:

Flusso di codice di autorizzazione (con PKCE)

Il flusso di 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 api protette. Restituisce inoltre token di aggiornamento che consentono l'accesso a lungo termine alle risorse per conto degli utenti senza richiedere l'interazione con tali utenti.

È consigliabile questo approccio. La presenza di token di aggiornamento a durata limitata consente all'applicazione di adattarsi alle limitazioni della privacy dei cookie dei browser moderni, ad esempio Safari ITP.

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

Single-page applications-auth

Flusso di concessione implicita

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

Non è consigliabile questo approccio.

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

API 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 propri dati, autenticando le richieste HTTP in ingresso con token. Il chiamante di un'API Web aggiunge un token all'intestazione dell'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 dell'API ed estrarre informazioni su quest'ultimo dalle attestazioni codificate nel token. Per altre informazioni sui tipi di token e attestazioni disponibili per un'app, vedere Azure AD B2C: informazioni di riferimento sui token.

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

  1. L'applicazione Web esegue criteri e l'utente completa l'esperienza utente.
  2. Azure AD B2C restituisce un oggetto id_token (OpenID Connect) e un codice di autorizzazione al browser.
  3. Il browser inserisce id_token e il codice di autenticazione nell'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 un oggetto access_token fornendogli il codice di autenticazione, l'ID client applicazione e le credenziali client.
  6. Vengono restituiti access_token e refresh_token al server Web.
  7. Viene chiamata l'API Web con access_token in un'intestazione dell'autorizzazione.
  8. L'API Web convalida il token.
  9. I dati sicuri vengono restituiti all'applicazione Web.

Per altre informazioni su codici di autorizzazione, token di aggiornamento e procedure di recupero dei token, vedere l'articolo relativo al protocollo OAuth 2.0.

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

Applicazioni per dispositivi mobili e native

Le applicazioni installate nei dispositivi, ad esempio le applicazioni desktop e per dispositivi mobili, devono spesso accedere a servizi back-end o ad API Web per conto degli utenti. È possibile aggiungere esperienze personalizzate di gestione delle identità alle applicazioni native ed eseguire chiamate sicure ai 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 ID da Microsoft Entra dopo che l'utente completa i criteri. L'oggetto authorization_code rappresenta l'autorizzazione dell'applicazione a chiamare servizi back-end per conto dell'utente che ha eseguito l'accesso. L'applicazione può quindi scambiare l'oggetto authorization_code in background con un access_token e un refresh_token. L'applicazione può usare l'oggetto access_token per eseguire l'autenticazione a un'API Web back-end nelle richieste HTTP. Può anche usare refresh_token per ottenere un nuovo access_token alla scadenza di quello precedente.

Applicazioni sul lato server o daemon

Anche le applicazioni che contengono processi a esecuzione prolungata o che funzionano senza la presenza di un utente necessitano di un modo per accedere alle risorse protette, ad esempio le API Web. Queste applicazioni possono autenticare e ottenere token usando le proprie 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 del flusso per conto e del flusso per conto non deve essere usato per l'autenticazione da server a server.

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

Tipi di applicazioni non supportati

Catene di API Web (flusso On-Behalf-Of)

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 nativi che dispongono di un back-end api Web e chiama un servizio online Microsoft, ad esempio microsoft API Graph.

Questo scenario di API Web concatenata può essere supportato usando la concessione delle credenziali di connessione JWT di OAuth 2.0, nota anche come flusso On-Behalf-Of. Tuttavia, il flusso per conto non è attualmente implementato in Azure AD B2C.

Passaggi successivi

Altre informazioni sui criteri predefiniti forniti dai flussi utente in Azure Active Directory B2C.