scenari di MSAL.NET

Introduction

Le librerie di autenticazione .NET supportano scenari che coinvolgono la protezione di un'API Web e l'acquisizione di token per un'API Web protetta. MSAL.NET viene utilizzato solo per quest'ultimo.

Gli sviluppatori possono acquisire un token da diversi tipi di applicazioni, tra cui applicazioni Web, applicazioni per dispositivi mobili, applicazioni desktop, API Web e applicazioni in esecuzione su dispositivi che non dispongono di un browser (o iOT). Questi tipi di applicazioni sono separati in due categorie:

• Le applicazioni client pubbliche (desktop e dispositivi mobili) usano la PublicClientApplication classe
• Applicazioni client riservate (app Web, API Web e applicazioni daemon - desktop o Web). Questi tipi di app usano .ConfidentialClientApplication

MSAL.NET supporta l'acquisizione di token nel nome di un utente o ( e solo per le applicazioni client riservate) nel nome dell'applicazione stessa (per nessun utente). In tal caso, l'applicazione client riservata condivide un segreto con Microsoft Entra ID

MSAL.NET supporta diverse piattaforme (.NET Framework, .NET e .NET MAUI). .NET app possono essere eseguite anche in sistemi operativi diversi (Windows, Linux e macOS). Gli scenari possono essere diversi a seconda delle piattaforme.

Scenari

L'immagine seguente riepiloga gli scenari supportati e mostra in quale piattaforma e a quale Microsoft Entra protocollo corrisponde:

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

Per proteggere un'app Web (accesso dell'utente) si useranno ASP.NET o ASP.NET Core con il middleware ASP.NET OpenID Connect. Ciò comporta la convalida del token eseguito dalle estensioni IdentityModel per .NET libreria, non MSAL.NET.

Per chiamare l'API Web nel nome dell'utente, si userà MSAL.NET ConfidentialClientApplication, sfruttando il flusso del codice di autorizzazione, quindi archiviando il token acquisito nella cache dei token e acquisendo automaticamente un token dalla cache quando necessario. Se necessario, MSAL aggiorna il token.

App per dispositivi mobili che chiama un'API Web per conto dell'utente che ha eseguito l'accesso in modo interattivo

Per chiamare un'API Web da un'applicazione per dispositivi mobili, usare i metodi di acquisizione di token interattivi di MSAL.NET PublicClientApplication. Questi metodi interattivi consentono di controllare l'esperienza di accesso dell'interfaccia utente, nonché la posizione della finestra di dialogo interattiva in alcune piattaforme.

Per abilitare questa interazione, MSAL.NET sfrutta un Web browser. Esistono specifiche a seconda della piattaforma mobile. In iOS e Android è possibile scegliere se usare il browser di sistema (impostazione predefinita) o un Web browser incorporato. È possibile abilitare la condivisione della cache dei token in iOS.

Protezione dell'app stessa con Intune

L'app per dispositivi mobili (scritta in Xamarin.iOS o Xamarin. Android) può avere criteri di protezione delle app applicati, in modo che possa essere gestito da InTune e riconosciuto da Intune come app gestita. InTune SDK è separato da MSAL e comunica con Microsoft Entra ID autonomamente.

App daemon desktop o del servizio che chiama un'API Web come se stessa (con il proprio nome)

È possibile scrivere un'app daemon che acquisisce un token usando la propria identità usando i metodi di acquisizione delle credenziali client di MSAL.NET ConfidentialClientApplication. Si supponga che l'app abbia registrato in precedenza un segreto (password dell'applicazione o certificato) con Microsoft Entra ID, che quindi condivide con questa chiamata.

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

Le applicazioni desktop possono usare la stessa autenticazione interattiva delle applicazioni per dispositivi mobili.

Per Windows applicazioni ospitate, è anche possibile che le applicazioni in esecuzione nei computer aggiunti a un dominio Windows o Microsoft Entra aggiunte per acquisire un token automaticamente usando l'autenticazione integrata Windows.

Se l'applicazione desktop è un'applicazione .NET Core in esecuzione in Linux o Mac, non è possibile usare il flusso di autenticazione interattiva (come .NET Core non fornisce un Web browser), né l'autenticazione integrata Windows. L'opzione migliore in questo caso consiste nell'usare il flusso del codice del dispositivo come illustrato in Applicazione senza un browser o un'applicazione iOT che chiama un'API nel nome dell'utente.

Sebbene non sia consigliabile, è possibile usare il flusso Username-password nelle applicazioni client pubbliche; È ancora necessario in alcuni scenari, ad esempio DevOps, ma è necessario tenere presente che l'uso impone vincoli all'applicazione. Ad esempio, non è possibile accedere agli utenti che devono eseguire Multi Factor Authentication (accesso condizionale) o sfruttare i vantaggi dell'accesso Single Sign-On (SSO). Il flusso username-password si basa sui principi dell'autenticazione moderna e viene fornito solo per motivi legacy.

Nelle applicazioni desktop, se si vuole che la cache dei token sia persistente, è necessario personalizzare la serializzazione della cache dei token.

Applicazione senza browser o applicazione iOT che chiama un'API nel nome dell'utente

Le applicazioni in esecuzione in un dispositivo senza un browser potranno comunque chiamare un'API nel nome di un utente, dopo aver eseguito l'accesso dell'utente in un altro dispositivo con un Web browser. Per questo è necessario usare il flusso del codice del dispositivo

API Web che chiama un'altra API Web downstream nel nome dell'utente per cui è stato chiamato

Se si vuole che il ASP.NET o ASP.NET Core'API Web protetta chiami un'altra API Web per conto dell'utente rappresentato dal token di accesso è stata usata per chiamare l'API, sarà necessario:

• Convalidare il token. Per questo si userà il middleware JWT ASP.NET sotto le quinte. Ciò comporta anche la convalida del token eseguito dalle estensioni IdentityModel per .NET libreria, non MSAL.NET
• Sarà quindi necessario acquisire un token per l'API Web downstream usando il metodo ConfidentialClientApplication Acquisizione di un token per conto di un utente nelle chiamate da servizio a servizio.
• Anche le API Web che chiamano altre API Web dovranno fornire una serializzazione della cache personalizzata.

API Web che chiama un'altra API nel proprio nome

Come nelle applicazioni desktop o daemon di servizi, un'API Web daemon (o un'app Web daemon) può usare i metodi di acquisizione delle credenziali client di ConfidentialClientApplication di MSAL.NET.

Caratteristiche trasverse

In tutti gli scenari che è possibile:

• Risolvere i problemi attivando log o telemetria
• Informazioni su come reagire alle eccezioni dovute al servizio MsalServiceExceptionMicrosoft Entra o a un errore nel client stessoMsalClientException
• Usare MSAL.NET con un proxy