Toepassings typen voor het micro soft Identity-platformApplication types for the Microsoft identity platform

Het micro soft Identity-platform ondersteunt verificatie voor een verscheidenheid aan moderne app-architecturen, die allemaal zijn gebaseerd op gestandaardiseerde protocollen OAuth 2,0 of OpenID Connect Connect.The Microsoft identity platform supports authentication for a variety of modern app architectures, all of them based on industry-standard protocols OAuth 2.0 or OpenID Connect. In dit artikel worden de typen apps beschreven die u kunt bouwen met behulp van micro soft Identity platform, ongeacht uw voorkeurs taal of-platform.This article describes the types of apps that you can build by using Microsoft identity platform, regardless of your preferred language or platform. De informatie is ontworpen om u te helpen bij het begrijpen van scenario's met een hoog niveau voordat u aan de slag gaat met de code in de toepassings scenario's.The information is designed to help you understand high-level scenarios before you start working with the code in the application scenarios.

De basisbeginselenThe basics

U moet elke app registreren die gebruikmaakt van het micro soft-identiteits platform in de Azure Portal app-registraties.You must register each app that uses the Microsoft identity platform in the Azure portal App registrations. Het registratie proces van de app verzamelt en wijst deze waarden voor uw app toe:The app registration process collects and assigns these values for your app:

  • Een toepassings-id (client) waarmee uw app op unieke wijze wordt geïdentificeerdAn Application (client) ID that uniquely identifies your app
  • Een omleidings-URI die u kunt gebruiken om antwoorden terug te sturen naar uw appA Redirect URI that you can use to direct responses back to your app
  • Een paar andere scenario-specifieke waarden, zoals ondersteunde account typenA few other scenario-specific values such as supported account types

Meer informatie over hoe u een app kunt registreren.For details, learn how to register an app.

Nadat de app is geregistreerd, communiceert de app met het micro soft-identiteits platform door aanvragen naar het eind punt te verzenden.After the app is registered, the app communicates with the Microsoft identity platform by sending requests to the endpoint. We bieden open-source frameworks en bibliotheken die de details van deze aanvragen verwerken.We provide open-source frameworks and libraries that handle the details of these requests. U hebt ook de optie om de verificatie logica zelf te implementeren door aanvragen voor deze eind punten te maken:You also have the option to implement the authentication logic yourself by creating requests to these endpoints:

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

Apps met één pagina (Java script)Single-page apps (JavaScript)

Veel moderne apps hebben een front-end van de app met één pagina, voornamelijk geschreven in Java script, vaak met een kader als een hoek, reageren of Vue.Many modern apps have a single-page app front end written primarily in JavaScript, often with a framework like Angular, React, or Vue. Het micro soft Identity-platform ondersteunt deze apps door gebruik te maken van het OpenID Connect Connect -protocol voor verificatie en ofwel OAuth 2,0 impliciet Grant flow of de recentere OAuth 2,0-autorisatie code + PKCE-stroom voor autorisatie (zie hieronder).The Microsoft identity platform supports these apps by using the OpenID Connect protocol for authentication and either OAuth 2.0 implicit grant flow or the more recent OAuth 2.0 authorization code + PKCE flow for authorization (see below).

In het onderstaande diagram ziet u de OAuth 2,0-autorisatie code toekenning (met details over PKCE wegge laten), waarbij de app een code van het micro soft Identity platform- authorize eind punt ontvangt en deze opnieuw gebruikt voor tokens en tokens vernieuwt met behulp van cross-site webaanvragen.The flow diagram below demonstrates the OAuth 2.0 authorization code grant (with details around PKCE omitted), where the app receives a code from the Microsoft identity platform authorize endpoint, and redeems it for tokens and refresh tokens using cross-site web requests. Het vernieuwings token verloopt elke 24 uur en de app moet een andere code aanvragen.The refresh token expires every 24 hours, and the app must request another code. Naast het toegangs token wordt een van id_token de aangemelde gebruiker voor de client toepassing doorgaans ook aangevraagd via dezelfde stroom en/of een afzonderlijke OpenID Connect-verbindings aanvraag (hier niet weer gegeven).In addition to the access token, an id_token that represents the signed-in user to the client application is typically also requested through the same flow and/or a separate OpenID Connect request (not shown here).

Diagram van de OAuth 2-autorisatie code stroom tussen een app met één pagina en het eind punt van het beveiligings token service.

Als u dit scenario in actie wilt zien, raadpleegt u de zelf studie: Meld u aan bij gebruikers en roep de Microsoft Graph-API aan vanuit een Java script Spa met behulp van auth code flow.To see this scenario in action, check out the Tutorial: Sign in users and call the Microsoft Graph API from a JavaScript SPA using auth code flow.

Autorisatie code stroom versus impliciete stroomAuthorization code flow vs. implicit flow

Voor de meeste van de geschiedenis van OAuth 2,0 was de impliciete stroom de aanbevolen manier om apps met één pagina te bouwen.For most of the history of OAuth 2.0, the implicit flow was the recommended way to build single-page apps. Als u cookies van derden verwijdert en meer aandacht besteed aan beveiligings problemen rondom de impliciete stroom, zijn we verplaatst naar de autorisatie code stroom voor apps met één pagina.With the removal of third-party cookies and greater attention paid to security concerns around the implicit flow, we've moved to the authorization code flow for single-page apps.

Om ervoor te zorgen dat uw app in Safari en andere privacy bewuste browsers wordt ondersteund, wordt het gebruik van de impliciete stroom niet langer aangeraden en wordt de autorisatie code stroom echter wel aanbevolen.To ensure compatibility of your app in Safari and other privacy-conscious browsers, we no longer recommend use of the implicit flow and instead recommend the authorization code flow.

Web-appsWeb apps

Voor web-apps (.NET, PHP, Java, Ruby, Python, node) die de gebruiker via een browser opent, kunt u OpenID Connect Connect gebruiken voor aanmelding door gebruikers.For web apps (.NET, PHP, Java, Ruby, Python, Node) that the user accesses through a browser, you can use OpenID Connect for user sign-in. In OpenID Connect Connect wordt de web-app een ID-token ontvangen.In OpenID Connect, the web app receives an ID token. Een ID-token is een beveiligings token waarmee de identiteit van de gebruiker wordt geverifieerd en informatie wordt verstrekt over de gebruiker in de vorm van claims:An ID token is a security token that verifies the user's identity and provides information about the user in the form of 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 de verschillende typen tokens die worden gebruikt in het micro soft Identity platform zijn beschikbaar in de naslag informatie voor het toegangs token en het id_tokenFurther details of different types of tokens used in the Microsoft identity platform are available in the access token reference and id_token reference

In web server-apps neemt de aanmeldings verificatie stroom de volgende stappen op hoog niveau:In web server apps, the sign-in authentication flow takes these high-level steps:

Toont de verificatie stroom van de web-app

U kunt de identiteit van de gebruiker controleren door de ID-token te valideren met een open bare handtekening sleutel die wordt ontvangen van het micro soft Identity-platform.You can ensure the user's identity by validating the ID token with a public signing key that is received from the Microsoft identity platform. Er wordt een sessie cookie ingesteld die kan worden gebruikt om de gebruiker te identificeren op volgende pagina-aanvragen.A session cookie is set, which can be used to identify the user on subsequent page requests.

Als u dit scenario in actie wilt zien, probeert u de code voorbeelden in de web-app uit te proberen in het scenario voor gebruikers.To see this scenario in action, try the code samples in the Web app that signs in users scenario.

Naast het gebruik van een eenvoudige aanmelding moet een webserver-app mogelijk toegang hebben tot een andere webservice, zoals een REST API.In addition to simple sign-in, a web server app might need to access another web service, such as a REST API. In dit geval maakt de webserver-app deel uit van een gecombineerde OpenID connect-verbinding en OAuth 2,0-stroom met behulp van de OAuth 2,0-autorisatie code stroom.In this case, the web server app engages in a combined OpenID Connect and OAuth 2.0 flow, by using the OAuth 2.0 authorization code flow. Meer informatie over dit scenario vindt u in aan de slag met web apps en Web-api's.For more information about this scenario, read about getting started with web apps and Web APIs.

Web-API'sWeb APIs

U kunt het micro soft-identiteits platform gebruiken voor het beveiligen van webservices, zoals de REST Web API van uw app.You can use the Microsoft identity platform to secure web services, such as your app's RESTful web API. Web-Api's kunnen worden geïmplementeerd in talloze platforms en talen.Web APIs can be implemented in numerous platforms and languages. Ze kunnen ook worden geïmplementeerd met behulp van HTTP-triggers in Azure Functions.They can also be implemented using HTTP Triggers in Azure Functions. In plaats van ID-tokens en sessie cookies gebruikt een web-API een OAuth 2,0-toegangs token om de gegevens te beveiligen en inkomende aanvragen te verifiëren.Instead of ID tokens and session cookies, a web API uses an OAuth 2.0 access token to secure its data and to authenticate incoming requests. De aanroeper van een web-API voegt een toegangs token toe in de autorisatie-header van een HTTP-aanvraag, zoals:The caller of a web API appends an access token in the authorization header of an HTTP request, like this:

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

De Web-API gebruikt het toegangs token om de identiteit van de API-aanroeper te controleren en om informatie over de aanroeper op te halen uit claims die zijn gecodeerd in het toegangs token.The web API uses the access token to verify the API caller's identity and to extract information about the caller from claims that are encoded in the access token. Meer informatie over de verschillende typen tokens die worden gebruikt in het micro soft Identity platform zijn beschikbaar in de naslag informatie voor het toegangs token en het id_token .Further details of different types of tokens used in the Microsoft identity platform are available in the access token reference and id_token reference.

Een web-API kan gebruikers de bevoegdheid geven om zich aan te melden of om specifieke functionaliteit of gegevens uit te scha kelen door machtigingen (ook wel scopesgenoemd) te bieden.A web API can give users the power to opt in or opt out of specific functionality or data by exposing permissions, also known as scopes. Voor een aanroep-app om machtigingen voor een bereik te verkrijgen, moet de gebruiker toestemming geven voor het bereik tijdens een stroom.For a calling app to acquire permission to a scope, the user must consent to the scope during a flow. Het micro soft Identity-platform vraagt de gebruiker om toestemming en registreert vervolgens machtigingen in alle toegangs tokens die de Web-API ontvangt.The Microsoft identity platform asks the user for permission, and then records permissions in all access tokens that the web API receives. De Web-API valideert de toegangs tokens die op elke aanroep worden ontvangen en voert autorisatie controles uit.The web API validates the access tokens it receives on each call and performs authorization checks.

Een web-API kan toegangs tokens ontvangen van alle typen apps, waaronder web server apps, desktop-en Mobile apps, apps met één pagina, daemons aan server zijde en zelfs andere web-Api's.A web API can receive access tokens from all types of apps, including web server apps, desktop and mobile apps, single-page apps, server-side daemons, and even other web APIs. De stroom op hoog niveau voor een web-API ziet er als volgt uit:The high-level flow for a web API looks like this:

Hiermee wordt de Web-API-verificatie stroom weer gegeven

Als u wilt weten hoe u een web-API kunt beveiligen met behulp van OAuth2-toegangs tokens, raadpleegt u de voor beelden van de Web-API in het scenario voor de beveiligde web-API.To learn how to secure a web API by using OAuth2 access tokens, check out the web API code samples in the protected web API scenario.

In veel gevallen moeten Web-Api's ook uitgaande aanvragen indienen bij andere stroomafwaartse Web-Api's die worden beveiligd door het micro soft Identity-platform.In many cases, web APIs also need to make outbound requests to other downstream web APIs secured by Microsoft identity platform. Om dit te doen, kunnen Web-Api's gebruikmaken van de namen van de stroom, waarmee de Web-API een binnenkomend toegangs token kan uitwisselen voor een ander toegangs token dat in uitgaande aanvragen moet worden gebruikt.To do so, web APIs can take advantage of the On-Behalf-Of flow, which allows the web API to exchange an incoming access token for another access token to be used in outbound requests. Zie voor meer informatie het micro soft Identity-platform en de OAuth 2,0-stroom.For more info, see the Microsoft identity platform and OAuth 2.0 On-Behalf-Of flow.

Mobiele en systeemeigen appsMobile and native apps

Apps die zijn geïnstalleerd op apparaten, zoals mobiele en desktop-apps, hebben vaak toegang tot back-end-services of Web-Api's waarmee gegevens worden opgeslagen en functies kunnen worden uitgevoerd namens een gebruiker.Device-installed apps, such as mobile and desktop apps, often need to access back-end services or web APIs that store data and perform functions on behalf of a user. Deze apps kunnen aanmelding en autorisatie toevoegen aan back-end-services met behulp van de OAuth 2,0-autorisatie code stroom.These apps can add sign-in and authorization to back-end services by using the OAuth 2.0 authorization code flow.

In deze stroom ontvangt de app een autorisatie code van het micro soft Identity-platform wanneer de gebruiker zich aanmeldt.In this flow, the app receives an authorization code from the Microsoft identity platform when the user signs in. De autorisatie code vertegenwoordigt de machtiging van de app voor het aanroepen van back-end-services namens de gebruiker die zich heeft aangemeld.The authorization code represents the app's permission to call back-end services on behalf of the user who is signed in. De app kan de autorisatie code op de achtergrond voor een OAuth 2,0-toegangs token en een vernieuwings token uitwisselen.The app can exchange the authorization code in the background for an OAuth 2.0 access token and a refresh token. De app kan het toegangs token gebruiken om te verifiëren bij Web-Api's in HTTP-aanvragen en het vernieuwings token gebruiken om nieuwe toegangs tokens op te halen wanneer oudere toegangs tokens verlopen.The app can use the access token to authenticate to web APIs in HTTP requests, and use the refresh token to get new access tokens when older access tokens expire.

Toont de systeem eigen app-verificatie stroom

Notitie

Als de toepassing de standaard systeem-Webweergave gebruikt, raadpleegt u de informatie over "bevestig mijn aanmelding" en de fout code AADSTS50199 in Azure AD-verificatie en autorisatie fout codes.If the application uses the default system webview, check the information about "Confirm My Sign-In" functionality and error code AADSTS50199 in Azure AD authentication and authorization error codes.

Daemons en apps aan de server zijdeDaemons and server-side apps

Apps die langlopende processen hebben of die werken zonder interactie met een gebruiker, hebben ook een manier nodig om toegang te krijgen tot beveiligde bronnen, zoals web-Api's.Apps that have long-running processes or that operate without interaction with a user also need a way to access secured resources, such as web APIs. 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-client referenties stroom.These apps can authenticate and get tokens by using the app's identity, rather than a user's delegated identity, with the OAuth 2.0 client credentials flow. U kunt de identiteit van de app bewijzen met behulp van een client geheim of certificaat.You can prove the app's identity using a client secret or certificate. Zie de .net core daemon-console toepassing met micro soft Identity platformvoor meer informatie.For more info, see .NET Core daemon console application using Microsoft identity platform.

In deze stroom communiceert de app rechtstreeks met het /token eind punt om toegang te krijgen:In this flow, the app interacts directly with the /token endpoint to obtain access:

Toont de verificatie stroom van de daemon-app

Als u een daemon-app wilt maken, raadpleegt u de documentatie van client referentiesof probeert u een .net-voorbeeld toepassing.To build a daemon app, see the client credentials documentation, or try a .NET sample app.

Volgende stappenNext steps

Nu u bekend bent met de typen toepassingen die worden ondersteund door het micro soft Identity platform, leest u meer over OAuth 2,0 en OpenID Connect Connect om inzicht te krijgen in de protocol onderdelen die worden gebruikt door de verschillende scenario's.Now that you're familiar with the types of applications supported by the Microsoft identity platform, learn more about OAuth 2.0 and OpenID Connect to gain an understanding of the protocol components used by the different scenarios.