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

A hozzáférési jogkivonatok lehetővé teszik, hogy az ügyfelek biztonságosan hívjanak meg védett webes API-kat, és a webes API-k hitelesítést és engedélyezést végeznek. Az OAuth-specifikáció 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ások titkosított blobokat használnak. A Microsoft Identitásplatform a jogkivonatot elfogadó API konfigurációja alapján számos különböző hozzáférési jogkivonat-formátumot használ. Az Microsoft Identitásplatform fejlesztői által regisztrált egyéni API-k a JSON Web Tokens (JWT) két különböző formátuma közül választhatnak, az úgynevezett "v1" és "v2" formátumból, valamint a Microsoft által fejlesztett API-k, például a Microsoft Graph vagy az Azure-beli API-k további jogvédett jogkivonat-formátumokkal. Ezek a jogvédett formátumok lehetnek titkosított jogkivonatok, JWT-k vagy különleges JWT-hez hasonló jogkivonatok, amelyek nem lesznek érvényesítve.

Az ügyfeleknek a hozzáférési jogkivonatokat átlátszatlan sztringekként kell kezelniük, mert a jogkivonat tartalma csak az erőforráshoz (az API-hoz) használható. Csak ellenőrzési és hibakeresési célokra a fejlesztők JWT-ket dekódolnak egy olyan webhely használatával, mint a jwt.ms. Vegye azonban figyelembe, hogy a Microsoft API-khoz kapott jogkivonatok nem mindig JWT-k, és nem mindig dekódolhatóak.

A hozzáférési jogkivonaton belüli adatokkal kapcsolatos 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 az alkalmazás használatának hozzáférési jogkivonatának metaadatait is visszaadja. Ezek az információk tartalmazzák a hozzáférési jogkivonat lejárati idejét és azokat a hatóköreket, amelyekre érvényes. Ezek az adatok lehetővé teszik, hogy az alkalmazás intelligens gyorsítótárazást biztosít a hozzáférési jogkivonatok számára anélkül, hogy magát a hozzáférési jogkivonatot elemezné.

A következő szakaszokból megtudhatja, hogyan érvényesítheti és használhatja az API a hozzáférési jogkivonatban lévő jogcímeket.

Megjegyzés

Az oldal összes dokumentációja , kivéve a feljegyzetteket, csak a regisztrált API-khoz kiadott jogkivonatokat tartalmazza. Nem vonatkozik a Microsoft tulajdonában lévő API-khoz kiadott jogkivonatokra, és nem használhatók arra sem, hogy a Microsoft Identitásplatform hogyan ad ki jogkivonatokat egy Ön által létrehozott API-hoz.

Jogkivonat-formátumok és tulajdonjog

1.0-s és 2.0-s

A hozzáférési jogkivonatok két verziója érhető el a Microsoft Identitásplatform: 1.0-s és 2.0-s verzió. Ezek a verziók szabályozzák, hogy milyen jogcímek vannak a jogkivonatban, így biztosítva, hogy a webes API szabályozni tudja, hogyan néznek ki a jogkivonatai. A webes API-knál alapértelmezés szerint az egyik van kiválasztva a regisztráció során – a csak Azure AD-s alkalmazások esetében az 1.0-s, a fogyasztói fiókokat támogató alkalmazások esetében pedig a 2.0-s. Ezt az alkalmazásjegyzékben a beállítását használó alkalmazások vezérelik, ahol és accessTokenAcceptedVersion null 1 1.0-s tokeneket eredményeznek, és 2 v2.0-jogkivonatokat eredményeznek.

Melyik alkalmazáshoz "kell" jogkivonatot"?

A hozzáférési jogkivonat kérésében két fél vesz részt: az ügyfél, aki a jogkivonatot kéri, és az erőforrás (az API), amely az API hívásakor elfogadja a jogkivonatot. A aud jogkivonatban a jogcím azt az erőforrást jelzi, amely számára a jogkivonatot szánták (a célközönsége). Az ügyfelek használják a jogkivonatot, de nem értheti meg, és nem is kísérelheti meg az elemzési kísérletet. Az erőforrások elfogadják a jogkivonatot.

A Microsoft Identitásplatform támogatja bármely tokenverzió kiadását bármely verzióvégpontból – ezek nem kapcsolódnak egymáshoz. Ezért a erőforrás-beállítás azt jelenti, hogy az 1.0-s verzió végpontját az API-hoz jogkivonat lehívására hívó ügyfél egy accessTokenAcceptedVersion 2 2.0-s verziós hozzáférési jogkivonatot kap. Az erőforrások mindig a saját jogkivonataikhoz (a jogcímükkel együtt) vannak, és csak ezek az alkalmazások módosíthatják aud a jogkivonat részleteit. Ez az oka annak, hogy az ügyfél nem kötelező hozzáférési jogkivonat-jogcímének módosítása nem módosítja azt a hozzáférési jogkivonatot, amely akkor érkezik, amikor jogkivonatot kérnek a számára, amelynek tulajdonosa a Microsoft Graph user.read erőforrás.

Mintatokenek

Az 1.0-s és 2.0-s tokenek hasonlóak, és számos azonos jogcímet tartalmaznak. Itt egy példát mutatunk be mindegyikre. Ezek a példatokenek azonban nem ellenőrzik a-t, mivel a kulcsok a közzététel előtt váltogattak, és a személyes adatok el lett távolítva belőle.

1.0-s verzió

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSIsImtpZCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSJ9.eyJhdWQiOiJlZjFkYTlkNC1mZjc3LTRjM2UtYTAwNS04NDBjM2Y4MzA3NDUiLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC9mYTE1ZDY5Mi1lOWM3LTQ0NjAtYTc0My0yOWYyOTUyMjIyOS8iLCJpYXQiOjE1MzcyMzMxMDYsIm5iZiI6MTUzNzIzMzEwNiwiZXhwIjoxNTM3MjM3MDA2LCJhY3IiOiIxIiwiYWlvIjoiQVhRQWkvOElBQUFBRm0rRS9RVEcrZ0ZuVnhMaldkdzhLKzYxQUdyU091TU1GNmViYU1qN1hPM0libUQzZkdtck95RCtOdlp5R24yVmFUL2tES1h3NE1JaHJnR1ZxNkJuOHdMWG9UMUxrSVorRnpRVmtKUFBMUU9WNEtjWHFTbENWUERTL0RpQ0RnRTIyMlRJbU12V05hRU1hVU9Uc0lHdlRRPT0iLCJhbXIiOlsid2lhIl0sImFwcGlkIjoiNzVkYmU3N2YtMTBhMy00ZTU5LTg1ZmQtOGMxMjc1NDRmMTdjIiwiYXBwaWRhY3IiOiIwIiwiZW1haWwiOiJBYmVMaUBtaWNyb3NvZnQuY29tIiwiZmFtaWx5X25hbWUiOiJMaW5jb2xuIiwiZ2l2ZW5fbmFtZSI6IkFiZSAoTVNGVCkiLCJpZHAiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83MmY5ODhiZi04NmYxLTQxYWYtOTFhYi0yZDdjZDAxMjIyNDcvIiwiaXBhZGRyIjoiMjIyLjIyMi4yMjIuMjIiLCJuYW1lIjoiYWJlbGkiLCJvaWQiOiIwMjIyM2I2Yi1hYTFkLTQyZDQtOWVjMC0xYjJiYjkxOTQ0MzgiLCJyaCI6IkkiLCJzY3AiOiJ1c2VyX2ltcGVyc29uYXRpb24iLCJzdWIiOiJsM19yb0lTUVUyMjJiVUxTOXlpMmswWHBxcE9pTXo1SDNaQUNvMUdlWEEiLCJ0aWQiOiJmYTE1ZDY5Mi1lOWM3LTQ0NjAtYTc0My0yOWYyOTU2ZmQ0MjkiLCJ1bmlxdWVfbmFtZSI6ImFiZWxpQG1pY3Jvc29mdC5jb20iLCJ1dGkiOiJGVnNHeFlYSTMwLVR1aWt1dVVvRkFBIiwidmVyIjoiMS4wIn0.D3H6pMUtQnoJAGq6AHd

Tekintse meg ezt az 1.0-s JWT.ms.

2.0-s verzió

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSJ9.eyJhdWQiOiI2ZTc0MTcyYi1iZTU2LTQ4NDMtOWZmNC1lNjZhMzliYjEyZTMiLCJpc3MiOiJodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjQ3L3YyLjAiLCJpYXQiOjE1MzcyMzEwNDgsIm5iZiI6MTUzNzIzMTA0OCwiZXhwIjoxNTM3MjM0OTQ4LCJhaW8iOiJBWFFBaS84SUFBQUF0QWFaTG8zQ2hNaWY2S09udHRSQjdlQnE0L0RjY1F6amNKR3hQWXkvQzNqRGFOR3hYZDZ3TklJVkdSZ2hOUm53SjFsT2NBbk5aY2p2a295ckZ4Q3R0djMzMTQwUmlvT0ZKNGJDQ0dWdW9DYWcxdU9UVDIyMjIyZ0h3TFBZUS91Zjc5UVgrMEtJaWpkcm1wNjlSY3R6bVE9PSIsImF6cCI6IjZlNzQxNzJiLWJlNTYtNDg0My05ZmY0LWU2NmEzOWJiMTJlMyIsImF6cGFjciI6IjAiLCJuYW1lIjoiQWJlIExpbmNvbG4iLCJvaWQiOiI2OTAyMjJiZS1mZjFhLTRkNTYtYWJkMS03ZTRmN2QzOGU0NzQiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJhYmVsaUBtaWNyb3NvZnQuY29tIiwicmgiOiJJIiwic2NwIjoiYWNjZXNzX2FzX3VzZXIiLCJzdWIiOiJIS1pwZmFIeVdhZGVPb3VZbGl0anJJLUtmZlRtMjIyWDVyclYzeERxZktRIiwidGlkIjoiNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjQ3IiwidXRpIjoiZnFpQnFYTFBqMGVRYTgyUy1JWUZBQSIsInZlciI6IjIuMCJ9.pj4N-w_3Us9DrBLfpCt

Tekintse meg ezt a 2.0-s JWT.ms.

Jogcímek a hozzáférési jogkivonatban

A JWT-k (JSON webes jogkivonatok) három részre vannak felosztva:

  • Fejléc – Információt nyújt a jogkivonat érvényesítéséről, beleértve a jogkivonat típusának és aláírásának a mikéntje adatait.
  • Hasznos adatok – A szolgáltatást hívó felhasználó vagy alkalmazás összes fontos adatát tartalmazza.
  • Aláírás – A jogkivonat érvényesítéséhez használt nyers anyag.

Az egyes darabokat pont ( ) és külön . Base64 kódolású választja el egymástól.

A jogcímek csak akkor létezikak, ha létezik érték a kitöltéshez. Az alkalmazásnak nem szabad függőséget vennie egy jogcímtől, amely jelen van. Ilyenek például a következők: (nem minden bérlőnek van szüksége a jelszavak lejáratára), és ( az ügyfél-hitelesítő adatok folyamatait olyan alkalmazások nevében használják, amelyek nem rendelkezik pwd_exp family_name névvel). A hozzáférési jogkivonat érvényesítéséhez használt jogcímek mindig jelen lesznek.

Egyes jogcímek segítségével az Azure AD biztonságos jogkivonatokat használhat újrafelhasználás esetén. Ezek a leírásban "átlátszatlanként" vannak megjelölve, és nem nyilvános használatra vannak megjelölve. Ezek a jogcímek megjelenhetnek a jogkivonatban, és értesítés nélkül is hozzáadhatóak újak.

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áshoz 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. Az 1.0-s és a 2.0-s hozzáférési jogkivonatban is ki van bocsátva.
x5t Sztring Ugyanúgy működik (használatban és értékben), mint kid a . x5t A egy örökölt jogcím, amely csak az 1.0-s verzió hozzáférési jogkivonataiból van kiadva kompatibilitási célokra.

Hasznos terhelési 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ímzettét – a 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ú jogkivonatok esetén ez mindig az API ügyfél-azonosítója, míg az 1.0-s verziójú jogkivonatok esetén ez lehet a kérésben használt ügyfél-azonosító vagy erőforrás URI, attól függően, hogy az ügyfél hogyan kérte le a jogkivonatot.
iss Sztring, STS URI Azonosítja a biztonsági jogkivonat-szolgáltatást (STS), amely a jogkivonatot hoz létre és ad vissza, valamint azt az Azure AD-bérlőt, amelyben a felhasználó hitelesítése történt. Ha a kiállított jogkivonat v2.0 jogkivonat (lásd a jogcímet), az ver URI a következőre végződik: /v2.0 . A guid azonosító, amely azt jelzi, hogy a felhasználó felhasználó egy Microsoft-fiók 9188040d-6c67-4c5b-b112-36a304b66dad felhasználó. Az alkalmazás a jogcím GUID részét használva korlátozhatja az alkalmazásba bejelentkező bérlők halmazát, ha van ilyen.
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ó 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ó – vendégek. Ha a jogcím nincs jelen, az azt jelenti, hogy a értéke iss használható helyette. 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ében a jogcím lehet "live.com" vagy egy STS URI, amely a Microsoft-fiók idp bérlőt 9188040d-6c67-4c5b-b112-36a304b66dad tartalmazza.
iat int, UNIX időbélyeg A "Kibocsátó" azt jelzi, hogy mikor történt a jogkivonat hitelesítése.
nbf int, UNIX időbélyeg Az "nbf" (nem előtte) jogcím azonosítja azt az időt, amely előtt a JWT nem fogadható el feldolgozásra.
exp int, UNIX időbélyeg Az "exp" (lejárati idő) jogcím azonosítja azt a lejárati időt, amely után a JWT nem fogadható el feldolgozásra. Fontos megjegyezni, hogy ennél az időpont előtt egy erőforrás is elutasíthatja a jogkivonatot, például ha változásra van szükség a hitelesítésben, vagy jogkivonat-visszavonást észleltek.
aio Átlátszatlan sztring Az Azure AD által az adatok jogkivonatok újbóli felhasználására való rögzítésére használt belső jogcím. Az erőforrások nem használják ezt a jogcímet.
acr Sztring, "0" vagy "1" Csak az 1.0-s tokenben van jelen. A "Hitelesítési környezet osztálya" jogcím. A "0" érték 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 az 1.0-s tokenben van jelen. A jogkivonat tulajdonosának hitelesítésének a mikéntje. További részletekért tekintse meg az amr claim szakaszt.
appid Sztring, GUID Csak az 1.0-s tokenben van jelen. A jogkivonatot használó ügyfél alkalmazásazonosítója. Az alkalmazás saját magaként vagy egy felhasználó nevében is viselkedhet. Az alkalmazásazonosító általában egy alkalmazásobjektumot képvisel, de egy szolgáltatásnév-objektumot is képviselhet az Azure AD-ban.
azp Sztring, GUID Csak a 2.0-s tokenben van jelen, a appid helyett. A jogkivonatot használó ügyfél alkalmazásazonosítója. Az alkalmazás saját magaként vagy egy felhasználó nevében is viselkedhet. Az alkalmazásazonosító általában egy alkalmazásobjektumot képvisel, de egy szolgáltatásnév-objektumot is képviselhet az Azure AD-ban.
appidacr "0", "1" vagy "2" Csak az 1.0-s tokenben van jelen. Azt jelzi, hogyan történt az ügyfél hitelesítése. Nyilvános ügyfélnél az érték "0". Ha az ügyfél-azonosítót és a titkos ügyféltitkot használja, az érték "1". Ha a hitelesítéshez ügyfél-tanúsítványt használtak, az érték "2".
azpacr "0", "1" vagy "2" Csak a 2.0-s tokenben van jelen, a appidacr helyett. Azt jelzi, hogyan történt az ügyfél hitelesítése. Nyilvános ügyfélnél az érték "0". Ha az ügyfél-azonosítót és a titkos ügyféltitkot használja, az érték "1". Ha a hitelesítéshez ügyfél-tanúsítványt használtak, az érték "2".
preferred_username Sztring A felhasználót képviselő elsődleges felhasználónév. Ez lehet egy e-mail-cím, telefonszám vagy egy általános felhasználónév megadott formátum nélkül. Az értéke változtatható, és idővel változhat. Mivel ez az érték nem állítható be, nem használható engedélyezési döntések meghozatalához. Használható azonban felhasználónevekre vonatkozó tippekhez, és olvasható felhasználói felületen felhasználónévként. A jogcím fogadásához szükség profile van a hatókörre. Csak a 2.0-s tokenben van jelen.
name Sztring Emberi olvasásra alkalmas értéket ad meg, amely azonosítja a jogkivonat tárgyát. Az érték nem garantáltan egyedi, hanem testreszabható, és úgy van kialakítva, hogy csak megjelenítési célokra legyen használható. A jogcím fogadásához szükség profile van a hatókörre.
scp Sztring, a hatókörök szóközöktől elválasztott listája Az alkalmazás által elérhetővé tért hatókörök halmaza, amelyekhez az ügyfélalkalmazás jóváhagyást kért (és kapott). Az alkalmazásnak ellenőriznie kell, hogy ezek a hatókörök érvényesek-e, és meg kell hoznia az engedélyezési döntéseket a hatókörök értéke alapján. Csak a felhasználói jogkivonatok esetén szerepel.
roles Sztringek tömbje, engedélyek listája Az alkalmazás által felfedett engedélyek, amelyek hívásához a kérelmező alkalmazás vagy felhasználó engedélyt kapott. Alkalmazás-jogkivonatok használatasorán a rendszer ezt használja az ügyfél-hitelesítő adatok folyamatában (v1.0, v2.0) a felhasználói hatókörök helyére. Felhasználói jogkivonatoknál ez a célalkalmazásban a felhasználóhoz rendelt szerepkörökkel lesz feltöltve.
wids RoleTemplateID GUID azonosítók tömbje A felhasználóhoz rendelt, bérlői szintű szerepköröket jelöli az Azure ADbeépített szerepkörei szakaszban. Ez a jogcím alkalmazásonként van konfigurálva az alkalmazásjegyzék groupMembershipClaims tulajdonságával. Az "Összes" vagy a "DirectoryRole" beállításra van szükség. Előfordulhat, hogy az implicit folyamaton keresztül lekért jogkivonatok nem feltétlenül hatnak a jogkivonatok hosszára.
groups GUID azonosítók JSON-tömbje Az érintett csoporttagságokat képviselő objektum-objektumokat biztosít. Ezek az értékek egyediek (lásd az objektumazonosítót), és biztonságosan használhatók a hozzáférés kezeléséhez, például egy erőforrás elérésére vonatkozó engedélyezés kényszerítése. A csoport jogcímben szereplő csoportokat a rendszer alkalmazásonként konfigurálja az alkalmazásjegyzék groupMembershipClaims tulajdonságával. A null érték az összes csoportot kizárja, a "SecurityGroup" érték csak Active Directory biztonságicsoport-tagságokat tartalmaz, az "Összes" érték pedig a biztonsági csoportokat és a Microsoft 365 terjesztési listákat is.

A jogcím implicit engedélyekkel való használatával kapcsolatos részletekért tekintse meg hasgroups groups az alábbi jogcímet.
Más folyamatok esetében, ha a felhasználó csoportszáma túllép egy korlátot (SAML esetén 150, JWT esetén 200), akkor a rendszer hozzáad egy túlcsatolási jogcímet a microsoftos Graph-végpontra hivatkozó jogcímforrásokhoz, amely a felhasználó csoportlistát tartalmazza.
hasgroups Logikai Ha jelen van, mindig , a felhasználó jelölése true legalább egy csoportban van. A JWT-k jogcíme helyére kerül az implicit engedélyfolyamatok esetében, ha a teljes csoportok jogcíme kiterjeszti az URI-töredéket az URL-cím hosszkorlátján túlra (jelenleg 6 vagy több groups csoport). Azt jelzi, hogy az ügyfélnek a Microsoft Graph API-t kell használnia a felhasználói csoportok meghatározásához ( https://graph.microsoft.com/v1.0/users/{userID}/getMemberObjects ).
groups:src1 JSON-objektum A nem korlátozott hosszúságú (lásd fent) jogkivonat-kérelmeknél, de még mindig túl nagy a jogkivonathoz, a felhasználó teljes csoportok listájára mutató hivatkozás hasgroups is megjelenik. A JWT-k elosztott jogcímként való igénylése az SAML-hez a jogcím helyére új groups jogcímként.

JWT-példaérték:
"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 adatokat érvényesít, például egy alkalmazás felhasználója. Ez az érték nem módosítható, és nem lehet újból hozzárendelni vagy újra felhasználni. Használható az engedélyezési ellenőrzések biztonságos végrehajtásához, például ha a jogkivonattal fér hozzá egy erőforráshoz, és kulcsként használható az adatbázistáblákban. Mivel a tárgy mindig jelen van az Azure AD által kihozott jogkivonatban, javasoljuk, hogy ezt az értéket használja egy általános célú engedélyezési rendszerben. A tárgy azonban egy párosított azonosító , amely egyedi egy adott alkalmazásazonosítóhoz. Ezért ha egyetlen felhasználó két különböző alkalmazásba jelentkezik be két különböző ügyfél-azonosítóval, ezek az alkalmazások két különböző értéket kapnak a tárgy jogcíméhez. Ez az architektúrától és az adatvédelmi követelményektől függően előfordulhat, hogy erre nincs szükség. Lásd még a jogcímet (amely a bérlőn oid belüli alkalmazásokban változatlan marad).
oid Sztring, GUID A kérelem "rendszerbiztonsági tagjának" nem módosítható azonosítója – az a felhasználó vagy szolgáltatásnév, akinek az identitása ellenőrizve lett. Az Azonosító jogkivonatok és az alkalmazás+felhasználói jogkivonatok esetén ez a felhasználó objektumazonosítója. A csak alkalmazás jogkivonatai esetén ez a hívó szolgáltatásnév objektumazonosítója. Arra is használható, hogy biztonságosan és kulcsként végezze el az engedélyezési ellenőrzéseket az adatbázistáblákban. Ez az azonosító egyedileg azonosítja a rendszerbiztonsági tagokat az alkalmazásokban – az ugyanazon felhasználóba bejelentkező két különböző alkalmazás ugyanazt az értéket fogja kapni a oid jogcímben. A tehát akkor használható, amikor lekérdezéseket készít a Microsoft online szolgáltatások, például oid a Microsoft Graph. A Microsoft Graph ezt az azonosítót adja vissza id tulajdonságként egy adott felhasználói fiókhoz. Mivel a lehetővé teszi, hogy több alkalmazás korreláljon a rendszerbiztonsági tagokkal, a hatókörre azért van szükség, hogy a felhasználók megkapják ezt a oid profile jogcímet. Vegye figyelembe, hogy ha egy felhasználó több bérlőben is létezik, a felhasználó minden bérlőben más objektumazonosítót fog tartalmazni – akkor is különböző fiókoknak minősül, ha mindegyik 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ók bé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ása esetén az alkalmazásnak le kell kérnie a profile hatókört.
unique_name Sztring Csak az 1.0-s tokenben van jelen. 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 Átlátszatlan sztring Az Azure által a jogkivonatok újraértékeléseként használt belső jogcím. Az erőforrásoknak nem szabad ezt a jogcímet használniuk.
rh Átlátszatlan sztring Az Azure által a jogkivonatok újraértékeléseként használt belső jogcím. Az erőforrások nem használhatják ezt a jogcímet.
ver Sztring, 1.0 vagy 2.0 A hozzáférési jogkivonat verzióját jelzi.

Csoportokra vonatkozó túlóraigény

Annak érdekében, hogy a jogkivonat mérete ne haladja meg a HTTP-fejléc méretkorlátját, az Azure AD korlátozza a csoport jogcímbe foglalható objektum-azonosítók számát. Ha egy felhasználó több csoport tagja, mint a túllépő korlát (SAML-jogkivonatok esetén 150, JWT-jogkivonatok esetén 200, és csak 6, ha implicit folyamaton keresztül van kibocsátva), akkor az Azure AD nem bocsátja ki a jogkivonatban a csoport jogcímet. Ehelyett a jogkivonat tartalmaz egy overage jogcímet, amely azt jelzi az alkalmazásnak, hogy lekérdezi a Microsoft Graph API-t 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]"
        }
       }
     }
  ...
}

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

1.0-s alapszintű jogcímek

Az 1.0-s és a 2.0-s tokenek alapértelmezés szerint nem tartalmazzák a következő jogcímeket. Ha a 2.0-s és valamelyik jogcímre van szüksége, opcionális jogcímek használatával kérheti ő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 Olyan esetekben, amikor a felhasználó helyszíni hitelesítéssel rendelkezik, ez a jogcím biztosítja a biztonsági azonosítóját. A régi onprem_sid alkalmazásokban a használatával is használható az engedélyezés.
pwd_exp int, UNIX időbélyeg Azt jelzi, hogy mikor jár le a felhasználó jelszava.
pwd_url Sztring Egy URL-cím, ahol a felhasználók új jelszót kérnek.
in_corp boolean Jelzi, ha az ügyfél a vállalati hálózatról jelentkezik be. Ha nem, a jogcím nem lesz benne.
nickname Sztring A felhasználó további neve, a vezetéknévtől és a vezetéknévtől elkülönítve.
family_name Sztring A felhasználó vezetéknevét, vezetéknevét vagy családnevét határozza meg a felhasználói objektumban meghatározottak szerint.
given_name Sztring A felhasználó első vagy megadott nevét adja meg a felhasználói objektumon beállítottak szerint.
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-tippeket kell használni az újrahitelesítési forgatókönyvekben.

A amr jogcím

A Microsoft-identitások különböző módokon hitelesíthetők, ami az ön alkalmazása szempontjából fontos lehet. A jogcím egy tömb, amely több elemet is tartalmazhat ( például ) egy olyan hitelesítéshez, amely jelszót és a Authenticator amr ["mfa", "rsa", "pwd"] is.

Érték Leírás
pwd Jelszóhitelesítés: a felhasználó Microsoft-jelszava vagy egy alkalmazás titkos ügyféltitkja.
rsa A hitelesítés egy RSA-kulcs igazolásán alapult, például a Microsoft Authenticator alkalmazással. Ebbe beletartozik az is, hogy a hitelesítést egy önaírt JWT végzett-e egy szolgáltatás tulajdonában lévő X509-tanúsítvánnyal.
otp Egy alkalommal használt PIN-kód e-mailben vagy szöveges üzenetben.
fed Összevont hitelesítési helyességi feltételt (például JWT vagy SAML) használtunk.
wia Windows Integrált hitelesítés
mfa Többtényezős hitelesítést használtunk. Ha ez jelen van, a többi hitelesítési módszer is szerepelni fog benne.
ngcmfa A mfa típussal egyenértékű, amely bizonyos speciális hitelesítőadat-típusok építéshez használatos.
wiaormfa A felhasználó egy Windows MFA hitelesítő adatait használta 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 a jogkivonatot kérő ügyfélalkalmazástól függően változik. Például a folyamatos hozzáférés-kiértékelési (CAE) képes ügyfelek, amelyek CAE-kompatibilis munkameneteket egyeztetnek, hosszú élettartamú (legfeljebb 28 órás) jogkivonat-élettartamot fognak látni. Amikor a hozzáférési jogkivonat lejár, az ügyfélnek a frissítési jogkivonat használatával (általában csendesen) be kell szereznie egy új frissítési jogkivonatot és hozzáférési jogkivonatot.

A hozzáférési jogkivonatok élettartamának módosításával szabályozhatja, hogy az ügyfélalkalmazás milyen gyakran járjon le az alkalmazás-munkamenet lejártakor, és milyen gyakran igényli a felhasználótól az újra hitelesítést (beavatkozás nélkül vagy interaktív módon). További információ: Configurable token lifetimes (Konfigurálható jogkivonatok élettartamának konfigurálása).

Jogkivonatok érvényesése

Nem minden alkalmazásnak kell érvényesítenie a jogkivonatokat. Az alkalmazások csak bizonyos esetekben érvényesítsen egy jogkivonatot:

  • A webes API-knak ellenőrizniük kell az ügyfél által nekik küldött hozzáférési jogkivonatokat. Csak a jogcímet tartalmazó jogkivonatokat kell aud elfogadniuk.
  • A bizalmas webalkalmazások ASP.NET Core például a ASP.NET Core ellenőrizniük kell a hibrid folyamat felhasználói böngészőjében küldött azonosító jogkivonatokat, 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 hasznosnak tenni a jogkivonat érvényességének érvényességét, és biztonsági és megbízhatósági kockázatot is jelent, ha a jogkivonat érvényességén alapuló döntéseket hoz. A nyilvános ügyfelek, például a natív alkalmazások vagy az spA-k nem ellenőrzik a jogkivonatokat – az alkalmazás közvetlenül kommunikál az internetszolgáltatóval, így az SSL-védelem biztosítja a jogkivonatok érvényességét.

Az API-k és a webalkalmazások csak olyan jogkivonatokat érvényesíthetnek, amelyek jogcíme megfelel az alkalmazásuknak; más erőforrások egyéni jogkivonat-érvényesítési aud szabályokkal is lehetnek. Például a Microsoft-Graph jogkivonatai a saját formátumuk miatt nem ellenőrzik ezeket a szabályokat. A más erőforráshoz szánt jogkivonatok érvényességének és elfogadásának problémája egy példa a zavaros problémára.

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

A következő információkat azok számára biztosítjuk, akik meg szeretnék érteni a mögöttes folyamatot. Az Azure AD middleware beépített képességekkel rendelkezik a hozzáférési jogkivonatok stb. stb., és a mintáink között tallózva megkeresheti a megfelelőt a választott nyelven. Számos külső, nyílt forráskódú kódtár is elérhető a JWT-ellenőrzéshez – legalább egy lehetőség áll rendelkezésre szinte minden platformhoz és nyelvhez. Az Azure AD hitelesítési kódtárakkal és kódmintákkal kapcsolatos további információkért lásd a hitelesítési kódtárakat.

Az aláírás érvényességének ellenőrzés

A JWT három szegmenst tartalmaz, amelyeket a karakter választ . el egymástól. Az első szegmens a fejléc, a második a törzs, a harmadik pedig az aláírás. Az aláírási szegmens segítségével ellenőrizheti a jogkivonat hitelességét, így az alkalmazás megbízhatónak használhatja.

Az Azure AD által kiadott jogkivonatok az iparági szabvány aszimmetrikus titkosítási algoritmusok, például az RS256 használatával vannak aláírva. A JWT fejléce a jogkivonat aláírási kulcsával és titkosítási módszerével kapcsolatos információkat tartalmaz:

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

A jogcím jelzi a jogkivonat aláíráshoz használt algoritmust, míg a jogcím a jogkivonat érvényesítéséhez használt adott nyilvános alg kid kulcsot jelöli.

Az Azure AD bármikor aláírhat egy id_token nyilvános-titkos kulcspárok bármelyikének használatával. Az Azure AD rendszeres időközönként váltogatja a lehetséges kulcskészleteket, ezért az alkalmazást úgy kell megírni, hogy automatikusan kezelje ezeket a kulcsváltozásokat. Az Azure AD által használt nyilvános kulcsok frissítéseit ésszerű gyakorisággal 24 óránként kell ellenőrizni.

Az aláírás ellenőrzéséhez szükséges aláírókulcs-adatokat a következő helyen található OpenID Csatlakozás metaadatok dokumentumával szerezheti be:

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

Tipp

Próbálja ki ezt az URL-címet egy böngészőben!

Ez a metaadat-dokumentum:

  • Egy JSON-objektum, amely számos hasznos információt tartalmaz, például az OpenID-hitelesítéshez szükséges különböző végpontok Csatlakozás helyét.
  • Tartalmaz egy et, amely a jogkivonatok aláíráshoz használt titkos kulcsoknak megfelelő nyilvános kulcsok jwks_uri halmazának helyét adja meg. A JSON-webkulcs (JWK) az adott pillanatban használt összes nyilvánoskulcs-információt jwks_uri tartalmazza. A JWK formátum leírását az RFC 7517 szabvány ismerteti. Az alkalmazás a JWT fejlécében található jogcím használatával kiválaszthatja a nyilvános kulcsot ebből a dokumentumból, amely megfelel egy adott jogkivonat aláírására használt titkos kid kulcsnak. Ezután a megfelelő nyilvános kulccsal és a jelzett algoritmussal képes aláírás-ellenőrzést is.

Megjegyzés

Javasoljuk, hogy a kid jogkivonat érvényesítéséhez használja a jogcímet. Bár az 1.0-s tokenek a és a jogcímet is x5t kid tartalmazzák, a 2.0-s tokenek csak a kid jogcímet tartalmazzák.

Az aláírás-ellenőrzés ezen dokumentum hatókörét nem tartalmazza – szükség esetén számos nyílt forráskódú kódtár érhető el. A tanúsítvány Microsoft Identitásplatform jogkivonat-aláíró bővítményt is ad a szabványokhoz: az egyéni aláírókulcsokat.

Ha az alkalmazás a jogcím-leképezési funkció használatának eredményeként egyéni aláírókulcsokkal rendelkezik, az alkalmazásazonosítót tartalmazó lekérdezési paramétert kell hozzáfűznie, hogy az alkalmazás aláírókulcs-információira mutasson, amelyet az ellenőrzéshez kell appid jwks_uri használni. Például: a https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration?appid=6731de76-14a6-49ae-97bc-6eba6914391e egy fájlját jwks_uri https://login.microsoftonline.com/{tenant}/discovery/keys?appid=6731de76-14a6-49ae-97bc-6eba6914391e tartalmazza.

Jogcímalapú engedélyezés

Ezt a lépést az alkalmazás üzleti logikája határozza meg. Az alábbiakban néhány gyakori engedélyezési módszert is meghatározunk.

  • A jogcím aud használatával győződjön meg arról, hogy a felhasználó meg kellett hívnia az alkalmazást. Ha az erőforrás azonosítója nem az igényben aud van, akkor visszautasítsa.
  • A jogcím használatával ellenőrizheti, hogy a felhasználó megadta-e a hívó alkalmazásnak az scp API hívásához szükséges engedélyt.
  • A és jogcímek használatával ellenőrizheti, hogy a felhasználó rendelkezik-e roles wids engedéllyel az API hí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ó.
  • Győződjön meg arról, hogy a hívó ügyfélnek engedélyezve van az API hívása a jogcím appid használatával.
  • Ellenőrizze, hogy tid a megfelel-e egy olyan bérlőnek, amely számára engedélyezett az API hívása.
  • A jogcím amr használatával ellenőrizze, hogy a felhasználó végrehajtotta-e az MFA-t. Ezt feltételes hozzáféréssel kell kikényszeríteni.
  • Ha a hozzáférési jogkivonatban a vagy jogcímeket kérte, ellenőrizze, hogy a felhasználó a csoportban van-e, amely számára engedélyezett roles groups a művelet.
    • Az implicit folyamattal lekért jogkivonatok esetén valószínűleg le kell majdkérdezni a Microsoft Graph-t ezekért az adatokért, mivel az gyakran túl nagy ahhoz, hogy elférjen a jogkivonatban.

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

Az alkalmazás jogkivonatokat kaphat a felhasználó számára (a folyamat általában tárgyalt) vagy közvetlenül egy alkalmazásból (az ügyfél-hitelesítő adatok folyamatán keresztül). Ezek a csak alkalmazásra vonatkozó jogkivonatok azt jelzik, hogy a hívás egy alkalmazásból érkezik, és nincs felhasználó, akiről biztonsági lenne. Ezek a jogkivonatok kezelése nagyrészt megegyezik:

  • A használatával a jogkivonat tárgyának megadott roles engedélyeket láthatja.
  • A vagy a használatával ellenőrizheti, hogy a hívó oid sub szolgáltatásnév a várt szolgáltatás-e.

Ha az alkalmazásnak különbséget kell tennie a csak alkalmazásra vonatkozó hozzáférési jogkivonatok és a felhasználók hozzáférési jogkivonatai között, használja a idtyp választható jogcímet. Ha hozzáadja a jogcímet a mezőhöz, és ellenőrzi a értéket, észlelheti a csak alkalmazásra vonatkozó hozzáférési idtyp accessToken app jogkivonatokat. 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 bármikor érvénytelenhetők vagy visszavonhatóak, különböző okokból. Ezek két fő kategóriába sorolhatók: időtúllépések és visszavonások.

Jogkivonatok időtúllépései

A jogkivonat élettartam-konfigurációjánakhasználatával a frissítési jogkivonatok élettartama módosítható. Bizonyos jogkivonatok használat nélküli használata normális és elvárt (például ha a felhasználó 3 hónapig nem nyitja meg az alkalmazást), ezért lejár. Az alkalmazások olyan forgatókönyveket fognak látni, amelyekben 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 megszabott idő alatt, a frissítési jogkivonat többé nem lesz érvényes.
  • MaxSessionAge: Ha a MaxAgeSessionMultiFactor vagy a MaxAgeSessionSingleFactor nem az alapértelmezettre van beállítva (visszavonásig), akkor a MaxAgeSession* eltelte után újrahitelesítésre lesz szükség.
  • Angol nyelvű Példák:
    • A bérlő maxInactiveTime (MaxInactiveTime) értékében öt nap van, és a felhasználó egy hétig szabadságon volt, ezért az Azure AD 7 napja nem látott új jogkivonat-kérelmet a felhasználótól. Amikor a felhasználó legközelebb új jogkivonatot kér, azt fogja látni, hogy a frissítési jogkivonat vissza lett vonva, és újra meg kell adnia a hitelesítő adatait.
    • A bizalmas alkalmazások maxAgeSessionSingleFactor (MaxAgeSessionSingleFactor) értékében egy nap van. Ha egy felhasználó hétfőn és keddként (25 óra eltelte után) jelentkezik be, újra kell hitelesülnie.

Visszavonási

A frissítési jogkivonatokat a kiszolgáló visszavonhatja a hitelesítő adatok módosítása, illetve a használat vagy a rendszergazdai művelet miatt. A frissítési jogkivonatok két osztályba esnek – a bizalmas ügyfeleknek kiadottakba (a jobb szélső oszlopba), valamint a nyilvános ügyfelek számára kiadottakba (minden más oszlopba).

Módosítás Jelszóalapú cookie Jelszóalapú jogkivonat Nem jelszóalapú cookie Nem jelszóalapú jogkivonat Bizalmas ügyféltoken
A jelszó lejár Életben marad Életben marad Életben marad Életben marad Életben marad
A felhasználó módosította a jelszót Revoked Revoked Életben marad Életben marad Életben marad
A felhasználó SSPR-t tesz Revoked Revoked Életben marad Életben marad Életben marad
A rendszergazda új jelszót kér Revoked Revoked Életben marad Életben marad Életben marad
A felhasználó a PowerShellen keresztül vonja vissza a frissítési jogkivonatokat Revoked Revoked Revoked Revoked Revoked
A 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ért fiókhoz. Példák nem jelszóalapú bejelentkezésre:

  • 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 jogkivonatok adatokat.

Következő lépések