Migrer des applications vers MSAL pour iOS et macOS

La bibliothèque d’authentification Azure Active Directory (ADAL Objective-C) a été créée pour fonctionner avec des comptes Microsoft Entra via le point de terminaison v1.0.

La bibliothèque d’authentification Microsoft pour iOS et macOS (MSAL) est conçue pour fonctionner avec toutes les identités Microsoft, telles que les comptes Microsoft Entra, les comptes Microsoft personnels et les comptes Azure AD B2C, par l’intermédiaire de la plateforme d’identités Microsoft (anciennement le point de terminaison Azure AD v2.0).

Le Plateforme d'identités Microsoft présente quelques différences clés avec Azure AD v1.0. Cet article met en évidence ces différences et fournit des conseils pour migrer une application d’ADAL vers MSAL.

Différences entre les fonctionnalités de l’application ADAL et MSAL

Qui peut se connecter

  • ADAL prend uniquement en charge les comptes professionnels et scolaires, également appelés comptes Microsoft Entra.
  • MSAL prend en charge les comptes de Microsoft personnels (comptes MSA) tels que Hotmail.com, Outlook.com et Live.com.
  • MSAL prend en charge les comptes professionnels et scolaires, ainsi que les comptes Azure AD B2C.

Conformité aux normes

  • Le Plateforme d'identités Microsoft suit les normes OAuth 2.0 et OpenId Connect.
  • Le Plateforme d'identités Microsoft vous permet de demander des autorisations dynamiquement. Les applications peuvent demander des autorisations uniquement si nécessaire et demander plus en fonction des besoins de l’application. Pour plus d’informations, consultez autorisations et consentement.

Différences entre les bibliothèques ADAL et MSAL

L’API publique MSAL reflète quelques différences clés entre Azure AD v1.0 et le Plateforme d'identités Microsoft.

MSALPublicClientApplication au lieu d’ADAuthenticationContext

ADAuthenticationContext est le premier objet créé par une application ADAL. Il représente une instanciation d’ADAL. Les applications créent une nouvelle instance de ADAuthenticationContext pour chaque combinaison cloud/locataire (autorité) Microsoft Entra. Vous pouvez utiliser la même ADAuthenticationContext méthode pour obtenir des jetons pour plusieurs applications clientes publiques.

Dans MSAL, l’interaction principale est via un MSALPublicClientApplication objet, qui est modélisé après le client public OAuth 2.0. Une instance de MSALPublicClientApplication peut être utilisée pour interagir avec plusieurs clouds Microsoft Entra et locataires, sans avoir à créer une instance pour chaque autorité. Pour la plupart des applications, une MSALPublicClientApplication instance est suffisante.

Étendues au lieu de ressources

Dans ADAL, une application a dû fournir un identificateur de ressource comme https://graph.microsoft.com pour acquérir des jetons à partir du point de terminaison Azure AD v1.0. Une ressource peut définir un certain nombre de portées, ou oAuth2Permissions dans le manifeste de l’application, qu’elle reconnaît. Cela a permis aux applications clientes de demander des jetons auprès de cette ressource pour un ensemble donné d’autorisations prédéfinies lors de l’enregistrement de l’application.

Dans MSAL, au lieu d’un seul identificateur de ressource, les applications fournissent un ensemble d’étendues par requête. Une portée est un identificateur de ressource suivi d’un nom de permission sous la forme ressource/permission. Par exemple : https://graph.microsoft.com/user.read

Il existe deux façons de fournir des étendues dans MSAL :

  • Fournissez la liste de toutes les autorisations dont vos applications ont besoin. Par exemple:

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

    Dans ce cas, l’application demande les autorisations directory.read et directory.write. L’utilisateur sera invité à consentir à ces autorisations s’il ne l’a pas déjà fait auparavant pour cette application. L’application peut également recevoir des autorisations supplémentaires auxquelles l’utilisateur a déjà consenti pour l’application. L’utilisateur n’est invité à donner son consentement que pour les nouvelles autorisations ou les autorisations qui n’ont pas été accordées.

  • L’étendue /.default.

Il s’agit de la portée par défaut de chaque application. Il fait référence à la liste statique des autorisations configurées lors de l’inscription de l’application. Son comportement est similaire à celui de resource. Cela peut être utile lors de la migration pour vous assurer qu’un ensemble similaire d’étendues et d’expérience utilisateur est conservé.

Pour utiliser l’étendue /.default , ajoutez /.default à l’identificateur de ressource. Par exemple : https://graph.microsoft.com/.default. Si votre ressource se termine par une barre oblique (/), vous devez toujours ajouter /.default, y compris la barre oblique de début, ce qui entraîne une étendue qui a une double barre oblique (//) dans celle-ci.

Vous pouvez lire plus d’informations sur l’utilisation de l’étendue « /.default » dans les autorisations et les étendues.

Prise en charge de différents types de WebView et des navigateurs

ADAL prend uniquement en charge UIWebView/WKWebView pour iOS et WebView pour macOS. MSAL pour iOS prend en charge d’autres options d’affichage du contenu web lors de la demande d’un code d’autorisation, et ne prend plus en charge UIWebView; ce qui peut améliorer l’expérience utilisateur et la sécurité.

Par défaut, MSAL sur iOS utilise ASWebAuthenticationSession, qui est le composant web recommandé par Apple pour l’authentification sur les appareils iOS 12+. Il fournit des avantages de l’authentification unique (SSO) via le partage de cookies entre les applications et le navigateur Safari.

Vous pouvez choisir d’utiliser un autre composant web en fonction des exigences de l’application et de l’expérience utilisateur final souhaitée. Pour plus d’options, consultez les types d’affichage web pris en charge .

Lors de la migration d’ADAL vers MSAL, WKWebView offre l’expérience utilisateur la plus similaire à ADAL sur iOS et macOS. Nous vous encourageons à migrer vers ASWebAuthenticationSession iOS, si possible. Pour macOS, nous vous encourageons à utiliser WKWebView.

Différences entre les API de gestion des comptes

Lorsque vous appelez les méthodes ADAL acquireToken() ou acquireTokenSilent(), vous recevez un objet ADUserInformation contenant une liste de revendications provenant de id_token, qui représente le compte en cours d’authentification. En outre, ADUserInformation retourne une userId valeur basée sur la upn revendication. Après l’acquisition de jeton interactive initiale, ADAL s’attend à ce que le développeur fournisse userId dans tous les appels silencieux.

ADAL ne fournit pas d’API pour récupérer les identités utilisateur connues. Il s’appuie sur l’application pour enregistrer et gérer ces comptes.

MSAL fournit un ensemble d’API pour répertorier tous les comptes connus de MSAL sans avoir à acquérir de jeton.

Comme ADAL, MSAL renvoie des informations sur le compte qui incluent une liste de revendications provenant du id_token. Il fait partie de l’objet MSALAccount à l’intérieur de l’objet MSALResult .

MSAL fournit un ensemble d’API pour supprimer des comptes, ce qui rend les comptes supprimés inaccessibles à l’application. Une fois le compte supprimé, les appels d’acquisition de jetons ultérieurs invitent l’utilisateur à effectuer une acquisition interactive de jetons. La suppression de compte s’applique uniquement à l’application cliente qui l’a démarrée et ne supprime pas le compte des autres applications s’exécutant sur l’appareil ou dans le navigateur système. Cela garantit que l’utilisateur continue d’avoir une expérience d’authentification unique sur l’appareil, même après la déconnexion d’une application individuelle.

En outre, MSAL retourne également un identificateur de compte qui peut être utilisé pour demander un jeton en mode silencieux ultérieurement. Toutefois, l’identificateur de compte (accessible par le biais identifier de la propriété dans l’objet MSALAccount ) n’est pas affichable et vous ne pouvez pas supposer le format dans lequel il se trouve et vous ne devez pas essayer d’interpréter ou d’analyser.

Migration du cache de compte

Lors de la migration depuis ADAL, les applications stockent normalement le userId d’ADAL, qui ne comporte pas le identifier requis par MSAL. En tant qu’étape de migration unique, une application peut interroger un compte MSAL à l’aide de l’id utilisateur d’ADAL avec l’API suivante :

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

Cette API lit à la fois le cache msal et le cache ADAL pour rechercher le compte par userId ADAL (UPN).

Si le compte est trouvé, le développeur doit utiliser le compte pour effectuer l’acquisition de jetons silencieux. La première acquisition silencieuse de jeton mettra effectivement le compte à niveau, et le développeur recevra un identifiant de compte compatible avec MSAL dans le résultat MSAL (identifier). Après cela, seul identifier doit être utilisé pour les recherches de compte à l’aide de l’API suivante :

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

Bien qu’il soit possible de continuer à utiliser le userId d’ADAL pour toutes les opérations dans MSAL, comme userId est basé sur l’UPN, il est soumis à plusieurs limites qui entraînent une expérience utilisateur médiocre. Par exemple, si l’UPN change, l’utilisateur doit se reconnecter. Nous recommandons à toutes les applications d’utiliser le compte identifier non affichable pour toutes les opérations.

En savoir plus sur la migration de l’état du cache.

Changements relatifs à l’acquisition de jeton

MSAL apporte quelques modifications aux appels d’acquisition de jetons :

  • Comme ADAL, acquireTokenSilent effectue toujours une requête silencieuse.
  • Contrairement à ADAL, acquireToken entraîne toujours l’affichage d’une interface utilisateur permettant à l’utilisateur d’agir, soit via la vue web, soit via l’application Microsoft Authenticator. Selon l’état de l’authentification unique dans webview/Microsoft Authenticator, l’utilisateur peut être invité à entrer ses informations d’identification.
  • Dans ADAL, acquireToken avec AD_PROMPT_AUTO essaie d’abord d’acquérir un jeton de manière silencieuse et n’affiche l’interface utilisateur que si la demande silencieuse échoue. Dans MSAL, cette logique peut être mise en œuvre en appelant d’abord acquireTokenSilent et en n’appelant acquireToken que si l’acquisition silencieuse échoue. Cela permet aux développeurs de personnaliser l’expérience utilisateur avant de commencer l’acquisition de jetons interactifs.

Différences de gestion des erreurs

MSAL fournit plus de clarté entre les erreurs qui peuvent être gérées par votre application et celles qui nécessitent une intervention de l’utilisateur. Le développeur doit gérer un nombre limité d’erreurs :

  • MSALErrorInteractionRequired: l’utilisateur doit effectuer une demande interactive. Cela peut être dû à diverses raisons telles qu’une session d’authentification expirée, une stratégie d’accès conditionnel a changé, un jeton d’actualisation a expiré ou a été révoqué, il n’y a pas de jetons valides dans le cache, etc.
  • MSALErrorServerDeclinedScopes: La demande n’a pas été entièrement terminée et certaines étendues n’ont pas été accordées à l’accès. Cela peut être dû au refus d’un utilisateur de donner son consentement à une ou plusieurs étendues.

La gestion de toutes les autres erreurs de la MSALError liste est facultative. Vous pouvez utiliser les informations contenues dans ces erreurs pour améliorer l’expérience utilisateur.

Consultez Gestion des exceptions et des erreurs à l’aide de MSAL pour plus d’informations sur la gestion des erreurs MSAL.

Prise en charge du broker

MSAL, à compter de la version 0.3.0, prend en charge l’authentification répartie à l’aide de l’application Microsoft Authenticator. Microsoft Authenticator permet également la prise en charge des scénarios d’accès conditionnel. Les exemples de scénarios d’accès conditionnel incluent des stratégies de conformité des appareils qui obligent l’utilisateur à inscrire l’appareil via Intune ou à s’inscrire auprès de Microsoft Entra ID pour obtenir un jeton. Ainsi que les stratégies d’accès conditionnel de gestion des applications mobiles (MAM), qui exigent une preuve de conformité avant que votre application puisse obtenir un jeton.

Pour activer le répartiteur pour votre application :

  1. Inscrivez un format d’URI de redirection compatible broker pour l’application. Le format d’URI de redirection compatible avec le répartiteur est msauth.<app.bundle.id>://auth. Remplacez <app.bundle.id> par l’ID de bundle de votre application. Si vous migrez à partir d’ADAL et que votre application était déjà compatible avec le répartiteur, il n’y a rien d’supplémentaire à faire. Votre URI de redirection précédent est entièrement compatible avec MSAL. Vous pouvez donc passer à l’étape 3.

  2. Ajoutez le schéma d’URI de redirection de votre application à votre fichier info.plist. Pour l’URI de redirection MSAL par défaut, le format est msauth.<app.bundle.id>. Par exemple:

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

  3. Ajoutez les schémas suivants à Info.plist de votre application sous LSApplicationQueriesSchemes :

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

  4. Ajoutez ce qui suit à votre fichier AppDelegate.m pour gérer les rappels : 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)

Dans ADAL, vous créez des instances distinctes de ADAuthenticationContext pour chaque locataire pour lequel l’application demande des jetons. Il ne s’agit plus d’une exigence dans MSAL. Dans MSAL, vous pouvez créer une seule instance de MSALPublicClientApplication et l’utiliser pour n’importe quel cloud Microsoft Entra et n’importe quelle organisation en spécifiant une autorité différente lors des appels à acquireToken et acquireTokenSilent.

SSO avec d’autres SDK

MSAL pour iOS permet d’assurer l’authentification unique grâce à un cache unifié avec ADAL Objective-C 2.7.x+.

L’authentification unique est obtenue par le biais du partage de trousseau iOS, et est disponible uniquement entre les applications publiées à partir du même compte de développeur Apple.

L’authentification unique par le biais du partage de trousseau iOS est le seul type d’authentification unique silencieux.

Sur macOS, MSAL peut réaliser l’authentification unique avec d’autres applications basées sur MSAL pour iOS et macOS, ainsi qu’avec des applications basées sur ADAL Objective-C.

MSAL sur iOS prend également en charge deux autres types d’authentification unique :

  • Authentification unique par le biais du navigateur web. MSAL pour iOS prend en charge ASWebAuthenticationSession, qui fournit l’authentification unique par le biais de cookies partagés entre d’autres applications sur l’appareil et spécifiquement le navigateur Safari.
  • Authentification unique (SSO) via un courtier d’authentification. Sur un appareil iOS, Microsoft Authenticator agit comme répartiteur d’authentification. Il peut suivre des stratégies d’accès conditionnel telles que l’exigence d’un appareil conforme et fournit l’authentification unique pour les appareils inscrits. Les kits SDK MSAL commençant par la version 0.3.0 prennent en charge un répartiteur par défaut.

SDK GAM Intune

Le SDK GAM Intune prend en charge MSAL pour iOS à partir de la version 11.1.2

MSAL et ADAL dans la même application

ADAL version 2.7.0 et ultérieures ne peut pas coexister avec MSAL dans la même application. La raison principale est due au code commun des sous-modules partagés. Étant donné que Objective-C ne prend pas en charge les espaces de noms, si vous ajoutez des frameworks ADAL et MSAL à votre application, il y aura deux instances de la même classe. Il n’y a aucune garantie quant à celui qui sera choisi au moment de l’exécution. Si les deux kits SDK utilisent la même version de la classe en conflit, votre application peut toujours fonctionner. Toutefois, s’il s’agit d’une version différente, votre application peut rencontrer des incidents inattendus difficiles à diagnostiquer.

L’exécution d’ADAL et MSAL dans la même application de production n’est pas prise en charge. Toutefois, si vous testez et migrez simplement vos utilisateurs d’ADAL Objective-C vers MSAL pour iOS et macOS, vous pouvez continuer à utiliser ADAL Objective-C 2.6.10. Il s’agit de la seule version qui fonctionne avec MSAL dans la même application. Il n’y aura aucune nouvelle mise à jour des fonctionnalités pour cette version ADAL. Il ne doit donc être utilisé qu’à des fins de migration et de test. Votre application ne doit pas s’appuyer sur la coexistence ADAL et MSAL à long terme.

La coexistence ADAL et MSAL dans la même application n’est pas prise en charge. La coexistence ADAL et MSAL entre plusieurs applications est entièrement prise en charge.

Étapes de migration pratiques

Migration de l’enregistrement d’application

Vous n'avez pas besoin de modifier votre application Microsoft Entra existante pour basculer vers MSAL et activer Microsoft Entra comptes. Toutefois, si votre application basée sur ADAL ne prend pas en charge l’authentification répartie, vous devez inscrire un nouvel URI de redirection pour l’application avant de pouvoir basculer vers MSAL.

L’URI de redirection doit être au format suivant : msauth.<app.bundle.id>://auth. Remplacez <app.bundle.id> par l’ID de bundle de votre application. Spécifiez l’URI de redirection dans le centre d’administration Microsoft Entra.

Pour iOS uniquement, pour prendre en charge l’authentification basée sur un certificat, un URI de redirection supplémentaire doit être inscrit dans votre application et le centre d’administration Microsoft Entra au format suivant : msauth://code/<broker-redirect-uri-in-url-encoded-form> Par exemple : msauth://code/msauth.com.microsoft.mybundleId%3A%2F%2Fauth

Nous recommandons à toutes les applications d’inscrire les deux URI de redirection.

Si vous souhaitez ajouter la prise en charge du consentement incrémentiel, sélectionnez les API et les autorisations que votre application est configurée pour demander l’accès dans votre inscription d’application sous l’onglet Autorisations de l’API .

Si vous effectuez une migration à partir d'ADAL et que vous souhaitez prendre en charge les comptes Microsoft Entra ID et MSA, votre inscription d'application existante doit être mise à jour pour prendre en charge les deux. Nous vous déconseillons de mettre à jour votre application de production existante pour prendre en charge immédiatement Microsoft Entra ID et MSA. Au lieu de cela, créez un autre ID client qui prend en charge les Microsoft Entra ID et MSA pour les tests, et une fois que vous avez vérifié que tous les scénarios fonctionnent, mettez à jour l'application existante.

Ajouter MSAL à votre application

Vous pouvez ajouter le SDK MSAL à votre application à l’aide de votre outil de gestion de package préféré. Consultez des instructions détaillées ici.

Mettre à jour le fichier Info.plist de votre application

Pour iOS uniquement, ajoutez le schéma d’URI de redirection de votre application à votre fichier info.plist. Pour les applications compatibles avec le courtier ADAL, cela devrait déjà être le cas. Le schéma d’URI de redirection MSAL par défaut sera au format suivant : msauth.<app.bundle.id>.

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

Ajoutez les schémas suivants à la liste Info.plist de votre application sous LSApplicationQueriesSchemes.

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

Mettre à jour votre code AppDelegate

Pour iOS uniquement, ajoutez ce qui suit à votre fichier 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)
}

Si vous utilisez Xcode 11, vous devez placer la fonction de rappel MSAL dans le fichier SceneDelegate à la place. Si vous prenez en charge à la fois UISceneDelegate et UIApplicationDelegate pour assurer la compatibilité avec une version plus ancienne d’iOS, le rappel MSAL doit être placé dans les deux fichiers.

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)
    }

Cela permet à MSAL de gérer les réponses du répartiteur et du composant web. Cela n’était pas nécessaire dans ADAL, car les méthodes déléguées d’application étaient combinées automatiquement. L’ajout manuel est moins susceptible d’erreurs et donne plus de contrôle à l’application.

Activer la mise en cache des jetons

Par défaut, MSAL met en cache les jetons de votre application dans le trousseau de clés d’iOS ou de macOS.

Pour activer la mise en cache des jetons :

  1. Vérifiez que votre application est correctement signée
  2. Accédez à vos paramètres de projet Xcode >onglet Capacités>Activer le partage de trousseau.
  3. Cliquez sur + et spécifiez une des entrées Groupes de trousseaux suivantes : 3.a. Pour iOS, entrez com.microsoft.adalcache 3.b. Pour macOS, entrez com.microsoft.identity.universalstorage.

Créer MSALPublicClientApplication et basculer vers ses appels acquireToken et acquireTokeSilent

Vous pouvez créer MSALPublicClientApplication à l’aide du code suivant :

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
}

Appelez ensuite l’API de gestion des comptes pour voir s’il existe des comptes dans le cache :

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
}

ou lire tous les témoignages :

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
}

Si un compte est trouvé, appelez 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
  }
}

Étapes suivantes

En savoir plus sur les flux d’authentification et les scénarios d’application

  • Last updated on