Condividi tramite

Azure AD B2C: protocolli di autenticazione

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) fornisce identità come servizio per le app supportando due protocolli standard di settore: OpenID Connect e OAuth 2.0. Il servizio è conforme agli standard, ma qualsiasi due implementazioni di questi protocolli può avere piccole differenze.

Le informazioni contenute in questa guida sono utili se si scrive il codice inviando e gestendo direttamente le richieste HTTP, anziché usando una libreria open source. È consigliabile leggere questa pagina prima di approfondire i dettagli di ogni protocollo specifico. Tuttavia, se si ha già familiarità con Azure AD B2C, è possibile passare direttamente alle guide di riferimento al protocollo.

Nozioni di base

Ogni app che usa Azure AD B2C deve essere registrata nella directory B2C nel portale di Azure. Il processo di registrazione dell'app raccoglie e assegna alcuni valori all'app:

  • ID applicazione che identifica in modo univoco l'app.

  • URI di reindirizzamento o identificatore del pacchetto che può essere usato per indirizzare le risposte all'app.

  • Altri valori specifici dello scenario. Per altre informazioni, vedere come registrare l'applicazione.

Dopo aver registrato l'app, comunica con Azure AD B2C inviando richieste all'endpoint:

https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/oauth2/v2.0/authorize
https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/oauth2/v2.0/token

Se si usa un dominio personalizzato, sostituire {tenant}.b2clogin.com con il dominio personalizzato, ad esempio contoso.com, negli endpoint.

In quasi tutti i flussi OAuth e OpenID Connect, quattro parti sono coinvolte nello scambio:

Diagramma che mostra i quattro ruoli OAuth 2.0.

  • Il server di autorizzazione è l'endpoint di Azure AD B2C. Gestisce in modo sicuro qualsiasi elemento correlato alle informazioni utente e all'accesso. Gestisce inoltre le relazioni di fiducia tra le parti in un flusso. È responsabile della verifica dell'identità dell'utente, della concessione e della revoca dell'accesso alle risorse e dell'emissione di token. È noto anche come fornitore di identità.

  • Il proprietario della risorsa è in genere l'utente finale. È la parte proprietaria dei dati e ha la possibilità di consentire a terze parti di accedere a tali dati o risorse.

  • Il client OAuth corrisponde alla tua app. È identificato dall'ID dell'applicazione. In genere è l'entità con cui gli utenti finali interagiscono. Richiede anche token dal server di autorizzazione. Il proprietario della risorsa deve concedere al client l'autorizzazione per accedere alla risorsa.

  • Il server di risorse è la posizione in cui si trovano la risorsa o i dati. Considera attendibile il server di autorizzazione per autenticare e autorizzare in modo sicuro il client OAuth. Usa anche token di accesso portatore per garantire che sia possibile concedere l'accesso a una risorsa.

Politiche e flussi utente

Azure AD B2C estende i protocolli OAuth 2.0 e OpenID Connect standard introducendo i criteri. Questi consentono ad Azure AD B2C di eseguire molto di più dell'autenticazione e dell'autorizzazione semplici.

Per configurare le attività di identità più comuni, il portale di Azure AD B2C include criteri predefiniti configurabili denominati flussi utente. I flussi utente descrivono completamente le esperienze di identità degli utenti, tra cui l'iscrizione, l'accesso e la modifica del profilo. I flussi utente possono essere definiti in un'interfaccia utente amministrativa. Possono essere eseguite usando un parametro di query speciale nelle richieste di autenticazione HTTP.

I criteri e i flussi utente non sono funzionalità standard di OAuth 2.0 e OpenID Connect, quindi è necessario dedicare il tempo necessario per comprenderli. Per altre informazioni, vedere la guida di riferimento al flusso utente di Azure AD B2C.

Token

L'implementazione di Azure AD B2C di OAuth 2.0 e OpenID Connect usa ampiamente i token di connessione, inclusi i token di connessione rappresentati come token Web JSON (JWT). Un token portatore è un token di sicurezza leggero che concede al portatore l'accesso a una risorsa protetta.

Il portatore è qualsiasi parte che può presentare il token. Azure AD B2C deve prima autenticare una parte coinvolta prima di poter ricevere un token portatore. Tuttavia, se i passaggi necessari non vengono eseguiti per proteggere il token nella trasmissione e nell'archiviazione, può essere intercettato e usato da una parte non intenzionale.

Alcuni token di sicurezza hanno meccanismi predefiniti che impediscono alle parti non autorizzate di usarli, ma i token di connessione non hanno questo meccanismo. Devono essere trasportati in un canale sicuro, ad esempio una sicurezza del livello di trasporto (HTTPS).

Se un token di connessione viene trasmesso all'esterno di un canale sicuro, un utente malintenzionato può usare un attacco man-in-the-middle per acquisire il token e usarlo per ottenere l'accesso non autorizzato a una risorsa protetta. Gli stessi principi di sicurezza si applicano quando i token di connessione vengono archiviati o memorizzati nella cache per un uso successivo. Assicurarsi sempre che l'app trasmetta e archivii i token di connessione in modo sicuro.

Per considerazioni aggiuntive sulla sicurezza dei token di connessione, vedere RFC 6750 Sezione 5.

Altre informazioni sui diversi tipi di token usati in Azure AD B2C sono disponibili nel riferimento al token di Azure AD B2C.

Protocolli

Quando si è pronti per esaminare alcune richieste di esempio, è possibile iniziare con una delle esercitazioni seguenti. Ognuno corrisponde a uno scenario di autenticazione specifico. Se hai bisogno di assistenza per determinare quale flusso è giusto per te, dai un'occhiata ai tipi di app che puoi creare utilizzando Azure AD B2C.