AD B2C Azure: protocolli di autenticazione
Azure Active Directory B2C (Azure AD B2C) fornisce l'identità come servizio per le app grazie al supporto di due protocolli standard del settore, OpenID Connect e OAuth 2.0. Anche se il servizio è conforme agli standard, possono esistere sottili differenze tra le implementazioni di questi protocolli.
Le informazioni in questa guida sono utili se si scrive codice inviando e gestendo direttamente le richieste HTTP, anziché usando una raccolta open source. Si consiglia di leggere questa pagina prima di approfondire i dettagli dei protocolli specifici. Se si ha già familiarità con Azure AD B2C, è possibile passare direttamente alle guide di riferimento dei protocolli.
Nozioni di base
Ogni app che usa Azure AD B2C deve essere registrata nella directory B2C del portale di Azure. Il processo di registrazione app raccoglie e assegna all'app alcuni valori:
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 maggiori 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 di OAuth e OpenID Connect sono coinvolte nello scambio quattro parti:
Il server di autorizzazione è l'endpoint di Azure AD B2C. Gestisce in modo sicuro tutto ciò che ha a che fare con l'accesso e le informazioni sull'utente, nonché le relazioni di trust 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 provider di identità.
Il proprietario della risorsa è in genere l'utente finale. È l'entità proprietaria dei dati e ha la possibilità di consentire a terze parti di accedere a tali dati o risorse.
Il client OAuth è l'app ed è identificato dal relativo ID applicazione. Si tratta in genere dell’entità con cui interagiscono gli utenti finali. Richiede i token dal server di autorizzazione. Il proprietario della risorsa deve concedere al client l'autorizzazione ad 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 il client OAuth in modo sicuro. Usa i token di accesso di connessione per fare in modo che sia possibile concedere l'accesso a una risorsa.
Criteri e flussi utente
Azure AD B2C estende i protocolli OAuth 2.0 e OpenID Connect standard con l'introduzione dei criteri. Questi consentono ad Azure AD B2C di andare oltre la semplice autenticazione e autorizzazione.
Per poter configurare le attività di gestione delle identità più comuni, il portale di Azure AD B2C include criteri predefiniti configurabili chiamati 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 ed eseguiti 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 dei flussi utente di Azure AD B2C.
Tokens
L'implementazione di OAuth 2.0 e OpenID Connect in Azure AD B2C fa un uso intensivo dei token di connessione, inclusi quelli rappresentati come token Web JSON (JWT). Un token di connessione è un token di sicurezza leggero che consente al "portatore" di accedere a una risorsa protetta.
Per "portatore" si intende qualsiasi parte che possa presentare il token. Per poter ricevere un token di connessione, Azure AD B2C deve prima autenticare una parte. 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 usando un canale protetto, ad esempio un protocollo Transport Layer Security (HTTPS).
Se un token di connessione viene trasmesso al di fuori di un canale protetto, un utente malintenzionato potrebbe usare un attacco man-in-the-middle per acquisire il token e usarlo per 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 futuro. Assicurarsi sempre che l'app trasmetta e archivi 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 nelle informazioni di riferimento sui token di Azure AD B2C.
Protocolli
Per esaminare alcuni esempi di richieste, è possibile iniziare con una delle esercitazioni indicate di seguito. Ognuna corrisponde a uno scenario di autenticazione specifico. Per informazioni su come determinare il flusso più adatto, vedere i tipi di app che è possibile compilare usando Azure AD B2C.