Toepassingstypen voor het Microsoft-identiteitsplatform

De Microsoft identity platform ondersteunt verificatie voor diverse moderne app-architecturen, allemaal op basis van industriestandaard protocollen OAuth 2.0 of OpenID Verbinding maken. In dit artikel worden de typen apps beschreven die u kunt bouwen met behulp van Microsoft identity platform, ongeacht de taal of het platform van uw voorkeur. De informatie is ontworpen om u inzicht te geven in scenario's op hoog niveau voordat u met de code in de toepassingsscenario's aan de slag gaat.

De basisbeginselen

U moet elke app registreren die gebruikmaakt van de Microsoft identity platform in de Azure Portal App-registraties. Het app-registratieproces verzamelt en wijst deze waarden voor uw app toe:

  • Een toepassings-id (client) die uw app uniek identificeert
  • Een omleidings-URI die u kunt gebruiken om antwoorden terug te sturen naar uw app
  • Enkele andere scenariospecifieke waarden, zoals ondersteunde accounttypen

Meer informatie over het registreren van een app.

Nadat de app is geregistreerd, communiceert de app met de Microsoft identity platform door aanvragen naar het eindpunt te verzenden. We bieden opensource-frameworks en bibliotheken die de details van deze aanvragen verwerken. U hebt ook de mogelijkheid om de verificatielogica zelf te implementeren door aanvragen te maken voor deze eindpunten:

https://login.microsoftonline.com/common/oauth2/v2.0/authorize
https://login.microsoftonline.com/common/oauth2/v2.0/token

Apps met één pagina (JavaScript)

Veel moderne apps hebben een front-end van één pagina die voornamelijk in JavaScript is geschreven, vaak met een framework zoals Angular, React of Vue. De Microsoft identity platform ondersteunt deze apps met behulp van het OpenID-Verbinding maken-protocol voor verificatie en een impliciete OAuth 2.0-toekenningsstroom of de recentere OAuth 2.0-autorisatiecode + PKCE-stroom voor autorisatie (zie hieronder).

In het onderstaande stroomdiagram ziet u de OAuth 2.0-autorisatiecodetoekenningen (met details over PKCE weggelaten), waarbij de app een code ontvangt van het Microsoft identity platform-eindpunt authorize en deze inwisselt voor een toegangstoken en een vernieuwingstoken met behulp van webaanvragen tussen sites. Het toegangstoken verloopt elke 24 uur en de app moet een andere code aanvragen met behulp van het vernieuwingstoken. Naast het toegangstoken wordt een id_token aanvraag die de aangemelde gebruiker voor de clienttoepassing vertegenwoordigt doorgaans ook aangevraagd via dezelfde stroom en/of een afzonderlijke OpenID-Verbinding maken aanvraag (hier niet weergegeven).

Diagram showing the OAuth 2 authorization code flow between a single-page app and the security token service endpoint.

Als u dit scenario in actie wilt zien, bekijkt u de zelfstudie: Gebruikers aanmelden en de Microsoft Graph API aanroepen vanuit een JavaScript-BEVEILIGD-WACHTWOORDVERIFICATIE met behulp van de verificatiecodestroom.

Autorisatiecodestroom versus impliciete stroom

Voor de meeste geschiedenis van OAuth 2.0 was de impliciete stroom de aanbevolen manier om apps met één pagina te bouwen. Met het verwijderen van cookies van derden en meer aandacht besteed aan beveiligingsproblemen rond de impliciete stroom, zijn we verplaatst naar de autorisatiecodestroom voor apps met één pagina.

Om ervoor te zorgen dat uw app compatibel is in Safari en andere privacybewuste browsers, wordt het gebruik van de impliciete stroom niet meer aanbevolen en wordt in plaats daarvan de autorisatiecodestroom aanbevolen.

Web-apps

Voor web-apps (.NET, PHP, Java, Ruby, Python, Node) waartoe de gebruiker toegang heeft via een browser, kunt u OpenID-Verbinding maken gebruiken voor gebruikersaanmelding. In OpenID Verbinding maken ontvangt de web-app een id-token. Een id-token is een beveiligingstoken waarmee de identiteit van de gebruiker wordt geverifieerd en informatie over de gebruiker wordt verstrekt in de vorm van claims:

// Partial raw ID token
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtyaU1QZG1Cd...

// Partial content of a decoded ID token
{
    "name": "John Smith",
    "email": "john.smith@gmail.com",
    "oid": "d9674823-dffc-4e3f-a6eb-62fe4bd48a58"
    ...
}

Meer informatie over verschillende typen tokens die in de Microsoft identity platform worden gebruikt, zijn beschikbaar in de verwijzing naar het toegangstoken en id_token verwijzing

In webserver-apps voert de aanmeldingsverificatiestroom deze stappen op hoog niveau uit:

Shows the web app authentication flow

U kunt de identiteit van de gebruiker controleren door het id-token te valideren met een openbare ondertekeningssleutel die wordt ontvangen van de Microsoft identity platform. Er wordt een sessiecooky ingesteld, die kan worden gebruikt om de gebruiker op volgende paginaaanvragen te identificeren.

Als u dit scenario in actie wilt zien, probeert u de codevoorbeelden in de web-app die zich aanmeldt bij het gebruikersscenario.

Naast eenvoudige aanmelding moet een webserver-app mogelijk toegang krijgen tot een andere webservice, zoals een REST API. In dit geval maakt de webserver-app gebruik van een gecombineerde OpenID-Verbinding maken- en OAuth 2.0-stroom met behulp van de OAuth 2.0-autorisatiecodestroom. Lees voor meer informatie over dit scenario hoe u aan de slag gaat met web-apps en web-API's.

Web-API's

U kunt de Microsoft identity platform gebruiken om webservices te beveiligen, zoals de RESTful-web-API van uw app. Web-API's kunnen worden geïmplementeerd in tal van platforms en talen. Ze kunnen ook worden geïmplementeerd met behulp van HTTP-triggers in Azure Functions. In plaats van id-tokens en sessiecookies gebruikt een web-API een OAuth 2.0-toegangstoken om de gegevens te beveiligen en binnenkomende aanvragen te verifiëren. De aanroeper van een web-API voegt als volgt een toegangstoken toe aan de autorisatieheader van een HTTP-aanvraag:

GET /api/items HTTP/1.1
Host: www.mywebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6...
Accept: application/json
...

De web-API gebruikt het toegangstoken om de identiteit van de API-aanroeper te verifiëren en om informatie over de aanroeper te extraheren uit claims die zijn gecodeerd in het toegangstoken. Meer informatie over verschillende typen tokens die in de Microsoft identity platform worden gebruikt, zijn beschikbaar in de verwijzing naar het toegangstoken en id_token verwijzing.

Met een web-API kunnen gebruikers zich aanmelden of zich afmelden voor specifieke functionaliteit of gegevens door machtigingen weer te geven, ook wel bereiken genoemd. Voor een aanroepende app om machtigingen voor een bereik te verkrijgen, moet de gebruiker toestemming geven voor het bereik tijdens een stroom. De Microsoft identity platform vraagt de gebruiker om toestemming en registreert vervolgens machtigingen in alle toegangstokens die de web-API ontvangt. De web-API valideert de toegangstokens die worden ontvangen voor elke aanroep en voert autorisatiecontroles uit.

Een web-API kan toegangstokens ontvangen van alle typen apps, waaronder webserver-apps, desktop- en mobiele apps, apps met één pagina, daemons aan de serverzijde en zelfs andere web-API's. De stroom op hoog niveau voor een web-API ziet er als volgt uit:

Shows the web API authentication flow

Als u wilt weten hoe u een web-API beveiligt met behulp van OAuth2-toegangstokens, bekijkt u de voorbeelden van web-API-code in het beveiligde web-API-scenario.

In veel gevallen moeten web-API's ook uitgaande aanvragen verzenden naar andere downstream web-API's die worden beveiligd door Microsoft identity platform. Om dit te doen, kunnen web-API's profiteren van de On-Behalf-Of-stroom, waardoor de web-API een binnenkomend toegangstoken kan uitwisselen voor gebruik in uitgaande aanvragen. Zie de Microsoft identity platform en OAuth 2.0 On-Behalf-Of-stroom voor meer informatie.

Mobiele en systeemeigen apps

Door het apparaat geïnstalleerde apps, zoals mobiele en desktop-apps, moeten vaak toegang hebben tot back-endservices of web-API's die gegevens opslaan en functies uitvoeren namens een gebruiker. Deze apps kunnen aanmeldings- en autorisatie toevoegen aan back-endservices met behulp van de OAuth 2.0-autorisatiecodestroom.

In deze stroom ontvangt de app een autorisatiecode van de Microsoft identity platform wanneer de gebruiker zich aanmeldt. De autorisatiecode vertegenwoordigt de machtiging van de app om back-endservices aan te roepen namens de gebruiker die is aangemeld. De app kan de autorisatiecode op de achtergrond uitwisselen voor een OAuth 2.0-toegangstoken en een vernieuwingstoken. De app kan het toegangstoken gebruiken om te verifiëren bij web-API's in HTTP-aanvragen en het vernieuwingstoken gebruiken om nieuwe toegangstokens op te halen wanneer oudere toegangstokens verlopen.

Shows the native app authentication flow

Notitie

Als de toepassing gebruikmaakt van de standaardsysteemwebweergave, controleert u de informatie over de functionaliteit 'Mijn aanmelding bevestigen' en foutcode AADSTS50199 in Azure AD-verificatie- en autorisatiefoutcodes.

Daemons en apps aan de serverzijde

Apps met langlopende processen of die werken zonder interactie met een gebruiker, hebben ook een manier nodig om toegang te krijgen tot beveiligde resources, zoals web-API's. Deze apps kunnen tokens verifiëren en ophalen met behulp van de identiteit van de app, in plaats van de gedelegeerde identiteit van een gebruiker, met de OAuth 2.0-clientreferentiestroom. U kunt de identiteit van de app bewijzen met behulp van een clientgeheim of certificaat. Zie de .NET Core daemon-consoletoepassing met behulp van Microsoft identity platform voor meer informatie.

In deze stroom communiceert de app rechtstreeks met het /token eindpunt om toegang te krijgen:

Shows the daemon app authentication flow

Als u een daemon-app wilt maken, raadpleegt u de documentatie over clientreferenties of probeert u een .NET-voorbeeld-app.

Volgende stappen

Nu u bekend bent met de typen toepassingen die door de Microsoft identity platform worden ondersteund, vindt u meer informatie over OAuth 2.0 en OpenID Verbinding maken om inzicht te krijgen in de protocolonderdelen die worden gebruikt door de verschillende scenario's.