Åtkomsttoken i Microsofts identitetsplattform

Artikel
04/13/2024

Med åtkomsttoken kan klienter anropa skyddade webb-API:er på ett säkert sätt. Webb-API:er använder åtkomsttoken för att utföra autentisering och auktorisering.

Enligt OAuth-specifikationen är åtkomsttoken täckande strängar utan ett angivet format. Vissa identitetsprovidrar (IDP:er) använder GUID och andra använder krypterade blobar. Formatet för åtkomsttoken kan bero på konfigurationen av DET API som accepterar den.

Anpassade API:er som registrerats av utvecklare på Microsofts identitetsplattform kan välja mellan två olika format för JSON-webbtoken (JWT) som heter v1.0 och v2.0. Microsoft-utvecklade API:er som Microsoft Graph eller API:er i Azure har andra patentskyddade tokenformat. Dessa patentskyddade format som inte kan verifieras kan vara krypterade token, JWT eller särskilda JWT-liknande.

Innehållet i token är endast avsett för API:et, vilket innebär att åtkomsttoken måste behandlas som ogenomskinliga strängar. Utvecklare kan bara avkoda JWT med hjälp av en webbplats som jwt.ms för validering och felsökning. Token som ett Microsoft API tar emot kanske inte alltid är en JWT som kan avkodas.

Klienter bör använda tokensvarsdata som returneras med åtkomsttoken för mer information om vad som finns i den. När klienten begär en åtkomsttoken returnerar Microsofts identitetsplattform även vissa metadata om åtkomsttoken för programmets användning. Den här informationen omfattar förfallotiden för åtkomsttoken och de omfång som den är giltig för. Med dessa data kan programmet utföra intelligent cachelagring av åtkomsttoken utan att behöva parsa själva åtkomsttoken.

Se följande avsnitt för att lära dig hur ett API kan verifiera och använda anspråken i en åtkomsttoken.

Kommentar

All dokumentation på den här sidan, förutom där detta anges, gäller endast för token som utfärdats för registrerade API:er. Den gäller inte för token som utfärdats för Microsoft-ägda API:er och dessa token kan inte heller användas för att verifiera hur Microsofts identitetsplattform utfärdar token för ett registrerat API.

Tokenformat

Det finns två versioner av åtkomsttoken i Microsofts identitetsplattform: v1.0 och v2.0. Dessa versioner fastställer de anspråk som finns i token och ser till att ett webb-API kan styra innehållet i token.

Webb-API:er har en av följande versioner som valts som standard under registreringen:

v1.0 för endast Microsoft Entra-program. I följande exempel visas en v1.0-token (nycklarna ändras och personlig information tas bort, vilket förhindrar tokenverifiering):

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSIsImtpZCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSJ9.eyJhdWQiOiJlZjFkYTlkNC1mZjc3LTRjM2UtYTAwNS04NDBjM2Y4MzA3NDUiLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC9mYTE1ZDY5Mi1lOWM3LTQ0NjAtYTc0My0yOWYyOTUyMjIyOS8iLCJpYXQiOjE1MzcyMzMxMDYsIm5iZiI6MTUzNzIzMzEwNiwiZXhwIjoxNTM3MjM3MDA2LCJhY3IiOiIxIiwiYWlvIjoiQVhRQWkvOElBQUFBRm0rRS9RVEcrZ0ZuVnhMaldkdzhLKzYxQUdyU091TU1GNmViYU1qN1hPM0libUQzZkdtck95RCtOdlp5R24yVmFUL2tES1h3NE1JaHJnR1ZxNkJuOHdMWG9UMUxrSVorRnpRVmtKUFBMUU9WNEtjWHFTbENWUERTL0RpQ0RnRTIyMlRJbU12V05hRU1hVU9Uc0lHdlRRPT0iLCJhbXIiOlsid2lhIl0sImFwcGlkIjoiNzVkYmU3N2YtMTBhMy00ZTU5LTg1ZmQtOGMxMjc1NDRmMTdjIiwiYXBwaWRhY3IiOiIwIiwiZW1haWwiOiJBYmVMaUBtaWNyb3NvZnQuY29tIiwiZmFtaWx5X25hbWUiOiJMaW5jb2xuIiwiZ2l2ZW5fbmFtZSI6IkFiZSAoTVNGVCkiLCJpZHAiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83MmY5ODhiZi04NmYxLTQxYWYtOTFhYi0yZDdjZDAxMjIyNDcvIiwiaXBhZGRyIjoiMjIyLjIyMi4yMjIuMjIiLCJuYW1lIjoiYWJlbGkiLCJvaWQiOiIwMjIyM2I2Yi1hYTFkLTQyZDQtOWVjMC0xYjJiYjkxOTQ0MzgiLCJyaCI6IkkiLCJzY3AiOiJ1c2VyX2ltcGVyc29uYXRpb24iLCJzdWIiOiJsM19yb0lTUVUyMjJiVUxTOXlpMmswWHBxcE9pTXo1SDNaQUNvMUdlWEEiLCJ0aWQiOiJmYTE1ZDY5Mi1lOWM3LTQ0NjAtYTc0My0yOWYyOTU2ZmQ0MjkiLCJ1bmlxdWVfbmFtZSI6ImFiZWxpQG1pY3Jvc29mdC5jb20iLCJ1dGkiOiJGVnNHeFlYSTMwLVR1aWt1dVVvRkFBIiwidmVyIjoiMS4wIn0.D3H6pMUtQnoJAGq6AHd

v2.0 för program som stöder konsumentkonton. I följande exempel visas en v2.0-token (nycklarna ändras och personlig information tas bort, vilket förhindrar tokenverifiering):

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSJ9.eyJhdWQiOiI2ZTc0MTcyYi1iZTU2LTQ4NDMtOWZmNC1lNjZhMzliYjEyZTMiLCJpc3MiOiJodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjQ3L3YyLjAiLCJpYXQiOjE1MzcyMzEwNDgsIm5iZiI6MTUzNzIzMTA0OCwiZXhwIjoxNTM3MjM0OTQ4LCJhaW8iOiJBWFFBaS84SUFBQUF0QWFaTG8zQ2hNaWY2S09udHRSQjdlQnE0L0RjY1F6amNKR3hQWXkvQzNqRGFOR3hYZDZ3TklJVkdSZ2hOUm53SjFsT2NBbk5aY2p2a295ckZ4Q3R0djMzMTQwUmlvT0ZKNGJDQ0dWdW9DYWcxdU9UVDIyMjIyZ0h3TFBZUS91Zjc5UVgrMEtJaWpkcm1wNjlSY3R6bVE9PSIsImF6cCI6IjZlNzQxNzJiLWJlNTYtNDg0My05ZmY0LWU2NmEzOWJiMTJlMyIsImF6cGFjciI6IjAiLCJuYW1lIjoiQWJlIExpbmNvbG4iLCJvaWQiOiI2OTAyMjJiZS1mZjFhLTRkNTYtYWJkMS03ZTRmN2QzOGU0NzQiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJhYmVsaUBtaWNyb3NvZnQuY29tIiwicmgiOiJJIiwic2NwIjoiYWNjZXNzX2FzX3VzZXIiLCJzdWIiOiJIS1pwZmFIeVdhZGVPb3VZbGl0anJJLUtmZlRtMjIyWDVyclYzeERxZktRIiwidGlkIjoiNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjQ3IiwidXRpIjoiZnFpQnFYTFBqMGVRYTgyUy1JWUZBQSIsInZlciI6IjIuMCJ9.pj4N-w_3Us9DrBLfpCt

Ange versionen för program genom att ange rätt värde för accessTokenAcceptedVersion inställningen i appmanifestet. Värdena null för och 1 resulterar i v1.0-token och värdet för 2 resulterar i v2.0-token.

Tokenägarskap

En begäran om åtkomsttoken omfattar två parter: klienten, som begär token och resursen (webb-API) som accepterar token. Den resurs som token är avsedd för (dess målgrupp) definieras i anspråket aud i en token. Klienter använder token men bör inte förstå eller försöka parsa den. Resurser accepterar token.

Microsofts identitetsplattform stöder utfärdande av tokenversioner från valfri versionsslutpunkt. När värdet accessTokenAcceptedVersion för är får 2till exempel en klient som anropar v1.0-slutpunkten för att hämta en token för resursen en v2.0-åtkomsttoken.

Resurser äger alltid sina token med anspråket aud och är de enda program som kan ändra sin tokeninformation.

Livslängd för token

Standardlivslängden för en åtkomsttoken är variabel. När den utfärdas tilldelar Microsofts identitetsplattform ett slumpmässigt värde mellan 60 och 90 minuter (i genomsnitt 75 minuter) som standardlivslängd för en åtkomsttoken. Variationen förbättrar tjänstens motståndskraft genom att sprida efterfrågan på åtkomsttoken över en tid, vilket förhindrar timtoppar i trafiken till Microsoft Entra-ID.

Klienter som inte använder villkorsstyrd åtkomst har en standardtid på två timmar för klienter som Microsoft Teams och Microsoft 365.

Justera livslängden för en åtkomsttoken för att styra hur ofta klientprogrammet förfaller programsessionen och hur ofta användaren måste autentisera igen (antingen tyst eller interaktivt). Om du vill åsidosätta standardvarianten för åtkomsttokens livslängd använder du Konfigurerbar tokenlivslängd (CTL).

Använd standardvarianten för tokenlivslängd för organisationer som har kontinuerlig åtkomstutvärdering (CAE) aktiverat. Använd standardvarianten för tokenlivslängd även om organisationerna använder CTL-principer. Standardtokens livslängd för livslängden för token med lång livslängd varierar från 20 till 28 timmar. När åtkomsttoken upphör att gälla måste klienten använda uppdateringstoken för att tyst hämta en ny uppdateringstoken och åtkomsttoken.

Organisationer som använder inloggningsfrekvens för villkorsstyrd åtkomst (SIF) för att framtvinga hur ofta inloggningar sker kan inte åsidosätta standardvarianten för åtkomsttokens livslängd. När organisationer använder SIF är tiden mellan autentiseringsmeddelanden för en klient den tokenlivslängd som sträcker sig mellan 60 och 90 minuter plus inloggningsfrekvensintervallet.

Här är ett exempel på hur standardvarianten för tokenlivslängd fungerar med inloggningsfrekvens. Anta att en organisation anger inloggningsfrekvens för varje timme. När token har en livslängd på mellan 60 och 90 minuter på grund av tokens livslängdsvariation sker det faktiska inloggningsintervallet någonstans mellan 1 timme och 2,5 timmar.

Om en användare med en token med en timmes livslängd utför en interaktiv inloggning på 59 minuter, finns det ingen fråga om autentiseringsuppgifter eftersom inloggningen ligger under SIF-tröskelvärdet. Om en ny token har en livslängd på 90 minuter skulle användaren inte se någon fråga om autentiseringsuppgifter på en och en halv timme. Under ett tyst förnyelseförsök kräver Microsoft Entra-ID en fråga om autentiseringsuppgifter eftersom den totala sessionslängden har överskridit inställningen för inloggningsfrekvens på 1 timme. I det här exemplet är tidsskillnaden mellan frågor om autentiseringsuppgifter på grund av SIF-intervallet och tokens livslängdsvariation 2,5 timmar.

Verifiera token

Alla program bör inte verifiera token. Endast i specifika scenarier bör program verifiera en token:

Webb-API:er måste verifiera åtkomsttoken som skickas till dem av en klient. De får endast acceptera token som innehåller en av deras AppId-URI:er som aud anspråk.
Webbappar måste verifiera ID-token som skickas till dem med hjälp av användarens webbläsare i hybridflödet innan du tillåter åtkomst till en användares data eller upprättar en session.

Om inget av de tidigare beskrivna scenarierna gäller behöver du inte verifiera token. Offentliga klienter som interna program, skrivbordsprogram eller ensidesprogram kan inte validera ID-token eftersom programmet kommunicerar direkt med IDP där SSL-skyddet säkerställer att ID-token är giltiga. De bör inte verifiera åtkomsttoken, eftersom de är till för att webb-API:et ska verifiera, inte klienten.

API:er och webbprogram får endast verifiera token som har ett aud anspråk som matchar programmet. Andra resurser kan ha anpassade valideringsregler för token. Du kan till exempel inte verifiera token för Microsoft Graph enligt dessa regler på grund av deras egna format. Validering och godkännande av token som är avsedda för en annan resurs är ett exempel på det förvirrade deputy-problemet .

Om programmet behöver verifiera en ID-token eller en åtkomsttoken bör det först verifiera tokens signatur och utfärdaren mot värdena i OpenID-identifieringsdokumentet.

Microsoft Entra-mellanprogrammet har inbyggda funktioner för validering av åtkomsttoken, se exempel för att hitta en på rätt språk. Det finns också flera bibliotek med öppen källkod från tredje part som är tillgängliga för JWT-validering. Mer information om autentiseringsbibliotek och kodexempel finns i autentiseringsbiblioteken. Om webbappen eller webb-API:et finns på ASP.NET eller ASP.NET Core använder du Microsoft.Identity.Web, som hanterar verifieringen åt dig.

v1.0- och v2.0-token

När webbappen/API:et verifierar en v1.0-token (veranspråk ="1.0") måste den läsa dokumentet OpenID Anslut metadata från v1.0-slutpunkten (https://login.microsoftonline.com/{example-tenant-id}/.well-known/openid-configuration), även om utfärdaren som konfigurerats för webb-API:et är en v2.0-utfärdare.
När webbappen/API:et verifierar en v2.0-token (veranspråk ="2.0" måste den läsa dokumentet OpenID Anslut metadata från v2.0-slutpunkten (https://login.microsoftonline.com/{example-tenant-id}/v2.0/.well-known/openid-configuration), även om utfärdaren som konfigurerats för webb-API:et är en v1.0-utfärdare.

I följande exempel antar vi att ditt program verifierar en v2.0-åtkomsttoken (och därför refererar till v2.0-versionerna av OIDC-metadatadokumenten och -nycklarna). Ta bara bort "/v2.0" i URL:en om du validerar v1.0-token.

Verifiera utfärdaren

OpenID Anslut Core säger "Utfärdaren identifierare [...] MÅSTE exakt matcha värdet för iss-anspråket (utfärdaren). För program som använder en klientspecifik metadataslutpunkt (t.exhttps://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/.well-known/openid-configuration. eller https://login.microsoftonline.com/contoso.onmicrosoft.com/v2.0/.well-known/openid-configuration) är detta allt som behövs.

Microsoft Entra ID har en klientoberoende version av dokumentet som är tillgängligt på https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration. Den här slutpunkten returnerar ett utfärdarvärde https://login.microsoftonline.com/{tenantid}/v2.0. Program kan använda den här klientoberoende slutpunkten för att verifiera token från varje klientorganisation med följande ändringar:

I stället för att förvänta sig att utfärdarens anspråk i token exakt matchar utfärdarvärdet från metadata, bör programmet ersätta {tenantid} värdet i utfärdarmetadata med det tenantid som är målet för den aktuella begäran och sedan kontrollera den exakta matchningen.

Programmet bör använda egenskapen issuer som returneras från nycklars slutpunkt för att begränsa omfånget för nycklar.

Nycklar som har ett utfärdarvärde som https://login.microsoftonline.com/{tenantid}/v2.0 kan användas med valfri matchande token utfärdare.
Nycklar som har ett utfärdarvärde som https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0 ska endast användas med exakt matchning.

Microsoft Entra klientoberoende nyckelslutpunkt (https://login.microsoftonline.com/common/discovery/v2.0/keys) returnerar ett dokument som:

{
  "keys":[
    {"kty":"RSA","use":"sig","kid":"jS1Xo1OWDj_52vbwGNgvQO2VzMc","x5t":"jS1Xo1OWDj_52vbwGNgvQO2VzMc","n":"spv...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"},
    {"kty":"RSA","use":"sig","kid":"2ZQpJ3UpbjAYXYGaXEJl8lV0TOI","x5t":"2ZQpJ3UpbjAYXYGaXEJl8lV0TOI","n":"wEM...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"},
    {"kty":"RSA","use":"sig","kid":"yreX2PsLi-qkbR8QDOmB_ySxp8Q","x5t":"yreX2PsLi-qkbR8QDOmB_ySxp8Q","n":"rv0...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0"}
  ]
}

Program som använder ett Microsoft Entra-klientorganisationsanspråk (tid) som en förtroendegräns i stället för standardanspråket för utfärdare bör se till att klient-ID-anspråket är ett guid och att utfärdaren och tenantid matchar.

Att använda klientoberoende metadata är effektivare för program som accepterar token från många klienter.

Kommentar

Med Microsoft Entra-klientoberoende metadata ska anspråk tolkas inom klientorganisationen, precis som under Standard OpenID-Anslut tolkas anspråk inom utfärdaren. Det vill: {"sub":"ABC123","iss":"https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0","tid":"aaaabbbb-0000-cccc-1111-dddd2222eeee"} och {"sub":"ABC123","iss":"https://login.microsoftonline.com/bbbbcccc-1111-dddd-2222-eeee3333ffff/v2.0","tid":"bbbbcccc-1111-dddd-2222-eeee3333ffff"} beskriv olika användare, även om de sub är desamma, eftersom anspråk som sub tolkas inom ramen för utfärdaren/klientorganisationen.

Verifiera signaturen

En JWT innehåller tre segment avgränsade med . tecknet. Det första segmentet är rubriken, det andra är brödtexten och det tredje är signaturen. Använd signatursegmentet för att utvärdera tokens äkthet.

Microsoft Entra ID utfärdar token som signerats med hjälp av branschstandardasymmetriska krypteringsalgoritmer, till exempel RS256. Rubriken för JWT innehåller information om nyckeln och krypteringsmetoden som används för att signera token:

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

Anspråket alg anger algoritmen som används för att signera token, medan anspråket kid anger den specifika offentliga nyckel som användes för att verifiera token.

Vid en viss tidpunkt kan Microsoft Entra-ID signera en ID-token med någon av en viss uppsättning offentliga-privata nyckelpar. Microsoft Entra ID roterar den möjliga uppsättningen nycklar regelbundet, så skriv programmet för att hantera dessa nyckeländringar automatiskt. En rimlig frekvens för att söka efter uppdateringar av de offentliga nycklar som används av Microsoft Entra ID är var 24:e timme.

Hämta de signeringsnyckeldata som krävs för att verifiera signaturen med hjälp av dokumentet OpenID Anslut metadata som finns på:

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

Dricks

Prova detta i en webbläsare: URL

Följande information beskriver metadatadokumentet:

Är ett JSON-objekt som innehåller flera användbara uppgifter, till exempel platsen för de olika slutpunkter som krävs för att utföra OpenID-Anslut autentisering.
Innehåller en jwks_uri, som ger platsen för den uppsättning offentliga nycklar som motsvarar de privata nycklar som används för att signera token. JSON-webbnyckeln (JWK) som finns i jwks_uri innehåller all offentlig nyckelinformation som används just då. RFC 7517 beskriver JWK-formatet. Programmet kan använda anspråket kid i JWT-huvudet för att välja den offentliga nyckeln från det här dokumentet, vilket motsvarar den privata nyckel som har använts för att signera en viss token. Den kan sedan utföra signaturverifiering med rätt offentlig nyckel och den angivna algoritmen.

Kommentar

Använd anspråket kid för att verifiera token. Även om v1.0-token innehåller både anspråken x5t och kid innehåller v2.0-token endast anspråket kid .

Att utföra signaturverifiering ligger utanför omfånget för det här dokumentet. Det finns många bibliotek med öppen källkod för att hjälpa till med signaturverifiering om det behövs. Men Microsofts identitetsplattform har ett tillägg för tokensignering till standarderna, som är anpassade signeringsnycklar.

Om programmet har anpassade signeringsnycklar till följd av att du använder funktionen för anspråksmappning lägger du till en appid frågeparameter som innehåller program-ID:t. För validering använder du jwks_uri som pekar på signeringsnyckelinformationen för programmet. Till exempel: https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration?appid=00001111-aaaa-2222-bbbb-3333cccc4444 innehåller en jwks_uri av https://login.microsoftonline.com/{tenant}/discovery/keys?appid=00001111-aaaa-2222-bbbb-3333cccc4444.

Verifiera utfärdaren

Webbappar som validerar ID-token och webb-API:er som validerar åtkomsttoken måste verifiera utfärdaren av token (iss anspråket) mot:

utfärdaren som är tillgänglig i openID connect-metadatadokumentet som är associerat med programkonfigurationen (utfärdaren). Metadatadokumentet som ska verifieras mot beror på:
- versionen av token
- konton som stöds av ditt program.
klientorganisations-ID (tid anspråk) för token,
utfärdaren av signeringsnyckeln.

Program för en enskild klientorganisation

OpenID Anslut Core säger "Utfärdaren identifierare [...] MÅSTE exakt matcha värdet för (utfärdarens iss ) anspråk." För program som använder en klientspecifik metadataslutpunkt, till exempel https://login.microsoftonline.com/{example-tenant-id}/v2.0/.well-known/openid-configuration eller https://login.microsoftonline.com/contoso.onmicrosoft.com/v2.0/.well-known/openid-configuration.

Program med en enda klientorganisation är program som stöder:

Konton i en organisationskatalog (endast exempel-klient-ID ): https://login.microsoftonline.com/{example-tenant-id}
Endast personliga Microsoft-konton: https://login.microsoftonline.com/consumers (konsumenter är ett smeknamn för klientorganisationen 9188040d-6c67-4c5b-b112-36a304b66dad)

Program för flera innehavare

Microsoft Entra-ID stöder även program med flera klientorganisationer. Dessa program stöder:

Konton i valfri organisationskatalog (alla Microsoft Entra-kataloger): https://login.microsoftonline.com/organizations
Konton i valfri organisationskatalog (alla Microsoft Entra-kataloger) och personliga Microsoft-konton (till exempel Skype, XBox): https://login.microsoftonline.com/common

För dessa program exponerar Microsoft Entra ID klientoberoende versioner av OIDC-dokumentet på https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration respektive https://login.microsoftonline.com/organizations/v2.0/.well-known/openid-configuration . Dessa slutpunkter returnerar ett utfärdarvärde, som är en mall som parametriseras av tenantid: https://login.microsoftonline.com/{tenantid}/v2.0. Program kan använda dessa klientoberoende slutpunkter för att verifiera token från varje klientorganisation med följande krav:

Verifiera utfärdaren av signeringsnyckeln
I stället för att förvänta sig att utfärdarens anspråk i token exakt matchar utfärdarvärdet från metadata, bör programmet ersätta {tenantid} värdet i utfärdarmetadata med klient-ID:t som är målet för den aktuella begäran och sedan kontrollera den exakta matchningen (tid anspråket för token).
Kontrollera att anspråket tid är ett GUID och att anspråket iss är av det formulär https://login.microsoftonline.com/{tid}/v2.0 där {tid} är det exakta tid anspråket. Den här valideringen binder klienten tillbaka till utfärdaren och tillbaka till omfånget för signeringsnyckeln som skapar en förtroendekedja.
Använd tid anspråk när de hittar data som är associerade med anspråkets ämne. Med andra ord måste anspråket tid vara en del av nyckeln som används för att komma åt användarens data.

Verifiera utfärdaren av signeringsnyckeln

Program som använder v2.0 klientoberoende metadata måste verifiera utfärdaren av signeringsnyckeln.

Utfärdare av nycklar för dokument- och signeringsnycklar

Enligt beskrivningen kommer ditt program från OpenID Anslut-dokumentet åt de nycklar som används för att signera token. Det hämtar motsvarande nyckeldokument genom att komma åt url:en som exponeras i egenskapen jwks_uri i Dokumentet OpenId Anslut.

 "jwks_uri": "https://login.microsoftonline.com/{example-tenant-id}/discovery/v2.0/keys",

Värdet {example-tenant-id} kan ersättas av ett GUID, ett domännamn eller vanliga organisationer och konsumenter

Dokumenten keys som exponeras av Azure AD v2.0 innehåller utfärdaren som använder den här signeringsnyckeln för varje nyckel. Till exempel returnerar den klientoberoende "vanliga" nyckelslutpunkten https://login.microsoftonline.com/common/discovery/v2.0/keys ett dokument som:

{
  "keys":[
    {"kty":"RSA","use":"sig","kid":"jS1Xo1OWDj_52vbwGNgvQO2VzMc","x5t":"jS1Xo1OWDj_52vbwGNgvQO2VzMc","n":"spv...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"},
    {"kty":"RSA","use":"sig","kid":"2ZQpJ3UpbjAYXYGaXEJl8lV0TOI","x5t":"2ZQpJ3UpbjAYXYGaXEJl8lV0TOI","n":"wEM...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"},
    {"kty":"RSA","use":"sig","kid":"yreX2PsLi-qkbR8QDOmB_ySxp8Q","x5t":"yreX2PsLi-qkbR8QDOmB_ySxp8Q","n":"rv0...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0"}
  ]
}

Validering av utfärdaren av signeringsnyckeln

Programmet bör använda issuer egenskapen för nyckeldokumentet, som är associerat med nyckeln som används för att signera token, för att begränsa omfånget för nycklar:

Nycklar som har ett utfärdarvärde med ett GUID som https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0 ska endast användas när anspråket iss i token matchar värdet exakt.
Nycklar som har ett mallutfärdarvärde som https://login.microsoftonline.com/{tenantid}/v2.0 ska endast användas när anspråket iss i token matchar det här värdet efter att anspråket tid har ersatts i token för {tenantid} platshållaren.

Att använda klientoberoende metadata är effektivare för program som accepterar token från många klienter.

Kommentar

Med Microsoft Entra-klientoberoende metadata ska anspråk tolkas inom klientorganisationen, precis som under Standard OpenID-Anslut tolkas anspråk inom utfärdaren. Det vill: {"sub":"ABC123","iss":"https://login.microsoftonline.com/{example-tenant-id}/v2.0","tid":"{example-tenant-id}"} och {"sub":"ABC123","iss":"https://login.microsoftonline.com/{another-tenand-id}/v2.0","tid":"{another-tenant-id}"} beskriv olika användare, även om de sub är desamma, eftersom anspråk som sub tolkas inom ramen för utfärdaren/klientorganisationen.

Sammanfattning

Här är lite pseudokod som kapslar in hur du validerar utfärdare och utfärdare av signeringsnycklar:

Hämta nycklar från konfigurerad metadata-URL
Kontrollera token om den är signerad med en av de publicerade nycklarna, misslyckas om inte

Identifiera nyckeln i metadata baserat på barnrubriken. Kontrollera egenskapen "utfärdare" som är kopplad till nyckeln i metadatadokumentet:

var issuer = metadata["kid"].issuer;
if (issuer.contains("{tenantId}", CaseInvariant)) issuer = issuer.Replace("{tenantid}", token["tid"], CaseInvariant);
if (issuer != token["iss"]) throw validationException;
if (configuration.allowedIssuer != "*" && configuration.allowedIssuer != issuer) throw validationException;
var issUri = new Uri(token["iss"]);
if (issUri.Segments.Count < 1) throw validationException;
if (issUri.Segments[1] != token["tid"]) throw validationException;

Se även

Nästa steg

Läs mer om säkerhetstoken som används i Microsoft Entra-ID.

Dela via

Åtkomsttoken i Microsofts identitetsplattform

Tokenformat

Tokenägarskap

Livslängd för token

Verifiera token

v1.0- och v2.0-token

Verifiera utfärdaren

Verifiera signaturen

Verifiera utfärdaren

Program för en enskild klientorganisation

Program för flera innehavare

Verifiera utfärdaren av signeringsnyckeln

Utfärdare av nycklar för dokument- och signeringsnycklar

Validering av utfärdaren av signeringsnyckeln

Sammanfattning

Se även

Nästa steg

Feedback

Ytterligare resurser