Implementare l'accesso Single Sign-On dalle app native alle visualizzazioni Web incorporate

Si applica a: Cerchio verde con un segno di spunta bianco che indica che il contenuto seguente si applica ai tenant esterni. Tenant esterni (maggiori informazioni)

Quando l'app per dispositivi mobili include funzionalità basate sul Web, ad esempio una pagina di aggiornamento del profilo o un dashboard rewards, gli utenti si aspettano un'esperienza single sign-on senza problemi. Non dovrebbero incontrare una seconda richiesta di accesso dopo aver già eseguito l'accesso tramite l'app nativa.

Questo articolo illustra come implementare l'accesso Single Sign-On (SSO) tra un'applicazione per dispositivi mobili nativa e una risorsa Web ospitata in una visualizzazione Web incorporata, WKWebView ad esempio in iOS o WebView in Android. A differenza dei browser di sistema, le visualizzazioni Web incorporate consentono di modificare le richieste di rete prima che vengano inviate. Questa funzionalità consente all'app di inserire lo stato di autenticazione dell'utente direttamente nelle intestazioni della richiesta.

Il flusso consigliato funziona come segue:

  1. L'utente accede tramite l'interfaccia utente nativa dell'app per dispositivi mobili usando Native Auth SDK o l'API di autenticazione nativa.
  2. Prima di caricare la visualizzazione Web, l'app recupera un token di accesso valido dall'SDK o dall'API.
  3. L'app carica la visualizzazione Web con una richiesta personalizzata che include il token di accesso nell'intestazione Authorization: Bearer <access_token> .
  4. La risorsa Web convalida il token e concede immediatamente l'accesso.

Il diagramma seguente illustra l'interazione tra la risorsa Web, l'app per dispositivi mobili, l'SDK e il servizio di gestione delle identità (ESTS):

Diagramma di sequenza che mostra il flusso SSO in cui l'app per dispositivi mobili accede tramite SDK, riceve i token e carica la visualizzazione Web con il token di accesso nell'intestazione Authorization.

Prerequisiti

Accedere con l'autenticazione nativa

Completare il flusso di accesso standard usando Native Auth SDK o l'API di autenticazione nativa. Quando l'accesso tramite l’SDK ha successo, memorizza nella cache il token di accesso, il token ID e il token di aggiornamento in modo sicuro. Se si usa direttamente l'API, l'app è responsabile dell'archiviazione sicura dei token ricevuti.

Per informazioni dettagliate sui passaggi di implementazione dell'accesso, vedere:

Recuperare il token di accesso

Quando l'utente attiva l'azione per aprire la visualizzazione Web, verificare che l'app disponga di un token di accesso valido e non scaduto prima di caricare la risorsa Web.

Se usi il Native Auth SDK, richiedi un token silenziosamente. L'SDK fornisce un getAccessToken() metodo che recupera un token valido dalla cache o lo aggiorna automaticamente. Per informazioni dettagliate sull'acquisizione di token di accesso con ambiti specifici, vedere:

Se si usa direttamente l'API di autenticazione nativa, l'app recupera i token tramite l'endpoint dell'API /oauth/v2.0/token . Per informazioni dettagliate, vedere Informazioni di riferimento sull'API di autenticazione nativa.

Richiedere il token con gli ambiti esatti richiesti dalla risorsa Web. Per i requisiti di ambito, vedere Limitazioni e requisiti di configurazione.

Caricare la visualizzazione Web con l'autenticazione

Esistono due metodi per passare lo stato di autenticazione alla visualizzazione Web. L'approccio consigliato utilizza le intestazioni di autorizzazione. Un fallback basato su cookie è disponibile per scenari legacy, ma è sconsigliato.

Inserire il token di accesso direttamente nell'intestazione Authorization della richiesta HTTP iniziale usata per caricare la visualizzazione Web. Questo è il metodo più sicuro e affidabile.

Questo approccio è preferibile perché:

  • Senza stato: non si basa su cookie persistenti sul lato client.
  • Isola il token: limita rigorosamente il token a questo flusso di richiesta specifico.
  • Evita vettori di attacco basati sul Web: evita i comuni problemi di sicurezza associati alle sessioni gestite dal browser.

Per caricare il Web View con autenticazione basata su header:

  1. Costruire l'URL per la risorsa Web. Assicura che usi HTTPS.
  2. Creare un oggetto richiesta di rete personalizzato.
  3. Aggiungere l'intestazione Authorization: Bearer <access_token> alla richiesta.
  4. Caricare la richiesta nel componente visualizzazione Web, WKWebView ad esempio in iOS o WebView in Android.

Opzione B: Usare i cookie (solo fallback)

Se la risorsa Web di destinazione non è in grado di gestire l'autenticazione basata su intestazione (ad esempio, alcune applicazioni legacy a pagina singola), è possibile inserire il token come cookie. Questo approccio è in genere sconsigliato a causa dei rischi per la sicurezza.

L'inserimento di cookie in una visualizzazione Web affida lo stato di autenticazione a un meccanismo gestito dal browser. Questo rende la sessione "ambient" (collegata automaticamente alle richieste), il che espone l'applicazione alle classi di attacco Web standard.

  • XSS (cross-site scripting): la sessione è vulnerabile all'hijacking se il contenuto Web è compromesso.
  • CSRF (falsificazione di richiesta intersito): c'è il rischio di richieste autenticate indesiderate.
  • Fissazione della sessione: un utente malintenzionato potrebbe controllare lo stato della sessione.
  • Conformità: questo approccio è in conflitto con le procedure consigliate per la sicurezza (ad esempio, MASTG-KNOW-0018) relative alla persistenza dello stato sensibile nei file JAR dei cookie di visualizzazione Web.

Avvertimento

L'approccio basato su cookie è approvato in modo condizionale e generalmente sconsigliato. Usarlo solo quando la risorsa Web di destinazione non può supportare l'autenticazione basata su intestazione.

Se si usa l'approccio basato su cookie, si applicano questi requisiti:

  • Utilizzare i cookie di sessione rilasciati dal server, laddove possibile.
  • Evitare di inserire i token di accesso non elaborati direttamente nei cookie.
  • Impostare i cookie con gli attributi HttpOnly, Secure e l'appropriato SameSite.
  • Applicare una protezione CSRF rigorosa sul lato server.

Convalidare e rendere persistente il token nel back-end

Quando la richiesta raggiunge la risorsa Web, il back-end elabora il token per stabilire la sessione.

Convalidare il token

Il server Web intercetta le richieste in ingresso e verifica la firma e le attestazioni del token. Per ASP.NET back-end Core, usare Microsoft.Identity.Web (MISE) per gestire automaticamente la convalida.

Assicurarsi che il claim 'audience' (aud) del token corrisponda all'identificatore dell'API Web e che il claim 'issuer' (iss) corrisponda all'autorità prevista.

Rendere persistente la sessione

La visualizzazione Web non rende persistenti le intestazioni personalizzate sugli eventi di spostamento successivi, ad esempio quando l'utente seleziona un collegamento. Per mantenere lo stato autenticato dopo la richiesta iniziale, il server rilascia un cookie di sessione standard (Set-Cookie) al termine della convalida del token di connessione iniziale.

Configurare il cookie di sessione con gli attributi seguenti:

  • HttpOnly
  • Secure
  • Una politica appropriata SameSite

Limitazioni e requisiti di configurazione

Per assicurarsi che il token rilasciato all'app per dispositivi mobili venga accettato dalla risorsa Web, tenere presenti le configurazioni seguenti:

  • Identità client condivisa: l'app per dispositivi mobili e l'app Web devono condividere lo stesso ID client (ID applicazione). Se hanno ID diversi, il back-end rifiuta il token dell'app per dispositivi mobili per disallineamento dell'audience.
  • Allineamento dell'ambito: l'app per dispositivi mobili richiede il token di accesso con gli ambiti esatti richiesti dalla risorsa Web ( ad esempio , Profile.Read). Orders.Write

Note

Questa soluzione è personalizzata specificamente per lo scenario di visualizzazione Web. Una soluzione più generica che estende le funzionalità SSO ai browser di sistema e ad altri scenari complessi è pianificata per una versione futura.

Contenuti correlati

  • Last updated on