Åtkomsttoken i Microsofts identitetsplattform
Åtkomsttoken är en typ av säkerhetstoken som utformats för auktorisering och ger åtkomst till specifika resurser för en autentiserad användare. Information i åtkomsttoken avgör om en användare har rätt att komma åt en viss resurs, ungefär som nycklar som låser upp specifika dörrar i en byggnad. Dessa enskilda informationsdelar som utgör token kallas anspråk. Därför är de känsliga autentiseringsuppgifter och utgör en säkerhetsrisk om de inte hanteras korrekt. Åtkomsttoken skiljer sig från ID-token som fungerar som autentiseringsbevis.
Med åtkomsttoken kan klienter anropa skyddade webb-API:er på ett säkert sätt. Även om klientprogram kan ta emot och använda åtkomsttoken bör de behandlas som ogenomskinliga strängar. Klientprogrammet bör inte försöka verifiera åtkomsttoken. Resursservern bör verifiera åtkomsttoken innan den godkänns som auktoriseringsbevis. 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. Den här artikeln förklarar viktig information om åtkomsttoken, inklusive format, ägarskap, livslängder och hur API:er 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 2
till 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 (
ver
anspråk ="1.0") måste den läsa dokumentet OpenID Connect-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 ditt webb-API är en v2.0-utfärdare. - När webbappen/API:et verifierar en v2.0-token (
ver
anspråk ="2.0") måste den läsa dokumentet OpenID Connect-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 ditt webb-API ä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 Connect 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.ex https://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":"A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u","x5t":"A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u","n":"spv...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"}, {"kty":"RSA","use":"sig","kid":"C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w","x5t":"C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w","n":"wEM...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"}, {"kty":"RSA","use":"sig","kid":"E3fH4iJ5kL6mN7oP8qR9sT0uV1wX2y","x5t":"E3fH4iJ5kL6mN7oP8qR9sT0uV1wX2y","n":"rv0...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0"} ] }
- Nycklar som har ett utfärdarvärde som
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 Connect 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": "H4iJ5kL6mN7oP8qR9sT0uV1wX2yZ3a",
"kid": "H4iJ5kL6mN7oP8qR9sT0uV1wX2yZ3a"
}
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 openID Connect-metadatadokumentet 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 Connect-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 ijwks_uri
innehåller all offentlig nyckelinformation som används just då. RFC 7517 beskriver JWK-formatet. Programmet kan använda anspråketkid
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 Connect 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 klienter
Microsoft Entra-ID stöder även program med flera klienter. 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åketiss
är av det formulärhttps://login.microsoftonline.com/{tid}/v2.0
där{tid}
är det exaktatid
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åkettid
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 Connect-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 OpenIdConnect-dokumentet.
"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":"A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u","x5t":"A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u","n":"spv...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"},
{"kty":"RSA","use":"sig","kid":"C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w","x5t":"C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w","n":"wEM...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"},
{"kty":"RSA","use":"sig","kid":"E3fH4iJ5kL6mN7oP8qR9sT0uV1wX2y","x5t":"E3fH4iJ5kL6mN7oP8qR9sT0uV1wX2y","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åketiss
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åketiss
i token matchar det här värdet efter att anspråkettid
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 Connect 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;