Condividi tramite

Tipi di applicazioni per Microsoft Identity Platform

  • Articolo

Microsoft Identity Platform supporta l'autenticazione per una vasta gamma di architetture di app moderne, tutte basate sui protocolli standard del settore OAuth 2.0 o OpenID Connect. Questo articolo descrive i tipi di app che è possibile compilare usando Microsoft Identity Platform, indipendentemente dal linguaggio o dalla piattaforma preferiti. Le informazioni consentono di comprendere gli scenari generali prima di iniziare a usare il codice negli scenari applicativi.

Nozioni di base

È necessario registrare ogni app che usa Microsoft Identity Platform nell'interfaccia di amministrazione di Microsoft Entra Registrazioni app. 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 app, l'app comunica con 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

I tipi di app supportati da Microsoft Identity Platform sono:

  • App a pagina singola
  • Applicazione Web
  • API Web
  • App per dispositivi mobili e native
  • Servizio, daemon, script

App a pagina singola

Molte app moderne dispongono di un front-end a pagina singola scritto principalmente in JavaScript, spesso usando un framework come Angular, React o Vue. Microsoft Identity Platform supporta queste app utilizzando il protocollo OpenID Connect per l'autenticazione e uno dei due tipi di concessione di autorizzazione definiti da OAuth 2.0. Usare il flusso del codice di autorizzazione con Proof Key for Code Exchange (PKCE) durante lo sviluppo di applicazioni a pagina singola. Questo flusso è più sicuro del flusso implicito, che non è più consigliato. Per altre informazioni, vedere preferire il flusso del codice di autorizzazione.

Il diagramma di flusso illustra il flusso di concessione del codice di autorizzazione OAuth 2.0 (omettendo i dettagli relativi a PKCE), in cui l'applicazione riceve un codice dall'endpoint di Microsoft Identity Platform authorize e lo riscatta per un token di accesso e un token di aggiornamento usando richieste Web intersito. Per le app a pagina singola, il token di accesso è valido per 1 ora e, una volta scaduto, è necessario richiederne un altro usando il token di aggiornamento. Oltre al token di accesso, di solito viene richiesto anche un id_token che rappresenta l'utente registrato nell'applicazione client attraverso lo stesso flusso e/o una richiesta OpenID Connect separata (non illustrata qui).

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

Per vederlo in azione, fare riferimento a Avvio rapido: far accedere gli utenti in un'app a pagina singola (SPA) e chiamare l'API Microsoft Graph tramite JavaScript.

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
abC1dEf2Ghi3jkL4mNo5Pqr6stU7vWx8Yza9...

// Partial content of a decoded ID token
{
    "name": "Casey Jensen",
    "email": "casey.jensen@onmicrosoft.com",
    "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"
    ...
}

Ulteriori dettagli sui diversi tipi di token usati in Microsoft Identity Platform sono disponibili nelle informazioni di riferimento sul token di accesso e su id_token.

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 tramite una chiave di firma pubblica ottenuta da Microsoft Identity Platform. Viene impostato un cookie di sessione che può essere usato per identificare l'utente nelle richieste di pagina successive.

Per altre informazioni, creare un'app Web ASP.NET Core per accedere agli utenti e chiamare l'API Microsoft Graph

Oltre al semplice accesso, un'app server Web potrebbe necessitare di accedere a un altro servizio Web, come 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 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 abC1dEf2Ghi3jkL4mNo5Pqr6stU7vWx8Yza9...
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 in Microsoft Identity Platform sono disponibili nelle informazioni di riferimento sul token di accesso e sul token ID.

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. Microsoft Identity Platform chiede l'autorizzazione all'utente 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 con i token di accesso OAuth2, vedi gli esempi di codice dell'API Web nell'esercitazione su un’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 sfruttare il flusso On-Behalf-Of (BO), 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 informazioni, vedi Microsoft Identity Platform e flusso On-Behalf-Of di 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 da Microsoft Identity Platform quando l'utente effettua l'accesso. 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 webview di sistema predefinita, controllare le informazioni sulla funzionalità "Conferma accesso" e il codice di errore AADSTS50199 nei codici di errore di autenticazione e autorizzazione di Microsoft Entra.

Server, daemon e script

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, vedi Applicazione console daemon .NET 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.

Vedi anche