Toepassingen migreren naar MSAL voor iOS en macOS

De Azure Active Directory Authentication Library (ADAL Objective-C) is gemaakt om te werken met Microsoft Entra accounts via het v1.0-eindpunt.

De Microsoft Authentication Library voor iOS en macOS (MSAL) zijn gebouwd om te werken met alle Microsoft identiteiten, zoals Microsoft Entra accounts, persoonlijke Microsoft-accounts en Azure AD B2C-accounts via de Microsoft identity platform (voorheen het Azure AD v2.0-eindpunt).

De Microsoft identity platform heeft enkele belangrijke verschillen met Azure AD v1.0. In dit artikel worden deze verschillen beschreven en vindt u richtlijnen voor het migreren van een app van ADAL naar MSAL.

Verschillen in mogelijkheden voor ADAL- en MSAL-apps

Wie kan zich aanmelden

  • ADAL ondersteunt alleen werk- en schoolaccounts, ook wel bekend als Microsoft Entra accounts.
  • MSAL ondersteunt persoonlijke Microsoft-accounts (MSA-accounts), zoals Hotmail.com, Outlook.com en Live.com.
  • MSAL ondersteunt werk- en schoolaccounts en Azure AD B2C-accounts.

Naleving van standaarden

  • De Microsoft identity platform volgt de OAuth 2.0- en OpenId Connect-standaarden.
  • Met de Microsoft identity platform kunt u dynamisch machtigingen aanvragen. Apps kunnen alleen naar behoefte om machtigingen vragen en meer aanvragen naarmate de app ze nodig heeft. Zie machtigingen en toestemming voor meer informatie.

Verschillen in ADAL- en MSAL-bibliotheken

De openbare MSAL-API weerspiegelt enkele belangrijke verschillen tussen Azure AD v1.0 en de Microsoft identity platform.

MSALPublicClientApplication in plaats van ADAuthenticationContext

ADAuthenticationContext is het eerste object dat een ADAL-app maakt. Het vertegenwoordigt een instantiëring van ADAL. Apps maken voor elke combinatie van Microsoft Entra-cloud en tenant (autoriteit) een nieuw exemplaar van ADAuthenticationContext. ADAuthenticationContext Hetzelfde kan worden gebruikt om tokens op te halen voor meerdere openbare clienttoepassingen.

In MSAL verloopt de belangrijkste interactie via een MSALPublicClientApplication-object, dat is gebaseerd op OAuth 2.0-openbare clienttoepassing. Eén exemplaar van MSALPublicClientApplication kan worden gebruikt om te communiceren met meerdere Microsoft Entra clouds en tenants, zonder dat u voor elke instantie een nieuw exemplaar hoeft te maken. Voor de meeste apps is één MSALPublicClientApplication exemplaar voldoende.

Scopes in plaats van resources

In ADAL moest een app een resource-id opgeven, zoals https://graph.microsoft.com, om tokens te verkrijgen van het Azure AD v1.0-eindpunt. Een resource kan in het app-manifest een aantal scopes definiëren, of oAuth2Permissions, die door de resource worden herkend. Hierdoor konden client-apps tokens aanvragen voor die resource voor een bepaalde set machtigingen die vooraf tijdens de app-registratie zijn gedefinieerd.

In MSAL bieden apps, in plaats van één resource-id, een set scopes bij elke aanvraag. Een scope is een resource-id gevolgd door een machtigingsnaam in de vorm resource/machtiging. Bijvoorbeeld: https://graph.microsoft.com/user.read

Er zijn twee manieren om scopes op te geven in MSAL:

  • Geef een lijst op met alle machtigingen die uw apps nodig hebben. Voorbeeld:

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

    In dit geval vraagt de app de directory.read en directory.write machtigingen aan. De gebruiker wordt gevraagd om toestemming te geven voor deze machtigingen als hij of zij nog niet eerder toestemming heeft gegeven voor deze app. De toepassing kan ook aanvullende machtigingen krijgen waarvoor de gebruiker al toestemming heeft gegeven voor de toepassing. De gebruiker wordt alleen gevraagd om toestemming te geven voor nieuwe machtigingen of machtigingen die niet zijn verleend.

  • Het /.default bereik.

Dit is het ingebouwde bereik voor elke toepassing. Deze verwijst naar de statische lijst met machtigingen die zijn geconfigureerd toen de toepassing werd geregistreerd. Het gedrag is vergelijkbaar met die van resource. Dit kan nuttig zijn bij het migreren om ervoor te zorgen dat een vergelijkbare set scopes en de gebruikerservaring behouden blijft.

Als u het bereik /.default wilt gebruiken, voegt u /.default toe aan de resource-id. Bijvoorbeeld: https://graph.microsoft.com/.default. Als uw resource eindigt op een slash (/), moet u nog steeds toevoegen /.default, inclusief de voorloopslash, wat resulteert in een bereik dat een dubbele slash (//) bevat.

U kunt meer informatie lezen over het gebruik van de scope "/.default" in machtigingen en scopes.

Verschillende webweergavetypen en -browsers ondersteunen

ADAL ondersteunt alleen UIWebView/WKWebView voor iOS en WebView voor macOS. MSAL voor iOS biedt ondersteuning voor meer opties voor het weergeven van webinhoud bij het aanvragen van een autorisatiecode en ondersteunt niet meer UIWebView; die de gebruikerservaring en beveiliging kan verbeteren.

MSAL op iOS maakt standaard gebruik van ASWebAuthenticationSession. Dit is het webonderdeel dat Apple aanbeveelt voor verificatie op iOS 12+-apparaten. Het biedt voordelen voor eenmalige aanmelding (SSO) via het delen van cookies tussen apps en de Safari-browser.

U kunt ervoor kiezen om een ander webonderdeel te gebruiken, afhankelijk van de app-vereisten en de gewenste eindgebruikerservaring. Zie ondersteunde typen webweergaven voor meer opties.

Wanneer u migreert van ADAL naar MSAL, WKWebView biedt de gebruikerservaring die het meest lijkt op ADAL op iOS en macOS. We raden u aan om, indien mogelijk, naar iOS te ASWebAuthenticationSession migreren. Voor macOS raden we u aan om te gebruiken WKWebView.

Verschillen tussen accountbeheer-API's

Wanneer u de ADAL-methoden acquireToken() of acquireTokenSilent() aanroept, ontvangt u een ADUserInformation-object dat een lijst met claims bevat uit de id_token die het account vertegenwoordigt dat wordt geauthenticeerd. Bovendien retourneert ADUserInformation een userId op basis van de upn claim. Na de initiële interactieve tokenverwerving verwacht ADAL dat de ontwikkelaar userId opgeeft bij alle stille aanroepen.

ADAL biedt geen API voor het ophalen van bekende gebruikersidentiteiten. Het is afhankelijk van de app om deze accounts op te slaan en te beheren.

MSAL biedt een set API's om alle accounts weer te geven die bekend zijn bij MSAL zonder een token te hoeven verkrijgen.

Net als ADAL geeft MSAL accountgegevens terug met een lijst met claims van de id_token. Het maakt deel uit van het MSALAccount object in het MSALResult object.

MSAL biedt een set API's voor het verwijderen van accounts, waardoor de verwijderde accounts niet toegankelijk zijn voor de app. Nadat het account is verwijderd, wordt de gebruiker bij latere aanroepen voor tokenverwerving gevraagd om interactief een token op te halen. Accountverwijdering is alleen van toepassing op de clienttoepassing die deze heeft gestart en verwijdert het account niet uit de andere apps die op het apparaat of in de systeembrowser worden uitgevoerd. Dit zorgt ervoor dat de gebruiker nog steeds een SSO-ervaring op het apparaat heeft, zelfs na het afmelden bij een afzonderlijke app.

Daarnaast retourneert MSAL ook een account-id die later kan worden gebruikt om zonder tussenkomst van de gebruiker een token aan te vragen. De account-id (toegankelijk via identifier de eigenschap in het MSALAccount object) kan echter niet worden weergegeven en u kunt niet aannemen in welke indeling deze zich bevindt en niet moet u proberen het te interpreteren of te parseren.

De accountcache migreren

Wanneer u vanaf ADAL migreert, slaan apps doorgaans ADAL's userId op, die niet beschikken over de identifier die vereist is voor MSAL. Als eenmalige migratiestap kan een app een query uitvoeren op een MSAL-account met behulp van de userId van ADAL met de volgende API:

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

Deze API leest zowel MSAL's als de cache van ADAL om het account te vinden op basis van ADAL userId (UPN).

Als het account wordt gevonden, moet de ontwikkelaar dat account gebruiken om stilzwijgend een token te verkrijgen. De eerste stille tokenverwerving werkt het account effectief bij en de ontwikkelaar krijgt een msAL-compatibele account-id in het MSAL-resultaat (identifier). Daarna mag alleen identifier worden gebruikt voor accountzoekacties met behulp van de volgende API:

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

Hoewel het mogelijk is om ADAL's userId te blijven gebruiken voor alle bewerkingen in MSAL, omdat userId deze is gebaseerd op UPN, is het onderhevig aan meerdere beperkingen die resulteren in een slechte gebruikerservaring. Als de UPN bijvoorbeeld wordt gewijzigd, moet de gebruiker zich opnieuw aanmelden. We raden aan dat alle apps voor alle bewerkingen het account identifier gebruiken dat niet kan worden weergegeven.

Lees meer over de migratie van cachestatussen.

Wijzigingen in het verkrijgen van tokens

MSAL brengt enkele wijzigingen in aanroepen voor tokenverkrijging met zich mee:

  • Net als ADAL acquireTokenSilent resulteert dit altijd in een stille aanvraag.
  • In tegenstelling tot ADAL resulteert acquireToken dit altijd in de gebruikersinterface die kan worden uitgevoerd via de webweergave of de Microsoft Authenticator-app. Afhankelijk van de SSO-status binnen webview/Microsoft Authenticator, kan de gebruiker worden gevraagd hun referenties in te voeren.
  • In ADAL probeert acquireToken met AD_PROMPT_AUTO eerst het token op de achtergrond op te halen en toont alleen de gebruikersinterface als de stille aanvraag mislukt. In MSAL kan deze logica worden bereikt door eerst aan te roepen acquireTokenSilent en alleen aan te roepen acquireToken als stille overname mislukt. Hierdoor kunnen ontwikkelaars de gebruikerservaring aanpassen voordat ze interactieve tokenverzameling starten.

Verschillen in foutafhandeling

MSAL biedt meer duidelijkheid tussen fouten die kunnen worden verwerkt door uw app en fouten waarvoor tussenkomst van de gebruiker is vereist. Er zijn een beperkt aantal fouten dat de ontwikkelaar moet afhandelen:

  • MSALErrorInteractionRequired: De gebruiker moet een interactieve aanvraag doen. Dit kan worden veroorzaakt door verschillende redenen, zoals een verlopen verificatiesessie, beleid voor voorwaardelijke toegang is gewijzigd, een vernieuwingstoken is verlopen of is ingetrokken, er zijn geen geldige tokens in de cache, enzovoort.
  • MSALErrorServerDeclinedScopes: Het verzoek is niet volledig afgerond en voor sommige scopes is geen toegang verleend. Dit kan worden veroorzaakt doordat een gebruiker toestemming voor een of meer machtigingen weigert.

Het afhandelen van alle andere fouten in de MSALError lijst is optioneel. U kunt de informatie in deze fouten gebruiken om de gebruikerservaring te verbeteren.

Zie Uitzonderingen en fouten verwerken met BEHULP van MSAL voor meer informatie over MSAL-foutafhandeling.

Broker-ondersteuning

MSAL biedt vanaf versie 0.3.0 ondersteuning voor brokered-verificatie met behulp van de Microsoft Authenticator-app. Microsoft Authenticator biedt ook ondersteuning voor scenario's voor voorwaardelijke toegang. Voorbeelden van scenario's voor voorwaardelijke toegang zijn nalevingsbeleid voor apparaten waarvoor de gebruiker het apparaat moet registreren via Intune of zich moet registreren bij Microsoft Entra ID om een token op te halen. En mam-beleid (Mobile Application Management) voor voorwaardelijke toegang, waarvoor bewijs van naleving is vereist voordat uw app een token kan ophalen.

Broker inschakelen voor uw toepassing:

  1. Registreer een broker-compatibele omleidings-URI-indeling voor de toepassing. De indeling van de broker-compatibele omleidings-URI is msauth.<app.bundle.id>://auth. Vervang door <app.bundle.id> de bundel-id van uw toepassing. Als u migreert van ADAL en uw toepassing al in staat was om broker te gebruiken, hoeft u niets extra te doen. Uw vorige omleidings-URI is volledig compatibel met MSAL, zodat u verder kunt gaan met stap 3.

  2. Voeg het omleidings-URI-schema van uw toepassing toe aan het bestand info.plist. Voor de standaard MSAL-omleidings-URI is de notatie msauth.<app.bundle.id>. Voorbeeld:

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

  3. Voeg de volgende schema's toe aan de Info.plist van uw app onder LSApplicationQueriesSchemes:

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

  4. Voeg het volgende toe aan het bestand AppDelegate.m om callbacks te verwerken: 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 maakt u afzonderlijke exemplaren van ADAuthenticationContext voor elke tenant waarvoor de app tokens aanvraagt. Dit is geen vereiste meer in MSAL. In MSAL kunt u één exemplaar van MSALPublicClientApplication maken en dit gebruiken voor elke Microsoft Entra-cloud en -organisatie door een andere authority op te geven voor de aanroepen van acquireToken en acquireTokenSilent.

SSO in combinatie met andere SDK's

MSAL voor iOS kan eenmalig aanmelden realiseren via een gedeelde cache met ADAL Objective-C 2.7.x+.

Single Sign-On (SSO) wordt mogelijk gemaakt via het delen van de iOS-sleutelhanger en is alleen beschikbaar tussen apps die zijn gepubliceerd onder hetzelfde Apple Developer-account.

SSO via het delen van iOS-sleutelhangers is het enige stille SSO-type.

Op macOS kan MSAL eenmalige aanmelding realiseren met andere op MSAL voor iOS en macOS gebaseerde toepassingen en op Objective-C gebaseerde ADAL-toepassingen.

MSAL op iOS ondersteunt ook twee andere typen van SSO:

  • SSO via de webbrowser. MSAL voor iOS ondersteunt ASWebAuthenticationSession, waarmee single sign-on mogelijk is via cookies die worden gedeeld met andere apps op het apparaat en specifiek met de Safari-browser.
  • SSO via een authenticatiebroker. Op een iOS-apparaat fungeert Microsoft Authenticator als verificatiebroker. Het kan Beleid voor voorwaardelijke toegang volgen, zoals dat een compatibel apparaat is vereist, en het biedt SSO voor geregistreerde apparaten. MSAL SDK's vanaf versie 0.3.0 ondersteunen standaard een broker.

Intune MAM SDK

De Intune MAM SDK ondersteunt MSAL voor iOS vanaf versie 11.1.2

MSAL en ADAL in dezelfde app

ADAL versie 2.7.0 en hoger kan niet naast MSAL in dezelfde toepassing bestaan. De belangrijkste reden is vanwege de algemene code van de gedeelde submodule. Omdat Objective-C geen ondersteuning biedt voor naamruimten, zijn er twee exemplaren van dezelfde klasse als u zowel ADAL- als MSAL-frameworks aan uw toepassing toevoegt. Er is geen garantie welke er bij runtime wordt gekozen. Als beide SDK's dezelfde versie van de conflicterende klasse gebruiken, werkt uw app mogelijk nog steeds. Als het echter een andere versie is, kan uw app onverwachte crashes ondervinden die moeilijk te diagnosticeren zijn.

Het uitvoeren van ADAL en MSAL in dezelfde productietoepassing wordt niet ondersteund. Als u echter alleen uw gebruikers test en migreert van ADAL Objective-C naar MSAL voor iOS en macOS, kunt u ADAL blijven gebruiken Objective-C 2.6.10. Dit is de enige versie die werkt met MSAL in dezelfde toepassing. Er zijn geen nieuwe functie-updates voor deze ADAL-versie, dus deze moet alleen worden gebruikt voor migratie- en testdoeleinden. Uw app moet niet afhankelijk zijn van co-existentie van ADAL en MSAL op de lange termijn.

Co-existentie van ADAL en MSAL in dezelfde toepassing wordt niet ondersteund. Co-existentie tussen ADAL en MSAL tussen meerdere toepassingen wordt volledig ondersteund.

Praktische migratiestappen

Migratie van app-registratie

U hoeft uw bestaande Microsoft Entra-toepassing niet te wijzigen om over te schakelen naar MSAL en Microsoft Entra-accounts in te schakelen. Als uw ADAL-toepassing echter geen ondersteuning biedt voor brokered verificatie, moet u een nieuwe omleidings-URI voor de toepassing registreren voordat u kunt overschakelen naar MSAL.

De omleidings-URI moet de volgende indeling hebben: msauth.<app.bundle.id>://auth. Vervang door <app.bundle.id> de bundel-id van uw toepassing. Geef de omleidings-URI op in de Microsoft Entra-beheercentrum.

Alleen voor iOS moet, ter ondersteuning van certificaatgebaseerde verificatie, een extra omleidings-URI worden geregistreerd in uw toepassing en het Microsoft Entra-beheercentrum in de volgende indeling: msauth://code/<broker-redirect-uri-in-url-encoded-form> Bijvoorbeeld: msauth://code/msauth.com.microsoft.mybundleId%3A%2F%2Fauth

We raden alle apps aan beide omleidings-URI's te registreren.

Als u ondersteuning voor incrementele toestemming wilt toevoegen, selecteert u de API's en machtigingen waarvoor uw app is geconfigureerd om toegang aan te vragen in uw app-registratie op het tabblad API-machtigingen .

Als u migreert vanuit ADAL en zowel Microsoft Entra ID- als MSA-accounts wilt ondersteunen, moet uw bestaande toepassingsregistratie worden bijgewerkt ter ondersteuning van beide. We raden u niet aan om uw bestaande productie-app meteen bij te werken zodat deze zowel Microsoft Entra ID als MSA ondersteunt. Maak in plaats daarvan een andere client-id die ondersteuning biedt voor zowel Microsoft Entra ID als MSA voor testen. Nadat u hebt gecontroleerd of alle scenario's werken, werkt u de bestaande app bij.

MSAL toevoegen aan uw app

U kunt MSAL SDK toevoegen aan uw app met behulp van het hulpprogramma voor pakketbeheer van uw voorkeur. Zie hier gedetailleerde instructies.

Het bestand Info.plist van uw app bijwerken

Alleen voor iOS voegt u het omleidings-URI-schema van uw toepassing toe aan uw bestand info.plist. Voor apps die compatibel zijn met ADAL Broker, moet deze er al zijn. Het standaard MSAL-omleidings-URI-schema heeft de volgende indeling: msauth.<app.bundle.id>.

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

Voeg de volgende schema's toe aan de info.plist van uw app onder LSApplicationQueriesSchemes.

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

Uw AppDelegate-code bijwerken

Voeg alleen voor iOS het volgende toe aan uw AppDelegate.m-bestand:

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

Als u Xcode 11 gebruikt, moet u MSAL-callback in plaats daarvan in het SceneDelegate bestand plaatsen. Als u zowel UISceneDelegate als UIApplicationDelegate ondersteunt voor compatibiliteit met oudere iOS, moet MSAL-callback in beide bestanden worden geplaatst.

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

Hierdoor kan MSAL antwoorden van de broker en het webonderdeel verwerken. Dit was niet nodig in ADAL, omdat het automatisch app-delegate-methoden 'swizzelde'. Handmatig toevoegen is minder foutgevoelig en geeft de toepassing meer controle.

Tokencaching inschakelen

MSAL slaat standaard de tokens van uw app op in de iOS- of macOS-sleutelhanger.

Tokencaching inschakelen:

  1. Zorg ervoor dat uw toepassing correct is ondertekend
  2. Ga naar het tabblad >Xcode Project Settings> CapabilitiesEnable Keychain Sharing
  3. Klik + en voer het volgende item onder Keychain Groups in: 3.a Voor iOS voert u com.microsoft.adalcache in 3.b Voor macOS voert u com.microsoft.identity.universalstorage in

MSALPublicClientApplication maken en overschakelen naar de acquireToken en acquireTokeSilent-aanroepen

U kunt MSALPublicClientApplication maken met de volgende code:

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
}

Roep vervolgens de accountbeheer-API aan om te zien of er accounts in de cache zijn:

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
}

of lees alle gebruikersaccounts:

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
}

Als er een account wordt gevonden, roept u de MSAL-API acquireTokenSilent aan:

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

Volgende stappen 

Meer informatie over verificatiestromen en toepassingsscenario's

  • Last updated on