Verificatie en autorisatie in Azure App Service voor mobiele apps

  • Artikel

In dit artikel wordt beschreven hoe verificatie en autorisatie werkt bij het ontwikkelen van systeemeigen mobiele apps met een App Service-back-end. App Service biedt geïntegreerde verificatie en autorisatie, zodat uw mobiele apps gebruikers kunnen aanmelden zonder code in App Service te wijzigen. Het biedt een eenvoudige manier om uw toepassing te beveiligen en te werken met gegevens per gebruiker.

Waarschuwing

In dit artikel wordt v4.2.0 van de Sdk voor de Azure Mobile Apps-client behandeld. De huidige release maakt gebruik van een nieuw verificatiemechanisme en biedt geen ondersteuning voor Azure-app serviceverificatie en autorisatie op dezelfde manier.

Zie Verificatie en autorisatie in Azure-app Service voor meer informatie over de werking van verificatie en autorisatie in App Service.

Verificatie met provider-SDK

Nadat alles is geconfigureerd in App Service, kunt u mobiele clients wijzigen om u aan te melden met App Service. Er zijn hier twee benaderingen:

  • Gebruik een SDK die een bepaalde id-provider publiceert om identiteit vast te stellen en vervolgens toegang te krijgen tot App Service.
  • Gebruik één regel code, zodat de SDK voor de Mobile Apps-client gebruikers kan aanmelden.

Tip

De meeste toepassingen moeten een provider-SDK gebruiken om een consistentere ervaring te krijgen wanneer gebruikers zich aanmelden, om ondersteuning voor tokenvernieuwing te gebruiken en om andere voordelen te krijgen die de provider opgeeft.

Wanneer u een provider-SDK gebruikt, kunnen gebruikers zich aanmelden bij een ervaring die nauwer kan worden geïntegreerd met het besturingssysteem waarop de app wordt uitgevoerd. Deze methode biedt u ook een providertoken en enkele gebruikersgegevens op de client, waardoor het veel eenvoudiger is om graph-API's te gebruiken en de gebruikerservaring aan te passen. Deze methode wordt de 'clientstroom' of 'clientgestuurde stroom' genoemd, omdat code op de client gebruikers aanmeldt.

Nadat een providertoken is verkregen, moet het worden verzonden naar App Service voor validatie. Azure-app Service valideert het token. De service maakt vervolgens een nieuw token voor de client. De Mobile Apps-client-SDK bevat helpermethoden voor het beheren van deze exchange en het token automatisch koppelen aan alle aanvragen aan de back-end van de toepassing. U kunt ook een verwijzing naar het providertoken behouden.

Notitie

Sommige platforms, zoals Windows (WPF), werken alleen met een clientgestuurde stroom. Anderen werken net zo goed met zowel de server- als de clientstroom. Als het platform alleen werkt met clientgestuurde stroom, wordt dit weergegeven in de snelstartgids.

Zie de App Service-verificatiestroom voor meer informatie over de verificatiestroom.

Verificatie zonder provider-SDK

Als u geen provider-SDK wilt instellen, kunt u toestaan dat de Azure-app Service de aanmelding voor u afhandelt. De Sdk van de Azure Mobile Apps-client opent een webweergave naar de provider van uw keuze en meldt u zich aan bij de gebruiker. Deze methode wordt de 'serverstroom' of 'servergestuurde stroom' genoemd, omdat de server het proces beheert waarmee gebruikers worden aangemeld. De client-SDK ontvangt nooit het providertoken.

Een token verzenden vanuit de clientgestuurde stroom

Wanneer u de clientgestuurde stroom gebruikt, moet u eerst de relevante informatie verkrijgen die Azure-app Service nodig heeft om het token te valideren. In de meeste gevallen is het token een toegangstoken. Raadpleeg de Azure-app Service-documentatie voor meer informatie.

Vervolgens kunt u het juiste JSON-object bouwen. Als u bijvoorbeeld MSAL gebruikt om een clientgestuurde stroom uit te voeren op .NET in een WPF-toepassing, kunt u de volgende code gebruiken:

var requestBody = new JObject(new JProperty("access_token", authResult.AccessToken));
var userInfo = await mobileClient.login("aad", requestBody);

De aanvraagbody moet voldoen aan de verwachtingen zoals uiteengezet in de documentatie.