Tipi di app e flussi di autenticazione di Microsoft Identity Platform

Microsoft Identity Platform supporta l'autenticazione per diversi tipi di architetture di applicazioni moderne. Tutte le architetture sono basate sui protocolli standard OAuth 2.0 e OpenID Connect. Usando le librerie di autenticazione per Microsoft Identity Platform, le applicazioni autenticano le identità e acquisiscono i token per accedere alle API protette.

Questo articolo descrive i flussi di autenticazione e gli scenari dell'applicazione in cui vengono usati.

Categorie di applicazioni

I token di sicurezza possono essere acquisiti da diversi tipi di applicazioni, tra cui:

• App Web
• App per dispositivi mobili
• App desktop
• API Web

I token possono essere acquisiti anche dalle app in esecuzione nei dispositivi che non dispongono di un browser o sono in esecuzione su Internet delle cose (IoT).

Le sezioni seguenti descrivono le categorie di applicazioni.

Risorse protette o applicazioni client

Gli scenari di autenticazione coinvolgono due attività:

• Acquisizione di token di sicurezza per un'API Web protetta: è consigliabile usare Microsoft Authentication Library (MSAL), sviluppato e supportato da Microsoft.
• Protezione di un'API Web o di un'app Web: una sfida per proteggere queste risorse consiste nel convalidare il token di sicurezza. In alcune piattaforme, Microsoft offre librerie middleware.

Con utenti o senza utenti

La maggior parte degli scenari di autenticazione acquisisce token per conto degli utenti che hanno eseguito l'accesso.

Esistono tuttavia anche app daemon. In questi scenari, le applicazioni acquisiscono i token per conto di se stessi senza alcun utente.

Applicazioni client a pagina singola, client pubblico e client riservato

I token di sicurezza possono essere acquisiti da più tipi di applicazioni. Queste applicazioni tendono a essere distinte nelle tre categorie seguenti. Ogni applicazione viene usata con librerie e oggetti diversi.

• Applicazioni a pagina singola: si tratta di app Web in cui i token vengono acquisiti da un'app JavaScript o TypeScript in esecuzione nel browser. Molte app moderne hanno un'applicazione a pagina singola nel front-end scritto principalmente in JavaScript. L'applicazione usa spesso un framework come Angular, React o Vue. MSAL.js è l'unica libreria di autenticazione Microsoft che supporta applicazioni a pagina singola.

• Applicazioni client pubbliche: le app in questa categoria, come i tipi seguenti, accedono sempre agli utenti:

  • App desktop che chiamano API Web per conto degli utenti connessi
  • App per dispositivi mobili
  • App in esecuzione su dispositivi che non dispongono di un browser, ad esempio quelle in esecuzione in IoT

• Applicazioni client riservate: le app in questa categoria includono:

  • App Web che chiamano un'API Web
  • API Web che chiamano un'API Web
  • App daemon, anche se implementate come un servizio console, ad esempio un daemon Linux o un servizio Windows

Tipi di account supportati

i flussi di autenticazione disponibili variano in base ai destinatari per l'accesso. Alcuni flussi sono disponibili solo per gli account aziendali e dell'istituto di istruzione. Altri sono disponibili sia per gli account aziendali che dell'istituto di istruzione e per gli account Microsoft personali.

Per altre informazioni, vedere Tipi di account supportati.

Tipi di applicazione

Microsoft Identity Platform supporta l'autenticazione per queste architetture di app:

• App a pagina singola
• App Web
• API Web
• App per dispositivi mobili
• App native
• App daemon
• App lato server

Le applicazioni usano flussi di autenticazione diversi per concedere l'accesso agli utenti e ottenere i token per chiamare le API protette.

Applicazione a pagina singola

Molte app Web moderne vengono create come applicazioni a pagina singola lato client. Queste applicazioni usano JavaScript o un framework come Angular, Vue e React. Queste applicazioni vengono eseguite in un Web browser.

Le applicazioni a pagina singola differiscono dalle tradizionali app Web sul lato server in termini di caratteristiche di autenticazione. Usando Microsoft Identity Platform, le applicazioni a pagina singola possono concedere l'accesso agli utenti e ottenere i token per l'accesso a servizi back-end o API Web. Microsoft Identity Platform offre due tipi di concessione per le applicazioni JavaScript:

MSAL.js (2.x)	MSAL.js (1.x)

App Web che accede a un utente

Per proteggere un'app Web che accede a un utente:

• Se si sviluppa in .NET, si usano ASP.NET o ASP.NET Core con il middleware ASP.NET OpenID Connect. La protezione di una risorsa comporta la convalida del token di sicurezza, eseguita dalle estensioni IdentityModel per .NET e non dalle librerie MSAL.

• Se si sviluppa in Node.js, si usa MSAL Node.

Per altre informazioni, vedere App Web che concedono l'accesso degli utenti.

App Web che accede a un utente e chiama un'API Web per conto dell'utente

Per chiamare un'API Web da un'app Web per conto di un utente, usare il flusso del codice di autorizzazione e archiviare i token acquisiti nella cache dei token. Se necessario, MSAL aggiorna i token e il controller li acquisisce automaticamente dalla cache.

Per altre informazioni, vedere App Web che chiama le API Web.

App desktop che chiama un'API Web per conto di un utente connesso

Per consentire a un'app desktop di chiamare un'API Web che consente agli utenti di accedere, usare i metodi interattivi di acquisizione di token di MSAL. Con questi metodi interattivi, è possibile controllare l'esperienza dell'interfaccia utente di accesso. MSAL usa un Web browser per questa interazione.

Esiste un'altra possibilità per le applicazioni ospitate in Windows nei computer aggiunti a un dominio Windows o da Microsoft Entra ID. Queste applicazioni possono acquisire automaticamente un token usando autenticazione di Windows integrato.

Le applicazioni in esecuzione in un dispositivo privo di browser potranno comunque chiamare un'API per conto di un utente. Per eseguire l'autenticazione, l'utente dovrà eseguire l'accesso in un altro dispositivo che include un Web browser. Questo scenario richiede l'uso del flusso di codice del dispositivo.

Anche se non è consigliabile usarlo, il flusso nome utente/password è disponibile nelle applicazioni client pubbliche. Questo flusso è ancora necessario in alcuni scenari, come DevOps.

L'uso del flusso nome utente/password vincola le applicazioni. Ad esempio, le applicazioni non possono accedere a un utente che deve usare l'autenticazione a più fattori o lo strumento di accesso condizionale in Microsoft Entra ID. Inoltre, le applicazioni non usufruiscono dell'accesso Single Sign-On. L'autenticazione con il flusso nome utente/password si basa sui principi dell'autenticazione moderna e viene fornita solo per motivi legacy.

Nelle app desktop, se si vuole che la cache dei token venga mantenuta, è possibile personalizzare la serializzazione della cache dei token. Implementando la serializzazione della cache dual token, è possibile usare cache di token compatibili con le versioni precedenti e compatibili con l'inoltro.

Per altre informazioni, vedere App desktop che chiama le API Web.

App per dispositivi mobili che chiama un'API Web per conto di un utente interattivo

Analogamente a un'app desktop, un'app per dispositivi mobili chiama i metodi interattivi di acquisizione di token di MSAL per acquisire un token per chiamare un'API Web.

In iOS e Android, MSAL usa il Web browser di sistema per impostazione predefinita, Tuttavia, è possibile indirizzarli all'uso della visualizzazione Web incorporata. Esistono specifiche che dipendono dalla piattaforma mobile: piattaforma UWP (Universal Windows Platform) (UWP), iOS o Android.

Per alcuni scenari, come quelli che comportano l'accesso condizionale correlato all'ID dispositivo o alla registrazione del dispositivo, è necessario installare un broker nel dispositivo. Gli esempi di broker includono il portale aziendale Microsoft in Android e Microsoft Authenticator in Android e iOS.

Per altre informazioni, vedere App per dispositivi mobili che chiama le API Web.

API Web protetta

È possibile usare l'endpoint di Microsoft Identity Platform per proteggere i servizi Web come l'API RESTful dell'app. Un'API Web protetta viene chiamata tramite un token di accesso. Il token consente di proteggere i dati dell'API 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.

Se si vuole proteggere il ASP.NET o ASP.NET'API Web Core, convalidare il token di accesso. A questo scopo verrà usato il middleware JWT ASP.NET. La convalida viene eseguita dalla libreria delle estensioni IdentityModel per .NET e non da MSAL.NET

Per altre informazioni, vedere API Web protetta.

API Web che chiama un'altra API Web per conto di un utente

Affinché l'API Web protetta chiami un'altra API Web per conto di un utente, l'app deve acquisire un token per l'API Web downstream. Tali chiamate vengono talvolta definite chiamate da servizio a servizio . Le API Web che chiamano altre API Web devono fornire la serializzazione della cache personalizzata.

Per altre informazioni, vedere API Web che chiama le API Web.

App daemon che chiama un'API Web nel nome del daemon

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 API Web protette. Un'app di questo tipo può autenticare e ottenere token usando l'identità dell'app. L'app dimostra la propria identità usando un segreto client o un certificato.

È possibile scrivere tali app daemon che acquisiscono un token per l'app chiamante usando i metodi di acquisizione delle credenziali client in MSAL. Questi metodi richiedono un segreto client aggiunto alla registrazione dell'app in Microsoft Entra ID. L'app quindi condivide il segreto con il daemon chiamato. Esempi di tali segreti includono password dell'applicazione, asserzione di certificati e asserzione client.

Per altre informazioni, vedere Applicazione daemon che chiama le API Web.

Scenari e flussi di autenticazione supportati

I flussi di autenticazione vengono usati per implementare gli scenari dell'applicazione che richiedono token. Non esiste un mapping uno-a-uno tra scenari di applicazioni e flussi di autenticazione.

Anche gli scenari che prevedono l'acquisizione di token vengono mappati ai flussi di autenticazione OAuth 2.0. Per altre informazioni, vedere Protocolli OAuth 2.0 e OpenID Connect in Microsoft Identity Platform.

Scenario	Procedura dettagliata per lo scenario	Flusso OAuth 2.0 e concessione	Destinatari
	App a singola pagina	Codice di autorizzazione con PKCE	Account aziendali o dell'istituto di istruzione, account personali e Azure Active Directory B2C (Azure AD B2C)
	App a singola pagina	Implicito	Account aziendali o dell'istituto di istruzione, account personali e Azure Active Directory B2C (Azure AD B2C)
	App Web che offre l'accesso agli utenti	Codice di autorizzazione	Account aziendali o dell'istituto di istruzione, account personali, Azure AD B2C
	App Web che chiama le API Web	Codice di autorizzazione	Account aziendali o dell'istituto di istruzione, account personali, Azure AD B2C
	App desktop che chiama le API Web	Interattivo usando il codice di autorizzazione con PKCE	Account aziendali o dell'istituto di istruzione, account personali, Azure AD B2C
		Autenticazione integrata di Windows	Account aziendali o dell'istituto di istruzione
		Password del proprietario della risorsa	Account aziendali o dell'istituto di istruzione e Azure AD B2C
	App senza browser	Codice del dispositivo	Account aziendali o dell'istituto di istruzione, account personali, ma non Azure AD B2C
	App per dispositivi mobili che chiama le API Web	Interattivo usando il codice di autorizzazione con PKCE	Account aziendali o dell'istituto di istruzione, account personali, Azure AD B2C
		Password del proprietario della risorsa	Account aziendali o dell'istituto di istruzione e Azure AD B2C
	App daemon che chiama le API Web	Credenziali del client	Autorizzazioni solo app che non dispongono di utenti e vengono usate solo nelle organizzazioni Microsoft Entra
	App Web che chiama le API Web	On-behalf-of	Account aziendali o dell'istituto di istruzione e account personali

Scenari e piattaforme e linguaggi supportati

Le librerie di autenticazione Microsoft supportano più piattaforme:

• .NET
• .NET Framework
• Java
• JavaScript
• macOS
• Android nativo
• iOS nativo
• Node.js
• Python
• Windows 10/UWP

Per creare le applicazioni è anche possibile usare vari linguaggi.

Nella colonna Windows della tabella seguente, ogni volta che viene menzionato .NET Framework, è possibile anche .NET Framework. Quest'ultima piattaforma viene omessa per evitare di creare confusione nella tabella.

Scenario	Windows	Linux	Mac	iOS	Android
App a singola pagina	MSAL.js	MSAL.js	MSAL.js	MSAL.js	MSAL.js
App a singola pagina	MSAL.js	MSAL.js	MSAL.js	MSAL.js	MSAL.js
App Web che offre l'accesso agli utenti	ASP.NET Core MSAL Node	ASP.NET Core MSAL Node	ASP.NET Core MSAL Node
App Web che chiama le API Web	ASP.NET Core + MSAL.NET MSAL Java Flask + MSAL Python MSAL Node	ASP.NET Core + MSAL.NET MSAL Java Flask + MSAL Python MSAL Node	ASP.NET Core + MSAL.NET MSAL Java Flask + MSAL Python MSAL Node
App desktop che chiama le API Web	MSAL.NET MSAL Java MSAL Python MSAL Node	MSAL.NET MSAL Java MSAL Python MSAL Node	MSAL.NET MSAL Java MSAL Python MSAL Node MSAL.objc
App per dispositivi mobili che chiama le API Web	MSAL.NET MSAL.NET			MSAL.objc	MSAL. Androide
App daemon	MSAL.NET MSAL Java MSAL Python MSAL Node	MSAL.NET MSAL Java MSAL Python MSAL Node	MSAL.NET MSAL Java MSAL Python MSAL Node
App Web che chiama le API Web	ASP.NET Core + MSAL.NET MSAL Java MSAL Python MSAL Node	ASP.NET Core + MSAL.NET MSAL Java MSAL Python MSAL Node	ASP.NET Core + MSAL.NET MSAL Java MSAL Python MSAL Node

Per altre informazioni, vedere Librerie di autenticazione di Microsoft Identity Platform.

Passaggi successivi

Per altre informazioni sull'autenticazione, vedere:

• Autenticazione e autorizzazione.
• Token di accesso di Microsoft Identity Platform.
• Protezione dell'accesso alle app IoT.