Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
Az OAuth 2.0 ügyfél hitelesítő adatok engedélyezési folyamata lehetővé teszi, hogy egy webszolgáltatás (bizalmas ügyfél) a saját hitelesítő adatait használja ahelyett, hogy egy felhasználót megszemélyesítene, amikor egy másik webszolgáltatás hívásakor hitelesítésre van szükség. Az RFC 6749-ben megadott, más néven két lábú OAuth-támogatás egy alkalmazás identitásának használatával használható a webes erőforrások eléréséhez. Ezt a típust gyakran használják olyan kiszolgáló–kiszolgáló interakciókhoz, amelyeknek a háttérben kell futniuk anélkül, hogy azonnali interakciót kell végezni egy felhasználóval, és gyakran démonoknak vagy szolgáltatásfiókoknak is nevezik.
Az ügyfél hitelesítő adatainak folyamatában az engedélyeket közvetlenül magának az alkalmazásnak adja meg egy rendszergazda. Amikor az alkalmazás jogkivonatot ad egy erőforrásnak, az erőforrás kényszeríti, hogy maga az alkalmazás is rendelkezik engedéllyel egy művelet végrehajtására, mivel nincs felhasználó, aki részt vesz a hitelesítésben. Ez a cikk az alábbiakhoz szükséges lépéseket ismerteti:
- Api meghívásának engedélyezése egy alkalmazás számára
- Az API meghívásához szükséges jogkivonatok lekérése.
Ez a cikk azt ismerteti, hogyan alkalmazhatja közvetlenül a protokollt az alkalmazásában. Ha lehetséges, javasoljuk, hogy a microsoftos hitelesítési kódtárak (MSAL) használatával jogkivonatokat szerezzen be, és biztonságos webes API-kat hívjon. Az MSAL-t használó mintaalkalmazásokra is hivatkozhat. Érdemes megjegyezni, hogy ezzel a folyamattal soha nem kapnak frissítési jogkivonatokat, mivel a client_id
és a client_secret
(amelyek a frissítési jogkivonat beszerzéséhez szükségesek lennének) a hozzáférési jogkivonatok beszerzésére használhatók helyette.
A magasabb szintű megbízhatóság érdekében a Microsoft identitásplatformja lehetővé teszi a hívó szolgáltatás számára, hogy közös titkos kulcs helyett tanúsítvány vagy összevont hitelesítő adatok használatával hitelesítse magát. Mivel az alkalmazás saját hitelesítő adatait használják, ezeket a hitelesítő adatokat biztonságban kell tartani. Ezt a hitelesítő adatot soha ne tegye közzé a forráskódban, ne ágyazza be weblapba, és ne használja széles körben elosztott natív alkalmazásban.
Protokolldiagram
A teljes ügyfél-hitelesítőadat-folyamat az alábbi diagramhoz hasonlóan néz ki. A cikk későbbi részében ismertetjük az egyes lépéseket.
Közvetlen engedélyezés lekérése
Az alkalmazások általában két módon kapnak közvetlen engedélyt egy erőforrás elérésére:
- Hozzáférés-vezérlési listán (ACL) keresztül az erőforráson
- Alkalmazásengedély-hozzárendelés a Microsoft Entra-azonosítóban
Ez a két módszer a Leggyakoribb a Microsoft Entra-azonosítóban, és az ügyfél-hitelesítő adatokat kezelő ügyfeleknek és erőforrásoknak ajánljuk őket. Az erőforrás választhat úgy is, hogy más módon engedélyezi az ügyfeleit. Minden erőforrás-kiszolgáló kiválaszthatja azt a metódust, amely a legérthetőbb az alkalmazás számára.
Hozzáférés-vezérlési listák
Az erőforrás-szolgáltató kikényszeríthet egy engedélyezési ellenőrzést az általa ismert és meghatározott szintű hozzáférést biztosító alkalmazás-(ügyfél-) azonosítók alapján. Amikor az erőforrás jogkivonatot kap a Microsoft identitásplatformjáról, akkor dekódolhatja a jogkivonatot, és kinyerheti az ügyfél alkalmazásazonosítóját a appid
és iss
jogcímekből. Ezután összehasonlítja az alkalmazást egy általa karbantartott hozzáférés-vezérlési listával (ACL). Az ACL részletessége és módszere jelentősen eltérhet az erőforrások között.
Gyakori használati eset, ha egy ACL használatával futtat teszteket egy webalkalmazáshoz vagy egy webes API-hoz. Előfordulhat, hogy a webes API csak a teljes engedélyek egy részét adja meg egy adott ügyfélnek. Az API-n a végpontok közötti tesztek futtatásához létrehozhat egy tesztügyfélt, amely jogkivonatokat szerez be a Microsoft identitásplatformjáról, majd elküldi őket az API-nak. Az API ezután ellenőrzi a tesztügyfél alkalmazásazonosítóját az ACL-ben, hogy teljes mértékben hozzáférhessen az API teljes működéséhez. Ha ilyen típusú ACL-t használ, győződjön meg arról, hogy nem csak a hívó appid
értékét ellenőrzi, hanem azt is, hogy a iss
jogkivonat értéke megbízható-e.
Ez a fajta engedélyezés gyakori az olyan démonok és szolgáltatásfiókok esetében, amelyeknek személyes Microsoft-fiókkal rendelkező felhasználóik adataihoz kell hozzáférniük. A szervezetek tulajdonában lévő adatok esetében azt javasoljuk, hogy az alkalmazásengedélyeken keresztül szerezze be a szükséges engedélyeket.
Tokenek szabályozása állítás roles
nélkül
Az ACL-alapú engedélyezési minta alkalmazásához a Microsoft Entra ID nem követeli meg, hogy az alkalmazások másik alkalmazáshoz jogkivonatokat szerezzenek be. Így a csak alkalmazásos tokenek kiadhatók jogcím nélkül roles
. Az API-kat elérhetővé tevő alkalmazásoknak engedélyellenőrzéseket kell végrehajtaniuk a jogkivonatok elfogadásához.
Ha meg szeretné akadályozni, hogy az alkalmazások csak szerepkör nélküli hozzáférési jogkivonatokat kaphassanak az alkalmazáshoz, győződjön meg arról, hogy a hozzárendelési követelmények engedélyezve vannak az alkalmazás számára. Ez megakadályozza, hogy a hozzárendelt szerepkörök nélküli felhasználók és alkalmazások jogkivonatot szerezzenek be ehhez az alkalmazáshoz.
Alkalmazásengedélyek
Az ACL-ek használata helyett API-k használatával közzéteheti az alkalmazásengedélyek egy készletét. Ezeket egy alkalmazásnak a szervezet rendszergazdája biztosítja, és csak az adott szervezet és alkalmazottai által birtokolt adatok elérésére használható. A Microsoft Graph például számos alkalmazásengedélyt tesz elérhetővé a következők végrehajtásához:
- E-mailek olvasása az összes postaládában
- E-mailek olvasása és írása minden postaládában
- E-mail küldése akármelyik felhasználóként
- Címtáradatok olvasása
Ha az alkalmazásszerepköröket (alkalmazásengedélyeket) saját API-val szeretné használni (szemben a Microsoft Graphtal), először el kellérhetővé tennie az alkalmazásszerepköröket az API alkalmazásregisztrációjában a Microsoft Entra felügyeleti központban. Ezután konfigurálja a szükséges alkalmazásszerepköröket úgy, hogy kiválasztja ezeket az engedélyeket az ügyfélalkalmazás alkalmazásregisztrációjában. Ha nem adott meg alkalmazásszerepköröket az API alkalmazásregisztrációjában, az ügyfélalkalmazás alkalmazásregisztrációjában nem fog tudni alkalmazásengedélyeket megadni az adott API-hoz a Microsoft Entra felügyeleti központban.
Alkalmazásként történő hitelesítéskor (a felhasználóval ellentétben) nem használhat delegált engedélyeket , mert nincs olyan felhasználó, aki az alkalmazás nevében járjon el. Olyan alkalmazásengedélyeket, más néven alkalmazásszerepköröket kell használnia, amelyeket egy rendszergazda vagy az API tulajdonosa ad meg.
További információ az alkalmazásengedélyekről: Engedélyek és hozzájárulás.
Ajánlott: Jelentkezzen be rendszergazdaként az alkalmazásba, hogy hozzárendelhessék az alkalmazás szerepköreit.
Amikor alkalmazásengedélyeket használó alkalmazást hoz létre, az alkalmazáshoz általában olyan lapra vagy nézetre van szükség, amelyen a rendszergazda jóváhagyja az alkalmazás engedélyeit. Ez a lap része lehet az alkalmazás bejelentkezési folyamatának, az alkalmazás beállításainak, vagy egy dedikált csatlakozási folyamatnak. Az alkalmazás gyakran csak akkor jeleníti meg ezt a kapcsolódási nézetet, ha egy felhasználó munkahelyi vagy iskolai Microsoft-fiókkal jelentkezett be.
Ha bejelentkezik az alkalmazásba, azonosíthatja azt a szervezetet, amelyhez a felhasználó tartozik, mielőtt megkérné a felhasználót az alkalmazásengedélyek jóváhagyására. Bár nem feltétlenül szükséges, ez segíthet intuitívabb felhasználói élmény kialakításában. A felhasználó bejelentkezéséhez kövesse a Microsoft identity platform protokolljának oktatóanyagait.
Engedélyek kérése címtáradminisztrátortól
Ha készen áll arra, hogy engedélyt kérjen a szervezet rendszergazdájától, átirányíthatja a felhasználót a Microsoft identitásplatform rendszergazdai hozzájárulási végpontjára.
// Line breaks are for legibility only.
GET https://login.microsoftonline.com/{tenant}/adminconsent?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&state=12345
&redirect_uri=http://localhost/myapp/permissions
Pro tipp: Próbálja meg beilleszteni a következő kérést egy böngészőbe.
https://login.microsoftonline.com/common/adminconsent?client_id=00001111-aaaa-2222-bbbb-3333cccc4444&state=12345&redirect_uri=http://localhost/myapp/permissions
Paraméter | Állapot | Leírás |
---|---|---|
tenant |
Kötelező | Az a bérlő, amelytől engedélyt szeretne kérni. Ez lehet GUID vagy olvasóbarát névformátum. Ha nem tudja, hogy a felhasználó melyik bérlőhöz tartozik, és szeretné engedélyezni, hogy bármelyik bérlővel jelentkezzen be, használja a következőt common : . |
client_id |
Kötelező | Az alkalmazás (ügyfél) azonosítója, amelyet a Microsoft Entra felügyeleti központ – Alkalmazásregisztrációk élmény rendelt az alkalmazásodhoz. |
redirect_uri |
Kötelező | Az átirányítási URI, ahová a választ el szeretné küldeni az alkalmazás számára. Pontosan meg kell egyeznie a portálon regisztrált átirányítási URI-k egyikével, azzal a kivételével, hogy URL-kódolásúnak kell lennie, és további elérésiút-szegmensekkel is rendelkezhet. |
state |
Ajánlott | A kérésben szereplő érték, amely a jogkivonat válaszában is visszakerül. Lehet bármilyen tartalmú karakterlánc. Az állapot a felhasználó állapotával kapcsolatos információk kódolására szolgál az alkalmazásban a hitelesítési kérelem előtt, például a lapon vagy a nézeten. |
Ezen a ponton a Microsoft Entra-azonosító kikényszeríti, hogy csak egy bérlői rendszergazda jelentkezzen be a kérés teljesítéséhez. A rendszer felkéri a rendszergazdát, hogy hagyja jóvá az alkalmazáshoz kért összes közvetlen alkalmazásengedélyt az alkalmazásregisztrációs portálon.
Sikeres válasz
Ha a rendszergazda jóváhagyja az alkalmazás engedélyeit, a sikeres válasz a következőképpen néz ki:
GET http://localhost/myapp/permissions?tenant=aaaabbbb-0000-cccc-1111-dddd2222eeee&state=state=12345&admin_consent=True
Paraméter | Leírás |
---|---|
tenant |
Az a címtárbérltető, amely megadta az alkalmazásnak a kért engedélyeket, GUID formátumban. |
state |
Egy érték, amely a kérésben szerepel, és a token válaszában is visszaadódik. Lehet bármilyen tartalmú karakterlánc. Az állapot a felhasználó állapotával kapcsolatos információk kódolására szolgál az alkalmazásban a hitelesítési kérelem előtt, például a lapon vagy a nézeten. |
admin_consent |
Állítsa true (Igaz) értékre. |
Hibaválasz
Ha a rendszergazda nem hagyja jóvá az alkalmazás engedélyeit, a sikertelen válasz a következőképpen néz ki:
GET http://localhost/myapp/permissions?error=permission_denied&error_description=The+admin+canceled+the+request
Paraméter | Leírás |
---|---|
error |
Hibakódsztring, amellyel osztályozhatja a hibák típusait, és amelyekkel reagálhat a hibákra. |
error_description |
Egy adott hibaüzenet, amely segíthet azonosítani a hiba kiváltó okát. |
Miután sikeres választ kapott az alkalmazáskiépítési végponttól, az alkalmazás megkapta a kért közvetlen alkalmazásengedélyeket. Most igényelhet tokent a szükséges erőforráshoz.
Token lekérése
Miután megszerezte az alkalmazáshoz szükséges engedélyezést, folytassa az API-k hozzáférési jogkivonatainak beszerzésével. Jogkivonat lekérése az ügyfél hitelesítő adatainak használatával: küldjön egy POST kérést a Microsoft identitásplatformjára /token
. Van néhány különböző eset:
- Hozzáférési jogkivonat-kérés megosztott titkos kóddal
- Hozzáférési jogkivonat kérése tanúsítvánnyal
- Hozzáférési jogkivonat-kérelem összevont hitelesítő adatokkal
Első eset: Hozzáférési jogkivonat-kérés megosztott titkos kóddal
POST /{tenant}/oauth2/v2.0/token HTTP/1.1 //Line breaks for clarity
Host: login.microsoftonline.com:443
Content-Type: application/x-www-form-urlencoded
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=https%3A%2F%2Fgraph.microsoft.com%2F.default
&client_secret=qWgdYAmab0YSkuL1qKv5bPX
&grant_type=client_credentials
# Replace {tenant} with your tenant!
curl -X POST -H "Content-Type: application/x-www-form-urlencoded" -d 'client_id=00001111-aaaa-2222-bbbb-3333cccc4444&scope=https%3A%2F%2Fgraph.microsoft.com%2F.default&client_secret=A1bC2dE3f...&grant_type=client_credentials' 'https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token'
Paraméter | Állapot | Leírás |
---|---|---|
tenant |
Kötelező | Az alkalmazás által célozni kívánt címtárbérlő, GUID vagy tartománynév formátumban. |
client_id |
Kötelező | Az alkalmazáshoz rendelt alkalmazásazonosító. Ezeket az információkat azon a portálon találja, ahol regisztrálta az alkalmazást. |
scope |
Kötelező | A kérelemben szereplő scope paraméter számára átadott értéknek a kívánt erőforrás erőforrás-azonosítójának (alkalmazásazonosítójának URI-jának) kell lennie, és utótaggal kell rendelkeznie .default . Minden hatókörnek egyetlen erőforráshoz kell tartoznia. Ha több erőforrás hatóköreit is beleszámítja, az hibát fog eredményezni. A Microsoft Graph-példában az érték a következő https://graph.microsoft.com/.default : . Ez az érték azt jelzi a Microsoft identitásplatformjának, hogy az alkalmazáshoz konfigurált összes közvetlen alkalmazásengedély közül a végpontnak ki kell adnia egy jogkivonatot a használni kívánt erőforráshoz társítottakhoz. A hatókörrel kapcsolatos további információkért /.default tekintse meg a hozzájárulási dokumentációt. |
client_secret |
Kötelező | Az alkalmazáshoz az alkalmazásregisztrációs portálon létrehozott ügyfélkód. A kliens titkát URL-kódolni kell, mielőtt elküldik. Az alapszintű hitelesítési minta, amely az RFC 6749 szerint a hitelesítő adatok megadását az Engedélyezés fejlécben helyettesíti, szintén támogatott. |
grant_type |
Kötelező | A értéknek client_credentials kell lennie. |
Második eset: Hozzáférési jogkivonat kérése tanúsítvánnyal
POST /{tenant}/oauth2/v2.0/token HTTP/1.1 // Line breaks for clarity
Host: login.microsoftonline.com:443
Content-Type: application/x-www-form-urlencoded
scope=https%3A%2F%2Fgraph.microsoft.com%2F.default
&client_id=11112222-bbbb-3333-cccc-4444dddd5555
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6Imd4OHRHeXN5amNScUtqRlBuZDdSRnd2d1pJMCJ9.eyJ{a lot of characters here}M8U3bSUKKJDEg
&grant_type=client_credentials
Paraméter | Állapot | Leírás |
---|---|---|
tenant |
Kötelező | Az alkalmazás által célozni kívánt címtárbérlő, GUID vagy tartománynév formátumban. |
client_id |
Kötelező | Az alkalmazáshoz rendelt alkalmazás (ügyfél) azonosítója. |
scope |
Kötelező | A kérelemben szereplő scope paraméter számára átadott értéknek a kívánt erőforrás erőforrás-azonosítójának (alkalmazásazonosítójának URI-jának) kell lennie, és utótaggal kell rendelkeznie .default . Minden hatókörnek egyetlen erőforráshoz kell tartoznia. Ha több erőforrás hatóköreit is beleszámítja, az hibát fog eredményezni. A Microsoft Graph-példában az érték a következő https://graph.microsoft.com/.default : . Ez az érték azt jelzi a Microsoft identitásplatformjának, hogy az alkalmazáshoz konfigurált összes közvetlen alkalmazásengedély közül a végpontnak ki kell adnia egy jogkivonatot a használni kívánt erőforráshoz társítottakhoz. A hatókörrel kapcsolatos további információkért /.default tekintse meg a hozzájárulási dokumentációt. |
client_assertion_type |
Kötelező | Az értéknek a következőre kell lennie: urn:ietf:params:oauth:client-assertion-type:jwt-bearer . |
client_assertion |
Kötelező | Egy JSON web token (állítás), amelyet létre kell hoznia és alá kell írnia az alkalmazása hitelesítő adataként regisztrált tanúsítvánnyal. A tanúsítvány hitelesítő adatairól a tanúsítvány regisztrálásának módjáról és az állítás formátumáról olvashat. |
grant_type |
Kötelező | A értéknek client_credentials kell lennie. |
A tanúsítványalapú kérés paraméterei csak egy módon térnek el a megosztott titkos kulcsalapú kéréstől: a client_secret
paramétert a rendszer a client_assertion_type
paraméterekkel helyettesíti client_assertion
.
Harmadik eset: Hozzáférési jogkivonat-kérés összevont hitelesítő adatokkal
POST /{tenant}/oauth2/v2.0/token HTTP/1.1 // Line breaks for clarity
Host: login.microsoftonline.com:443
Content-Type: application/x-www-form-urlencoded
scope=https%3A%2F%2Fgraph.microsoft.com%2F.default
&client_id=11112222-bbbb-3333-cccc-4444dddd5555
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6Imd4OHRHeXN5amNScUtqRlBuZDdSRnd2d1pJMCJ9.eyJ{a lot of characters here}M8U3bSUKKJDEg
&grant_type=client_credentials
Paraméter | Állapot | Leírás |
---|---|---|
client_assertion |
Kötelező | Egy olyan állítás (JWT vagy JSON webes jogkivonat), amelyet az alkalmazás a Microsoft identitásplatformján kívüli másik identitásszolgáltatótól kap, például a Kubernetestől. Ennek a JWT-nek a sajátosságait összevont identitás hitelesítő adatként kell regisztrálni az alkalmazásban. A számítási feladatok identitás-összevonásáról szóló cikkből megtudhatja, hogyan állíthatja be és használhatja a más identitásszolgáltatóktól származó állításokat. |
A kérelemben minden ugyanaz, mint a tanúsítványalapú folyamat, a forrás kritikus kivételével client_assertion
. Ebben a folyamatban az alkalmazás nem hozza létre magát a JWT-állítást. Ehelyett az alkalmazás egy másik identitásszolgáltató által létrehozott JWT-t használ. Ezt számítási feladatok identitás-összevonásának nevezzük, ahol az alkalmazások identitása egy másik identitásplatformon a Microsoft identitásplatformon belüli jogkivonatok beszerzésére szolgál. Ez leginkább felhők közötti forgatókönyvekhez ideális, például a számítási feladatok Azure-on kívüli üzemeltetéséhez, de a Microsoft identitásplatform által védett API-khoz való hozzáféréshez. A más identitásszolgáltatók által létrehozott JWT-k kötelező formátumával kapcsolatos információkért olvassa el az helyességi formátumot.
Sikeres válasz
Bármely metódus sikeres válasza a következőképpen néz ki:
{
"token_type": "Bearer",
"expires_in": 3599,
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNBVGZNNXBP..."
}
Paraméter | Leírás |
---|---|
access_token |
A kért hozzáférési jogkivonat. Az alkalmazás felhasználhatja ezt a jogkivonatot a védett erőforráshoz való hitelesítéshez, például egy webes API-hoz. |
token_type |
A token típusértékét jelzi. A Microsoft identitásplatformja csak a következő típust támogatja bearer : . |
expires_in |
A hozzáférési jogkivonat érvényességének időtartama (másodpercben). |
Figyelmeztetés
Ne kísérelje meg a jogkivonatok érvényesítését vagy olvasását a kódban a nem birtokolt API-k esetében, beleértve az ebben a példában szereplő jogkivonatokat is. A Microsoft-szolgáltatások jogkivonatai olyan speciális formátumot használhatnak, amely nem érvényesíthető JWT-ként, és titkosíthatók az egyéni (Microsoft-fiókos) felhasználók számára is. Bár a jogkivonatok olvasása hasznos hibakeresési és tanulási eszköz, ne vegyen fel függőségeket a kódban, és ne feltételezze a nem ön által vezérelt API-khoz tartozó jogkivonatokat.
Hibaválasz
A hibaválasz (400 hibás kérelem) a következőképpen néz ki:
{
"error": "invalid_scope",
"error_description": "AADSTS70011: The provided value for the input parameter 'scope' is not valid. The scope https://foo.microsoft.com/.default is not valid.\r\nTrace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333\r\nCorrelation ID: aaaa0000-bb11-2222-33cc-444444dddddd\r\nTimestamp: 2016-01-09 02:02:12Z",
"error_codes": [
70011
],
"timestamp": "YYYY-MM-DD HH:MM:SSZ",
"trace_id": "0000aaaa-11bb-cccc-dd22-eeeeee333333",
"correlation_id": "aaaa0000-bb11-2222-33cc-444444dddddd"
}
Paraméter | Leírás |
---|---|
error |
Hibakód-sztring, amellyel osztályozhatja a előforduló hibák típusait, és reagálhat a hibákra. |
error_description |
Egy adott hibaüzenet, amely segíthet azonosítani a hitelesítési hiba kiváltó okát. |
error_codes |
Az STS-specifikus hibakódok listája, amelyek segíthetnek a diagnosztikában. |
timestamp |
A hiba előfordulásának időpontja. |
trace_id |
A diagnosztikával kapcsolatos segítségkérés egyedi azonosítója. |
correlation_id |
A kérés egyedi azonosítója, amely segítséget nyújt az összetevők közötti diagnosztikában. |
Token használata
Most, hogy megszerezte a jogkivonatot, a jogkivonat használatával kéréseket intézhet az erőforráshoz. Ha a jogkivonat lejár, ismételje meg a végpontra /token
irányuló kérést egy új hozzáférési jogkivonat beszerzéséhez.
GET /v1.0/users HTTP/1.1
Host: graph.microsoft.com:443
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbG...
Próbálja ki a következő parancsot a terminálban, és ügyeljen arra, hogy a tokent cserélje le a sajátjára.
curl -X GET -H "Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbG..." 'https://graph.microsoft.com/v1.0/users'
Kódminták és egyéb dokumentáció
Olvassa el az ügyfél hitelesítő adatainak áttekintési dokumentációját a Microsoft Authentication Libraryből
Minta | Platforma | Leírás |
---|---|---|
active-directory-dotnetcore-daemon-v2 | .NET 6.0+ | Egy ASP.NET Core-alkalmazás, amely a Microsoft Graphot lekérdező bérlő felhasználóit jeleníti meg az alkalmazás identitásával, nem pedig egy felhasználó nevében. A minta a hitelesítéshez használt tanúsítványokkal is szemlélteti a variációt. |
active-directory-dotnet-daemon-v2 | ASP.NET MVC | Egy webalkalmazás, amely a Microsoft Graph-ból származó adatokat szinkronizálja az alkalmazás identitásával, nem pedig egy felhasználó nevében. |
ms-identity-javascript-nodejs-console | Node.js konzol | Egy Node.js alkalmazás, amely egy bérlő felhasználóit jeleníti meg a Microsoft Graph lekérdezésével az alkalmazás identitásával |