Tipi di applicazioni per Microsoft Identity Platform

Microsoft Identity Platform supporta l'autenticazione per varie architetture di app moderne, tutte basate su protocolli standard del settore OAuth 2.0 o OpenID Connessione. 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 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 dell'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 hanno un front-end di app a pagina singola scritto principalmente in JavaScript, spesso con un framework come Angular, React o Vue. Microsoft Identity Platform supporta queste app usando il protocollo OpenID Connessione 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 illustra il flusso di concessione del codice di autorizzazione OAuth 2.0 (con i dettagli relativi a PKCE omesso), in cui l'app 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 applicazioni a pagina singola, il token di accesso è valido per 1 ora e, una volta scaduto, deve richiedere un altro codice usando il token di aggiornamento. Oltre al token di accesso, un oggetto id_token che rappresenta l'utente connesso all'applicazione client viene in genere richiesto anche tramite lo stesso flusso e/o una richiesta OpenID separata Connessione (non illustrata qui).

Per visualizzare questa funzionalità in azione, fare riferimento alla guida introduttiva: Accedere agli utenti in un'app a pagina singola e chiamare l'API Microsoft Graph usando JavaScript.

Flusso del codice di autorizzazione e flusso implicito

Il flusso del codice di autorizzazione OAuth 2.0 è ora il modo consigliato per creare contratti a pagina singola per garantire la compatibilità dell'app in Safari e altri browser consapevoli della privacy.The OAuth 2.0 authorization code flow is now the recommended way to build SPAs to ensure compatibility of your app in Safari and other privacy-conscious browser. Dopo la rimozione di cookie di terze parti e maggiore attenzione, 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
abC1dEf2Ghi3jkL4mNo5Pqr6stU7vWx8Yza9...

// Partial content of a decoded ID token
{
    "name": "Casey Jensen",
    "email": "casey.jensen@onmicrosoft.com",
    "oid": "ab12cd34-effe-5678-9012-abcdef012345"
    ...
}

Altri dettagli sui diversi tipi di token usati in 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:

È possibile verificare l'identità dell'utente convalidando il token ID con una chiave di firma pubblica ricevuta da Microsoft Identity Platform. Viene anche 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 che consente di accedere agli utenti nella serie di esercitazioni in più parti seguente

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 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 nel riferimento al token di accesso e nel riferimento al 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 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:

Per informazioni su come proteggere un'API Web usando i token di accesso OAuth2, vedere gli esempi di codice dell'API Web nell'esercitazione sull'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 tale scopo, le API Web possono sfruttare il flusso OBO (On-Behalf-Of), che consente all'API Web di scambiare un token di accesso in ingresso per un altro token di accesso da usare nelle richieste in uscita. Per altre info, vedi 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 da Microsoft Identity Platform quando l'utente esegue 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.

Nota

Se l'applicazione usa la visualizzazione Web di sistema predefinita, controllare le informazioni sulla funzionalità "Conferma accesso personale" e il codice AADSTS50199 di errore 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, vedere Applicazione console daemon .NET con Microsoft Identity Platform.

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

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

Vedi anche

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.