Microsoft Identitásplatform hozzáférési jogkivonatok

A hozzáférési jogkivonatok lehetővé teszik az ügyfelek számára a védett webes API-k biztonságos hívását. A hozzáférési jogkivonatokat a webes API-k használják hitelesítés és engedélyezés végrehajtásához.

Az OAuth specifikációja szerint a hozzáférési jogkivonatok átlátszatlan sztringek, beállított formátum nélkül. Egyes identitásszolgáltatók (IDP-k) guid azonosítókat, míg mások titkosított blobokat használnak. A hozzáférési jogkivonat formátuma attól függ, hogy a jogkivonatot elfogadó API hogyan van konfigurálva.

A fejlesztők által a Microsoft Identitásplatform regisztrált egyéni API-k két különböző JSON-webes jogkivonat (JWT) és v1.0v2.0formátum közül választhatnak. Microsoft fejlesztésű API-k, például a Microsoft Graph vagy az Azure API-k más saját jogkivonat-formátumokkal rendelkeznek. Ezek a védett formátumok lehetnek titkosított jogkivonatok, JWT-k vagy speciális JWT-szerű jogkivonatok, amelyek nem lesznek érvényesítve.

Az ügyfeleknek átlátszatlan sztringként kell kezelnie a hozzáférési jogkivonatokat, mert a jogkivonat tartalma csak az API-hoz készült. A fejlesztők csak ellenőrzési és hibakeresési célokra dekódolhatják a JWT-ket egy olyan webhely használatával, mint a jwt.ms. Előfordulhat, hogy a Microsoft API-hoz kapott jogkivonatok nem mindig JWT-nek minősülnek, és nem mindig dekódolhatók.

A hozzáférési jogkivonaton belüli részletekért az ügyfeleknek a hozzáférési jogkivonattal visszaadott jogkivonat-válaszadatokat kell használniuk az ügyfélnek. Amikor az ügyfél hozzáférési jogkivonatot kér, a Microsoft Identitásplatform a hozzáférési jogkivonat néhány metaadatát is visszaadja az alkalmazás felhasználásához. Ezek az információk tartalmazzák a hozzáférési jogkivonat lejárati idejét és azokat a hatóköröket, amelyekre érvényes. Ezek az adatok lehetővé teszik az alkalmazás számára a hozzáférési jogkivonatok intelligens gyorsítótárazását anélkül, hogy magát a hozzáférési jogkivonatot kellene elemeznie.

Az alábbi szakaszokból megtudhatja, hogyan érvényesítheti és használhatja az API a hozzáférési jogkivonaton belüli jogcímeket.

Megjegyzés

Az ezen a lapon található összes dokumentáció, kivéve, ha fel van jegyezve, csak a regisztrált API-khoz kibocsátott jogkivonatokra vonatkozik. Nem vonatkozik a Microsoft tulajdonában lévő API-khoz kibocsátott jogkivonatokra, és ezek a jogkivonatok sem használhatók annak ellenőrzésére, hogy a Microsoft Identitásplatform hogyan ad ki jogkivonatokat egy regisztrált API-hoz.

Jogkivonat-formátumok

A hozzáférési jogkivonatok két verziója érhető el a Microsoft Identitásplatform: v1.0 és v2.0. Ezek a verziók határozzák meg a jogkivonatban található jogcímeket, és győződjön meg arról, hogy a webes API szabályozni tudja a jogkivonat tartalmát.

A webes API-k a regisztráció során az alábbi verziók egyikét jelölik ki alapértelmezettként:

  • 1.0-s verzió csak Azure AD alkalmazásokhoz. Az alábbi példa egy 1.0-s verziós jogkivonatot mutat be (ez a jogkivonat-példa nem érvényesíthető, mert a kulcsok a közzététel előtt el lettek forgva, és a személyes adatok el lettek távolítva):

    eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSIsImtpZCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSJ9.eyJhdWQiOiJlZjFkYTlkNC1mZjc3LTRjM2UtYTAwNS04NDBjM2Y4MzA3NDUiLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC9mYTE1ZDY5Mi1lOWM3LTQ0NjAtYTc0My0yOWYyOTUyMjIyOS8iLCJpYXQiOjE1MzcyMzMxMDYsIm5iZiI6MTUzNzIzMzEwNiwiZXhwIjoxNTM3MjM3MDA2LCJhY3IiOiIxIiwiYWlvIjoiQVhRQWkvOElBQUFBRm0rRS9RVEcrZ0ZuVnhMaldkdzhLKzYxQUdyU091TU1GNmViYU1qN1hPM0libUQzZkdtck95RCtOdlp5R24yVmFUL2tES1h3NE1JaHJnR1ZxNkJuOHdMWG9UMUxrSVorRnpRVmtKUFBMUU9WNEtjWHFTbENWUERTL0RpQ0RnRTIyMlRJbU12V05hRU1hVU9Uc0lHdlRRPT0iLCJhbXIiOlsid2lhIl0sImFwcGlkIjoiNzVkYmU3N2YtMTBhMy00ZTU5LTg1ZmQtOGMxMjc1NDRmMTdjIiwiYXBwaWRhY3IiOiIwIiwiZW1haWwiOiJBYmVMaUBtaWNyb3NvZnQuY29tIiwiZmFtaWx5X25hbWUiOiJMaW5jb2xuIiwiZ2l2ZW5fbmFtZSI6IkFiZSAoTVNGVCkiLCJpZHAiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83MmY5ODhiZi04NmYxLTQxYWYtOTFhYi0yZDdjZDAxMjIyNDcvIiwiaXBhZGRyIjoiMjIyLjIyMi4yMjIuMjIiLCJuYW1lIjoiYWJlbGkiLCJvaWQiOiIwMjIyM2I2Yi1hYTFkLTQyZDQtOWVjMC0xYjJiYjkxOTQ0MzgiLCJyaCI6IkkiLCJzY3AiOiJ1c2VyX2ltcGVyc29uYXRpb24iLCJzdWIiOiJsM19yb0lTUVUyMjJiVUxTOXlpMmswWHBxcE9pTXo1SDNaQUNvMUdlWEEiLCJ0aWQiOiJmYTE1ZDY5Mi1lOWM3LTQ0NjAtYTc0My0yOWYyOTU2ZmQ0MjkiLCJ1bmlxdWVfbmFtZSI6ImFiZWxpQG1pY3Jvc29mdC5jb20iLCJ1dGkiOiJGVnNHeFlYSTMwLVR1aWt1dVVvRkFBIiwidmVyIjoiMS4wIn0.D3H6pMUtQnoJAGq6AHd
    
  • v2.0 a fogyasztói fiókokat támogató alkalmazásokhoz. Az alábbi példa egy 1.0-s verziós jogkivonatot mutat be (ez a jogkivonat-példa nem érvényesíthető, mert a kulcsok a közzététel előtt el lettek forgva, és a személyes adatok el lettek távolítva):

    eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSJ9.eyJhdWQiOiI2ZTc0MTcyYi1iZTU2LTQ4NDMtOWZmNC1lNjZhMzliYjEyZTMiLCJpc3MiOiJodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjQ3L3YyLjAiLCJpYXQiOjE1MzcyMzEwNDgsIm5iZiI6MTUzNzIzMTA0OCwiZXhwIjoxNTM3MjM0OTQ4LCJhaW8iOiJBWFFBaS84SUFBQUF0QWFaTG8zQ2hNaWY2S09udHRSQjdlQnE0L0RjY1F6amNKR3hQWXkvQzNqRGFOR3hYZDZ3TklJVkdSZ2hOUm53SjFsT2NBbk5aY2p2a295ckZ4Q3R0djMzMTQwUmlvT0ZKNGJDQ0dWdW9DYWcxdU9UVDIyMjIyZ0h3TFBZUS91Zjc5UVgrMEtJaWpkcm1wNjlSY3R6bVE9PSIsImF6cCI6IjZlNzQxNzJiLWJlNTYtNDg0My05ZmY0LWU2NmEzOWJiMTJlMyIsImF6cGFjciI6IjAiLCJuYW1lIjoiQWJlIExpbmNvbG4iLCJvaWQiOiI2OTAyMjJiZS1mZjFhLTRkNTYtYWJkMS03ZTRmN2QzOGU0NzQiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJhYmVsaUBtaWNyb3NvZnQuY29tIiwicmgiOiJJIiwic2NwIjoiYWNjZXNzX2FzX3VzZXIiLCJzdWIiOiJIS1pwZmFIeVdhZGVPb3VZbGl0anJJLUtmZlRtMjIyWDVyclYzeERxZktRIiwidGlkIjoiNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjQ3IiwidXRpIjoiZnFpQnFYTFBqMGVRYTgyUy1JWUZBQSIsInZlciI6IjIuMCJ9.pj4N-w_3Us9DrBLfpCt
    

A verzió alkalmazásokhoz állítható be úgy, hogy megadja a megfelelő értéket az accessTokenAcceptedVersionalkalmazásjegyzékben lévő beállításnak. A és 1 az null eredmény értéke v1.0 jogkivonat, az eredmények értéke 2 pedig a 2.0-s jogkivonatokban.

Jogkivonat tulajdonjoga

Két fél vesz részt egy hozzáférési jogkivonat-kérésben: az ügyfél, aki a jogkivonatot kéri, és az erőforrás (webes API), amely elfogadja a jogkivonatot. A aud jogkivonatban szereplő jogcím azt az erőforrást jelzi, amelynek a jogkivonatot ( célközönségét) szánják. Az ügyfelek a jogkivonatot használják, de nem érthetik meg vagy nem kísérelhetik meg elemezni. Az erőforrások elfogadják a jogkivonatot.

A Microsoft Identitásplatform támogatja bármely jogkivonat-verzió kiadását bármely verzióvégpontról – ezek nem kapcsolódnak. Ha accessTokenAcceptedVersion a értékre 2van állítva, a v1.0-s végpontot hívó ügyfél a 2.0-s verziójú hozzáférési jogkivonatot kap egy adott erőforrás jogkivonatának lekéréséhez.

Az erőforrások mindig a jogcím használatával birtokolják a aud jogkivonataikat, és az egyetlen alkalmazás, amely módosíthatja a jogkivonat részleteit.

Jogcímek hozzáférési jogkivonatokban

A JWT-k három részre vannak osztva:

  • Fejléc – Információt nyújt a jogkivonat érvényesítéséről, beleértve a jogkivonat típusával és aláírásának módjával kapcsolatos információkat.
  • Payload – Tartalmazza a szolgáltatást meghívni próbáló felhasználó vagy alkalmazás összes fontos adatát.
  • Signature – A jogkivonat érvényesítéséhez használt nyersanyag.

Minden darab egy ponttal (.) és külön Base64 kódolással van elválasztva.

A jogcímek csak akkor vannak jelen, ha létezik érték a kitöltéséhez. Az alkalmazások nem függenek attól, hogy egy jogcím jelen van-e. Ilyenek például a következők pwd_exp : (nem minden bérlőnek kell jelszavakat érvényesítenie) és family_name (az ügyfél hitelesítő adatainak folyamatai olyan alkalmazások nevében vannak, amelyek nem rendelkeznek névvel). A hozzáférési jogkivonat érvényesítéséhez használt jogcímek mindig jelen vannak.

Egyes jogcímek a Microsoft Identitásplatform biztonságos jogkivonatok újbóli felhasználásának elősegítésére szolgálnak. Ezek a jogcímek a leírásban Opaqueúgy vannak megjelölve, hogy nem nyilvános fogyasztásra szolgálnak. Ezek a jogcímek megjelenhetnek vagy nem jelennek meg egy jogkivonatban, és újak is felvehetők értesítés nélkül.

Fejléc jogcímek

Jogcím Formátum Leírás
typ Sztring – mindig JWT Azt jelzi, hogy a jogkivonat egy JWT.
alg Sztring A jogkivonat aláírásához használt algoritmust jelöli, például RS256: .
kid Sztring Megadja a nyilvános kulcs ujjlenyomatát, amely a jogkivonat aláírásának ellenőrzésére használható. Az 1.0-s és a 2.0-s verziós hozzáférési jogkivonatokban is kibocsátva.
x5t Sztring Ugyanazt a függvényt használja (használatban és értékben), mint a kid. x5t és egy örökölt jogcím, amelyet csak az 1.0-s verziós hozzáférési jogkivonatokban bocsátanak ki kompatibilitási célokból.

Hasznos adatokra vonatkozó jogcímek

Jogcím Formátum Leírás
aud Sztring, alkalmazásazonosító URI vagy GUID Azonosítja a jogkivonat kívánt célközönségét. Az API-nak ellenőriznie kell ezt az értéket, és el kell utasítania a jogkivonatot, ha az érték nem egyezik. A 2.0-s verziójú jogkivonatokban ez az érték mindig az API ügyfél-azonosítója. Az 1.0-s verziójú jogkivonatokban ez lehet a kérelemben használt ügyfél-azonosító vagy erőforrás-URI. Az érték attól függ, hogy az ügyfél hogyan kérte a jogkivonatot.
iss Sztring, biztonsági jogkivonat-szolgáltatás (STS) URI-ja Azonosítja a jogkivonatot összeállító és visszaküldött STS-t, valamint azt a Azure AD bérlőt, amelyben a felhasználó hitelesítése megtörtént. Ha a kibocsátott jogkivonat egy v2.0-s jogkivonat (lásd a ver jogcímet), az URI a következő lesz: /v2.0. Az a GUID, amely azt jelzi, hogy a felhasználó egy Microsoft-fiók felhasználói felhasználója, a következő: 9188040d-6c67-4c5b-b112-36a304b66dad. Az alkalmazás a jogcím GUID-részével korlátozhatja az alkalmazásba bejelentkezni képes bérlők körét, ha vannak ilyenek.
idp Sztring, általában STS URI A jogkivonat alanyát hitelesítő identitásszolgáltatót adja meg. Ez az érték megegyezik a Kiállítói jogcím értékével, kivéve, ha a felhasználói fiók nem ugyanabban a bérlőben van, mint a kiállító, például a vendégek. Ha a jogcím nem jelenik meg, a értéke iss használható helyette. A szervezeti környezetben használt személyes fiókok (például egy Azure AD-bérlőbe meghívott személyes fiók) esetén a idp jogcím lehet "live.com" vagy egy STS URI, amely tartalmazza a Microsoft fiókbérlőt9188040d-6c67-4c5b-b112-36a304b66dad.
iat int, unix időbélyeg Meghatározza, hogy mikor történt a jogkivonat hitelesítése.
nbf int, unix időbélyeg Megadja azt az időpontot, amely előtt a JWT nem fogadható el feldolgozásra.
exp int, unix időbélyeg Megadja azt a lejárati időt, amelyen vagy azt követően a JWT nem fogadható el feldolgozásra. Egy erőforrás ezt megelőzően is elutasíthatja a jogkivonatot. Az elutasítás akkor fordulhat elő, ha módosítani kell a hitelesítést, vagy jogkivonat-visszavonást észleltek.
aio Átlátszatlan sztring Egy belső jogcím, amelyet a Azure AD használ a jogkivonatok újbóli felhasználására vonatkozó adatok rögzítéséhez. Az erőforrások nem használhatják ezt a jogcímet.
acr Sztring, a 0 vagy 1, csak 1.0-s verziós jogkivonatokban jelenik meg A "Hitelesítési környezeti osztály" jogcím értéke 0 azt jelzi, hogy a végfelhasználói hitelesítés nem felelt meg az ISO/IEC 29115 követelményeinek.
amr Sztringek JSON-tömbje, amely csak az 1.0-s verziójú jogkivonatokban található Azonosítja, hogy a jogkivonat tárgya hogyan lett hitelesítve.
appid Sztring, GUID, csak 1.0-s verziós jogkivonatokban jelenik meg A jogkivonatot használó ügyfél alkalmazásazonosítója. Az alkalmazás önmagában vagy egy felhasználó nevében is működhet. Az alkalmazásazonosító általában egy alkalmazásobjektumot jelöl, de egy szolgáltatásnév objektumot is képviselhet a Azure AD.
azp Sztring, GUID, csak v2.0-jogkivonatokban jelenik meg A helyettesítője a következőnek appid: . A jogkivonatot használó ügyfél alkalmazásazonosítója. Az alkalmazás önmagában vagy egy felhasználó nevében is működhet. Az alkalmazásazonosító általában egy alkalmazásobjektumot jelöl, de egy szolgáltatásnév objektumot is képviselhet a Azure AD.
appidacr Sztring 0, , 1, vagy 2, csak az 1.0-s verziós jogkivonatokban Az ügyfél hitelesítésének módját jelzi. Nyilvános ügyfél esetén az érték .0 Ha ügyfélazonosítót és titkos ügyfélkulcsot használ, az érték a következő 1: . Ha a hitelesítéshez ügyféltanúsítványt használtak, az érték a következő 2: .
azpacr Sztring 0, , 1, vagy 2, csak v2.0-jogkivonatokban A helyettesítője a következőnek appidacr: . Az ügyfél hitelesítésének módját jelzi. Nyilvános ügyfél esetén az érték .0 Ha ügyfélazonosítót és titkos ügyfélkulcsot használ, az érték a következő 1: . Ha a hitelesítéshez ügyféltanúsítványt használtak, az érték a következő 2: .
preferred_username Sztring, amely csak a 2.0-s verziós jogkivonatokban található. A felhasználót jelképező elsődleges felhasználónév. Az érték lehet egy megadott formátumú e-mail-cím, telefonszám vagy általános felhasználónév. Az érték nem módosítható, és idővel változhat. Mivel az érték nem módosítható, nem használható engedélyezési döntések meghozatalára. Az érték használható azonban felhasználónév-tippekhez, valamint az emberi olvasásra alkalmas felhasználói felületen felhasználónévként. A profile kérelem fogadásához a hatókörre van szükség.
name Sztring Egy emberi olvasásra alkalmas értéket biztosít, amely azonosítja a jogkivonat tárgyát. Az érték nem garantáltan egyedi, nem módosítható, és csak megjelenítési célokra használható. A profile kérelem fogadásához a hatókörre van szükség.
scp Sztring, a hatókörök szóközzel elválasztott listája Az alkalmazás által közzétett hatókörök, amelyekhez az ügyfélalkalmazás hozzájárulást kért (és kapott). Az alkalmazásnak ellenőriznie kell, hogy ezek a hatókörök érvényesek-e, amelyeket az alkalmazás közzétett, és engedélyezési döntéseket kell hoznia ezen hatókörök értéke alapján. Csak a felhasználói jogkivonatokhoz tartozik.
roles Sztringek tömbje, engedélyek listája Az alkalmazás által közzétett engedélyek készlete, amelyet a kérelmező alkalmazás vagy felhasználó engedélyt kapott a hívásra. Az alkalmazás-jogkivonatok esetében ezt az engedélykészletet az ügyfél hitelesítőadat-folyamata (v1.0, v2.0) használja a felhasználói hatókörök helyett. A felhasználói jogkivonatok esetében ez az értékkészlet azokkal a szerepkörökkel van feltöltve, amelyhez a felhasználó hozzá lett rendelve a célalkalmazásban.
wids RoleTemplateID GUID-azonosítók tömbje A felhasználóhoz rendelt bérlői szerepköröket jelöli a Azure AD beépített szerepkörökben található szerepkörök szakaszából. Ez a jogcím alkalmazásonként van konfigurálva az groupMembershipClaimsalkalmazásjegyzék tulajdonságán keresztül. All A beállítást a vagy DirectoryRole értékre kell állítani. Előfordulhat, hogy a token hossza miatt az implicit folyamaton keresztül beszerzett jogkivonatokban nem található meg.
groups GRAFIKUS AZONOSÍTÓK JSON-tömbje Olyan objektumazonosítókat biztosít, amelyek a tárgy csoporttagságait jelölik. Ezek az értékek egyediek, és biztonságosan használhatók a hozzáférés kezeléséhez, például az erőforrásokhoz való hozzáférés engedélyezésének kikényszerítéséhez. A csoportok jogcímében szereplő csoportok alkalmazásonként vannak konfigurálva az groupMembershipClaimsalkalmazásjegyzék tulajdonságán keresztül. A érték null az összes csoportot kizárja, egy SecurityGroup érték csak az Active Directory biztonsági csoporttagságokat tartalmazza, a érték All pedig a biztonsági csoportokat és a Microsoft 365 terjesztési listákat is tartalmazza.

hasgroups A jogcím implicit támogatással való használatával groups kapcsolatos részletekért tekintse meg a jogcímet. Más folyamatok esetén, ha a felhasználó által használt csoportok száma meghaladja az SAML esetében 150-et, JWT esetén pedig 200-t, akkor Azure AD hozzáad egy túlhasználati jogcímet a jogcímforrásokhoz. A jogcímforrások a Microsoft Graph-végpontra mutatnak, amely a felhasználó csoportjainak listáját tartalmazza.
hasgroups Logikai Ha van ilyen, mindig trueazt jelzi, hogy a felhasználó legalább egy csoportban van-e. A JWT-k implicit engedélyezési folyamatokban való igénylése groups helyett használatos, ha a teljes csoportigénylés az URL-cím hosszára vonatkozó korlátokon (jelenleg hat vagy több csoporton) túlterjedne az URI-töredékre. Azt jelzi, hogy az ügyfélnek a Microsoft Graph API kell használnia a felhasználó csoportjainak (https://graph.microsoft.com/v1.0/users/{userID}/getMemberObjects) meghatározásához.
groups:src1 JSON-objektum Az olyan jogkivonat-kérések esetében, amelyek nem hosszabbak (lásd ), hasgroupsde még mindig túl nagyak a jogkivonathoz, megjelenik a felhasználó teljes csoportlistájára mutató hivatkozás. Elosztott jogcímként a JWT-k esetében az SAML-et a jogcím helyett groups új jogcímként.

Példa JWT-értékre:
"groups":"src1"
"_claim_sources: "src1" : { "endpoint" : "https://graph.microsoft.com/v1.0/users/{userID}/getMemberObjects" }
sub Sztring A rendszerbiztonsági tag, amelyről a jogkivonat információkat állít be, például egy alkalmazás felhasználója. Ez az érték nem módosítható, és nem rendelhető újra és nem használható fel újra. Az engedélyezési ellenőrzések biztonságos végrehajtására használható, például amikor a jogkivonatot egy erőforrás eléréséhez használják, és kulcsként használhatók az adatbázistáblákban. Mivel a tárgy mindig jelen van a problémákat Azure AD jogkivonatokban, használja ezt az értéket egy általános célú engedélyezési rendszerben. A tárgy azonban egy adott alkalmazásazonosítóra egyedi, párosított azonosító. Ha egyetlen felhasználó két különböző ügyfélazonosítóval jelentkezik be két különböző alkalmazásba, ezek az alkalmazások két különböző értéket kapnak a tulajdonosi jogcímhez. Az architektúrától és az adatvédelmi követelményektől függően két különböző értékre lehet szükség, vagy nem. Lásd még a jogcímet oid (amely nem változik a bérlőn belüli alkalmazások között).
oid Sztring, GUID A kérelmező nem módosítható azonosítója, amely az a felhasználó vagy szolgáltatásnév, amelynek identitását ellenőrizték. Az engedélyezési ellenőrzések biztonságos végrehajtására is használható, és kulcsként is használható az adatbázistáblákban. Ez az azonosító egyedileg azonosítja a kérelmezőt az alkalmazások között. Az ugyanabban a felhasználóban bejelentkező két különböző alkalmazás ugyanazt az értéket kapja a oid jogcímben. Ez oid használható Microsoft online szolgáltatások lekérdezések, például a Microsoft Graph lekérdezéseihez. A Microsoft Graph ezt az azonosítót adja vissza egy id adott felhasználói fiók tulajdonságaként. Mivel a oid lehetővé teszi, hogy több alkalmazás is korrelálja a tagokat, a profile hatókörre azért van szükség, hogy a felhasználók megkaphassák ezt a jogcímet. Ha egyetlen felhasználó több bérlőben létezik, a felhasználó minden bérlőben más-más objektumazonosítót tartalmaz. A fiókok eltérőnek minősülnek, annak ellenére, hogy a felhasználó minden fiókba ugyanazokkal a hitelesítő adatokkal jelentkezik be.
tid Sztring, GUID Azt a bérlőt jelöli, amelybe a felhasználó bejelentkezik. Munkahelyi és iskolai fiókok esetén a GUID annak a szervezetnek a nem módosítható bérlőazonosítója, amelybe a felhasználó bejelentkezik. A személyes Microsoft fiókbérlőbe (például Xbox, Teams for Life vagy Outlook) való bejelentkezések esetén az érték .9188040d-6c67-4c5b-b112-36a304b66dad A jogcím fogadásához az alkalmazásnak le kell kérnie a hatókört profile .
unique_name Sztring, csak 1.0-s verziós jogkivonatokban jelenik meg A jogkivonat alanyát azonosító, ember által olvasható értéket ad meg. Ez az érték nem garantáltan egyedi a bérlőn belül, és csak megjelenítési célokra használható.
uti Sztring Jogkivonat-azonosító jogcím, amely egyenértékű jti a JWT-specifikációval. Egyedi, jogkivonatonkénti azonosító, amely megkülönbözteti a kis- és nagybetűk számát.
rh Átlátszatlan sztring Az Azure által a tokenek újraértékeléséhez használt belső jogcím. Az erőforrások nem használhatják ezt a jogcímet.
ver Sztring, vagy 1.02.0 A hozzáférési jogkivonat verzióját jelzi.

Csoportok túlhasználati jogcíme

Azure AD korlátozza a csoportokban szereplő objektumazonosítók számát, hogy a HTTP-fejléc méretkorlátja alatt maradjon. Ha egy felhasználó több csoport tagja, mint a túlhasználati korlát (SAML-jogkivonatok esetén 150, JWT-tokenek esetén 200, implicit folyamat esetén pedig csak 6), akkor a Azure AD nem bocsátja ki a csoportok jogcímét a jogkivonatban. Ehelyett tartalmaz egy túlhasználati jogcímet a jogkivonatban, amely jelzi az alkalmazásnak, hogy lekérdezi a Microsoft Graph API a felhasználó csoporttagságának lekéréséhez.

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

BulkCreateGroups.ps1 A túlhasználati forgatókönyvek teszteléséhez használja az Alkalmazás-létrehozási szkriptek mappában megadottakat.

v1.0 alapjogcímek

Az alábbi jogcímek az 1.0-s verziós jogkivonatok részét képezik, de alapértelmezés szerint nem szerepelnek a 2.0-s verziós jogkivonatokban. Ha ezeket a jogcímeket a 2.0-s verzióhoz szeretné használni, az alkalmazás opcionális jogcímek használatával kéri őket.

Jogcím Formátum Leírás
ipaddr Sztring A felhasználó által hitelesített IP-cím.
onprem_sid Sztring SID formátumban Azokban az esetekben, amikor a felhasználó helyszíni hitelesítéssel rendelkezik, ez a jogcím biztosítja a biztonsági azonosítóját. Használja ezt a jogcímet a régi alkalmazásokban való engedélyezéshez.
pwd_exp int, Unix-időbélyeg Azt jelzi, hogy a felhasználó jelszava mikor jár le.
pwd_url Sztring Egy URL-cím, ahová a felhasználókat elküldheti a jelszó alaphelyzetbe állításához.
in_corp boolean Jelzi, ha az ügyfél a vállalati hálózatról jelentkezik be. Ha nem, akkor a jogcím nem szerepel benne.
nickname Sztring A felhasználó másik neve, a vezeték- és utónévtől függetlenül.
family_name Sztring Megadja a felhasználó vezetéknevét, vezetéknevét vagy családi nevét a felhasználói objektumban meghatározottak szerint.
given_name Sztring Megadja a felhasználó utónevét vagy utónevét a felhasználói objektumon beállított módon.
upn Sztring A felhasználó felhasználóneve. Lehet telefonszám, e-mail-cím vagy formázatlan sztring. Csak megjelenítési célokra és felhasználónév-emlékeztetők újbóli hitelesítése esetén használható.

amr-jogcím

Az identitások különböző módokon hitelesíthetők, ami az alkalmazás szempontjából releváns lehet. A amr jogcím egy tömb, amely több elemet is tartalmazhat, például ["mfa", "rsa", "pwd"]egy jelszót és az Authenticator alkalmazást használó hitelesítéshez.

Érték Leírás
pwd Jelszó-hitelesítés, a felhasználó Microsoft jelszava vagy egy alkalmazás titkos ügyfélkódja.
rsa A hitelesítés egy RSA-kulcs bizonyítékán alapult, például a Microsoft Authenticator alkalmazással. Ez az érték azt is jelzi, hogy a hitelesítést egy önaláírt JWT végezte-e egy szolgáltatás tulajdonában lévő X509-tanúsítvánnyal.
otp Egyszeri pin-kód e-mail vagy szöveges üzenet használatával.
fed Összevont hitelesítési feltételt (például JWT vagy SAML) használtunk.
wia Integrált Windows-hitelesítés
mfa A rendszer többtényezős hitelesítést használt. Ha ez a jogcím jelen van, a rendszer a többi hitelesítési módszert is tartalmazza.
ngcmfa Egyenértékű azzal, mfaamelyet bizonyos speciális hitelesítő adatok kiépítéséhez használnak.
wiaormfa A felhasználó a Windowst vagy egy MFA-hitelesítő adatot használt a hitelesítéshez.
none Nem történt hitelesítés.

Hozzáférési jogkivonat élettartama

A hozzáférési jogkivonatok alapértelmezett élettartama változó. A rendszer a hozzáférési jogkivonatok alapértelmezett élettartamát 60–90 perc (átlagosan 75 perc) közötti véletlenszerű értékhez rendeli hozzá. A változat javítja a szolgáltatás rugalmasságát azáltal, hogy a hozzáférési jogkivonatok igényét egy idő alatt elosztja, ami megakadályozza a Azure AD felé tartó forgalom óránkénti megugrását.

A feltételes hozzáférést nem használó bérlők alapértelmezett hozzáférési jogkivonat-élettartama két óra az olyan ügyfelek számára, mint a Microsoft Teams és Microsoft 365.

A hozzáférési jogkivonat élettartama módosítható annak szabályozásához, hogy az ügyfélalkalmazás milyen gyakran jár le az alkalmazás munkamenetében, és hogy milyen gyakran kell a felhasználónak újrahitelesítenie (akár csendesen, akár interaktívan). Az alapértelmezett hozzáférési jogkivonat élettartam-változatának felülbírálásához állítson be egy statikus alapértelmezett hozzáférési jogkivonat-élettartamot a Konfigurálható tokenélettartam (CTL) használatával.

A rendszer az alapértelmezett jogkivonat-élettartam-változatot alkalmazza azokra a szervezetekre, amelyeken engedélyezve van a folyamatos hozzáférés-kiértékelés (CAE). Az alapértelmezett tokenélettartam-változat akkor is érvényesül, ha a szervezetek CTL-szabályzatokat használnak. A hosszú élettartamú tokenek alapértelmezett élettartama 20 és 28 óra között lehet. A hozzáférési jogkivonat lejárata után az ügyfélnek a frissítési jogkivonatot kell használnia egy új frissítési jogkivonat és hozzáférési jogkivonat csendes beszerzéséhez.

Azok a szervezetek, amelyek a feltételes hozzáférés bejelentkezési gyakoriságát (SIF) használják a bejelentkezés gyakoriságának kikényszerítésére, nem bírálhatják felül az alapértelmezett hozzáférési jogkivonat élettartamának változását. Ha a szervezetek SIF-t használnak, az ügyfél hitelesítőadat-kérései közötti idő a jogkivonat élettartama 60–90 perc, valamint a bejelentkezési gyakorisági időköz.

Íme egy példa a tokenek alapértelmezett élettartam-változatának működésére a bejelentkezési gyakorisággal. Tegyük fel, hogy egy szervezet óránként beállítja a bejelentkezési gyakoriságot. A tényleges bejelentkezési időköz 1 óra és 2,5 óra között történik, mivel a jogkivonat kiadása 60–90 perces élettartammal történik (a token élettartamának változása miatt).

Ha egy egyórás élettartamú jogkivonattal rendelkező felhasználó 59 percen belül (közvetlenül a bejelentkezési gyakoriság túllépése előtt) végez interaktív bejelentkezést, nincs hitelesítőadat-kérés, mert a bejelentkezés az SIF küszöbértéke alatt van. Ha egy új jogkivonatot 90 perces élettartammal bocsátanak ki, a felhasználó másfél óráig nem látna hitelesítőadat-kérést. A 90 perces jogkivonat-élettartam csendes megújítási kísérlete esetén Azure AD hitelesítőadat-kérést igényel, mert a munkamenet teljes hossza túllépte a bejelentkezési gyakoriság 1 órás beállítását. Ebben a példában az SIF-időköz és a token élettartamának változása miatt a hitelesítőadat-kérések közötti időeltérés 2,5 óra lenne.

Jogkivonatok érvényesítése

Nem minden alkalmazásnak kell érvényesítenie a jogkivonatokat. Csak bizonyos esetekben érvényesítsenek jogkivonatot az alkalmazások:

  • A webes API-knak ellenőrizniük kell az ügyfél által nekik küldött hozzáférési jogkivonatokat. Csak a jogcímüket tartalmazó jogkivonatokat fogadhatják aud el.
  • Az olyan bizalmas webalkalmazásoknak, mint a ASP.NET Core, ellenőrizniük kell a nekik küldött azonosító jogkivonatokat a felhasználó böngészőjével a hibrid folyamatban, mielőtt hozzáférést engedélyeznek a felhasználó adataihoz, vagy munkamenetet hoznak létre.

Ha a fenti forgatókönyvek egyike sem alkalmazható, az alkalmazás nem fogja kihasználni a jogkivonat érvényesítését, és biztonsági és megbízhatósági kockázatot jelenthet, ha a jogkivonat érvényességén alapuló döntéseket hoznak. Az olyan nyilvános ügyfelek, mint a natív vagy egyoldalas alkalmazások, nem használhatják a jogkivonatok érvényesítését, mivel az alkalmazás közvetlenül kommunikál az identitásszolgáltatóval, ahol az SSL-védelem biztosítja a tokenek érvényességét.

Az API-knak és a webalkalmazásoknak csak az alkalmazásnak megfelelő jogcímekkel rendelkező aud jogkivonatokat kell érvényesíteniük. Más erőforrásokhoz egyéni jogkivonat-érvényesítési szabályok tartozhatnak. A Microsoft Graph jogkivonatai például a saját formátumuk miatt nem ellenőrzik ezeket a szabályokat. Egy másik erőforráshoz szánt tokenek ellenőrzése és elfogadása egy példa a zavaros helyettes problémára.

Ha az alkalmazásnak ellenőriznie kell egy azonosító jogkivonatot vagy egy hozzáférési jogkivonatot, először ellenőriznie kell a jogkivonat aláírását és a kiállítót az OpenID felderítési dokumentumban szereplő értékek alapján. A dokumentum bérlőfüggetlen verziója például a következő helyen található: https://login.microsoftonline.com/common/.well-known/openid-configuration.

A Azure AD köztes szoftver beépített képességekkel rendelkezik a hozzáférési jogkivonatok érvényesítéséhez. A megfelelő nyelven történő kereséshez tekintse meg a mintákat. A JWT-ellenőrzéshez számos külső nyílt forráskódú kódtár is elérhető. A Azure AD hitelesítési kódtárakról és kódmintákról további információt a hitelesítési kódtárakban talál.

Az aláírás ellenőrzése

A JWT három szegmenst tartalmaz, amelyeket a . karakter választ el egymástól. Az első szegmenst fejlécnek, a másodikat törzsnek, a harmadikat pedig aláírásnak nevezzük. Az aláírási szegmens a jogkivonat hitelességének ellenőrzésére használható, hogy az alkalmazás megbízhatónak minősíthesse azt.

A Azure AD által kibocsátott jogkivonatok iparági szabványnak megfelelő aszimmetrikus titkosítási algoritmusok, például RS256 használatával vannak aláírva. A JWT fejléce információkat tartalmaz a jogkivonat aláírásához használt kulcsról és titkosítási módszerről:

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

A alg jogcím a jogkivonat aláírásához használt algoritmust jelzi, a kid jogcím pedig a jogkivonat érvényesítéséhez használt konkrét nyilvános kulcsot.

A Azure AD bármely adott időpontban aláírhat egy azonosító jogkivonatot a nyilvános-titkos kulcspárok egy bizonyos készletének bármelyikével. Azure AD rendszeres időközönként elforgatja a lehetséges kulcskészletet, ezért az alkalmazást úgy kell írni, hogy automatikusan kezelje ezeket a kulcsmódosításokat. A Azure AD által használt nyilvános kulcsok frissítéseinek ellenőrzésének ésszerű gyakorisága 24 óránként történik.

Szerezze be az aláírás ellenőrzéséhez szükséges aláírókulcs-adatokat az OpenID Connect metaadat-dokumentumával , amely a következő helyen található:

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

Tipp

Próbálja ki ezt egy böngészőben: URL

Az alábbi információk a metaadat-dokumentumot ismertetik:

  • Egy JSON-objektum, amely számos hasznos információt tartalmaz, például az OpenID Connect-hitelesítéshez szükséges különböző végpontok helyét.
  • Tartalmaz egy jwks_uri, amely megadja a jogkivonatok aláírásához használt titkos kulcsoknak megfelelő nyilvános kulcsok halmazának helyét. A(z) helyen jwks_uri található JSON-webkulcs (JWK) az adott pillanatban használt összes nyilvános kulcsinformációt tartalmazza. A JWK formátumot az RFC 7517 ismerteti. Az alkalmazás a kid JWT fejlécben található jogcímet használhatja a dokumentum nyilvános kulcsának kiválasztásához, amely egy adott jogkivonat aláírásához használt titkos kulcsnak felel meg. Ezután a megfelelő nyilvános kulccsal és a megadott algoritmussal végezhet aláírás-ellenőrzést.

Megjegyzés

A jogcím használatával kid érvényesítheti a jogkivonatot. Bár az 1.0-s verziós jogkivonatok a és kid a x5t jogcímeket is tartalmazzák, a 2.0-s verziós jogkivonatok csak a kid jogcímet tartalmazzák.

Az aláírás-ellenőrzés a dokumentum hatókörén kívül esik. Számos nyílt forráskódú kódtár érhető el, amelyek szükség esetén segítenek az aláírás-ellenőrzésben. A Microsoft Identitásplatform azonban egy jogkivonat-aláírási kiterjesztéssel rendelkezik a szabványokhoz, amelyek egyéni aláíró kulcsok.

Ha az alkalmazás egyéni aláíró kulcsokkal rendelkezik a jogcímleképezési funkció használata miatt, fűzze hozzá az appid alkalmazásazonosítót jwks_uri tartalmazó lekérdezési paramétert, hogy az az alkalmazás aláírókulcs-adataira mutatjon, amelyeket az ellenőrzéshez kell használni. Például: https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration?appid=6731de76-14a6-49ae-97bc-6eba6914391e egy a-t https://login.microsoftonline.com/{tenant}/discovery/keys?appid=6731de76-14a6-49ae-97bc-6eba6914391ejwks_uri tartalmaz.

Jogcímalapú engedélyezés

Az alkalmazás üzleti logikája jogcímalapú engedélyezést diktál. Az alábbiakban felsorolunk néhány gyakori engedélyezési módszert.

A jogkivonat érvényesítése

aud A jogcím használatával győződjön meg arról, hogy a felhasználó meg akarta hívni az alkalmazást. Ha az erőforrás azonosítója nem szerepel a aud jogcímben, utasítsa el.

Felhasználói engedély érvényesítése

A és wids jogcímek roles használatával ellenőrizze, hogy a felhasználó rendelkezik-e engedéllyel az API meghívásához. Előfordulhat például, hogy egy rendszergazda írási engedéllyel rendelkezik az API-ba, de nem egy normál felhasználóhoz. Ellenőrizze, hogy a tid jogkivonat belső azonosítója megegyezik-e az API-ban az adatok tárolásához használt bérlőazonosítóval.

Amikor egy felhasználó adatokat tárol az API-ban egy bérlőről, újra be kell jelentkeznie a bérlőbe az adatok eléréséhez. Soha ne engedélyezze az egyik bérlő adatainak elérését egy másik bérlőből.

amr A jogcím használatával ellenőrizze, hogy a felhasználó végrehajtotta-e az MFA-t. Az MFA érvényesítése feltételes hozzáféréssel történik. Ha roles vagy groups jogcímeket kér a hozzáférési jogkivonat, ellenőrizze, hogy a felhasználó a művelet végrehajtására jogosult csoportban van-e.

Az implicit folyamattal lekért jogkivonatok esetében kérje le az adatokhoz tartozó Microsoft Graphot, mivel az gyakran túl nagy ahhoz, hogy elférjen a tokenben.

Ne használjon email vagy upn igényeljen értékeket annak meghatározásához, hogy a hozzáférési jogkivonatban szereplő felhasználónak hozzáféréssel kell-e rendelkeznie az adatokhoz. Az ilyen, nem módosítható jogcímértékek idővel változhatnak, így nem biztonságosak és megbízhatatlanok az engedélyezéshez.

Használjon nem módosítható jogcímértékeket tid és sub kombinált oid kulcsot az API adatainak egyedi azonosításához és annak meghatározásához, hogy a felhasználónak hozzáférést kell-e biztosítani az adatokhoz.

  • Jó: tid + sub
  • Jobb: tid + oid - a oid konzisztens az alkalmazások között, így az alkalmazások ökoszisztémája naplózhatja a felhasználók hozzáférését az adatokhoz.

Ne használjon mutáns, emberi olvasásra alkalmas azonosítókat, például email vagy upn egyedileg azonosító adatokat.

Alkalmazás-bejelentkezés ellenőrzése

  • scp A jogcím használatával ellenőrizze, hogy a felhasználó megadta-e a hívó alkalmazás engedélyét az API meghívásához.
  • Győződjön meg arról, hogy a hívó ügyfél meghívhatja az API-t a appid jogcím (1.0-s verziós jogkivonatok esetén) vagy a azp jogcím (2.0-s verziós jogkivonatok esetén) használatával.
    • Ezeket a jogcímeket (appid, ) csak akkor kell érvényesítenie, ha azt szeretné, azphogy a webes API-t csak előre meghatározott alkalmazások (például üzletági alkalmazások vagy jól ismert előtér-kezelők által hívott webes API-k) hívják meg. A hívó alkalmazásokból való hozzáférés engedélyezésére szolgáló API-knak nem kell ellenőrizniük ezeket a jogcímeket.

Felhasználói és alkalmazás-jogkivonatok

Az alkalmazások jogkivonatokat kaphatnak egy felhasználóhoz, vagy közvetlenül egy alkalmazástól az ügyfél hitelesítő adatainak folyamatán keresztül. Ezek a csak alkalmazásjogkivonatok azt jelzik, hogy ez a hívás egy alkalmazásból származik, és nem rendelkezik egy felhasználóval, aki támogatja azt. Ezek a jogkivonatok nagyrészt azonosak:

  • A használatával roles megtekintheti a jogkivonat tárgyát képező engedélyeket.
  • Használja oid vagy sub ellenőrizze, hogy a hívó szolgáltatásnév a várt-e.

Ha az alkalmazásnak meg kell különböztetnie a csak alkalmazásalapú hozzáférési jogkivonatokat és a hozzáférési jogkivonatokat a felhasználók számára, használja az idtypopcionális jogcímet. Ha csak alkalmazáselérési jogkivonatokat szeretne észlelni, adja hozzá a idtyp jogcímet a accessToken mezőhöz, és ellenőrizze az értéket app. A felhasználók azonosító jogkivonatai és hozzáférési jogkivonatai nem tartalmazzák a idtyp jogcímet.

Jogkivonat visszavonása

A frissítési jogkivonatok különböző okokból bármikor érvényteleníthetők vagy visszavonhatók. Az okok az időtúllépések és visszavonások kategóriáiba tartoznak.

Jogkivonatok időtúllépései

Ha egy szervezet tokenélettartam-konfigurációt használ, a frissítési jogkivonatok élettartama módosítható. Egyes jogkivonatok várhatóan használat nélkül is használhatók. A felhasználó például három hónapig nem nyitja meg az alkalmazást, és a jogkivonat lejár. Az alkalmazások olyan helyzetekbe ütközhetnek, amikor a bejelentkezési kiszolgáló az életkora miatt elutasít egy frissítési jogkivonatot.

  • MaxInactiveTime: Ha a frissítési jogkivonatot nem használták a MaxInactiveTime által diktált időn belül, a frissítési jogkivonat már nem érvényes.
  • MaxSessionAge: Ha a MaxAgeSessionMultiFactor vagy a MaxAgeSessionSingleFactor értéke nem az alapértelmezett (visszavonásig) értékre van állítva, akkor a MaxAgeSession* időtartamának leteltét követően újrahitelesítésre van szükség. Példák:
    • A bérlő öt napos MaxInactiveTime-tal rendelkezik, és a felhasználó egy hétig szabadságon volt, így Azure AD hét napja nem látott új jogkivonat-kérést a felhasználótól. Amikor a felhasználó legközelebb új jogkivonatot kér, azt fogja tapasztalni, hogy a frissítési jogkivonatát visszavonták, és újra meg kell adnia a hitelesítő adatait.
    • Egy bizalmas alkalmazás maxAgeSessionSingleFactor egy napból áll. Ha egy felhasználó hétfőn és kedden (25 óra elteltével) jelentkezik be, újra meg kell adnia a hitelesítést.

Jogkivonatok visszavonása

A frissítési jogkivonatokat a kiszolgáló visszavonhatja a hitelesítő adatok módosítása vagy a használat vagy a rendszergazdai művelet miatt. A frissítési jogkivonatok a bizalmas ügyfelek és a nyilvános ügyfelek osztályaiban találhatók.

Módosítás Jelszóalapú cookie Jelszóalapú jogkivonat Nem jelszóalapú cookie Nem jelszóalapú jogkivonat Bizalmas ügyféljogkivonat
A jelszó lejár Életben marad Életben marad Életben marad Életben marad Életben marad
Felhasználó által módosított jelszó Revoked Revoked Életben marad Életben marad Életben marad
A felhasználó elvégzi az SSPR-t Revoked Revoked Életben marad Életben marad Életben marad
Rendszergazda alaphelyzetbe állítja a jelszót Revoked Revoked Életben marad Életben marad Életben marad
A felhasználó visszavonja a frissítési jogkivonatokat a PowerShell használatával Revoked Revoked Revoked Revoked Revoked
Rendszergazda visszavonja a felhasználó összes frissítési jogkivonatát a PowerShell használatával Revoked Revoked Revoked Revoked Revoked
Egyszeri kijelentkezés (v1.0, v2.0 ) a weben Revoked Életben marad Revoked Életben marad Életben marad

Nem jelszóalapú

A nem jelszóalapú bejelentkezés olyan, ahol a felhasználó nem adott meg jelszót a lekéréséhez. A nem jelszóalapú bejelentkezések például a következők:

  • Az arc használata Windows Hello
  • FIDO2-kulcs
  • SMS
  • Hang
  • PIN kód

Az elsődleges frissítési jogkivonatokkal kapcsolatos további részletekért tekintse meg az elsődleges frissítési jogkivonatokat .

Következő lépések