Share via

OAuth 2.0 en OpenID Connect (OIDC) op het Microsoft identity platform

  • Artikel

Kennis over OAuth of OpenID Connect (OIDC) op protocolniveau is niet vereist voor het gebruik van het Microsoft Identity Platform. U zult echter protocoltermen en -concepten tegenkomen wanneer u het identiteitsplatform gebruikt om verificatie toe te voegen aan uw apps. Terwijl u werkt met het Microsoft Entra-beheercentrum, onze documentatie en verificatiebibliotheken, kunt u weten welke basisprincipes u kunnen helpen bij uw integratie en algehele ervaring.

Rollen in OAuth 2.0

Vier partijen zijn over het algemeen betrokken bij een OAuth 2.0- en OpenID Connect-verificatie- en autorisatieuitwisseling. Deze uitwisselingen worden vaak verificatiestromen of verificatiestromen genoemd.

Diagram met de OAuth 2.0-rollen

  • Autorisatieserver : het Microsoft Identity Platform is de autorisatieserver. Ook wel een id-provider of IdP genoemd, verwerkt deze op veilige manier de gegevens van de eindgebruiker, de toegang en de vertrouwensrelaties tussen de partijen in de verificatiestroom. De autorisatieserver geeft de beveiligingstokens uit die uw apps en API's gebruiken voor het verlenen, weigeren of intrekken van toegang tot resources (autorisatie) nadat de gebruiker zich heeft aangemeld (geverifieerd).

  • Client: de client in een OAuth-uitwisseling is de toepassing die toegang tot een beveiligde resource aanvraagt. De client kan een web-app zijn die wordt uitgevoerd op een server, een web-app met één pagina die wordt uitgevoerd in de webbrowser van een gebruiker of een web-API die een andere web-API aanroept. De client wordt vaak aangeduid als clienttoepassing, toepassing of app.

  • Resource-eigenaar : de resource-eigenaar in een verificatiestroom is meestal de toepassingsgebruiker of eindgebruiker in OAuth-terminologie . De eindgebruiker is eigenaar van de beveiligde resource (hun gegevens) waartoe uw app namens hen toegang heeft. De eigenaren van resources kunnen uw app (de client) toegang verlenen of weigeren tot de resources die ze bezitten. Uw app kan bijvoorbeeld de API van een extern systeem aanroepen om het e-mailadres van een gebruiker te verkrijgen uit zijn profiel op dat systeem. Hun profielgegevens zijn een resource waarvan de eindgebruiker eigenaar is op het externe systeem en de eindgebruiker kan de aanvraag van de app om toegang te verkrijgen tot de gegevens ervan, toestaan of weigeren.

  • Resourceserver: de resourceserver treedt op als host of biedt toegang tot de gegevens van een resource-eigenaar. Meestal is de resourceserver een web-API voor een gegevensarchief. De resourceserver vertrouwt op de autorisatieserver voor het uitvoeren van verificatie en gebruikt informatie in bearer-tokens die zijn uitgegeven door de autorisatieserver om toegang tot resources te verlenen of te weigeren.

Tokens

De partijen in een verificatiestroom gebruiken bearer-tokens om een principal (gebruiker, host of service) te garanderen, verifiëren en authenticeren en om toegang tot beveiligde resources te verlenen of te weigeren (autorisatie). Bearer-tokens op het Microsoft identity platform zijn opgemaakt als JSON-webtokens (JWT).

Drie typen bearer-tokens worden door het identiteitsplatform gebruikt als beveiligingstokens:

  • Toegangstokens: toegangstokens worden door de autorisatieserver verstrekt aan de clienttoepassing. De client geeft toegangstokens door aan de resourceserver. Toegangstokens bevatten de machtigingen die door de autorisatieserver werden verleend aan de client.

  • Id-tokens: id-tokens worden door de autorisatieserver verstrekt aan de clienttoepassing. Clients gebruiken id-tokens bij het aanmelden van gebruikers en om basisinformatie over hen te verkrijgen.

  • Vernieuwingstokens: de client gebruikt een vernieuwingstoken of RT om nieuwe toegangs- en id-tokens aan te vragen van de autorisatieserver. Uw code moet vernieuwingstokens en de bijbehorende tekenreeksinhoud behandelen als gevoelige gegevens, omdat ze alleen zijn bedoeld voor gebruik door de autorisatieserver.

App-registratie

Uw client-app heeft een manier nodig om de door het Microsoft identity platform uitgegeven beveiligingstokens te vertrouwen. De eerste stap bij het tot stand brengen van een vertrouwensrelatie is door uw app te registreren. Wanneer u uw app registreert, wijst het identiteitsplatform deze automatisch enkele waarden toe, terwijl andere u configureert op basis van het type toepassing.

Twee van de meestgebruikte instellingen voor app-registratie zijn:

  • Toepassings-id (client): ook wel toepassings-id en client-id genoemd. Deze waarde wordt door het identiteitsplatform aan uw app toegewezen. De client-id identificeert uw app op unieke wijze op het identiteitsplatform en wordt opgenomen in de beveiligingstokens die het platform verstrekt.
  • Omleidings-URI: de autorisatieserver gebruikt een omleidings-URI om de gebruikersagent van de resource-eigenaar (webbrowser, mobiele app) om te leiden naar een andere bestemming nadat de interactie is voltooid. Bijvoorbeeld nadat de eindgebruiker verifieert met de autorisatieserver. Niet alle clienttypen gebruiken omleidings-URI's.

De registratie van uw app bevat ook informatie over de verificatie- en autorisatie-eindpunten die u in uw code zult gebruiken om id- en toegangstokens te verkrijgen.

Eindpunten

Het Microsoft identity platform biedt verificatie- en autorisatieservices aan met implementaties van OAuth 2.0 en OpenID Connect (OIDC) 1.0 conform de standaarden. Standaarden-compatibele autorisatieservers, zoals het identiteitsplatform, bieden een set HTTP-eindpunten voor gebruik door de partijen in een verificatiestroom om de stroom uit te voeren.

De eindpunt-URI's voor uw app worden automatisch gegenereerd wanneer u uw app registreert of configureert. De eindpunten die u in de code van uw app gebruikt, zijn afhankelijk van het type van de toepassing en de identiteiten (accounttypen) die deze moeten ondersteunen.

Twee vaak gebruikte eindpunten zijn het autorisatie-eindpunt en het tokeneindpunt. Hier volgen voorbeelden van de eindpunten authorize en token:

# Authorization endpoint - used by client to obtain authorization from the resource owner.
https://login.microsoftonline.com/<issuer>/oauth2/v2.0/authorize
# Token endpoint - used by client to exchange an authorization grant or refresh token for an access token.
https://login.microsoftonline.com/<issuer>/oauth2/v2.0/token

# NOTE: These are examples. Endpoint URI format may vary based on application type,
#       sign-in audience, and Azure cloud instance (global or national cloud).

#       The {issuer} value in the path of the request can be used to control who can sign into the application. 
#       The allowed values are **common** for both Microsoft accounts and work or school accounts, 
#       **organizations** for work or school accounts only, **consumers** for Microsoft accounts only, 
#       and **tenant identifiers** such as the tenant ID or domain name.

Als u de eindpunten wilt vinden voor een toepassing die u hebt geregistreerd, gaat u in het Microsoft Entra-beheercentrum naar:

Identiteitstoepassingen>> App-registraties>< YOUR-APPLICATION-eindpunten>>

Volgende stappen

Lees vervolgens meer over de OAuth 2.0-verificatiestromen die worden gebruikt door elk toepassingstype en de bibliotheken die u in uw apps kunt gebruiken om ze uit te voeren:

We raden u ten zeerste aan uw eigen bibliotheek of onbewerkte HTTP-aanroepen te maken om verificatiestromen uit te voeren. Een Microsoft Authentication Library is veiliger en eenvoudiger. Als uw scenario echter voorkomt dat u onze bibliotheken gebruikt of als u meer wilt weten over de implementatie van het Microsoft Identity Platform, hebben we protocolreferenties: