Migrieren von Anwendungen zu MSAL für iOS und macOS

Die Azure Active Directory-Authentifizierungsbibliothek (ADAL Objective-C) wurde erstellt, um mit Microsoft Entra Konten über den v1.0-Endpunkt zu arbeiten.

Die Microsoft Authentication Library für iOS und macOS (MSAL) ist für die Verwendung mit allen Microsoft-Identitäten wie Microsoft Entra-Konten, persönlichen Microsoft-Konten und Azure AD B2C-Konten über die Microsoft-Identitätsplattform (früher Azure AD v2.0-Endpunkt) konzipiert.

Die Microsoft Identity Platform weist einige wichtige Unterschiede mit Azure AD v1.0 auf. In diesem Artikel werden diese Unterschiede erläutert und Anleitungen zum Migrieren einer App von ADAL zu MSAL bereitgestellt.

Unterschiede zwischen ADAL- und MSAL-App-Funktionen

Wer sich anmelden kann

• ADAL unterstützt nur Geschäfts- und Schulkonten – auch als Microsoft Entra Konten bezeichnet.
• MSAL unterstützt persönliche Microsoft-Konten (MSA-Konten) wie Hotmail.com, Outlook.com und Live.com.
• MSAL unterstützt Geschäfts-, Schul- und Unikonten sowie Azure AD B2C-Konten.

Einhaltung von Standards

• Der Microsoft Identity Platform folgt den OAuth 2.0- und OpenId Connect-Standards.

Inkrementelle und dynamische Zustimmung

• Mit dem Microsoft Identity Platform können Sie Berechtigungen dynamisch anfordern. Apps können Berechtigungen nur bei Bedarf anfordern und weitere anfordern, wenn die App sie benötigt. Weitere Informationen finden Sie unter Berechtigungen und Zustimmung.

Unterschiede bei der ADAL- und MSAL-Bibliothek

Die öffentliche MSAL-API spiegelt einige wichtige Unterschiede zwischen Azure AD v1.0 und dem Microsoft Identity Platform wider.

MSALPublicClientApplication anstelle von ADAuthenticationContext

ADAuthenticationContext ist das erste Objekt, das eine ADAL-App erstellt. Sie stellt eine Instanziierung von ADAL dar. Apps erstellen eine neue Instanz von ADAuthenticationContext für jede Kombination aus Microsoft Entra-Cloud und -Mandant (dieser entspricht der autoritativen Stelle). Dasselbe ADAuthenticationContext kann verwendet werden, um Token für mehrere öffentliche Clientanwendungen abzurufen.

In MSAL erfolgt die Hauptinteraktion über ein Objekt, das nach dem MSALPublicClientApplicationöffentlichen OAuth 2.0-Client modelliert wird. Eine Instanz von MSALPublicClientApplication kann verwendet werden, um mit mehreren Microsoft-Entra-Clouds und Mandanten zu interagieren, ohne für jede Autorität eine neue Instanz erstellen zu müssen. Für die meisten Apps reicht eine MSALPublicClientApplication Instanz aus.

Bereiche anstelle von Ressourcen

In ADAL musste eine App einen Ressourcenbezeichner wie https://graph.microsoft.com angeben, um Tokens vom Azure AD v1.0-Endpunkt abzurufen. Eine Ressource kann eine Reihe von Bereichen oder oAuth2Permissions im App-Manifest definieren, die es versteht. Dadurch konnten Client-Apps Token aus dieser Ressource für eine bestimmte Gruppe von Bereichen anfordern, die während der App-Registrierung vordefiniert sind.

In MSAL stellen Apps anstelle eines einzelnen Ressourcenbezeichners eine Reihe von Bereichen pro Anforderung bereit. Ein Scope ist ein Ressourcenbezeichner, gefolgt von einem Berechtigungsnamen in der Form Ressource/Berechtigung. Beispiel: https://graph.microsoft.com/user.read

Es gibt zwei Möglichkeiten, in MSAL Scopes anzugeben:

• Geben Sie eine Liste aller Berechtigungen an, die Ihre Apps benötigen. Beispiel:

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

  In diesem Fall fordert die App die Berechtigungen directory.read und directory.write an. Der Benutzer wird aufgefordert, diesen Berechtigungen zuzustimmen, wenn er ihnen zuvor für diese App noch nicht zugestimmt hat. Die Anwendung erhält möglicherweise auch zusätzliche Berechtigungen, denen der Benutzer bereits für die Anwendung zugestimmt hat. Der Benutzer wird nur aufgefordert, neuen Berechtigungen oder Berechtigungen zuzustimmen, die nicht erteilt wurden.

• Durch den Bereich /.default.

Dies ist der integrierte Geltungsbereich jeder Anwendung. Sie bezieht sich auf die statische Liste der Berechtigungen, die beim Registrieren der Anwendung konfiguriert wurden. Sein Verhalten ähnelt dem von resource. Dies kann bei der Migration hilfreich sein, um sicherzustellen, dass eine ähnliche Gruppe von Bereichen und Benutzererfahrung beibehalten wird.

Um den /.default Gültigkeitsbereich zu verwenden, hängen Sie /.default an den Ressourcenbezeichner an. Beispiel: https://graph.microsoft.com/.default. Wenn die Adresse Ihrer Ressource mit einem Schrägstrich (/) endet, sollten Sie dennoch /.default einschließlich des führenden Schrägstrichs anfügen. Das Ergebnis ist dann ein Bereich mit zwei Schrägstrichen (//).

Weitere Informationen zur Verwendung des Bereichs "/.default" finden Sie in Berechtigungen und Bereichen.

Unterstützen verschiedener WebView-Typen und Browser

ADAL unterstützt nur UIWebView/WKWebView für iOS und WebView für macOS. MSAL für iOS unterstützt weitere Optionen zum Anzeigen von Webinhalten beim Anfordern eines Autorisierungscodes und unterstützt nicht mehr UIWebView; dies kann die Benutzerfreundlichkeit und Sicherheit verbessern.

Standardmäßig verwendet MSAL unter iOS ASWebAuthenticationSession, also die Webkomponente, die Apple für die Authentifizierung auf iOS 12+-Geräten empfiehlt. Es bietet Single-Sign-on-Vorteile (SSO) durch die gemeinsame Nutzung von Cookies zwischen Apps und dem Safari-Browser.

Sie können je nach App-Anforderungen und der gewünschten Endbenutzerumgebung eine andere Webkomponente verwenden. Weitere Optionen finden Sie unter unterstützten Webansichtstypen .

Bei der Migration von ADAL zu MSAL WKWebView ist die Benutzerfreundlichkeit ähnlich wie ADAL unter iOS und macOS. Wir empfehlen Ihnen, wenn möglich zu ASWebAuthenticationSession unter iOS zu migrieren. Für macOS empfehlen wir Ihnen, WKWebView zu verwenden.

Unterschiede bei der Kontoverwaltungs-API

Wenn Sie die ADAL-Methoden acquireToken() oder acquireTokenSilent() aufrufen, erhalten Sie ein ADUserInformation-Objekt, das eine Liste von Ansprüchen aus dem id_token enthält, das das authentifizierte Konto darstellt. Außerdem gibt ADUserInformation auf der Grundlage des upn-Anspruchs eine userId zurück. Nach dem ersten interaktiven Tokenabruf erwartet ADAL, dass Entwickler eine userId für alle automatischen Aufrufe angeben.

ADAL stellt keine API zum Abrufen bekannter Benutzeridentitäten bereit. Sie basiert auf der App, um diese Konten zu speichern und zu verwalten.

MSAL stellt eine Reihe von APIs bereit, um alle Konten aufzulisten, die MSAL bekannt sind, ohne ein Token abrufen zu müssen.

Ebenso wie ADAL gibt MSAL Kontoinformationen zurück, die eine Liste der Ansprüche des id_token enthalten. Es ist Teil des MSALAccount Objekts innerhalb des MSALResult Objekts.

MSAL stellt eine Reihe von APIs zum Entfernen von Konten bereit, wodurch auf die entfernten Konten nicht zugegriffen werden kann. Nachdem das Konto entfernt wurde, fordern spätere Aufrufe zur Tokenanforderung den Benutzer zu einer interaktiven Tokenanforderung auf. Die Kontoentfernung gilt nur für die Clientanwendung, die sie gestartet hat, und entfernt das Konto nicht aus den anderen Apps, die auf dem Gerät oder im Systembrowser ausgeführt werden. Dadurch wird sichergestellt, dass der Benutzer weiterhin über eine SSO-Erfahrung auf dem Gerät verfügt, auch nachdem er sich von einer einzelnen App abgemeldet hat.

Darüber hinaus gibt MSAL auch einen Kontobezeichner zurück, der verwendet werden kann, um ein Token später im Hintergrund anzufordern. Die Konto-ID (auf die über die Eigenschaft identifier im Objekt MSALAccount zugegriffen werden kann) ist jedoch nicht darstellbar, und Sie können weder davon ausgehen, in welchem Format sie vorliegt, noch sollten Sie versuchen, sie zu interpretieren oder zu parsen.

Migrieren des Kontocaches

Bei der Migration von ADAL speichern Apps normalerweise die userId von ADAL, die nicht über das von MSAL erforderliche identifier verfügt. Als einmaliger Migrationsschritt kann eine App ein MSAL-Konto mithilfe der UserId von ADAL mit der folgenden API abfragen:

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

Diese API liest sowohl den Cache von MSAL als auch den ADAL-Cache, um das Konto von ADAL userId (UPN) zu finden.

Wenn das Konto gefunden wird, sollte der Entwickler dieses zum automatischen Abrufen des Tokens verwenden. Durch den ersten automatischen Tokenabruf wird für das Konto ein Upgrade durchgeführt. Das MSAL-Ergebnis enthält einen MSAL-kompatiblen Kontobezeichner (identifier), der vom Entwickler verwendet werden kann. Danach sollte nur identifier für Kontosuche mithilfe der folgenden API verwendet werden:

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

Obwohl es möglich ist, ADALs userId für alle Vorgänge in MSAL weiterhin zu verwenden, da userId sie auf UPN basiert, unterliegt es mehreren Einschränkungen, die zu einer schlechten Benutzererfahrung führen. Wenn sich der UPN beispielsweise ändert, muss sich der Benutzer erneut anmelden. Es wird empfohlen, dass alle Apps das nicht anzuzeigende Konto identifier für alle Vorgänge verwenden.

Weitere Informationen zur Migration des Cachezustands.

Änderungen beim Tokenerwerb

MSAL führt einige Änderungen des Tokenakquisitionsaufrufs ein:

• Wie ADAL führt acquireTokenSilent immer zu einer stillen Anforderung.
• Im Gegensatz zu ADAL acquireToken führt dies immer zu Benutzeroberflächen mit Aktionen über die Webansicht oder die Microsoft Authenticator App. Je nach SSO-Status innerhalb von Webview/Microsoft Authenticator wird der Benutzer möglicherweise aufgefordert, seine Anmeldeinformationen einzugeben.
• In ADAL führt acquireToken in Kombination mit AD_PROMPT_AUTO zunächst zu einem automatischen Tokenabruf. Die Benutzeroberfläche wird nur angezeigt, wenn die automatische Anforderung fehlschlägt. In MSAL kann diese Logik erreicht werden, indem zunächst acquireTokenSilent aufgerufen wird und acquireToken nur dann aufgerufen wird, wenn der stille Erwerb fehlschlägt. Auf diese Weise können Entwickler die Benutzeroberfläche anpassen, bevor Sie die interaktive Tokenerfassung starten.

Unterschiede bei der Fehlerbehandlung

MSAL bietet mehr Klarheit zwischen Fehlern, die von Ihrer App behandelt werden können, und denen, die einen Eingriff durch den Benutzer erfordern. Es gibt eine begrenzte Anzahl von Fehlern, die Entwickler behandeln müssen:

• MSALErrorInteractionRequired: Der Benutzer muss eine interaktive Anforderung ausführen. Dies kann aus verschiedenen Gründen verursacht werden, z. B. eine abgelaufene Authentifizierungssitzung, die Richtlinie für bedingten Zugriff hat sich geändert, ein Aktualisierungstoken ist abgelaufen oder wurde widerrufen, es gibt keine gültigen Token im Cache usw.
• MSALErrorServerDeclinedScopes: Die Anforderung wurde nicht vollständig abgeschlossen, und einigen Bereichen wurde kein Zugriff gewährt. Dies kann dazu führen, dass ein Benutzer die Zustimmung zu einem oder mehreren Bereichen zurücknimmt.

Die Behandlung aller anderen Fehler in der MSALError Liste ist optional. Sie können die Informationen in diesen Fehlern verwenden, um die Benutzererfahrung zu verbessern.

Weitere Informationen zur MSAL-Fehlerbehandlung finden Sie unter Behandeln von Ausnahmen und Fehlern mithilfe von MSAL .

Brokerunterstützung

MSAL bietet ab Version 0.3.0 Unterstützung für die vermittelte Authentifizierung mithilfe der Microsoft Authenticator-App. Microsoft Authenticator ermöglicht auch die Unterstützung für Szenarien mit bedingtem Zugriff. Beispiele für Szenarien für bedingten Zugriff sind Gerätecompliancerichtlinien, die erfordern, dass der Benutzer das Gerät über Intune registriert oder sich bei Microsoft Entra ID registriert, um ein Token abzurufen. Und Richtlinien für den bedingten Zugriff (Mobile Application Management, MAM), die einen Nachweis der Compliance erfordern, bevor Ihre App ein Token abrufen kann.

So aktivieren Sie den Broker für Ihre Anwendung:

1. Registrieren Sie ein brokerkompatibles Umleitungs-URI-Format für die Anwendung. Das brokerkompatible Umleitungs-URI-Format ist msauth.<app.bundle.id>://auth. Ersetzen Sie <app.bundle.id> durch die Bundle-ID Ihrer Anwendung. Wenn Sie von ADAL migrieren und Ihre Anwendung bereits brokerfähig war, gibt es nichts Zusätzliches, was Sie tun müssen. Ihr vorheriger Umleitungs-URI ist vollständig mit MSAL kompatibel, sodass Sie mit Schritt 3 fortfahren können.

2. Fügen Sie das Umleitungs-URI-Schema Ihrer Anwendung zu Ihrer Info.plist-Datei hinzu. Für den standardmäßigen MSAL-Umleitungs-URI lautet das Format msauth.<app.bundle.id>. Beispiel:

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

3. Fügen Sie der Info.plist Ihrer App unter "LSApplicationQueriesSchemes" die folgenden Schemas hinzu:

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

4. Fügen Sie Der Datei "AppDelegate.m" Folgendes hinzu, um Rückrufe zu behandeln: 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 erstellen Sie für jeden Mandanten, für den die App Token anfordert, separate Instanzen von ADAuthenticationContext. Dies ist keine Anforderung mehr in MSAL. In MSAL können Sie eine einzelne Instanz von MSALPublicClientApplication erstellen und sie für jede Microsoft Entra-Cloud und Organisation verwenden, indem Sie für die Aufrufe von acquireToken und acquireTokenSilent eine andere Autorisierungsinstanz angeben.

SSO in Partnerschaft mit anderen SDKs

MSAL für iOS kann SSO über einen einheitlichen Cache mit ADAL Objective-C 2.7.x+ erreichen.

SSO wird durch die iOS-Schlüsselbundfreigabe ermöglicht und kann nur für Apps verwendet werden, die über dasselbe Apple Developer-Konto veröffentlicht wurden.

Die Nutzung von SSO mithilfe der iOS-Schlüsselbundfreigabe ist die einzige Möglichkeit, den SSO-Vorgang automatisch auszuführen.

Unter macOS kann MSAL SSO mit anderen auf MSAL für iOS und macOS sowie auf ADAL Objective-C basierenden Anwendungen ermöglichen.

MSAL unter iOS unterstützt auch zwei andere SSO-Typen:

• SSO über den Webbrowser. MSAL für iOS unterstützt ASWebAuthenticationSession, das Single Sign-On (SSO) über Cookies ermöglicht, die von anderen Apps auf dem Gerät und insbesondere dem Safari-Browser gemeinsam genutzt werden.
• SSO über einen Authentifizierungsbroker. Auf einem iOS-Gerät fungiert Microsoft Authenticator als Authentifizierungsbroker. Sie kann Richtlinien für bedingten Zugriff befolgen, z. B. ein kompatibles Gerät anfordern und SSO für registrierte Geräte bereitstellen. MSAL-SDKs ab Version 0.3.0 unterstützen standardmäßig einen Broker.

Intune MAM SDK

Das Intune MAM SDK unterstützt MSAL für iOS ab Version 11.1.2

MSAL und ADAL in derselben App

ADAL, Version 2.7.0 und höher, kann in derselben Anwendung nicht mit MSAL koexistieren. Der Hauptgrund hierfür ist der gemeinsame Gemeinsame Untermodulcode. Da Objective-C keine Namespaces unterstützt, gibt es zwei Instanzen derselben Klasse, wenn Sie ADAL- und MSAL-Frameworks zu Ihrer Anwendung hinzufügen. Es gibt keine Garantie dafür, welche Klasse zur Laufzeit ausgewählt wird. Wenn beide SDKs dieselbe Version der konfliktierenden Klasse verwenden, funktioniert Ihre App möglicherweise noch. Wenn es sich jedoch um eine andere Version handelt, kann ihre App unerwartete Abstürze feststellen, die schwierig zu diagnostizieren sind.

Das Ausführen von ADAL und MSAL in derselben Produktionsanwendung wird nicht unterstützt. Wenn Sie jedoch nur Ihre Benutzer von ADAL Objective-C zu MSAL für iOS und macOS testen und migrieren, können Sie weiterhin ADAL Objective-C 2.6.10 verwenden. Es ist die einzige Version, die mit MSAL in derselben Anwendung funktioniert. Es gibt keine neuen Featureupdates für diese ADAL-Version, daher sollte sie nur für Migrations- und Testzwecke verwendet werden. Ihre App sollte sich langfristig nicht auf ADAL und MSAL-Koexistenz verlassen.

ADAL- und MSAL-Koexistenz in derselben Anwendung werden nicht unterstützt. Die Koexistenz von ADAL und MSAL zwischen mehreren Anwendungen wird vollständig unterstützt.

Praktische Migrationsschritte

Migration der App-Registrierung

Sie müssen Ihre vorhandene Microsoft Entra-Anwendung nicht ändern, um zu MSAL zu wechseln und Microsoft Entra Konten zu aktivieren. Wenn Ihre ADAL-basierte Anwendung jedoch keine vermittelte Authentifizierung unterstützt, müssen Sie einen neuen Umleitungs-URI für die Anwendung registrieren, bevor Sie zu MSAL wechseln können.

Der Umleitungs-URI sollte in diesem Format vorliegen: msauth.<app.bundle.id>://auth. Ersetzen Sie <app.bundle.id> durch die Bundle-ID Ihrer Anwendung. Geben Sie den Umleitungs-URI im Microsoft Entra Admin Center an.

Nur für iOS muss zur Unterstützung der zertifikatbasierten Authentifizierung ein zusätzlicher Umleitungs-URI in Ihrer Anwendung und im Microsoft Entra Admin Center im folgenden Format registriert werden: msauth://code/<broker-redirect-uri-in-url-encoded-form> Beispiel: msauth://code/msauth.com.microsoft.mybundleId%3A%2F%2Fauth

Es wird empfohlen, dass alle Apps beide Umleitungs-URIs registrieren.

Wenn Sie Unterstützung für die inkrementelle Einwilligung hinzufügen möchten, wählen Sie die APIs und Berechtigungen aus, für deren Zugriff Ihre App in Ihrer App-Registrierung auf der Registerkarte API-Berechtigungen konfiguriert ist.

Wenn Sie von ADAL migrieren und sowohl Microsoft Entra ID- als auch MSA-Konten unterstützen möchten, muss Ihre vorhandene Anwendungsregistrierung aktualisiert werden, um beide zu unterstützen. Es wird nicht empfohlen, Ihre vorhandene Produktions-App so zu aktualisieren, dass sie sowohl Microsoft Entra ID als auch MSA sofort unterstützt. Erstellen Sie stattdessen eine weitere Client-ID, die sowohl Microsoft Entra ID als auch MSA für Tests unterstützt, und nachdem Sie überprüft haben, dass alle Szenarien funktionieren, aktualisieren Sie die vorhandene App.

Hinzufügen von MSAL zu Ihrer App

Sie können MSAL SDK mit Ihrem bevorzugten Paketverwaltungstool zu Ihrer App hinzufügen. Ausführliche Anweisungen finden Sie hier.

Aktualisieren der Info.plist-Datei Ihrer App

Fügen Sie nur für iOS das Umleitungs-URI-Schema Ihrer Anwendung zu Ihrer Info.plist-Datei hinzu. Für kompatible ADAL-Broker-Apps sollte es bereits vorhanden sein. Das standardmäßige MSAL-Umleitungs-URI-Schema ist im Format enthalten: msauth.<app.bundle.id>.

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

Fügen Sie die folgenden Schemas in der Info.plist Ihrer App unter LSApplicationQueriesSchemes hinzu.

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

Aktualisieren des AppDelegate-Codes

Fügen Sie für iOS nur Folgendes zur Datei "AppDelegate.m" hinzu:

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

Wenn Sie Xcode 11 verwenden, sollten Sie stattdessen MSAL-Rückruf in die SceneDelegate Datei einfügen. Wenn Sie zur Erzielung von Kompatibilität mit älteren iOS-Versionen sowohl „UISceneDelegate“ als auch „UIApplicationDelegate“ unterstützen, muss der MSAL-Rückruf in beide Dateien eingefügt werden.

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

Auf diese Weise kann MSAL Antworten vom Broker und der Webkomponente verarbeiten. Dies war in ADAL nicht erforderlich, da für die App-Delegatmethoden automatisch ein Swizzling ausgeführt wurde. Das manuelle Hinzufügen ist weniger fehleranfällig und bietet der Anwendung mehr Kontrolle.

Token-Zwischenspeicherung aktivieren

Standardmäßig speichert MSAL die Token Ihrer App im iOS- oder macOS-Schlüsselbund zwischen.

So aktivieren Sie die Tokenzwischenspeicherung:

1. Sicherstellen, dass Ihre Anwendung ordnungsgemäß signiert ist
2. Wechseln Sie zu den Projekteinstellungen in Xcode >zur Registerkarte „Funktionen“>Aktivieren Sie die Schlüsselbundfreigabe
3. Klicken Sie auf + und geben Sie den folgenden Schlüsselbundgruppen-Eintrag ein: 3.a Für iOS geben Sie com.microsoft.adalcache ein. 3.b Für macOS geben Sie com.microsoft.identity.universalstorage ein.

Erstellen Sie MSALPublicClientApplication und wechseln Sie zu den zugehörigen acquireToken- und acquireTokeSilent-Aufrufen.

Sie können mit folgendem Code erstellen MSALPublicClientApplication :

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
}

Rufen Sie dann die Kontoverwaltungs-API auf, um festzustellen, ob Konten im Cache vorhanden sind:

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
}

oder lesen Sie alle Konten:

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
}

Wenn ein Konto gefunden wird, rufen Sie die MSAL-API acquireTokenSilent auf:

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

Nächste Schritte

Weitere Informationen zu Authentifizierungsflüssen und Anwendungsszenarien