Toegangs tokens van micro soft Identity platformMicrosoft identity platform access tokens

Met toegangs tokens kunnen clients beveiligde web-Api's veilig aanroepen en worden ze door Web-Api's gebruikt om verificatie en autorisatie uit te voeren.Access tokens enable clients to securely call protected web APIs, and are used by web APIs to perform authentication and authorization. Met de OAuth-specificatie zijn toegangs tokens ondoorzichtige teken reeksen zonder een ingestelde indeling-sommige id-providers (id) gebruiken GUID'S, andere gebruiken versleutelde blobs.Per the OAuth specification, access tokens are opaque strings without a set format - some identity providers (IDPs) use GUIDs, others use encrypted blobs. Het micro soft Identity-platform maakt gebruik van verschillende toegangs token indelingen, afhankelijk van de configuratie van de API waarmee het token wordt geaccepteerd.The Microsoft identity platform uses a variety of access token formats depending on the configuration of the API that accepts the token. Aangepaste api's die zijn geregistreerd door ontwikkel aars op het micro soft Identity-platform kunnen kiezen uit twee verschillende indelingen van JSON-webtokens (JWTs), ' v1 ' en ' v2 ', en door micro soft ontwikkelde api's, zoals Microsoft Graph of Api's in azure, hebben extra eigen token indelingen.Custom APIs registered by developers on the Microsoft identity platform can choose from two different formats of JSON Web Tokens (JWTs), called "v1" and "v2", and Microsoft-developed APIs like Microsoft Graph or APIs in Azure have additional proprietary token formats. Deze eigen indelingen kunnen versleutelde tokens, JWTs of speciale JWT-achtige tokens zijn die niet worden gevalideerd.These proprietary formats might be encrypted tokens, JWTs, or special JWT-like tokens that will not validate.

Clients moeten toegangs tokens behandelen als ondoorzichtige teken reeksen, omdat de inhoud van het token alleen bedoeld is voor de bron (de API).Clients must treat access tokens as opaque strings because the contents of the token are intended for the resource (the API) only. Ontwikkel aars kunnen JWTs, alleen voor validatie en fout opsporing, decoderen met behulp van een site zoals JWT.MS.For validation and debugging purposes only, developers can decode JWTs using a site like jwt.ms. Houd er echter rekening mee dat de tokens die u voor een micro soft API ontvangt mogelijk niet altijd een JWT zijn en dat u ze niet altijd kunt decoderen.Be aware, however, that the tokens you receive for a Microsoft API might not always be a JWT, and that you can't always decode them.

Voor meer informatie over de inhoud van het toegangs token moeten clients de token antwoord gegevens gebruiken die worden geretourneerd met het toegangs token voor uw client.For details on what's inside the access token, clients should use the token response data that's returned with the access token to your client. Als uw client een toegangs token aanvraagt, retourneert het micro soft Identity-platform ook meta gegevens over het toegangs token voor het verbruik van uw app.When your client requests an access token, the Microsoft identity platform also returns some metadata about the access token for your app's consumption. Deze informatie omvat de verloop tijd van het toegangs token en de scopes waarvoor deze geldig is.This information includes the expiry time of the access token and the scopes for which it's valid. Met deze gegevens kan uw app intelligente caching van toegangs tokens uitvoeren zonder dat het toegangs token zelf moet worden geparseerd.This data allows your app to do intelligent caching of access tokens without having to parse the access token itself.

Raadpleeg de volgende secties voor meer informatie over hoe uw API de claims in een toegangs token kan valideren en gebruiken.See the following sections to learn how your API can validate and use the claims inside an access token.

Notitie

Alle documentatie op deze pagina, tenzij anders vermeld, is alleen van toepassing op tokens die zijn uitgegeven voor Api's die u hebt geregistreerd.All documentation on this page, except where noted, applies only to tokens issued for APIs you've registered. Het is niet van toepassing op tokens die zijn uitgegeven voor Api's van micro soft en kunnen niet worden gebruikt om te valideren hoe het micro soft Identity-platform tokens uitgeeft voor een API die u maakt.It does not apply to tokens issued for Microsoft-owned APIs, nor can those tokens be used to validate how the Microsoft identity platform will issue tokens for an API you create.

Token indelingen en eigendomToken formats and ownership

v 1.0 en v 2.0v1.0 and v2.0

Er zijn twee versies van toegangs tokens beschikbaar in het micro soft Identity-platform: v 1.0 en v 2.0.There are two versions of access tokens available in the Microsoft identity platform: v1.0 and v2.0. Deze versies bepalen welke claims zich in het token bevinden. Zo zorgt u ervoor dat een web-API kan bepalen hoe hun tokens eruitzien.These versions govern what claims are in the token, ensuring that a web API can control what their tokens look like. Web-Api's hebben een van deze als standaard waarde geselecteerd tijdens registratie-v 1.0 voor Azure AD-Only apps en v 2.0 voor apps die consumenten accounts ondersteunen.Web APIs have one of these selected as a default during registration - v1.0 for Azure AD-only apps, and v2.0 for apps that support consumer accounts. Dit kan worden bestuurd door toepassingen met behulp van de accessTokenAcceptedVersion instelling in het app-manifest, waar null en als 1 resultaat in v 1.0-tokens, en 2 resulteert in v 2.0-tokens.This is controllable by applications using the accessTokenAcceptedVersion setting in the app manifest, where null and 1 result in v1.0 tokens, and 2 results in v2.0 tokens.

Welke app is een token voor?What app is a token "for"?

Er zijn twee partijen betrokken bij een aanvraag voor een toegangs token: de client, die het token aanvraagt en de bron (de API) die het token accepteert wanneer de API wordt aangeroepen.There are two parties involved in an access token request: the client, who requests the token, and the resource (the API) that accepts the token when the API is called. De aud claim in een token geeft aan op welke bron het token is bedoeld (de doel groep).The aud claim in a token indicates the resource the token is intended for (its audience). Clients gebruiken het token, maar moeten deze niet begrijpen of proberen te parseren.Clients use the token but should not understand or attempt to parse it. Resources accepteren het token.Resources accept the token.

Het micro soft Identity-platform ondersteunt het uitgeven van een token versie vanuit elk versie-eind punt, ze zijn niet gerelateerd.The Microsoft identity platform supports issuing any token version from any version endpoint - they are not related. Daarom ontvangt een bron instelling accessTokenAcceptedVersion om aan te geven 2 dat een client die het v 1.0-eind punt aanroept om een token op te halen voor die API een v 2.0-toegangs token zal ontvangen.This is why a resource setting accessTokenAcceptedVersion to 2 means that a client calling the v1.0 endpoint to get a token for that API will receive a v2.0 access token. Resources zijn altijd eigenaar van hun tokens (die met hun aud claim) en zijn de enige toepassingen die hun token details kunnen wijzigen.Resources always own their tokens (those with their aud claim) and are the only applications that can change their token details. Daarom is het wijzigen van de optionele claims van het toegangs token voor uw client geen invloed op het toegangs token dat wordt ontvangen wanneer een token wordt aangevraagd voor user.read , dat eigendom is van de Microsoft Graph bron.This is why changing the access token optional claims for your client does not change the access token received when a token is requested for user.read, which is owned by the Microsoft Graph resource.

Voorbeeld tokensSample tokens

v 1.0 en v 2.0-tokens zien er ongeveer hetzelfde uit en bevatten veel van dezelfde claims.v1.0 and v2.0 tokens look similar and contain many of the same claims. Hier vindt u een voor beeld van elk.An example of each is provided here. Deze voorbeeld tokens worden niet gevalideerd, omdat de sleutels voorafgaand aan de publicatie en persoonlijke gegevens worden verwijderd.These example tokens will not validate, however, as the keys have rotated prior to publication and personal information has been removed from them.

v1.0v1.0

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSIsImtpZCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSJ9.eyJhdWQiOiJlZjFkYTlkNC1mZjc3LTRjM2UtYTAwNS04NDBjM2Y4MzA3NDUiLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC9mYTE1ZDY5Mi1lOWM3LTQ0NjAtYTc0My0yOWYyOTUyMjIyOS8iLCJpYXQiOjE1MzcyMzMxMDYsIm5iZiI6MTUzNzIzMzEwNiwiZXhwIjoxNTM3MjM3MDA2LCJhY3IiOiIxIiwiYWlvIjoiQVhRQWkvOElBQUFBRm0rRS9RVEcrZ0ZuVnhMaldkdzhLKzYxQUdyU091TU1GNmViYU1qN1hPM0libUQzZkdtck95RCtOdlp5R24yVmFUL2tES1h3NE1JaHJnR1ZxNkJuOHdMWG9UMUxrSVorRnpRVmtKUFBMUU9WNEtjWHFTbENWUERTL0RpQ0RnRTIyMlRJbU12V05hRU1hVU9Uc0lHdlRRPT0iLCJhbXIiOlsid2lhIl0sImFwcGlkIjoiNzVkYmU3N2YtMTBhMy00ZTU5LTg1ZmQtOGMxMjc1NDRmMTdjIiwiYXBwaWRhY3IiOiIwIiwiZW1haWwiOiJBYmVMaUBtaWNyb3NvZnQuY29tIiwiZmFtaWx5X25hbWUiOiJMaW5jb2xuIiwiZ2l2ZW5fbmFtZSI6IkFiZSAoTVNGVCkiLCJpZHAiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83MmY5ODhiZi04NmYxLTQxYWYtOTFhYi0yZDdjZDAxMjIyNDcvIiwiaXBhZGRyIjoiMjIyLjIyMi4yMjIuMjIiLCJuYW1lIjoiYWJlbGkiLCJvaWQiOiIwMjIyM2I2Yi1hYTFkLTQyZDQtOWVjMC0xYjJiYjkxOTQ0MzgiLCJyaCI6IkkiLCJzY3AiOiJ1c2VyX2ltcGVyc29uYXRpb24iLCJzdWIiOiJsM19yb0lTUVUyMjJiVUxTOXlpMmswWHBxcE9pTXo1SDNaQUNvMUdlWEEiLCJ0aWQiOiJmYTE1ZDY5Mi1lOWM3LTQ0NjAtYTc0My0yOWYyOTU2ZmQ0MjkiLCJ1bmlxdWVfbmFtZSI6ImFiZWxpQG1pY3Jvc29mdC5jb20iLCJ1dGkiOiJGVnNHeFlYSTMwLVR1aWt1dVVvRkFBIiwidmVyIjoiMS4wIn0.D3H6pMUtQnoJAGq6AHd

Bekijk dit v 1.0-token in JWT.MS.View this v1.0 token in JWT.ms.

v2.0v2.0

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSJ9.eyJhdWQiOiI2ZTc0MTcyYi1iZTU2LTQ4NDMtOWZmNC1lNjZhMzliYjEyZTMiLCJpc3MiOiJodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjQ3L3YyLjAiLCJpYXQiOjE1MzcyMzEwNDgsIm5iZiI6MTUzNzIzMTA0OCwiZXhwIjoxNTM3MjM0OTQ4LCJhaW8iOiJBWFFBaS84SUFBQUF0QWFaTG8zQ2hNaWY2S09udHRSQjdlQnE0L0RjY1F6amNKR3hQWXkvQzNqRGFOR3hYZDZ3TklJVkdSZ2hOUm53SjFsT2NBbk5aY2p2a295ckZ4Q3R0djMzMTQwUmlvT0ZKNGJDQ0dWdW9DYWcxdU9UVDIyMjIyZ0h3TFBZUS91Zjc5UVgrMEtJaWpkcm1wNjlSY3R6bVE9PSIsImF6cCI6IjZlNzQxNzJiLWJlNTYtNDg0My05ZmY0LWU2NmEzOWJiMTJlMyIsImF6cGFjciI6IjAiLCJuYW1lIjoiQWJlIExpbmNvbG4iLCJvaWQiOiI2OTAyMjJiZS1mZjFhLTRkNTYtYWJkMS03ZTRmN2QzOGU0NzQiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJhYmVsaUBtaWNyb3NvZnQuY29tIiwicmgiOiJJIiwic2NwIjoiYWNjZXNzX2FzX3VzZXIiLCJzdWIiOiJIS1pwZmFIeVdhZGVPb3VZbGl0anJJLUtmZlRtMjIyWDVyclYzeERxZktRIiwidGlkIjoiNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjQ3IiwidXRpIjoiZnFpQnFYTFBqMGVRYTgyUy1JWUZBQSIsInZlciI6IjIuMCJ9.pj4N-w_3Us9DrBLfpCt

Bekijk dit v 2.0-token in JWT.MS.View this v2.0 token in JWT.ms.

Claims in toegangs tokensClaims in access tokens

JWTs (JSON-webtokens) zijn onderverdeeld in drie delen:JWTs (JSON Web Tokens) are split into three pieces:

  • Header : bevat informatie over het valideren van het token , inclusief informatie over het type token en hoe deze is ondertekend.Header - Provides information about how to validate the token including information about the type of token and how it was signed.
  • Payload : bevat alle belang rijke gegevens over de gebruiker of app die probeert uw service aan te roepen.Payload - Contains all of the important data about the user or app that is attempting to call your service.
  • Hand tekening : is de grond stof die wordt gebruikt om het token te valideren.Signature - Is the raw material used to validate the token.

Elk onderdeel wordt gescheiden door een punt ( . ) en afzonderlijk base64-gecodeerd.Each piece is separated by a period (.) and separately Base64 encoded.

Claims zijn alleen aanwezig als er een waarde bestaat om deze op te vullen.Claims are present only if a value exists to fill it. Uw app mag geen afhankelijkheid hebben van een claim die aanwezig is.Your app shouldn't take a dependency on a claim being present. Voor beelden zijn onder meer pwd_exp (niet elke Tenant vereist dat wacht woorden verlopen) en family_name (client referentie stromen bestaan uit namens toepassingen die geen namen hebben).Examples include pwd_exp (not every tenant requires passwords to expire) and family_name (client credential flows are on behalf of applications which don't have names). De claims die worden gebruikt voor de validatie van het toegangs token, zijn altijd aanwezig.Claims used for access token validation will always be present.

Sommige claims worden gebruikt voor het beveiligen van Azure AD-tokens in het geval van hergebruik.Some claims are used to help Azure AD secure tokens in case of reuse. Deze zijn gemarkeerd als niet als openbaar verbruik in de beschrijving als ' dekkend '.These are marked as not being for public consumption in the description as "Opaque". Deze claims kunnen al dan niet worden weer gegeven in een token en nieuwe kunnen zonder kennisgeving worden toegevoegd.These claims may or may not appear in a token, and new ones may be added without notice.

Header claimsHeader claims

ClaimClaim IndelingFormat BeschrijvingDescription
typ Teken reeks-altijd "JWT"String - always "JWT" Geeft aan dat het token een JWT-waarde is.Indicates that the token is a JWT.
nonce TekenreeksString Een unieke id die wordt gebruikt voor beveiliging tegen token replay-aanvallen.A unique identifier used to protect against token replay attacks. Uw resource kan deze waarde vastleggen om te beschermen tegen herhalingen.Your resource can record this value to protect against replays.
alg TekenreeksString Hiermee wordt het algoritme aangegeven dat is gebruikt voor het ondertekenen van het token, bijvoorbeeld ' RS256 'Indicates the algorithm that was used to sign the token, for example, "RS256"
kid TekenreeksString Hiermee geeft u de vinger afdruk voor de open bare sleutel die wordt gebruikt om dit token te ondertekenen.Specifies the thumbprint for the public key that's used to sign this token. Verzonden in de toegangs tokens v 1.0 en v 2.0.Emitted in both v1.0 and v2.0 access tokens.
x5t TekenreeksString Werkt hetzelfde (in gebruik en waarde) als kid .Functions the same (in use and value) as kid. x5t is een verouderde claim die alleen wordt verzonden in toegangs tokens v 1.0 voor compatibiliteits doeleinden.x5t is a legacy claim emitted only in v1.0 access tokens for compatibility purposes.

Nettolading claimsPayload claims

ClaimClaim IndelingFormat BeschrijvingDescription
aud Teken reeks, een app-ID-URI of-GUIDString, an App ID URI or GUID Identificeert de beoogde ontvanger van het token.Identifies the intended recipient of the token - its audience. Uw API moet deze waarde valideren en het token afwijzen als de waarde niet overeenkomt.Your API should validate this value and reject the token if the value doesn't match. In v 2.0-tokens is dit altijd de client-ID van de API, terwijl in de v 1.0-tokens de client-ID of de resource-URI in de aanvraag kan worden gebruikt, afhankelijk van hoe de client het token heeft aangevraagd.In v2.0 tokens, this is always the client ID of the API, while in v1.0 tokens it can be the client ID or the resource URI used in the request, depending on how the client requested the token.
iss Teken reeks, een STS-URIString, an STS URI Identificeert de Security Token Service (STS) die het token bouwt en retourneert en de Azure AD-Tenant waarin de gebruiker is geverifieerd.Identifies the security token service (STS) that constructs and returns the token, and the Azure AD tenant in which the user was authenticated. Als het uitgegeven token een v 2.0-token is (Zie de ver claim), wordt de URI beëindigd in /v2.0 .If the token issued is a v2.0 token (see the ver claim), the URI will end in /v2.0. De GUID waarmee wordt aangegeven dat de gebruiker een consumenten gebruiker van een Microsoft-account is 9188040d-6c67-4c5b-b112-36a304b66dad .The GUID that indicates that the user is a consumer user from a Microsoft account is 9188040d-6c67-4c5b-b112-36a304b66dad. Uw app kan gebruikmaken van het GUID-gedeelte van de claim om de set tenants te beperken die zich kunnen aanmelden bij de app, indien van toepassing.Your app can use the GUID portion of the claim to restrict the set of tenants that can sign in to the app, if applicable.
idp Teken reeks, meestal een STS-URIString, usually an STS URI Registreert de identiteitsprovider waarmee het onderwerp van het token is geverifieerd.Records the identity provider that authenticated the subject of the token. Deze waarde is gelijk aan de waarde van de verlener-claim tenzij het gebruikers account zich niet in dezelfde Tenant bevindt als de verlener-gasten, bijvoorbeeld.This value is identical to the value of the Issuer claim unless the user account not in the same tenant as the issuer - guests, for instance. Als de claim niet aanwezig is, betekent dit dat de waarde van iss kan worden gebruikt.If the claim isn't present, it means that the value of iss can be used instead. Voor persoonlijke accounts die worden gebruikt in een organisatie context (bijvoorbeeld een persoonlijk account dat is uitgenodigd voor een Azure AD-Tenant), is de idp claim mogelijk ' Live.com ' of een STS-URI met de Microsoft-account Tenant 9188040d-6c67-4c5b-b112-36a304b66dad .For personal accounts being used in an organizational context (for instance, a personal account invited to an Azure AD tenant), the idp claim may be 'live.com' or an STS URI containing the Microsoft account tenant 9188040d-6c67-4c5b-b112-36a304b66dad.
iat int, een UNIX-time stampint, a UNIX timestamp ' Uitgegeven op ' geeft aan wanneer de authenticatie voor dit token is opgetreden."Issued At" indicates when the authentication for this token occurred.
nbf int, een UNIX-time stampint, a UNIX timestamp De claim ' NBF ' (niet vóór) identificeert de tijd waarna de JWT niet moet worden geaccepteerd voor verwerking.The "nbf" (not before) claim identifies the time before which the JWT must not be accepted for processing.
exp int, een UNIX-time stampint, a UNIX timestamp De claim ' exp ' (verval tijd) identificeert de verval tijd op of waarna de JWT niet moet worden geaccepteerd voor verwerking.The "exp" (expiration time) claim identifies the expiration time on or after which the JWT must not be accepted for processing. Het is belang rijk te weten dat een resource het token vóór deze tijd kan afwijzen, zoals wanneer een wijziging in de verificatie vereist is of een intrekking van het token is gedetecteerd.It's important to note that a resource may reject the token before this time as well, such as when a change in authentication is required or a token revocation has been detected.
aio Dekkende teken reeksOpaque String Een interne claim die door Azure AD wordt gebruikt om gegevens te registreren voor het opnieuw gebruiken van tokens.An internal claim used by Azure AD to record data for token reuse. Resources mogen deze claim niet gebruiken.Resources should not use this claim.
acr Teken reeks, een ' 0 ' of ' 1 'String, a "0" or "1" Alleen aanwezig in v 1.0-tokens.Only present in v1.0 tokens. Claim van de verificatie context klasse.The "Authentication context class" claim. De waarde ' 0 ' geeft aan dat de verificatie van de eind gebruiker niet voldoet aan de vereisten van ISO/IEC 29115.A value of "0" indicates the end-user authentication did not meet the requirements of ISO/IEC 29115.
amr JSON-matrix met teken reeksenJSON array of strings Alleen aanwezig in v 1.0-tokens.Only present in v1.0 tokens. Hiermee wordt aangegeven hoe het onderwerp van het token is geverifieerd.Identifies how the subject of the token was authenticated. Zie de sectie AMR claim voor meer informatie.See the amr claim section for more details.
appid Teken reeks, een GUIDString, a GUID Alleen aanwezig in v 1.0-tokens.Only present in v1.0 tokens. De toepassings-ID van de client die het token gebruikt.The application ID of the client using the token. De toepassing kan optreden als zichzelf of namens een gebruiker.The application can act as itself or on behalf of a user. De toepassings-ID vertegenwoordigt meestal een toepassings object, maar kan ook een Service Principal object in azure AD vertegenwoordigen.The application ID typically represents an application object, but it can also represent a service principal object in Azure AD.
azp Teken reeks, een GUIDString, a GUID Alleen aanwezig in v 2.0-tokens, een vervanging voor appid .Only present in v2.0 tokens, a replacement for appid. De toepassings-ID van de client die het token gebruikt.The application ID of the client using the token. De toepassing kan optreden als zichzelf of namens een gebruiker.The application can act as itself or on behalf of a user. De toepassings-ID vertegenwoordigt meestal een toepassings object, maar kan ook een Service Principal object in azure AD vertegenwoordigen.The application ID typically represents an application object, but it can also represent a service principal object in Azure AD.
appidacr "0", "1" of "2""0", "1", or "2" Alleen aanwezig in v 1.0-tokens.Only present in v1.0 tokens. Hiermee wordt aangegeven hoe de client is geverifieerd.Indicates how the client was authenticated. Voor een open bare client is de waarde 0.For a public client, the value is "0". Als de client-ID en het client geheim worden gebruikt, is de waarde "1".If client ID and client secret are used, the value is "1". Als er een client certificaat voor verificatie is gebruikt, is de waarde 2.If a client certificate was used for authentication, the value is "2".
azpacr "0", "1" of "2""0", "1", or "2" Alleen aanwezig in v 2.0-tokens, een vervanging voor appidacr .Only present in v2.0 tokens, a replacement for appidacr. Hiermee wordt aangegeven hoe de client is geverifieerd.Indicates how the client was authenticated. Voor een open bare client is de waarde 0.For a public client, the value is "0". Als de client-ID en het client geheim worden gebruikt, is de waarde "1".If client ID and client secret are used, the value is "1". Als er een client certificaat voor verificatie is gebruikt, is de waarde 2.If a client certificate was used for authentication, the value is "2".
preferred_username TekenreeksString De primaire gebruikers naam die de gebruiker vertegenwoordigt.The primary username that represents the user. Dit kan een e-mail adres, telefoon nummer of een algemene gebruikers naam zijn zonder een opgegeven indeling.It could be an email address, phone number, or a generic username without a specified format. De waarde is onveranderbaar en kan in de loop van de tijd veranderen.Its value is mutable and might change over time. Omdat de waarde is ververanderbaar, mag deze niet worden gebruikt om autorisatie beslissingen te nemen.Since it is mutable, this value must not be used to make authorization decisions. Het kan worden gebruikt voor hints voor gebruikers namen, maar ook in een gebruikers interface die door een gebruiker kan worden gelezen.It can be used for username hints, however, and in human-readable UI as a username. Het profile bereik is vereist om deze claim te kunnen ontvangen.The profile scope is required in order to receive this claim. Alleen aanwezig in v 2.0-tokens.Present only in v2.0 tokens.
name TekenreeksString Biedt een lees bare waarde waarmee het onderwerp van het token wordt geïdentificeerd.Provides a human-readable value that identifies the subject of the token. De waarde is niet gegarandeerd uniek, is onveranderbaar en is ontworpen om alleen te worden gebruikt voor weergave doeleinden.The value is not guaranteed to be unique, it is mutable, and it's designed to be used only for display purposes. Het profile bereik is vereist om deze claim te kunnen ontvangen.The profile scope is required in order to receive this claim.
scp Teken reeks, een door spaties gescheiden lijst met bereikenString, a space separated list of scopes De set bereiken die wordt weer gegeven door uw toepassing waarvoor de client toepassing toestemming heeft aangevraagd (en ontvangen).The set of scopes exposed by your application for which the client application has requested (and received) consent. Uw app moet controleren of deze bereiken geldig zijn voor uw app en autorisatie beslissingen nemen op basis van de waarde van deze bereiken.Your app should verify that these scopes are valid ones exposed by your app, and make authorization decisions based on the value of these scopes. Alleen opgenomen voor gebruikers tokens.Only included for user tokens.
roles Matrix van teken reeksen, een lijst met machtigingenArray of strings, a list of permissions De set machtigingen die door uw toepassing worden weer gegeven en waarvoor de aanvraag of gebruiker toestemming heeft gegeven om deze aan te roepen.The set of permissions exposed by your application that the requesting application or user has been given permission to call. Voor toepassings tokenswordt dit gebruikt tijdens de client referentie stroom (v 1.0, v 2.0) in plaats van de gebruikers scopes.For application tokens, this is used during the client credential flow (v1.0, v2.0) in place of user scopes. Voor gebruikers tokens wordt dit ingevuld met de rollen waaraan de gebruiker is toegewezen in de doel toepassing.For user tokens this is populated with the roles the user was assigned to on the target application.
wids Matrix van RoleTemplateID -guid'sArray of RoleTemplateID GUIDs Hiermee worden de rollen voor de Tenant opgegeven die aan deze gebruiker zijn toegewezen, in het gedeelte van de rollen in Azure AD ingebouwde rollen.Denotes the tenant-wide roles assigned to this user, from the section of roles present in Azure AD built-in roles. Deze claim wordt per toepassing geconfigureerd op basis groupMembershipClaims van de eigenschap van het toepassings manifest.This claim is configured on a per-application basis, through the groupMembershipClaims property of the application manifest. Het instellen op ' all ' of ' DirectoryRole ' is vereist.Setting it to "All" or "DirectoryRole" is required. Mag niet aanwezig zijn in tokens die zijn verkregen via de impliciete stroom vanwege problemen met de token lengte.May not be present in tokens obtained through the implicit flow due to token length concerns.
groups JSON-matrix met GUID'SJSON array of GUIDs Bevat object-Id's die de groepslid maatschappen van het onderwerp vertegenwoordigen.Provides object IDs that represent the subject's group memberships. Deze waarden zijn uniek (zie object-ID) en kunnen veilig worden gebruikt voor het beheren van toegang, zoals het afdwingen van autorisatie voor toegang tot een bron.These values are unique (see Object ID) and can be safely used for managing access, such as enforcing authorization to access a resource. De groepen die zijn opgenomen in de claim groepen, worden per toepassing geconfigureerd via de groupMembershipClaims eigenschap van het toepassings manifest.The groups included in the groups claim are configured on a per-application basis, through the groupMembershipClaims property of the application manifest. Een waarde van Null sluit alle groepen uit, de waarde ' beveiligings groep ' bevat alleen Active Directory beveiligings groepslid maatschappen en de waarde ' all ' bevat zowel beveiligings groepen als Microsoft 365 distributie lijsten.A value of null will exclude all groups, a value of "SecurityGroup" will include only Active Directory Security Group memberships, and a value of "All" will include both Security Groups and Microsoft 365 Distribution Lists.

Zie hasgroups onderstaande claim voor meer informatie over het gebruik van de groups claim met de impliciete toekenning.See the hasgroups claim below for details on using the groups claim with the implicit grant.
Voor andere stromen geldt dat als het aantal groepen dat de gebruiker in de loop van een limiet is (150 voor SAML, 200 voor JWT), een overschrijding-claim wordt toegevoegd aan de claim bronnen die naar het Microsoft Graph-eind punt met de lijst met groepen voor de gebruiker verwijzen.For other flows, if the number of groups the user is in goes over a limit (150 for SAML, 200 for JWT), then an overage claim will be added to the claim sources pointing at the Microsoft Graph endpoint containing the list of groups for the user.
hasgroups BooleaansBoolean Indien aanwezig, true wordt het identificeren van de gebruiker altijd in ten minste één groep.If present, always true, denoting the user is in at least one group. Wordt gebruikt in plaats van de groups claim voor JWTs in impliciete toekennings stromen als de claim van de volledige groep het URI-fragment zou uitbreiden dat groter is dan de URL-lengte limieten (momenteel 6 of meer groepen).Used in place of the groups claim for JWTs in implicit grant flows if the full groups claim would extend the URI fragment beyond the URL length limits (currently 6 or more groups). Geeft aan dat de client de Microsoft Graph-API moet gebruiken om de groepen van de gebruiker te bepalen https://graph.microsoft.com/v1.0/users/{userID}/getMemberObjects .Indicates that the client should use the Microsoft Graph API to determine the user's groups (https://graph.microsoft.com/v1.0/users/{userID}/getMemberObjects).
groups:src1 JSON-objectJSON object Voor token aanvragen die geen beperkte lengte hebben (Zie hasgroups hierboven), maar nog steeds te groot zijn voor het token, wordt een koppeling naar de lijst met volledige groepen voor de gebruiker opgenomen.For token requests that are not length limited (see hasgroups above) but still too large for the token, a link to the full groups list for the user will be included. Voor JWTs als een gedistribueerde claim voor SAML als een nieuwe claim in plaats van de groups claim.For JWTs as a distributed claim, for SAML as a new claim in place of the groups claim.

Voor beeld-JWT-waarde:Example JWT Value:
"groups":"src1"
"_claim_sources: "src1" : { "endpoint" : "https://graph.microsoft.com/v1.0/users/{userID}/getMemberObjects" }"_claim_sources: "src1" : { "endpoint" : "https://graph.microsoft.com/v1.0/users/{userID}/getMemberObjects" }
sub TekenreeksString De principal over welke het token informatie bedient, zoals de gebruiker van een app.The principal about which the token asserts information, such as the user of an app. Deze waarde is onveranderbaar en kan niet opnieuw worden toegewezen of opnieuw worden gebruikt.This value is immutable and cannot be reassigned or reused. Het kan worden gebruikt om autorisatie controles veilig uit te voeren, zoals wanneer het token wordt gebruikt om toegang te krijgen tot een resource, en kan worden gebruikt als sleutel in database tabellen.It can be used to perform authorization checks safely, such as when the token is used to access a resource, and can be used as a key in database tables. Omdat het onderwerp altijd aanwezig is in de tokens die door Azure AD worden uitgegeven, raden we u aan deze waarde te gebruiken in een autorisatie systeem voor algemeen gebruik.Because the subject is always present in the tokens that Azure AD issues, we recommend using this value in a general-purpose authorization system. Het onderwerp is echter een Pairwise-id en is uniek voor een bepaalde toepassings-ID.The subject is, however, a pairwise identifier - it is unique to a particular application ID. Als één gebruiker zich bij twee verschillende apps aanmeldt met twee verschillende client-Id's, ontvangen die apps daarom twee verschillende waarden voor de claim van de certificaat houder.Therefore, if a single user signs into two different apps using two different client IDs, those apps will receive two different values for the subject claim. Dit kan al dan niet gewenst zijn, afhankelijk van de vereisten van uw architectuur en privacy.This may or may not be desired depending on your architecture and privacy requirements. Zie ook de oid claim (die hetzelfde blijft voor apps binnen een Tenant).See also the oid claim (which does remain the same across apps within a tenant).
oid Teken reeks, een GUIDString, a GUID De onveranderbare id voor de principal van de aanvraag-de gebruiker of Service-Principal waarvan de identiteit is geverifieerd.The immutable identifier for the "principal" of the request - the user or service principal whose identity has been verified. In ID-tokens en app + gebruikers tokens is dit de object-ID van de gebruiker.In ID tokens and app+user tokens, this is the object ID of the user. In alleen-app-tokens is dit de object-id van de aanroepende Service-Principal.In app-only tokens, this is the object id of the calling service principal. Het kan ook worden gebruikt om autorisatie controles veilig en als sleutel in database tabellen uit te voeren.It can also be used to perform authorization checks safely and as a key in database tables. Deze ID is een unieke identificatie van de principal voor alle toepassingen. twee verschillende toepassingen die in dezelfde gebruiker worden ondertekend, ontvangen dezelfde waarde in de oid claim.This ID uniquely identifies the principal across applications - two different applications signing in the same user will receive the same value in the oid claim. Kan dus oid worden gebruikt bij het uitvoeren van query's naar micro soft onlineservices, zoals de Microsoft Graph.Thus, oid can be used when making queries to Microsoft online services, such as the Microsoft Graph. De Microsoft Graph retourneert deze ID als de id eigenschap voor een bepaald gebruikers account.The Microsoft Graph will return this ID as the id property for a given user account. Omdat de oid principals van meerdere apps mogen correleren, profile is de scope vereist om deze claim voor gebruikers te ontvangen.Because the oid allows multiple apps to correlate principals, the profile scope is required in order to receive this claim for users. Houd er rekening mee dat als één gebruiker bestaat in meerdere tenants, de gebruiker een andere object-ID in elke Tenant bevat. deze worden beschouwd als verschillende accounts, zelfs als de gebruiker zich aanmeldt bij elke account met dezelfde referenties.Note that if a single user exists in multiple tenants, the user will contain a different object ID in each tenant - they are considered different accounts, even though the user logs into each account with the same credentials.
tid Teken reeks, een GUIDString, a GUID Hiermee wordt de Azure AD-Tenant aangegeven waarvan de gebruiker zich bevindt.Represents the Azure AD tenant that the user is from. Voor werk-en school accounts is de GUID de onveranderlijke Tenant-ID van de organisatie waartoe de gebruiker behoort.For work and school accounts, the GUID is the immutable tenant ID of the organization that the user belongs to. De waarde is voor persoonlijke accounts 9188040d-6c67-4c5b-b112-36a304b66dad .For personal accounts, the value is 9188040d-6c67-4c5b-b112-36a304b66dad. Het profile bereik is vereist om deze claim te kunnen ontvangen.The profile scope is required in order to receive this claim.
unique_name TekenreeksString Alleen aanwezig in v 1.0-tokens.Only present in v1.0 tokens. Biedt een voor mensen leesbare waarde waarmee het onderwerp van het token wordt geïdentificeerd.Provides a human readable value that identifies the subject of the token. Deze waarde is niet gegarandeerd uniek binnen een Tenant en mag alleen worden gebruikt voor weergave doeleinden.This value is not guaranteed to be unique within a tenant and should be used only for display purposes.
uti Dekkende teken reeksOpaque String Een interne claim die door Azure wordt gebruikt om tokens opnieuw te valideren.An internal claim used by Azure to revalidate tokens. Resources mogen deze claim niet gebruiken.Resources shouldn't use this claim.
rh Dekkende teken reeksOpaque String Een interne claim die door Azure wordt gebruikt om tokens opnieuw te valideren.An internal claim used by Azure to revalidate tokens. Resources mogen deze claim niet gebruiken.Resources should not use this claim.
ver Teken reeks, ofwel 1.0 of 2.0String, either 1.0 or 2.0 Hiermee wordt de versie van het toegangs token aangegeven.Indicates the version of the access token.

Claim van groepen overschrijdingGroups overage claim

Om ervoor te zorgen dat de token grootte niet groter is dan de grootte limieten voor de HTTP-header, beperkt Azure AD het aantal object-Id's dat in de claim van de groep wordt opgenomen.To ensure that the token size doesn't exceed HTTP header size limits, Azure AD limits the number of object IDs that it includes in the groups claim. Als een gebruiker lid is van meer groepen dan de limiet van overschrijding (150 voor SAML-tokens, 200 voor JWT-tokens en slechts 6 als deze is uitgegeven via de impliciete stroom), verzendt Azure AD de groeperings claim niet in het token.If a user is member of more groups than the overage limit (150 for SAML tokens, 200 for JWT tokens, and only 6 if issued via the implicit flow), then Azure AD does not emit the groups claim in the token. In plaats daarvan bevat het een overschrijding-claim in het token dat aangeeft dat de toepassing een query moet uitvoeren op de Microsoft Graph-API om het groepslid maatschap van de gebruiker op te halen.Instead, it includes an overage claim in the token that indicates to the application to query the Microsoft Graph API to retrieve the user's group membership.

{
  ...
  "_claim_names": {
   "groups": "src1"
    },
    {
  "_claim_sources": {
    "src1": {
        "endpoint":"[Url to get this user's group membership from]"
        }
       }
     }
  ...
}

U kunt de BulkCreateGroups.ps1 gegeven in de map scripts voor het maken van apps gebruiken om overschrijding-scenario's te testen.You can use the BulkCreateGroups.ps1 provided in the App Creation Scripts folder to help test overage scenarios.

v 1.0 basis claimsv1.0 basic claims

De volgende claims worden opgenomen in v 1.0-tokens, indien van toepassing, maar zijn niet standaard opgenomen in de v 2.0-tokens.The following claims will be included in v1.0 tokens if applicable, but aren't included in v2.0 tokens by default. Als u gebruikmaakt van v 2.0 en een van deze claims nodig hebt, vraagt u deze aan met behulp van optionele claims.If you're using v2.0 and need one of these claims, request them using optional claims.

ClaimClaim IndelingFormat BeschrijvingDescription
ipaddr TekenreeksString Het IP-adres waarmee de gebruiker is geverifieerd.The IP address the user authenticated from.
onprem_sid Teken reeks, in sid-indelingString, in SID format In gevallen waarin de gebruiker een on-premises verificatie heeft, levert deze claim de SID.In cases where the user has an on-premises authentication, this claim provides their SID. U kunt gebruiken onprem_sid voor autorisatie in oudere toepassingen.You can use onprem_sid for authorization in legacy applications.
pwd_exp int, een UNIX-time stampint, a UNIX timestamp Hiermee wordt aangegeven wanneer het wacht woord van de gebruiker verloopt.Indicates when the user's password expires.
pwd_url TekenreeksString Een URL waar gebruikers kunnen worden verzonden om hun wacht woord opnieuw in te stellen.A URL where users can be sent to reset their password.
in_corp booleaansboolean Geeft aan of de client zich aanmeldt vanuit het bedrijfs netwerk.Signals if the client is logging in from the corporate network. Als dat niet het geval is, is de claim niet opgenomen.If they aren't, the claim isn't included.
nickname TekenreeksString Een extra naam voor de gebruiker, gescheiden van de voor-en achternaam.An additional name for the user, separate from first or last name.
family_name TekenreeksString Hiermee geeft u de achternaam, de achternaam of de familynaam van de gebruiker op zoals gedefinieerd in het gebruikers object.Provides the last name, surname, or family name of the user as defined on the user object.
given_name TekenreeksString Hiermee wordt de eerste of de voor naam van de gebruiker opgegeven, zoals ingesteld op het gebruikers object.Provides the first or given name of the user, as set on the user object.
upn TekenreeksString De gebruikers naam van de gebruiker.The username of the user. Dit kan een telefoon nummer, e-mail adres of niet-opgemaakte teken reeks zijn.May be a phone number, email address, or unformatted string. Moet alleen worden gebruikt voor weergave doeleinden en het bieden van gebruikers naam hints in scenario's voor herauthenticatie.Should only be used for display purposes and providing username hints in reauthentication scenarios.

De amr claimThe amr claim

Micro soft-identiteiten kunnen op verschillende manieren worden geverifieerd. Dit kan relevant zijn voor uw toepassing.Microsoft identities can authenticate in different ways, which may be relevant to your application. De amr claim is een matrix die meerdere items kan bevatten, zoals ["mfa", "rsa", "pwd"] , voor een verificatie waarbij zowel een wacht woord als de verificator-app wordt gebruikt.The amr claim is an array that can contain multiple items, such as ["mfa", "rsa", "pwd"], for an authentication that used both a password and the Authenticator app.

WaardeValue BeschrijvingDescription
pwd Wachtwoord verificatie: het micro soft-wacht woord van een gebruiker of het client geheim van de app.Password authentication, either a user's Microsoft password or an app's client secret.
rsa Verificatie is gebaseerd op het bewijs van een RSA-sleutel, bijvoorbeeld met de app Microsoft Authenticator.Authentication was based on the proof of an RSA key, for example with the Microsoft Authenticator app. Dit geldt ook als verificatie is uitgevoerd door een zelfondertekende JWT met een x509-certificaat van een service.This includes if authentication was done by a self-signed JWT with a service owned X509 certificate.
otp Eenmalige wachtwoord code met een e-mail of een tekst bericht.One-time passcode using an email or a text message.
fed Er is een Federated Authentication-bevestiging (zoals JWT of SAML) gebruikt.A federated authentication assertion (such as JWT or SAML) was used.
wia Geïntegreerde Windows-verificatieWindows Integrated Authentication
mfa Multi-factor Authentication is gebruikt.Multi-factor authentication was used. Als dit het geval is, worden ook de andere verificatie methoden opgenomen.When this is present the other authentication methods will also be included.
ngcmfa Gelijk aan mfa , gebruikt voor het inrichten van bepaalde geavanceerde referentie typen.Equivalent to mfa, used for provisioning of certain advanced credential types.
wiaormfa De gebruiker heeft Windows of een MFA-referentie gebruikt voor verificatie.The user used Windows or an MFA credential to authenticate.
none Er is geen verificatie uitgevoerd.No authentication was done.

Levens duur van toegangs tokenAccess token lifetime

De standaard levensduur van een toegangs token varieert, afhankelijk van de client toepassing die het token aanvraagt.The default lifetime of an access token varies, depending on the client application requesting the token. Een voor beeld: een voor de clients geschikte, voortdurende toegang evaluatie (CAE) die onderhandelen over CAE-sessies krijgt een lange levens duur van het token (tot 28 uur).For example, continuous access evaluation (CAE) capable clients that negotiate CAE-aware sessions will see a long lived token lifetime (up to 28 hours). Wanneer het toegangs token verloopt, moet de client het vernieuwings token gebruiken om (meestal op de achtergrond) een nieuw vernieuwings token en toegangs token te verkrijgen.When the access token expires, the client must use the refresh token to (usually silently) acquire a new refresh token and access token.

U kunt de levens duur van een toegangs token aanpassen om te bepalen hoe vaak de client toepassing de toepassings sessie verloopt en hoe vaak de gebruiker opnieuw moet worden geverifieerd (op de achtergrond of interactief).You can adjust the lifetime of an access token to control how often the client application expires the application session, and how often it requires the user to re-authenticate (either silently or interactively). Lees de levens duur van Configureer bare tokensvoor meer informatie.For more information, read Configurable token lifetimes.

Tokens validerenValidating tokens

Niet alle apps moeten tokens valideren.Not all apps should validate tokens. In specifieke scenario's moeten apps een token valideren:Only in specific scenarios should apps validate a token:

  • Web-api's moeten de door een client verzonden toegangs tokens valideren.Web APIs must validate access tokens sent to them by a client. Ze mogen alleen tokens accepteren die hun aud claim bevatten.They must only accept tokens containing their aud claim.
  • Vertrouwelijke web-apps zoals ASP.NET Core moeten ID-tokens valideren die naar hen worden verzonden via de browser van de gebruiker in de hybride stroom, voordat toegang tot de gegevens van een gebruiker wordt toegestaan of een sessie tot stand wordt gebracht.Confidential web apps like ASP.NET Core must validate ID tokens sent to them via the user's browser in the hybrid flow, before allowing access to a user's data or establishing a session.

Als geen van de bovenstaande scenario's van toepassing is, kan uw toepassing niet profiteren van het valideren van het token en kan dit een beveiligings-en betrouwbaarheids risico opleveren als er beslissingen worden genomen op basis van de geldigheid van het token.If none of the above scenarios apply, your application will not benefit from validating the token, and may present a security and reliability risk if decisions are made based on the validity of the token. Open bare clients, zoals systeem eigen apps of SPAs, profiteren niet van het valideren van tokens: de app communiceert rechtstreeks met de IDP, dus SSL-beveiliging zorgt ervoor dat de tokens geldig zijn.Public clients like native apps or SPAs don't benefit from validating tokens - the app communicates directly with the IDP, so SSL protection ensures the tokens are valid.

Api's en web apps moeten alleen tokens valideren die een aud claim hebben die overeenkomen met hun toepassing; andere resources kunnen aangepaste token validatie regels hebben.APIs and web apps must only validate tokens that have an aud claim that matches their application; other resources may have custom token validation rules. Tokens voor Microsoft Graph worden bijvoorbeeld niet volgens deze regels gevalideerd vanwege hun eigen indeling.For example, tokens for Microsoft Graph won't validate according to these rules due to their proprietary format. Het valideren en accepteren van tokens die zijn bedoeld voor een andere resource is een voor beeld van het probleem met verwarde adjunct .Validating and accepting tokens meant for another resource is an example of the confused deputy problem.

Als uw toepassing een id_token of een access_token moet valideren volgens het bovenstaande, moet uw app eerst de hand tekening van het token valideren en de uitgever van de waarden in het detectie document voor OpenID Connect.If your application needs to validate an id_token or an access_token according to the above, your app should first validate the token's signature and issuer against the values in the OpenID discovery document. De Tenant-onafhankelijke versie van het document bevindt zich bijvoorbeeld in https://login.microsoftonline.com/common/.well-known/openid-configuration .For example, the tenant-independent version of the document is located at https://login.microsoftonline.com/common/.well-known/openid-configuration.

De volgende informatie wordt verstrekt voor degenen die het onderliggende proces willen begrijpen.The following information is provided for those who wish to understand the underlying process. De Azure AD-middleware heeft ingebouwde mogelijkheden voor het valideren van toegangs tokens, en u kunt bladeren door onze voor beelden om er een te vinden in de taal van uw keuze.The Azure AD middleware has built-in capabilities for validating access tokens, and you can browse through our samples to find one in the language of your choice. Er zijn ook verschillende open source-bibliotheken van derden beschikbaar voor JWT-validatie-er is ten minste één optie voor vrijwel elk platform en elke taal.There are also several third-party open-source libraries available for JWT validation - there is at least one option for almost every platform and language. Zie voor meer informatie over Azure AD-verificatie bibliotheken en code voorbeelden de verificatie bibliotheken.For more information about Azure AD authentication libraries and code samples, see the authentication libraries.

De hand tekening validerenValidating the signature

Een JWT bevat drie segmenten, gescheiden door het . teken.A JWT contains three segments, which are separated by the . character. Het eerste segment wordt de kop, het tweede als de hoofd tekst en de derde als de hand tekening genoemd.The first segment is known as the header, the second as the body, and the third as the signature. Het handtekening segment kan worden gebruikt om de echtheid van het token te valideren, zodat het kan worden vertrouwd door uw app.The signature segment can be used to validate the authenticity of the token so that it can be trusted by your app.

Tokens die zijn uitgegeven door Azure AD, worden ondertekend met behulp van standaard algoritmen voor asymmetrische versleuteling van de industrie, zoals RS256.Tokens issued by Azure AD are signed using industry standard asymmetric encryption algorithms, such as RS256. De kop van de JWT bevat informatie over de sleutel en versleutelings methode die wordt gebruikt om het token te ondertekenen:The header of the JWT contains information about the key and encryption method used to sign the token:

{
  "typ": "JWT",
  "alg": "RS256",
  "x5t": "iBjL1Rcqzhiy4fpxIxdZqohM2Yk",
  "kid": "iBjL1Rcqzhiy4fpxIxdZqohM2Yk"
}

De alg claim geeft het algoritme aan dat is gebruikt voor het ondertekenen van het token, terwijl de kid claim de specifieke open bare sleutel aangeeft die is gebruikt om het token te valideren.The alg claim indicates the algorithm that was used to sign the token, while the kid claim indicates the particular public key that was used to validate the token.

Op elk gewenst moment kan Azure AD een id_token ondertekenen met behulp van een van een of meer combi Naties van open bare en persoonlijke sleutels.At any given point in time, Azure AD may sign an id_token using any one of a certain set of public-private key pairs. Azure AD roteert de mogelijke set sleutels periodiek. Daarom moet uw app worden geschreven om deze sleutel wijzigingen automatisch af te handelen.Azure AD rotates the possible set of keys on a periodic basis, so your app should be written to handle those key changes automatically. Een redelijke frequentie om te controleren op updates voor de open bare sleutels die door Azure AD worden gebruikt, is om de 24 uur.A reasonable frequency to check for updates to the public keys used by Azure AD is every 24 hours.

U kunt de gegevens van de handtekening sleutel verkrijgen die nodig zijn om de hand tekening te valideren met behulp van het OpenID Connect Connect meta data-document op de volgende locatie:You can acquire the signing key data necessary to validate the signature by using the OpenID Connect metadata document located at:

https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration

Tip

Probeer deze URL in een browser.Try this URL in a browser!

Dit meta gegevens document:This metadata document:

  • Is een JSON-object dat verschillende nuttige informatie bevat, zoals de locatie van de verschillende eind punten die vereist zijn voor het uitvoeren van OpenID Connect Connect-verificatie.Is a JSON object containing several useful pieces of information, such as the location of the various endpoints required for doing OpenID Connect authentication.
  • Bevat een jwks_uri , waarmee de locatie wordt opgegeven van de set open bare sleutels die worden gebruikt voor het ondertekenen van tokens.Includes a jwks_uri, which gives the location of the set of public keys used to sign tokens. De JSON-websleutel (JWK) die zich bevindt jwks_uri in de bevat alle informatie over de open bare sleutel die op dat moment in gebruik is.The JSON Web Key (JWK) located at the jwks_uri contains all of the public key information in use at that particular moment in time. De JWK-indeling wordt beschreven in RFC 7517.The JWK format is described in RFC 7517. Uw app kan de kid claim in de JWT-header gebruiken om te selecteren welke open bare sleutel in dit document is gebruikt voor het ondertekenen van een bepaald token.Your app can use the kid claim in the JWT header to select which public key in this document has been used to sign a particular token. Vervolgens kan de hand tekening worden gevalideerd met de juiste open bare sleutel en het aangegeven algoritme.It can then do signature validation using the correct public key and the indicated algorithm.

Notitie

Het is raadzaam kid om de claim te gebruiken om uw token te valideren.We recommend using the kid claim to validate your token. Hoewel v 1.0-tokens zowel de x5t als kid -claims bevatten, bevatten de v 2.0-tokens alleen de kid claim.Though v1.0 tokens contain both the x5t and kid claims, v2.0 tokens contain only the kid claim.

Het uitvoeren van de handtekening validatie valt buiten het bereik van dit document. er zijn veel open-source bibliotheken beschikbaar om u zo nodig te helpen.Doing signature validation is outside the scope of this document - there are many open-source libraries available for helping you do so if necessary. Het micro soft Identity-platform heeft echter een uitbrei ding voor token-ondertekening van de standaard-aangepaste handtekening sleutels.However, the Microsoft identity platform has one token signing extension to the standards - custom signing keys.

Als uw app aangepaste handtekening sleutels heeft als gevolg van het gebruik van de functie voor het toewijzen van claims , moet u een appid query parameter met de app-id toevoegen om een jwks_uri verwijzing naar de informatie van de handtekening sleutel van uw app te krijgen. deze moet worden gebruikt voor de validatie.If your app has custom signing keys as a result of using the claims-mapping feature, you must append an appid query parameter containing the app ID to get a jwks_uri pointing to your app's signing key information, which should be used for validation. Bijvoorbeeld: https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration?appid=6731de76-14a6-49ae-97bc-6eba6914391e bevat een jwks_uri van https://login.microsoftonline.com/{tenant}/discovery/keys?appid=6731de76-14a6-49ae-97bc-6eba6914391e .For example: https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration?appid=6731de76-14a6-49ae-97bc-6eba6914391e contains a jwks_uri of https://login.microsoftonline.com/{tenant}/discovery/keys?appid=6731de76-14a6-49ae-97bc-6eba6914391e.

Autorisatie op basis van claimsClaims based authorization

Met de bedrijfs logica van uw toepassing wordt deze stap gedicteerd. sommige algemene autorisatie methoden worden hieronder beschreven.Your application's business logic will dictate this step, some common authorization methods are laid out below.

  • Controleer de scp of- roles claim om te controleren of alle huidige bereiken overeenkomen met die van uw API, en laat de client de aangevraagde actie uitvoeren.Check the scp or roles claim to verify that all present scopes match those exposed by your API, and allow the client to do the requested action.
  • Zorg ervoor dat de aanroepende client uw API mag aanroepen met behulp van de appid claim.Ensure the calling client is allowed to call your API using the appid claim.
  • De verificatie status van de aanroepende client valideren met appidacr -deze mag niet 0 zijn als open bare clients uw API niet mogen aanroepen.Validate the authentication status of the calling client using appidacr - it shouldn't be 0 if public clients aren't allowed to call your API.
  • Controleer op een lijst met achterstallige nonce claims om te controleren of het token niet opnieuw is afgespeeld.Check against a list of past nonce claims to verify the token isn't being replayed.
  • Controleer of het tid overeenkomt met een Tenant die uw API mag aanroepen.Check that the tid matches a tenant that is allowed to call your API.
  • Gebruik de amr claim om te controleren of de gebruiker MFA heeft uitgevoerd.Use the amr claim to verify the user has performed MFA. Dit moet worden afgedwongen met behulp van voorwaardelijke toegang.This should be enforced using Conditional Access.
  • Als u de roles of groups claims in het toegangs token hebt aangevraagd, controleert u of de gebruiker zich in de groep bevindt die deze actie mag uitvoeren.If you've requested the roles or groups claims in the access token, verify that the user is in the group allowed to do this action.
    • Voor tokens die zijn opgehaald met behulp van de impliciete stroom moet u waarschijnlijk de Microsoft Graph voor deze gegevens opvragen, omdat het vaak te groot is voor het token.For tokens retrieved using the implicit flow, you'll likely need to query the Microsoft Graph for this data, as it's often too large to fit in the token.

Tokens van gebruikers en toepassingenUser and application tokens

Uw toepassing kan tokens ontvangen voor de gebruiker (de stroom die gewoonlijk wordt besproken) of rechtstreeks vanuit een toepassing (via de client referentie stroom).Your application may receive tokens for user (the flow usually discussed) or directly from an application (through the client credentials flow). Deze app-tokens geven aan dat deze aanroep afkomstig is van een toepassing en geen back-up van de-gebruiker heeft.These app-only tokens indicate that this call is coming from an application and does not have a user backing it. Deze tokens worden grotendeels hetzelfde behandeld:These tokens are handled largely the same:

  • Gebruik roles om machtigingen weer te geven die zijn verleend aan het onderwerp van het token.Use roles to see permissions that have been granted to the subject of the token.
  • Gebruik oid of sub om te controleren of de aanroepende Service-Principal de verwachte is.Use oid or sub to validate that the calling service principal is the expected one.

Als uw app onderscheid moet maken tussen alleen app-toegangs tokens en toegangs tokens voor gebruikers, gebruikt u de idtyp optionele claim.If your app needs to distinguish between app-only access tokens and access tokens for users, use the idtyp optional claim. Door de claim toe te voegen idtyp aan het accessToken veld en de waarde te controleren app , kunt u alleen app-toegangs tokens detecteren.By adding the idtyp claim to the accessToken field, and checking for the value app, you can detect app-only access tokens. ID-tokens en toegangs tokens voor gebruikers worden niet opgenomen in de idtyp claim.ID tokens and access tokens for users will not have the idtyp claim included.

Token intrekkingToken revocation

Vernieuwings tokens kunnen op elk gewenst moment ongeldig worden gemaakt of ingetrokken om verschillende redenen.Refresh tokens can be invalidated or revoked at any time, for different reasons. Deze zijn onderverdeeld in twee hoofd categorieën: time-outs en intrekken.These fall into two main categories: timeouts and revocations.

Token-time-outsToken timeouts

Met de configuratie van de levens duur van tokenskan de levens duur van vernieuwings tokens worden gewijzigd.Using token lifetime configuration, the lifetime of refresh tokens can be altered. Het is normaal en verwacht dat sommige tokens zonder gebruik worden uitgevoerd (bijvoorbeeld de gebruiker heeft de app drie maanden niet geopend) en verloopt daarom.It is normal and expected for some tokens to go without use (e.g. the user does not open the app for 3 months) and therefore expire. Apps zullen scenario's ondervinden waarbij de aanmeldings server een vernieuwings token weigert als gevolg van de leeftijd.Apps will encounter scenarios where the login server rejects a refresh token due to its age.

  • MaxInactiveTime: als het vernieuwings token niet is gebruikt binnen de tijd die is bepaald door de MaxInactiveTime, is het vernieuwings token niet langer geldig.MaxInactiveTime: If the refresh token hasn't been used within the time dictated by the MaxInactiveTime, the Refresh Token will no longer be valid.
  • MaxSessionAge: als MaxAgeSessionMultiFactor of MaxAgeSessionSingleFactor is ingesteld op een andere waarde dan de standaard instelling (tot-ingetrokken), is de verificatie vereist na de tijd die is ingesteld in de MaxAgeSession * verstreken.MaxSessionAge: If MaxAgeSessionMultiFactor or MaxAgeSessionSingleFactor have been set to something other than their default (Until-revoked), then reauthentication will be required after the time set in the MaxAgeSession* elapses.
  • Voorbeelden:Examples:
    • De Tenant heeft een MaxInactiveTime van vijf dagen en de gebruiker heeft gedurende een week op vakantie gezet, waarna Azure AD gedurende 7 dagen geen nieuwe token aanvraag van de gebruiker heeft gezien.The tenant has a MaxInactiveTime of five days, and the user went on vacation for a week, and so Azure AD hasn't seen a new token request from the user in 7 days. De volgende keer dat de gebruiker een nieuw token aanvraagt, wordt het vernieuwings token ingetrokken en moeten ze hun referenties opnieuw invoeren.The next time the user requests a new token, they'll find their Refresh Token has been revoked, and they must enter their credentials again.
    • Een gevoelige toepassing heeft een MaxAgeSessionSingleFactor van één dag.A sensitive application has a MaxAgeSessionSingleFactor of one day. Als een gebruiker zich op maandag aanmeldt en op dinsdag (nadat 25 uur is verstreken), moeten ze opnieuw worden geverifieerd.If a user logs in on Monday, and on Tuesday (after 25 hours have elapsed), they'll be required to reauthenticate.

IntrekkingsRevocation

Het vernieuwen van tokens kan door de server worden ingetrokken vanwege een wijziging in de referenties of door het gebruik of de beheerder.Refresh tokens can be revoked by the server due to a change in credentials, or due to use or admin action. Vernieuwings tokens kunnen worden onderverdeeld in twee klassen, die zijn uitgegeven aan vertrouwelijke clients (de meest rechtse kolom) en die worden verleend aan open bare clients (alle andere kolommen).Refresh tokens fall into two classes - those issued to confidential clients (the rightmost column) and those issued to public clients (all other columns).

WijzigingChange Cookie op basis van wacht woordenPassword-based cookie Token op basis van wacht woordenPassword-based token Cookie op basis van niet-wacht woordNon-password-based cookie Niet-op wacht woord gebaseerde tokenNon-password-based token Vertrouwelijk client tokenConfidential client token
Wacht woord verlooptPassword expires Blijft actiefStays alive Blijft actiefStays alive Blijft actiefStays alive Blijft actiefStays alive Blijft actiefStays alive
Het wacht woord is gewijzigd door de gebruikerPassword changed by user RevokedRevoked RevokedRevoked Blijft actiefStays alive Blijft actiefStays alive Blijft actiefStays alive
Gebruiker heeft SSPRUser does SSPR RevokedRevoked RevokedRevoked Blijft actiefStays alive Blijft actiefStays alive Blijft actiefStays alive
Beheerder wacht woord opnieuw instellenAdmin resets password RevokedRevoked RevokedRevoked Blijft actiefStays alive Blijft actiefStays alive Blijft actiefStays alive
Gebruiker trekt de vernieuwings tokens in via Power shellUser revokes their refresh tokens via PowerShell RevokedRevoked RevokedRevoked RevokedRevoked RevokedRevoked RevokedRevoked
De beheerder trekt alle vernieuwings tokens voor een gebruiker in via Power shellAdmin revokes all refresh tokens for a user via PowerShell RevokedRevoked RevokedRevoked RevokedRevoked RevokedRevoked RevokedRevoked
Eenmalige afmelding (v 1.0, v 2.0 ) op InternetSingle sign-out (v1.0, v2.0 ) on web RevokedRevoked Blijft actiefStays alive RevokedRevoked Blijft actiefStays alive Blijft actiefStays alive

Niet op wacht woord gebaseerdNon-password-based

Een aanmelding zonder wacht woord is een aanmeldings locatie waar de gebruiker geen wacht woord heeft getypt om deze op te halen.A non-password-based login is one where the user didn't type in a password to get it. Voor beelden van aanmelding op basis van een wacht woord zijn:Examples of non-password-based login include:

  • Uw gezicht gebruiken met Windows helloUsing your face with Windows Hello
  • FIDO2-sleutelFIDO2 key
  • SmsSMS
  • SpraakVoice
  • PINPIN

Bekijk de primaire vernieuwings tokens voor meer informatie over primaire vernieuwings tokens.Check out Primary Refresh Tokens for more details on primary refresh tokens.

Volgende stappenNext steps