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

A hozzáférési jogkivonatok lehetővé teszik, hogy az ügyfelek biztonságosan meghívják a védett webes API-kat. 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ó szerint a hozzáférési jogkivonatok nem formázott, átlátszatlan sztringek. 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 -formátum közül választhatnak, amelyeket meghívnak v1.0 és v2.0. A Microsoft által fejlesztett API-k, például a Microsoft Graph vagy az Azure API-k más jogkivonat-formátumokkal rendelkeznek. Ezek a jogvé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 sztringekként kell kezelnie a hozzáférési jogkivonatokat, mert a jogkivonat tartalma csak az API-hoz készült. Csak érvényesítési és hibakeresési célokra a fejlesztők jWT-ket dekódolhatnak egy olyan webhely használatával, mint a jwt.ms. Előfordulhat, hogy a Microsoft API-hoz kapott jogkivonatok nem mindig JWT-k, é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álaszadatait 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 használatához. Ezek az információk tartalmazzák a hozzáférési jogkivonat lejárati idejét és az érvényes hatóköröket. 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.

A következő 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. Ez nem vonatkozik a Microsoft tulajdonában lévő API-khoz kiadott jogkivonatokra, és nem használható ezekre a jogkivonatokra annak ellenőrzésére, hogy a Microsoft Identitásplatform hogyan bocsát 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: 1.0-s és 2.0-s verzióban. 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 következő verziók egyikét választják alapértelmezettként a regisztráció során:

  • 1.0-s verzió 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 forgatva, és a személyes adatok el lettek távolítva):

    eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSIsImtpZCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSJ9.eyJhdWQiOiJlZjFkYTlkNC1mZjc3LTRjM2UtYTAwNS04NDBjM2Y4MzA3NDUiLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC9mYTE1ZDY5Mi1lOWM3LTQ0NjAtYTc0My0yOWYyOTUyMjIyOS8iLCJpYXQiOjE1MzcyMzMxMDYsIm5iZiI6MTUzNzIzMzEwNiwiZXhwIjoxNTM3MjM3MDA2LCJhY3IiOiIxIiwiYWlvIjoiQVhRQWkvOElBQUFBRm0rRS9RVEcrZ0ZuVnhMaldkdzhLKzYxQUdyU091TU1GNmViYU1qN1hPM0libUQzZkdtck95RCtOdlp5R24yVmFUL2tES1h3NE1JaHJnR1ZxNkJuOHdMWG9UMUxrSVorRnpRVmtKUFBMUU9WNEtjWHFTbENWUERTL0RpQ0RnRTIyMlRJbU12V05hRU1hVU9Uc0lHdlRRPT0iLCJhbXIiOlsid2lhIl0sImFwcGlkIjoiNzVkYmU3N2YtMTBhMy00ZTU5LTg1ZmQtOGMxMjc1NDRmMTdjIiwiYXBwaWRhY3IiOiIwIiwiZW1haWwiOiJBYmVMaUBtaWNyb3NvZnQuY29tIiwiZmFtaWx5X25hbWUiOiJMaW5jb2xuIiwiZ2l2ZW5fbmFtZSI6IkFiZSAoTVNGVCkiLCJpZHAiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83MmY5ODhiZi04NmYxLTQxYWYtOTFhYi0yZDdjZDAxMjIyNDcvIiwiaXBhZGRyIjoiMjIyLjIyMi4yMjIuMjIiLCJuYW1lIjoiYWJlbGkiLCJvaWQiOiIwMjIyM2I2Yi1hYTFkLTQyZDQtOWVjMC0xYjJiYjkxOTQ0MzgiLCJyaCI6IkkiLCJzY3AiOiJ1c2VyX2ltcGVyc29uYXRpb24iLCJzdWIiOiJsM19yb0lTUVUyMjJiVUxTOXlpMmswWHBxcE9pTXo1SDNaQUNvMUdlWEEiLCJ0aWQiOiJmYTE1ZDY5Mi1lOWM3LTQ0NjAtYTc0My0yOWYyOTU2ZmQ0MjkiLCJ1bmlxdWVfbmFtZSI6ImFiZWxpQG1pY3Jvc29mdC5jb20iLCJ1dGkiOiJGVnNHeFlYSTMwLVR1aWt1dVVvRkFBIiwidmVyIjoiMS4wIn0.D3H6pMUtQnoJAGq6AHd
    
  • 2.0-s verzió 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 forgatva, és a személyes adatok el lettek távolítva):

    eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSJ9.eyJhdWQiOiI2ZTc0MTcyYi1iZTU2LTQ4NDMtOWZmNC1lNjZhMzliYjEyZTMiLCJpc3MiOiJodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjQ3L3YyLjAiLCJpYXQiOjE1MzcyMzEwNDgsIm5iZiI6MTUzNzIzMTA0OCwiZXhwIjoxNTM3MjM0OTQ4LCJhaW8iOiJBWFFBaS84SUFBQUF0QWFaTG8zQ2hNaWY2S09udHRSQjdlQnE0L0RjY1F6amNKR3hQWXkvQzNqRGFOR3hYZDZ3TklJVkdSZ2hOUm53SjFsT2NBbk5aY2p2a295ckZ4Q3R0djMzMTQwUmlvT0ZKNGJDQ0dWdW9DYWcxdU9UVDIyMjIyZ0h3TFBZUS91Zjc5UVgrMEtJaWpkcm1wNjlSY3R6bVE9PSIsImF6cCI6IjZlNzQxNzJiLWJlNTYtNDg0My05ZmY0LWU2NmEzOWJiMTJlMyIsImF6cGFjciI6IjAiLCJuYW1lIjoiQWJlIExpbmNvbG4iLCJvaWQiOiI2OTAyMjJiZS1mZjFhLTRkNTYtYWJkMS03ZTRmN2QzOGU0NzQiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJhYmVsaUBtaWNyb3NvZnQuY29tIiwicmgiOiJJIiwic2NwIjoiYWNjZXNzX2FzX3VzZXIiLCJzdWIiOiJIS1pwZmFIeVdhZGVPb3VZbGl0anJJLUtmZlRtMjIyWDVyclYzeERxZktRIiwidGlkIjoiNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjQ3IiwidXRpIjoiZnFpQnFYTFBqMGVRYTgyUy1JWUZBQSIsInZlciI6IjIuMCJ9.pj4N-w_3Us9DrBLfpCt
    

A verzió az alkalmazásjegyzékben szereplő beállítás megfelelő értékének accessTokenAcceptedVersion megadásával állítható be az alkalmazásokhoz. Az 1.0-s verziós jogkivonatok értékei null és 1 eredménye, valamint az eredmények értéke 2 a 2.0-s verzió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 lévő jogcím azt az erőforrást jelzi, amelynek a jogkivonatot szánják (célközönsége). 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 bármely verzióvégpontból támogatja a jogkivonatverziók kiadását – ezek nem kapcsolódnak egymáshoz. Ha accessTokenAcceptedVersion be van állítva 2, egy 1.0-s verziójú végpontot hívó ügyfél a 2.0-s verziójú hozzáférési jogkivonatot kap az 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 csak ezek az alkalmazások módosíthatják a jogkivonat részleteit.

Jogcímek hozzáférési jogkivonatokban

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

  • Fejléc – Információkat 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.
  • Hasznos adat – Tartalmazza a szolgáltatást meghívni próbáló felhasználó vagy alkalmazás összes fontos adatát.
  • Aláírás – 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 van egy érték, amely kitölti azt. Egy alkalmazásnak nem szabad függőséget vállalnia egy meglévő jogcímen. Ilyenek például a következők pwd_exp (nem minden bérlőnek kell jelszót megadnia) és family_name (az ügyfél hitelesítőadat-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 nem nyilvános fogyasztásra vannak megjelölve a leírásban Opaque. Ezek a jogcímek megjelenhetnek vagy nem jelennek meg a jogkivonatokban, és új jogcímek is felvehetők előzetes értesítés nélkül.

Fejlécjogcí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 jelzi, például RS256.
kid Sztring Megadja a jogkivonat aláírásának érvényesítéséhez használható nyilvános kulcs ujjlenyomatát. 1.0-s és 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, amely csak az 1.0-s verziós hozzáférési jogkivonatokban van kibocsátva kompatibilitási célokból.

Hasznos adatok jogcíme

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 2.0-s verziós jogkivonat (lásd a ver jogcímet), az URI a következőre /v2.0végződik: . Az a GUID, amely azt jelzi, hogy a felhasználó egy Microsoft-fiók felhasználói felhasználója.9188040d-6c67-4c5b-b112-36a304b66dad Az alkalmazás a jogcím GUID-részének használatával 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 található, mint a kiállító, például a vendégek. Ha a jogcím nem jelenik meg, az érték iss használható helyette. A szervezeti környezetben használt személyes fiókok (például egy Azure AD-bérlőhöz meghívott személyes fiók) esetén a idp jogcím lehet "live.com" vagy a Microsoft-fiók bérlőt 9188040d-6c67-4c5b-b112-36a304b66dadtartalmazó STS URI.
iat int, Unix-időbélyeg Meghatározza, hogy mikor történt a jogkivonat hitelesítése.
nbf int, Unix-időbélyeg Azt az időpontot adja meg, amely előtt a JWT nem fogadható el feldolgozásra.
exp int, Unix-időbélyeg Azt a lejárati időt adja meg, amely után 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 észlelnek.
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, csak 1.0-s verziójú jogkivonatokban jelenik meg Azonosítja a jogkivonat tulajdonosának hitelesítését.
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 Azure AD.
azp Csak 2.0-s verziós jogkivonatokban található sztring, GUID A csere a 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 Azure AD.
appidacr Csak az 1.0-s verziós jogkivonatokban található sztring 0, a . 1vagy 2a. Az ügyfél hitelesítésének módját jelzi. Nyilvános ügyfél esetén az érték 0. Ha ügyfél-azonosítót és titkos ügyfélkulcsot használ, az érték .1 Ha a hitelesítéshez ügyféltanúsítványt használtak, az érték a következő 2: .
azpacr Csak a 2.0-s verziós jogkivonatokban található sztring 0, a . 1vagy 2a. A csere a appidacr. Az ügyfél hitelesítésének módját jelzi. Nyilvános ügyfél esetén az érték 0. Ha ügyfél-azonosítót és titkos ügyfélkulcsot használ, az érték .1 Ha a hitelesítéshez ügyféltanúsítványt használtak, az érték a következő 2: .
preferred_username Sztring, csak 2.0-s verziós jogkivonatokban jelenik meg. A felhasználót jelölő elsődleges felhasználónév. Az érték lehet egy e-mail-cím, telefonszám vagy egy megadott formátum nélküli általános felhasználónév. Az érték módosítható, és idővel változhat. Mivel az érték 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ára a hatókör szükséges.
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ára a hatókör szükséges.
scp Sztring, a hatókörök szóközzel elválasztott listája Azon 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 elérhetővé tesz, és a hatókörök értéke alapján kell engedélyezési döntéseket hoznia. 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áshoz. Az alkalmazásjogkivonatok esetében ez az engedélykészlet az ügyfél hitelesítőadat-folyamata során (1.0-s verzió, 2.0-s verzió) használatos a felhasználói hatókörök helyett. Felhasználói jogkivonatok esetén 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. A beállítás megadása All kötelező vagy DirectoryRole kötelező. Előfordulhat, hogy a tokenek hossza miatt nem jelenik meg az implicit folyamaton keresztül beszerzett jogkivonatokban.
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. Egy érték kizárja az null összes csoportot, egy érték SecurityGroup csak az Active Directory biztonsági csoport tagságát tartalmazza, és a All 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 150-et, JWT esetén pedig 200-at, akkor Azure AD hozzáad egy túlhasználati jogcímet a jogcímforrásokhoz. A jogcímforrások arra a Microsoft Graph-végpontra mutatnak, amely a felhasználó csoportjainak listáját tartalmazza.
hasgroups Logikai Ha jelen van, mindig trueazt jelzi, hogy a felhasználó legalább egy csoportban van-e. A JWT-kre vonatkozó jogcím helyett groups implicit engedélyezési folyamatokban használatos, ha a teljes csoportok jogcíme az URI-töredéket az URL-cím hosszának korlátain (jelenleg hat vagy több csoporton) túlterjedne. 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 hossza nem korlátozott (lásd hasgroups), de még mindig túl nagy a jogkivonathoz, megjelenik a felhasználó teljes csoportlistájára mutató hivatkozás. Elosztott jogcímként a JWT-k esetében az SAML-hez 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 Az 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ó az adatbázistáblákban. Mivel a tárgy mindig megtalálható 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 olyan párirányú azonosító, amely egyedi egy adott alkalmazásazonosítóhoz. Ha egy 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úra és az adatvédelmi követelmények függvényében két különböző értékre lehet szükség, vagy sem. Lásd még a jogcímet oid (amely a bérlőn belüli alkalmazásokban változatlan marad).
oid Sztring, GUID A kérelmező nem módosítható azonosítója, amely annak a felhasználónak vagy szolgáltatásnévnek a azonosítója, akinek az 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 az adatbázistáblákban. Ez az azonosító egyedileg azonosítja a kérelmezőt az alkalmazások között. Az ugyanazon felhasználóba bejelentkező két különböző alkalmazás ugyanazt az értéket kapja a oid jogcímben. Ez oid használható a Microsoft online szolgáltatások lekérdezéseihez, például a Microsoft Graphhoz. A Microsoft Graph ezt az azonosítót adja vissza egy id adott felhasználói fiók tulajdonságaként. Mivel a oid rendszer lehetővé teszi, hogy több alkalmazás is korrelálja a rendszerneveket, a profile hatókörre azért van szükség, hogy megkaphassa ezt a jogcímet a felhasználók számára. Ha egyetlen felhasználó több bérlőben is 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ó ugyanazokkal a hitelesítő adatokkal jelentkezik be mindegyik fiókba.
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ók bérlőjéhez (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űt.
rh Átlátszatlan sztring Az Azure által a jogkivonatok újraértékelésére 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 található objektumazonosítók számát, hogy a HTTP-fejléc méretkorlátja alatt maradjon. Ha egy felhasználó a túlhasználati korlátnál több csoport tagja (SAML-jogkivonatok esetén 150, JWT-jogkivonatok esetén 200, implicit folyamat esetén pedig csak 6), akkor Azure AD nem bocsátja ki a jogkivonatban szereplő csoportjogcímet. Ehelyett tartalmaz egy túlhasználati jogcímet a jogkivonatban, amely jelzi az alkalmazásnak, hogy lekérdezze 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.

1.0-s verziós alapszintű jogcímek

A következő jogcímek az 1.0-s verziós jogkivonatokban találhatók, ha vannak ilyenek, 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ímekkel kéri le ő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. Ezt a jogcímet használhatja az örökölt 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 jelszavuk 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 definiált módon.
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-tippek újbóli hitelesítéshez való megadására 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 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 igazolásá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 A rendszer összevont hitelesítési helyességi feltételt (például JWT vagy SAML) használt.
wia Integrált Windows-hitelesítés
mfa Többtényezős hitelesítést használtunk. Ha ez a jogcím jelen van, a rendszer a többi hitelesítési módszert is tartalmazza.
ngcmfa Egyenértékű azzal mfa, amelyet bizonyos speciális hitelesítő adatok kiépítéséhez használnak.
wiaormfa A felhasználó Windows- vagy MFA-hitelesítő adatokat 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 kiállításkor a hozzáférési jogkivonatok alapértelmezett élettartama véletlenszerűen 60–90 perc (átlagosan 75 perc) közötti véletlenszerű értéket kap. 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 elterjeszti, ami megakadályozza a Azure AD felé irányuló 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 a Microsoft 365.

A hozzáférési jogkivonatok élettartama módosítható, így szabályozható, 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.

Az alapértelmezett jogkivonat-élettartam-változat azokra a szervezetekre lesz alkalmazva, amelyeken engedélyezve van a folyamatos hozzáférés-kiértékelés (CAE). A rendszer akkor is alkalmazza az alapértelmezett jogkivonat-élettartam-változatot, ha a szervezetek CTL-szabályzatokat használnak. A hosszú élettartamú tokenek alapértelmezett élettartama 20 és 28 óra között lehet. Amikor a hozzáférési jogkivonat lejár, 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ési bejelentkezési gyakoriságot (SIF) használják a bejelentkezések gyakoriságának kényszerítésére, nem bírálhatják felül az alapértelmezett hozzáférési jogkivonat élettartam-változását. Ha a szervezetek SIF-t használnak, az ügyfél hitelesítőadat-kérései között eltelt 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 állítja be 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 (a bejelentkezési gyakoriság túllépése előtt) végez interaktív bejelentkezést, nem jelenik meg 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án át 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 az 1 órás bejelentkezési gyakorisági beállítást. Ebben a példában az SIF-időköz és a token élettartamának változása miatt a hitelesítő adatok kérései közötti időkülönbség 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 egy felhasználó adataihoz, vagy munkamenetet hoznak létre.

Ha a fenti forgatókönyvek egyike sem érvényes, az alkalmazás nem fogja haszná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 élvezik 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 jogkivonatok érvényességét.

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

Ha az alkalmazásnak érvényesítenie kell egy azonosító jogkivonatot vagy 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 https://login.microsoftonline.com/common/.well-known/openid-configurationtalálható: .

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 rendelkezésre áll. 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 érvényesíté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 használható a jogkivonat hitelességének ellenőrzésére, hogy az alkalmazás megbízhatónak minősíthesse azt.

A Azure AD által kibocsátott jogkivonatok az iparági szabványnak megfelelő aszimmetrikus titkosítási algoritmusok, például az 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 jogcím pedig kid a jogkivonat érvényesítéséhez használt konkrét nyilvános kulcsot.

Egy adott időpontban Azure AD aláírhat egy azonosító jogkivonatot a nyilvános-titkos kulcspárok egy bizonyos készletének bármelyikével. Azure AD a kulcsok lehetséges készletét rendszeres időközönként elforgatja, ezért az alkalmazást úgy kell megírni, hogy az 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-cím

A metaadat-dokumentumot a következő információk ismertetik:

  • Egy olyan 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, a tokenek aláírásához használt titkos kulcsoknak megfelelő nyilvános kulcskészlet helyét. A JSON-webkulcs (JWK) a jwks_uri megadott időpontban 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ím használatával kiválaszthatja a nyilvános kulcsot a dokumentumból, amely megfelel az adott jogkivonat aláírásához használt titkos kulcsnak. Ezután a megfelelő nyilvános kulccsal és a jelzett algoritmussal végezhet aláírás-ellenőrzést.

Megjegyzés

kid A jogcím használatával érvényesítheti a jogkivonatot. Bár az 1.0-s verziós jogkivonatok mind a jogcímeket, mind a x5tkid jogcímeket tartalmazzák, a 2.0-s verziós jogkivonatok csak a jogcímet kid 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 a jogcímleképezési funkció használatával egyéni aláírási kulcsokkal rendelkezik, 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, amelyet 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 tartalmaz egyjwks_uri.https://login.microsoftonline.com/{tenant}/discovery/keys?appid=6731de76-14a6-49ae-97bc-6eba6914391e

Jogcímalapú engedélyezés

Az alkalmazás üzleti logikája a jogcímalapú engedélyezést diktálja. 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 ellenőrzése

roles A jogcímekkel wids ellenőrizze, hogy a felhasználó rendelkezik-e engedéllyel az API meghívásához. Előfordulhat például, hogy egy rendszergazda engedéllyel rendelkezik az API-ba való íráshoz, de nem egy normál felhasználóhoz. Ellenőrizze, hogy a tid jogkivonat belső azonosítója megegyezik-e az ADATOK API-ban való 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őrő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 a groups hozzáférési jogkivonatban jogcímeket kérnek, ellenőrizze, hogy a felhasználó abban a csoportban van-e, amely jogosult a művelet végrehajtására.

Az implicit folyamattal lekért jogkivonatok esetében kérdezze le a Microsoft Graphot ezekről az adatokról, mivel gyakran túl nagy ahhoz, hogy elférjen a jogkivonatban.

Ne használjon email vagy upn igényeljen értékeket annak megállapítá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 suboid kombinált 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 adni az adatokhoz.

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

Ne használjon mutáns, ember által olvasható azonosítókat, például emailupn az adatok egyedi azonosításához.

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

  • scp A jogcím használatával ellenőrizze, hogy a felhasználó engedélyezte-e a hívó alkalmazásnak az API meghívását.
  • 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.
    • Csak akkor kell érvényesítenie ezeket a jogcímeket (appid, azp) ha korlátozni szeretné, hogy a webes API-t csak előre meghatározott alkalmazások (például üzletági alkalmazások vagy jól ismert előtérrendszerek által hívott webes API-k) hívják meg. A hívó alkalmazások hozzáférésének engedélyezésére szolgáló API-knak nem kell érvényesíteniü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áshoz tartozó jogkivonatok azt jelzik, hogy ez a hívás egy alkalmazásból érkezik, és nem rendelkezik olyan felhasználóval, aki támogatja azt. Ezek a jogkivonatok nagyjából azonosak:

  • A jogkivonat tulajdonosának megadott engedélyek megtekintésére használható roles .
  • 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 felhasználói hozzáférési jogkivonatokat, 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 jogkivonat-élettartam-konfigurációt használ, a frissítési jogkivonatok élettartama módosítható. Egyes jogkivonatok használata várhatóan használat nélkül is működik. 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 forgatókönyvekkel találkozhatnak, amikor a bejelentkezési kiszolgáló az életkora miatt elutasítja a frissítési jogkivonatot.

  • MaxInactiveTime: Ha a frissítési jogkivonatot nem használták a MaxInactiveTime által meghatározott 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), akkor a MaxAgeSession* idő eltelte után ú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 jelentkezik be (25 óra leteltét követően), újra be kell jelentkeznie.

Jogkivonat visszavonása

A frissítési jogkivonatokat a kiszolgáló visszavonhatja a hitelesítő adatok változása, illetve 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ó SSPR-t végez Revoked Revoked Életben marad Életben marad Életben marad
Rendszergazda jelszó alaphelyzetbe állítása 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 egy 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 az, ahol a felhasználó nem adott meg jelszót a lekéréséhez. 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