Tipi di applicazioni per Microsoft Identity Platform

Il Microsoft Identity Platform supporta l'autenticazione per varie architetture di app moderne, tutte basate su protocolli standard del settore OAuth 2.0 o OpenID Connect. Questo articolo descrive brevemente i tipi di app che è possibile compilare usando Microsoft Identity Platform, indipendentemente dal linguaggio o dalla piattaforma preferita. Le informazioni sono progettate per facilitare la comprensione degli scenari di alto livello prima di iniziare a usare il codice negli scenari dell'applicazione.

Nozioni di base

È necessario registrare ogni app che usa il Microsoft Identity Platform nel Registrazioni app portale di Azure. Il processo di registrazione delle app raccoglie e assegna all'app questi valori:

  • Un ID applicazione (client) che identifica l'app in modo univoco
  • Un URI di reindirizzamento che può essere usato per reindirizzare le risposte all'app
  • Altri valori specifici dello scenario, ad esempio i tipi di account supportati

Per i dettagli, vedere come registrare un'app.

Dopo la registrazione dell'app, l'app comunica con il Microsoft Identity Platform inviando richieste all'endpoint. Microsoft offre framework e librerie open source che gestiscono i dettagli di queste richieste. È sempre possibile implementare personalmente la logica di autenticazione creando richieste a questi endpoint:

https://login.microsoftonline.com/common/oauth2/v2.0/authorize
https://login.microsoftonline.com/common/oauth2/v2.0/token

App a singola pagina (JavaScript)

Molte app moderne hanno un front-end dell'app a singola pagina scritto principalmente in JavaScript, spesso con un framework come Angular, React o Vue. Il Microsoft Identity Platform supporta queste app usando il protocollo OpenID Connect per l'autenticazione e uno dei due tipi di concessioni di autorizzazione definite da OAuth 2.0. I tipi di concessione supportati sono il flusso di concessione implicita OAuth 2.0 o il codice di autorizzazione OAuth 2.0 più recente + flusso PKCE (vedere di seguito).

Il diagramma di flusso seguente illustra la concessione del codice di autorizzazione OAuth 2.0 (con i dettagli relativi a PKCE omesso), in cui l'app riceve un codice dall'endpoint Microsoft Identity Platform authorize e lo riscatta per un token di accesso e un token di aggiornamento usando richieste Web tra siti. Il token di accesso scade ogni 24 ore e l'app deve richiedere un altro codice usando il token di aggiornamento. Oltre al token di accesso, viene in genere richiesto un id_token oggetto che rappresenta l'utente connesso all'applicazione client tramite lo stesso flusso e/o una richiesta OpenID Connect separata (non illustrata qui).

Diagramma che mostra il flusso del codice di autorizzazione OAuth 2 tra un'app a pagina singola e l'endpoint del servizio token di sicurezza.

Per osservare il funzionamento di questo scenario, consultare l’Esercitazione: Eseguire l'accesso degli utenti e chiamare l'API Microsoft Graph da un'applicazione a pagina singola JavaScript usando il flusso del codice di autenticazione.

Flusso del codice di autorizzazione e flusso implicito

Per la maggior parte dei casi nella cronologia di OAuth 2.0, il flusso implicito era il metodo consigliato per creare app a pagina singola. Con la rimozione dei cookie di terze parti e una maggiore attenzione rivolta ai problemi di sicurezza relativi al flusso implicito, il flusso del codice di autorizzazione per le app a pagina singola dovrebbe ora essere implementato per garantire la compatibilità dell'app in Safari e altri browser consapevoli della privacy. L'uso continuo del flusso implicito non è consigliato.

App Web

Per le app Web (.NET, PHP, Java, Ruby, Python, Node) accessibili tramite un browser, è possibile eseguire l'accesso utente tramite OpenID Connect. In OpenID Connect, l'app Web riceve un token ID. Un token ID è un token di sicurezza che verifica 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"
    ...
}

Altri dettagli sui diversi tipi di token usati nella Microsoft Identity Platform sono disponibili nel riferimento al token di accesso e id_token riferimento.

Nelle app del server Web, il flusso di autenticazione dell'accesso esegue i passaggi generali seguenti:

Mostra il flusso di autenticazione dell'app Web

È possibile verificare l'identità dell'utente convalidando il token ID con una chiave di firma pubblica ricevuta dal Microsoft Identity Platform. Viene anche impostato un cookie di sessione che può essere usato per identificare l'utente nelle richieste di pagina successive.

Per visualizzare questo scenario in azione, provare gli esempi di codice in Accedi utenti da un'app Web.

Oltre a un accesso semplice, un'app server Web potrebbe dover accedere a un altro servizio Web, ad esempio un'API REST (Representational State Transfer). In questo caso, l'app per server Web agisce in un flusso di OpenID Connect e OAuth 2.0 combinato, tramite il flusso del codice di autorizzazione OAuth 2.0. Per altre informazioni su questo scenario, vedere l'esempio di codice.

API Web

È possibile usare il Microsoft Identity Platform per proteggere i servizi Web, ad esempio l'API Web RESTful dell'app. Le API Web possono essere implementate in numerose piattaforme e linguaggi. Possono inoltre essere implementate usando trigger HTTP in Funzioni di Azure. Al posto dei token ID e dei cookie di sessione, un'API Web usa un token di accesso OAuth 2.0 per proteggere i dati e autenticare le richieste in ingresso. Il chiamante di un'API Web aggiunge un token di accesso nell'intestazione dell'autorizzazione di una richiesta HTTP come illustrato di seguito:

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

L'API Web usa il token di accesso per verificare l'identità del chiamante dell'API ed estrarre informazioni su quest'ultimo dalle attestazioni codificate nel token di accesso. Altri dettagli sui diversi tipi di token usati nella Microsoft Identity Platform sono disponibili nel riferimento al token di accesso e id_token riferimento.

Un'API Web può consentire agli utenti di fornire il consenso o rifiutare esplicitamente specifici dati o funzionalità esponendo le autorizzazioni, note anche come ambiti. Per far sì che un'app chiamante acquisisca l'autorizzazione ad accedere a un ambito, l'utente deve fornire il consenso all'ambito durante un flusso. Il Microsoft Identity Platform chiede all'utente l'autorizzazione e quindi registra le autorizzazioni in tutti i token di accesso ricevuti dall'API Web. L'API Web convalida i token di accesso ricevuti ad ogni chiamata ed esegue i controlli di autorizzazione appropriati.

Un'API Web può ricevere token di accesso da tutti i tipi di app, tra cui app per server Web, desktop, per dispositivi mobili, a singola pagina, daemon sul lato server e anche altre API Web. Il flusso generale per un'API Web è simile al seguente:

Mostra il flusso di autenticazione dell'API Web

Per informazioni su come proteggere un'API Web usando i token di accesso OAuth2, vedere gli esempi di codice api Web nello scenario dell'API Web protetta.

In molti casi, le API Web devono anche effettuare richieste in uscita ad altre API Web downstream protette da Microsoft Identity Platform. A questo scopo, le API Web possono ricorrere al flusso On-Behalf-Of, che consente all'API Web di scambiare un token di accesso in ingresso con un altro token di accesso da usare in richieste in uscita. Per altre info, vedi il flusso on-behalf-of di Microsoft Identity Platform e OAuth 2.0.

App per dispositivi mobili e native

Le app installate in un dispositivo, ad esempio app desktop e per dispositivi mobili, devono spesso accedere a servizi back-end o ad API Web che archiviano i dati ed eseguono funzioni per conto dell'utente. Queste app possono aggiungere accesso e autorizzazioni ai servizi back-end tramite il flusso del codice di autorizzazione OAuth 2.0.

In questo flusso, l'app riceve un codice di autorizzazione dal Microsoft Identity Platform quando l'utente accede. Questo codice rappresenta l'autorizzazione dell'app a chiamare servizi back-end per conto dell'utente che ha eseguito l'accesso. L'app può scambiare il codice di autorizzazione in background con un token di accesso OAuth 2.0 e un token di aggiornamento. L'app può usare il token di accesso per l'autenticazione all'API Web nelle richieste HTTP e il token di aggiornamento per ottenere nuovi token di accesso quando i precedenti scadono.

Mostra il flusso di autenticazione dell'app nativa

Nota

Se l'applicazione usa la visualizzazione Web di sistema predefinita, controllare le informazioni sulla funzionalità "Conferma accesso personale" e sul codice di errore AADSTS50199 nei codici di errore di autenticazione e autorizzazione di Azure AD.

App daemon e lato server

Anche le app che contengono processi a esecuzione prolungata o che non prevedono l'interazione con l'utente necessitano di un modo per accedere alle risorse protette, ad esempio le API Web. Queste app possono autenticarsi e ottenere i token usando l'identità dell'app, anziché un'identità delegata dell'utente, con il flusso delle credenziali client di OAuth 2.0. È possibile dimostrare l'identità dell'app usando un certificato o un segreto client. Per altre informazioni, vedere Applicazione console daemon .NET Core con Microsoft Identity Platform.

In questo flusso, l'app interagisce direttamente con l'endpoint /token per ottenere l’accesso:

Mostra il flusso di autenticazione dell'app daemon

Per compilare un'app daemon, vedere la documentazione sulle credenziali client oppure provare un'app .NET di esempio.

Passaggi successivi

Una volta acquisita familiarità con i tipi di applicazioni supportati da Microsoft Identity Platform, è possibile consultare altre informazioni su OAuth 2.0 e OpenID Connect per ottenere dettagli sui componenti dei protocolli usati dai diversi scenari.