Eseguire la migrazione di applicazioni a MSAL per iOS e macOS

La Azure Active Directory Authentication Library (ADAL Objective-C) è stata creata per lavorare con gli account Microsoft Entra tramite l'endpoint v1.0.

Il Microsoft Authentication Library per iOS e macOS (MSAL) è progettato per funzionare con tutte le identità di Microsoft, ad esempio account di Microsoft Entra, account Microsoft personali e account AD B2C Azure tramite il Microsoft Identity Platform (in precedenza l'endpoint Azure AD v2.0).

Il Microsoft Identity Platform presenta alcune differenze principali con Azure AD v1.0. Questo articolo illustra queste differenze e fornisce indicazioni per eseguire la migrazione di un'app da ADAL a MSAL.

Differenze tra le funzionalità delle app ADAL e MSAL

Chi può accedere

  • ADAL supporta solo gli account aziendali e dell'istituto di istruzione, noti anche come account Microsoft Entra.
  • MSAL supporta account Microsoft personali (account MSA), ad esempio Hotmail.com, Outlook.com e Live.com.
  • MSAL supporta gli account aziendali e scolastici e gli account Azure AD B2C.

Conformità agli standard

  • Il Microsoft Identity Platform segue gli standard OAuth 2.0 e OpenId Connect.
  • Il Microsoft Identity Platform consente di richiedere le autorizzazioni in modo dinamico. Le app possono richiedere autorizzazioni solo in base alle esigenze e richiedere di più in base alle esigenze dell'app. Per altre informazioni, vedere Autorizzazioni e consenso.

Differenze tra le librerie ADAL e MSAL

L'API pubblica MSAL riflette alcune differenze principali tra Azure AD v1.0 e il Microsoft Identity Platform.

MSALPublicClientApplication invece di ADAuthenticationContext

ADAuthenticationContext è il primo oggetto creato da un'app ADAL. Rappresenta un'istanziazione di ADAL. Le app creano una nuova istanza di ADAuthenticationContext per ogni combinazione di cloud e tenant (autorità) Microsoft Entra. Lo stesso ADAuthenticationContext può essere usato per ottenere token per più applicazioni client pubbliche.

In MSAL l'interazione principale è tramite un MSALPublicClientApplication oggetto, modellato dopo OAuth 2.0 Public Client. Un'istanza di MSALPublicClientApplication può essere utilizzata per interagire con più cloud Microsoft Entra e tenant, senza dover creare una nuova istanza per ogni autorità. Per la maggior parte delle app, è sufficiente un'istanza MSALPublicClientApplication .

Ambiti anziché risorse

In ADAL un'app doveva fornire un identificatore di risorsa come https://graph.microsoft.com per acquisire i token dall'endpoint di Azure AD v1.0. Una risorsa può definire una serie di ambiti, o oAuth2Permissions, nel manifest dell'app, che supporta. In questo modo, le app client possono richiedere token da tale risorsa per un determinato set di ambiti predefiniti durante la registrazione dell'app.

In MSAL, anziché un singolo identificatore di risorsa, le app forniscono un set di ambiti per ogni richiesta. Un ambito è un identificatore di risorsa seguito da un nome di autorizzazione nel formato risorsa/autorizzazione. Ad esempio, https://graph.microsoft.com/user.read

Esistono due modi per fornire ambiti in MSAL:

  • Fornire un elenco di tutte le autorizzazioni necessarie per le app. Per esempio:

    @[@"https://graph.microsoft.com/directory.read", @"https://graph.microsoft.com/directory.write"]

    In questo caso, l'app richiede le autorizzazioni directory.read e directory.write. All'utente verrà chiesto di fornire il consenso per tali autorizzazioni se non gli è stato concesso il consenso prima per questa app. L'applicazione potrebbe anche ricevere autorizzazioni aggiuntive a cui l'utente ha già acconsentito per l'applicazione. All'utente verrà richiesto di fornire il consenso solo per le nuove autorizzazioni o le autorizzazioni non concesse.

  • Ambito /.default .

Questo è l'ambito predefinito per ogni applicazione. Fa riferimento all'elenco statico di autorizzazioni configurate al momento della registrazione dell'applicazione. Il comportamento è simile a quello di resource. Ciò può essere utile quando si esegue la migrazione per garantire che venga mantenuto un set simile di ambiti ed esperienza utente.

Per usare l'ambito /.default , aggiungere /.default all'identificatore di risorsa. Ad esempio: https://graph.microsoft.com/.default. Se la risorsa termina con una barra finale (/), devi comunque aggiungere /.default, inclusa la barra obliqua iniziale, ottenendo un ambito che contiene una doppia barra obliqua (//).

È possibile leggere altre informazioni sull'uso dell'ambito "/.default" nelle autorizzazioni e negli ambiti.

Supporto per diversi tipi di WebView e browser

ADAL supporta solo UIWebView/WKWebView per iOS e WebView per macOS. MSAL per iOS supporta più opzioni per la visualizzazione del contenuto Web quando si richiede un codice di autorizzazione e non supporta UIWebViewpiù , che può migliorare l'esperienza utente e la sicurezza.

Per impostazione predefinita, MSAL in iOS usa ASWebAuthenticationSession, ovvero il componente Web consigliato da Apple per l'autenticazione nei dispositivi iOS 12+. Offre vantaggi per l'accesso Single Sign-On (SSO) tramite la condivisione di cookie tra le app e il browser Safari.

È possibile scegliere di usare un componente Web diverso a seconda dei requisiti dell'app e dell'esperienza dell'utente finale desiderata. Per altre opzioni, vedere Tipi di visualizzazione Web supportati .

Quando si esegue la migrazione da ADAL a MSAL, WKWebView offre l'esperienza utente più simile ad ADAL in iOS e macOS. È consigliabile eseguire la migrazione a ASWebAuthenticationSession in iOS, se possibile. Per macOS, è consigliabile usare WKWebView.

Differenze tra le API di gestione degli account

Quando si chiamano i metodi acquireToken() ADAL o acquireTokenSilent(), si riceve un ADUserInformation oggetto contenente un elenco di attestazioni da id_token che rappresenta l'account autenticato. Inoltre, ADUserInformation restituisce un oggetto userId in base all'attestazione upn. Dopo l'acquisizione interattiva iniziale del token, ADAL si aspetta che gli sviluppatori forniscano userId in tutte le chiamate non interattive.

ADAL non fornisce un'API per recuperare le identità utente note. Si basa sull'app per salvare e gestire tali account.

MSAL fornisce un set di API per elencare tutti gli account noti a MSAL senza dover acquisire un token.

Analogamente ad ADAL, MSAL restituisce informazioni sull'account che contengono un elenco di attestazioni da id_token. Fa parte dell'oggetto MSALAccount all'interno dell'oggetto MSALResult .

MSAL fornisce un set di API per rimuovere gli account, rendendo gli account rimossi inaccessibili all'app. Dopo la rimozione dell'account, le chiamate successive di acquisizione dei token richiederanno all'utente di eseguire l'acquisizione interattiva dei token. La rimozione dell'account si applica solo all'applicazione client che l'ha avviata e non rimuove l'account dalle altre app in esecuzione nel dispositivo o dal browser di sistema. Ciò garantisce che l'utente continui a avere un'esperienza SSO nel dispositivo anche dopo la disconnessione di una singola app.

INOLTRE, MSAL restituisce anche un identificatore di account che può essere usato per richiedere un token in modo invisibile all'utente in un secondo momento. Tuttavia, l'identificatore dell'account (accessibile tramite identifier la proprietà nell'oggetto MSALAccount ) non è visualizzabile e non è possibile presupporre il formato in cui si trova né provare a interpretarlo o analizzarlo.

Migrazione della cache dell'account

Quando si esegue la migrazione da ADAL, le app in genere memorizzano il userId di ADAL, che non dispone del identifier richiesto da MSAL. Come passaggio di migrazione una tantum, un'app può eseguire query su un account MSAL usando l'ID utente di ADAL con l'API seguente:

- (nullable MSALAccount *)accountForUsername:(nonnull NSString *)username error:(NSError * _Nullable __autoreleasing * _Nullable)error;

Questa API legge sia la cache di MSAL che quella di ADAL per trovare l'account in base ad ADAL userId (UPN).

Se l'account viene individuato, lo sviluppatore deve usare l'account per eseguire l'acquisizione silenziosa del token. La prima acquisizione silenziosa del token aggiornerà di fatto l'account e lo sviluppatore otterrà un identificatore dell'account compatibile con MSAL nel risultato MSAL (identifier). Successivamente, è consigliabile usare solo identifier per le ricerche di account usando l'API seguente:

- (nullable MSALAccount *)accountForIdentifier:(nonnull NSString *)identifier error:(NSError * _Nullable __autoreleasing * _Nullable)error;

Anche se è possibile continuare a usare ADAL userId per tutte le operazioni in MSAL, poiché userId è basato su UPN, è soggetto a più limitazioni che comportano un'esperienza utente non valida. Ad esempio, se l'UPN cambia, l'utente deve eseguire di nuovo l'accesso. È consigliabile che tutte le app usino l'account identifier non visualizzabile per tutte le operazioni.

Altre informazioni sulla migrazione dello stato della cache.

Modifiche all'acquisizione di token

MSAL introduce alcune modifiche alle chiamate di acquisizione del token:

  • Come ADAL, acquireTokenSilent genera sempre una richiesta invisibile all'utente.
  • A differenza di ADAL, acquireToken genera sempre un'interfaccia utente pratica tramite la visualizzazione Web o l'app Microsoft Authenticator. A seconda dello stato SSO all'interno di webview/Microsoft Authenticator, all'utente potrebbe essere richiesto di immettere le credenziali.
  • In ADAL, acquireToken con AD_PROMPT_AUTO tenta prima di acquisire il token in modo invisibile all'utente e mostra l'interfaccia utente solo se la richiesta invisibile all'utente non riesce. In MSAL, questa logica si può ottenere richiamando prima acquireTokenSilent e richiamando acquireToken solo se l'acquisizione silenziosa non riesce. Ciò consente agli sviluppatori di personalizzare l'esperienza utente prima di avviare l'acquisizione interattiva dei token.

Differenze di gestione degli errori

MSAL offre maggiore chiarezza tra gli errori che possono essere gestiti dall'app e quelli che richiedono l'intervento dell'utente. Lo sviluppatore deve gestire un numero limitato di errori:

  • MSALErrorInteractionRequired: l'utente deve eseguire una richiesta interattiva. Ciò può essere causato per diversi motivi, ad esempio una sessione di autenticazione scaduta, i criteri di accesso condizionale sono stati modificati, un token di aggiornamento scaduto o è stato revocato, non sono presenti token validi nella cache e così via.
  • MSALErrorServerDeclinedScopes: la richiesta non è stata completata completamente e ad alcuni ambiti non è stato concesso l'accesso. Ciò può essere causato da un utente che rifiuta il consenso a uno o più ambiti.

La gestione di tutti gli altri errori nell'elencoMSALError è facoltativa. È possibile usare le informazioni contenute in tali errori per migliorare l'esperienza utente.

Per altre informazioni sulla gestione degli errori MSAL, vedere Gestione di eccezioni ed errori tramite MSAL .

Supporto per broker

MSAL, a partire dalla versione 0.3.0, fornisce il supporto per l'autenticazione negoziata usando l'app Microsoft Authenticator. Microsoft Authenticator abilita anche il supporto per gli scenari di accesso condizionale. Esempi di scenari di accesso condizionale includono i criteri di conformità dei dispositivi che richiedono all'utente di registrare il dispositivo tramite Intune o registrarsi con Microsoft Entra ID per ottenere un token. E i criteri di accesso condizionale MAM (Mobile Application Management), che richiedono la prova della conformità prima che l'app possa ottenere un token.

Per abilitare il broker per la tua applicazione:

  1. Registrare un formato URI di reindirizzamento compatibile con broker per l'applicazione. Il formato dell'URI di reindirizzamento compatibile con broker è msauth.<app.bundle.id>://auth. Sostituire <app.bundle.id> con l'ID bundle dell'applicazione. Se si esegue la migrazione da ADAL e l'applicazione è già in grado di supportare broker, non è necessario eseguire alcuna operazione aggiuntiva. L'URI di reindirizzamento precedente è completamente compatibile con MSAL, quindi è possibile passare al passaggio 3.

  2. Aggiungere lo schema URI di reindirizzamento dell'applicazione al file info.plist. Per l'URI di reindirizzamento MSAL predefinito, il formato è msauth.<app.bundle.id>. Per esempio:

    <key>CFBundleURLSchemes</key>
<array>
    <string>msauth.<app.bundle.id></string>
</array>

  3. Aggiungi i seguenti schemi all'Info.plist della tua app sotto LSApplicationQueriesSchemes:

    <key>LSApplicationQueriesSchemes</key>
<array>
     <string>msauthv2</string>
     <string>msauthv3</string>
</array>

  4. Aggiungere quanto segue al file AppDelegate.m per gestire i callback: Objective-C:

    - (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<NSString *,id> *)options`
{
    return [MSALPublicClientApplication handleMSALResponse:url sourceApplication:options[UIApplicationOpenURLOptionsSourceApplicationKey]];
}

    Swift:

    func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
    return MSALPublicClientApplication.handleMSALResponse(url, sourceApplication: options[UIApplication.OpenURLOptionsKey.sourceApplication] as? String)
}

Business to Business (B2B)

In ADAL si creano istanze separate di ADAuthenticationContext per ogni tenant per cui l'app richiede i token. Questo non è più un requisito in MSAL. In MSAL è possibile creare una singola istanza di MSALPublicClientApplication e usarla per qualsiasi cloud e organizzazione Microsoft Entra specificando un'autorità diversa per le chiamate acquireToken e acquireTokenSilent.

SSO in collaborazione con altri SDK

MSAL per iOS può consentire il Single Sign-On (SSO) tramite una cache unificata con ADAL Objective-C 2.7.x+.

L'accesso Single Sign-On viene ottenuto tramite la condivisione keychain iOS ed è disponibile solo tra le app pubblicate dallo stesso account Apple Developer.

L'SSO tramite la condivisione del portachiavi di iOS è l'unico tipo di SSO senza intervento dell'utente.

Su macOS, MSAL può realizzare l'SSO con altre applicazioni per iOS e macOS basate su MSAL e con applicazioni basate su ADAL per Objective-C.

MSAL in iOS supporta anche altri due tipi di accesso SSO:

  • SSO tramite il Web browser. MSAL per iOS supporta ASWebAuthenticationSession, che fornisce l'accesso Single Sign-On (SSO) tramite cookie condivisi con altre app sul dispositivo e in particolare con il browser Safari.
  • SSO tramite un broker di autenticazione. In un dispositivo iOS Microsoft Authenticator funge da broker di autenticazione. Può seguire i criteri di accesso condizionale, ad esempio la richiesta di un dispositivo conforme e fornisce l'accesso SSO per i dispositivi registrati. Gli SDK MSAL a partire dalla versione 0.3.0 supportano un broker per impostazione predefinita.

Intune MAM SDK

Intune MAM SDK supporta MSAL per iOS a partire dalla versione 11.1.2

MSAL e ADAL nella stessa app

ADAL versione 2.7.0 e successive non possono coesistere con MSAL nella stessa applicazione. Il motivo principale è dovuto al codice comune del modulo secondario condiviso. Poiché Objective-C non supporta gli spazi dei nomi, se si aggiungono i framework ADAL e MSAL all'applicazione, ci saranno due istanze della stessa classe. Non c'è alcuna garanzia su quale venga selezionato in fase di esecuzione. Se entrambi gli SDK usano la stessa versione della classe in conflitto, l'app potrebbe comunque funzionare. Tuttavia, se si tratta di una versione diversa, l'app potrebbe riscontrare arresti anomali imprevisti difficili da diagnosticare.

L'esecuzione di ADAL e MSAL nella stessa applicazione di produzione non è supportata. Tuttavia, se si sta eseguendo il test e la migrazione degli utenti da ADAL Objective-C a MSAL per iOS e macOS, è possibile continuare a usare ADAL Objective-C 2.6.10. È l'unica versione che funziona con MSAL nella stessa applicazione. Non ci saranno nuovi aggiornamenti delle funzionalità per questa versione di ADAL, quindi deve essere usato solo a scopo di migrazione e test. L'app non dovrebbe dipendere dalla coesistenza di ADAL e MSAL nel lungo termine.

La coesistenza di ADAL e MSAL nella stessa applicazione non è supportata. La coesistenza di ADAL e MSAL tra più applicazioni è completamente supportata.

Passaggi pratici per la migrazione

Migrazione della registrazione delle app

Non è necessario modificare l'applicazione Microsoft Entra esistente per passare a MSAL e abilitare gli account Microsoft Entra. Tuttavia, se l'applicazione basata su ADAL non supporta l'autenticazione negoziata, è necessario registrare un nuovo URI di reindirizzamento per l'applicazione prima di passare a MSAL.

L'URI di reindirizzamento deve essere nel formato seguente: msauth.<app.bundle.id>://auth. Sostituire <app.bundle.id> con l'ID bundle dell'applicazione. Specificare l'URI di reindirizzamento nel Interfaccia di amministrazione di Microsoft Entra.

Solo per iOS, per supportare l'autenticazione basata su certificati, è necessario registrare un URI di reindirizzamento aggiuntivo nell'applicazione e il Interfaccia di amministrazione di Microsoft Entra nel formato seguente: msauth://code/<broker-redirect-uri-in-url-encoded-form>. Ad esempio, msauth://code/msauth.com.microsoft.mybundleId%3A%2F%2Fauth

È consigliabile che tutte le app registrino entrambi gli URI di reindirizzamento.

Se vuoi aggiungere il supporto per il consenso incrementale, seleziona le API e le autorizzazioni a cui l'app è configurata per richiedere l'accesso nella registrazione dell'app nella scheda Autorizzazioni API .

Se si esegue la migrazione da ADAL e si vuole supportare sia gli account Microsoft Entra ID che gli account MSA, la registrazione dell'applicazione esistente deve essere aggiornata per supportare entrambi. Non è consigliabile aggiornare immediatamente l'app di produzione esistente per supportare sia Microsoft Entra ID che msa. Creare invece un altro ID client che supporti sia Microsoft Entra ID che MSA per il test e dopo aver verificato che tutti gli scenari funzionino, aggiornare l'app esistente.

Aggiungi MSAL alla tua app

È possibile aggiungere MSAL SDK all'app usando lo strumento di gestione dei pacchetti preferito. Vedere le istruzioni dettagliate qui.

Aggiornare il file Info.plist dell'app

Solo per iOS, aggiungere lo schema URI di reindirizzamento dell'applicazione al file info.plist. Per le app compatibili con il broker ADAL, dovrebbe essere già presente. Lo schema URI di reindirizzamento MSAL predefinito sarà nel formato : msauth.<app.bundle.id>.

<key>CFBundleURLSchemes</key>
<array>
    <string>msauth.<app.bundle.id></string>
</array>

Aggiungi i seguenti schemi a Info.plist della tua app sotto LSApplicationQueriesSchemes.

<key>LSApplicationQueriesSchemes</key>
<array>
     <string>msauthv2</string>
     <string>msauthv3</string>
</array>

Aggiornare il codice AppDelegate

Solo per iOS, aggiungere quanto segue al file AppDelegate.m:

Objective-C:

- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<NSString *,id> *)options`
{
    return [MSALPublicClientApplication handleMSALResponse:url sourceApplication:options[UIApplicationOpenURLOptionsSourceApplicationKey]];
}

Swift:

func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
    return MSALPublicClientApplication.handleMSALResponse(url, sourceApplication: options[UIApplication.OpenURLOptionsKey.sourceApplication] as? String)
}

Se si usa Xcode 11, è consigliabile inserire il callback MSAL nel SceneDelegate file. Se si supportano sia UISceneDelegate che UIApplicationDelegate per la compatibilità con iOS meno recenti, è necessario inserire il callback MSAL in entrambi i file.

Objective-C:

 - (void)scene:(UIScene *)scene openURLContexts:(NSSet<UIOpenURLContext *> *)URLContexts
 {
     UIOpenURLContext *context = URLContexts.anyObject;
     NSURL *url = context.URL;
     NSString *sourceApplication = context.options.sourceApplication;
     
     [MSALPublicClientApplication handleMSALResponse:url sourceApplication:sourceApplication];
 }

Swift:

func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {
        
        guard let urlContext = URLContexts.first else {
            return
        }
        
        let url = urlContext.url
        let sourceApp = urlContext.options.sourceApplication
        
        MSALPublicClientApplication.handleMSALResponse(url, sourceApplication: sourceApp)
    }

Ciò consente a MSAL di gestire le risposte dal broker e dal componente Web. Questo non era necessario in ADAL, poiché eseguiva automaticamente il method swizzling dei metodi dell'App Delegate. L'aggiunta manuale è meno soggetta a errori e offre all'applicazione un maggiore controllo.

Abilitare la memorizzazione nella cache dei token

Per impostazione predefinita, MSAL memorizza nella cache i token dell'app nel keychain iOS o macOS.

Per abilitare la memorizzazione nella cache dei token:

  1. Verificare che l'applicazione sia firmata correttamente
  2. Vai alle impostazioni del progetto Xcode >scheda Funzionalità>Abilita la condivisione del portachiavi
  3. Fare clic + e immettere una voce Keychain Groups seguente: 3.a Per iOS, immettere 3.b Per macOS immettere com.microsoft.adalcachecom.microsoft.identity.universalstorage

Creare MSALPublicClientApplication e passare alle chiamate acquireToken e acquireTokeSilent

È possibile creare MSALPublicClientApplication usando il codice seguente:

Objective-C:

NSError *error = nil;
MSALPublicClientApplicationConfig *configuration = [[MSALPublicClientApplicationConfig alloc] initWithClientId:@"<your-client-id-here>"];
    
MSALPublicClientApplication *application =
[[MSALPublicClientApplication alloc] initWithConfiguration:configuration
                                                     error:&error];

Swift:

let config = MSALPublicClientApplicationConfig(clientId: "<your-client-id-here>")
do {
  let application = try MSALPublicClientApplication(configuration: config)
  // continue on with application
            
} catch let error as NSError {
  // handle error here
}

Chiamare quindi l'API di gestione degli account per verificare se nella cache sono presenti account:

Objective-C:

NSString *accountIdentifier = nil /*previously saved MSAL account identifier */;
NSError *error = nil;
MSALAccount *account = [application accountForIdentifier:accountIdentifier error:&error];

Swift:

// definitions that need to be initialized
let application: MSALPublicClientApplication!
let accountIdentifier: String! /*previously saved MSAL account identifier */

do {
  let account = try application.account(forIdentifier: accountIdentifier)
  // continue with account usage
} catch let error as NSError {
  // handle error here
}

o visualizzare tutti gli account:

Objective-C:

NSError *error = nil;
NSArray<MSALAccount *> *accounts = [application allAccounts:&error];

Swift:

let application: MSALPublicClientApplication!
do {
  let accounts = try application.allAccounts()
  // continue with account usage
} catch let error as NSError {
  // handle error here
}

Se viene trovato un account, chiamare l'API MSAL acquireTokenSilent :

Objective-C:

MSALSilentTokenParameters *silentParameters = [[MSALSilentTokenParameters alloc] initWithScopes:@[@"<your-resource-here>/.default"] account:account];
    
[application acquireTokenSilentWithParameters:silentParameters
                              completionBlock:^(MSALResult *result, NSError *error)
{
    if (result)
    {
        NSString *accessToken = result.accessToken;
        // Use your token
    }
    else
    {
        // Check the error
        if ([error.domain isEqual:MSALErrorDomain] && error.code == MSALErrorInteractionRequired)
        {
            // Interactive auth will be required
        }
            
        // Other errors may require trying again later, or reporting authentication problems to the user
    }
}];

Swift:

let application: MSALPublicClientApplication!
let account: MSALAccount!
        
let silentParameters = MSALSilentTokenParameters(scopes: ["<your-resource-here>/.default"], 
                                                 account: account)
application.acquireTokenSilent(with: silentParameters) {
  (result: MSALResult?, error: Error?) in
  if let accessToken = result?.accessToken {
     // use accessToken
  }
  else {
    // Check the error
    guard let error = error else {
      assert(true, "callback should contain a valid result or error")
      return
    }
    
    let nsError = error as NSError
    if (nsError.domain == MSALErrorDomain
        && nsError.code == MSALError.interactionRequired.rawValue) {
      // Interactive auth will be required
    }
                
    // Other errors may require trying again later, or reporting authentication problems to the user
  }
}

Passaggi successivi

Altre informazioni sui flussi di autenticazione e sugli scenari dell'applicazione

  • Last updated on