Hitelesítés és engedélyezés a Azure-alkalmazás Service-ben és az Azure Functionsben

Az Azure App Service beépített hitelesítést (felhasználók bejelentkezését) és engedélyezést (biztonságos adatokhoz való hozzáférést biztosító) képességeket biztosít. Ezeket a képességeket néha Egyszerű hitelesítésnek nevezik. Ezek használatával bejelentkezhet a felhasználókba, és hozzáférhet az adatokhoz úgy, hogy a webalkalmazásban, a RESTful API-ban, a mobilkiszolgálón és a függvényekben kevés vagy semmilyen kódot nem ír.

Ez a cikk azt ismerteti, hogyan segíti az App Service az alkalmazás hitelesítésének és engedélyezésének egyszerűsítését.

A beépített hitelesítés használatának okai

A hitelesítés és az engedélyezés implementálásához használhatja a csomagban lévő biztonsági funkciókat a választott webes keretrendszerben, vagy írhat saját eszközöket. A hitelesítés és engedélyezés biztonságos megoldásának megvalósítása jelentős erőfeszítést igényelhet. Az iparági ajánlott eljárásokat és szabványokat kell követnie. Gondoskodnia kell arról is, hogy a megoldás naprakész maradjon a legújabb biztonsági, protokoll- és böngészőfrissítésekkel.

Az App Service és az Azure Functions beépített képességei időt és energiát takaríthatnak meg azáltal, hogy beépített hitelesítést biztosítanak az összevont identitásszolgáltatókkal, így az alkalmazás többi részére összpontosíthat.

Az App Service-ben anélkül integrálhatja a hitelesítési képességeket a webalkalmazásba vagy AZ API-ba, hogy saját maga valósítja meg őket. Ez a funkció közvetlenül a platformba van beépítve, és nem igényel semmilyen nyelvet, SDK-t, biztonsági szakértelmet vagy kódot. Több bejelentkezési szolgáltatóval is integrálhatja, például a Microsoft Entra, a Facebook, a Google és az X szolgáltatással.

Előfordulhat, hogy az alkalmazásnak összetettebb forgatókönyveket kell támogatnia, például Visual Studio-integrációt vagy növekményes hozzájárulást. Ezekhez a forgatókönyvekhez számos hitelesítési megoldás érhető el. További információ: Hitelesítési forgatókönyvek és javaslatok.

Identitásszolgáltatók

Az App Service összevont identitást használ. Egy Microsoft- vagy nem Microsoft-identitásszolgáltató kezeli az Ön felhasználói identitásait és hitelesítési folyamatát. Alapértelmezés szerint a következő identitásszolgáltatók érhetők el:

Szolgáltató Bejelentkezési végpont Útmutató
Microsoft Entra /.auth/login/aad App Service Microsoft Entra platform bejelentkezése
Facebook /.auth/login/facebook App Service Facebook-bejelentkezés
Google /.auth/login/google App Service Google-bejelentkezés
X /.auth/login/x App Service X-bejelentkezés
GitHub /.auth/login/github App Service GitHub-bejelentkezés
Apple /.auth/login/apple App Service-bejelentkezés Apple-bejelentkezéssel (előzetes verzió)
Bármely OpenID Connect-szolgáltató /.auth/login/<providerName> App Service OpenID Connect-bejelentkezés

Ha ezen szolgáltatók egyikével konfigurálja ezt a funkciót, a bejelentkezési végpontja elérhető a felhasználói hitelesítéshez és a szolgáltatótól származó hitelesítési jogkivonatok érvényesítéséhez. A felhasználók számára tetszőleges számú bejelentkezési lehetőséget biztosíthat.

A beépített hitelesítés használatának szempontjai

A beépített hitelesítés engedélyezésével az alkalmazáshoz érkező összes kérés automatikusan https-ra lesz átirányítva, függetlenül attól, hogy az App Service konfigurációs beállítása kényszeríti-e a HTTPS-t. Ezt az automatikus átirányítást a V2 konfigurációban megadott beállítással requireHttps tilthatja le. Javasoljuk azonban, hogy továbbra is használja a HTTPS-t, és győződjön meg arról, hogy a rendszer soha nem továbbít biztonsági jogkivonatokat nem biztonságos HTTP-kapcsolatokon keresztül.

Az App Service-t használhatja a webhelytartalomhoz és API-khoz való hozzáférés korlátozásával vagy anélkül történő hitelesítéshez. Hozzáférési korlátozások megadása a webalkalmazás Beállítások>hitelesítésének>beállításai szakaszában:

  • Ha csak hitelesített felhasználókra szeretné korlátozni az alkalmazások hozzáférését, állítsa be a műveletet, ha a kérés nincs hitelesítve , és jelentkezzen be az egyik konfigurált identitásszolgáltatóval.
  • Ha hitelesíteni szeretné, de nem korlátozná a hozzáférést, állítsa be az elvégzendő műveletet, ha a kérés nincs hitelesítve opciót Engedélyezze a névtelen kéréseket (nincs művelet).

Fontos

Az egyes alkalmazásregisztrációkhoz saját engedélyt és hozzájárulást kell adnia. Kerülje a környezetek közötti engedélymegosztást, használjon külön alkalmazásregisztrációkat a külön üzembehelyezési pontokhoz. Új kódok tesztelésekor ez a gyakorlat segíthet megelőzni, hogy a problémák érintsék az éles alkalmazást.

Hogyan működik?

Funkcióarchitektúra

A hitelesítési és engedélyezési köztes szoftver összetevő a platform azon funkciója, amely ugyanazon a virtuális gépen fut, mint az alkalmazás. Ha engedélyezi, minden bejövő HTTP-kérés áthalad ezen az összetevőn, mielőtt az alkalmazás kezelené.

Architektúradiagram, amely a hely tesztkörnyezetében az identitásszolgáltatókkal folytatott interakciót mutatja be, mielőtt engedélyezi az üzembe helyezett hely felé irányuló forgalmat.

A platform köztes szoftvere számos dolgot kezel az alkalmazáshoz:

  • Felhasználók és ügyfelek hitelesítése a megadott identitásszolgáltatókkal
  • Ellenőrzi, tárolja és frissíti az OAuth-jogkivonatokat, amelyeket a konfigurált identitásszolgáltatók bocsátottak ki
  • A hitelesített munkamenet kezelése
  • Identitásadatok beszúrása HTTP-kérelemfejlécekbe

A modul az alkalmazáskódtól külön fut. Konfigurálhatja az Azure Resource Manager beállításaival vagy egy konfigurációs fájllal. Nincs szükség SDK-kra, adott programozási nyelvekre vagy az alkalmazáskód módosítására.

Szolgáltatásarchitektúra Windows rendszeren (nem tárolóalapú üzembe helyezés)

A hitelesítési és engedélyezési modul natív IIS-modulként fut ugyanabban a tesztkörnyezetben, mint az alkalmazás. Ha engedélyezi, minden bejövő HTTP-kérés áthalad rajta, mielőtt az alkalmazás kezelené.

Funkcióarchitektúra Linuxon és tárolókon

A hitelesítési és engedélyezési modul egy külön tárolóban fut, amely elkülönítve van az alkalmazáskódtól. A modul az Ambassador minta használatával kommunikál a bejövő forgalommal a Windowshoz hasonló funkciók végrehajtásához. Mivel nem fut folyamatban, nem lehetséges a konkrét nyelvi keretrendszerekkel való közvetlen integráció. Az alkalmazás által igényelt releváns információk azonban a kérelemfejlécekben lesznek átadva.

Hitelesítési folyamat

A hitelesítési folyamat minden szolgáltató esetében ugyanaz. Ez attól függően különbözik, hogy be szeretne-e jelentkezni a szolgáltató SDK-jával:

  • Szolgáltatói SDK nélkül: Az alkalmazás delegáltjai összevonták a bejelentkezést az App Service-be. Ez a delegálás jellemzően a böngészőalkalmazások esetében fordul elő, amelyek a szolgáltató bejelentkezési oldalát mutatják be a felhasználónak. A kiszolgálókód kezeli a bejelentkezési folyamatot, ezért kiszolgáló által irányított folyamatnak vagy kiszolgálói folyamatnak is nevezik.

    Ez az eset azokra a böngészőalkalmazásokra és mobilalkalmazásokra vonatkozik, amelyek beágyazott böngészőt használnak a hitelesítéshez.

  • Szolgáltató SDK-val: Az alkalmazás manuálisan jelentkezteti be a felhasználókat a szolgáltatóhoz. Ezután elküldi a hitelesítési jogkivonatot az App Service-nek ellenőrzés céljából. Ez a folyamat általában a böngésző nélküli alkalmazások esetében fordul elő, amelyek nem tudják bemutatni a szolgáltató bejelentkezési oldalát a felhasználónak. Az alkalmazáskód kezeli a bejelentkezési folyamatot, ezért ügyfél által irányított folyamatnak vagy ügyfélfolyamatnak is nevezik.

    Ez az eset a REST API-kra, az Azure Functionsre és a JavaScript böngészőügyfelekre vonatkozik, azon böngészőalkalmazások mellett, amelyek nagyobb rugalmasságot igényelnek a bejelentkezési folyamat során. Azokra a natív mobilalkalmazásokra is vonatkozik, amelyek a szolgáltató SDK-ját használva jelentkeznek be a felhasználók.

Az App Service megbízható böngészőalkalmazásából egy másik REST API-ra irányuló hívások az App Service-ben vagy az Azure Functionsben a kiszolgáló által irányított folyamaton keresztül hitelesíthetők. További információ: Bejelentkezés és kijelentkezés testreszabása Azure-alkalmazás szolgáltatáshitelesítésben.

Az alábbi táblázat a hitelesítési folyamat lépéseit mutatja be.

Lépés Szolgáltatói SDK nélkül Szolgáltatói SDK-val
1. Bejelentkezés a felhasználóba A szolgáltató átirányítja az ügyfelet a következőre /.auth/login/<provider>: . Az ügyfélkód közvetlenül a szolgáltató SDK-jával jelentkezik be a felhasználó, és kap egy hitelesítési jogkivonatot. További információkért tekintse meg a szolgáltató dokumentációját.
2. Hitelesítés utáni magatartás A szolgáltató átirányítja az ügyfelet a következőre /.auth/login/<provider>/callback: . Az ügyfélkód közzéteszi a szolgáltatótól származó jogkivonatot/.auth/login/<provider> ellenőrzés céljából.
3. Hitelesített munkamenet létrehozása Az App Service egy hitelesített cookie-t ad hozzá a válaszhoz. Az App Service a saját hitelesítési jogkivonatát adja vissza az ügyfélkódnak.
4. Hitelesített tartalom kiszolgálása Az ügyfél egy hitelesítési cookie-t is tartalmaz a későbbi kérésekben (amelyet a böngésző automatikusan kezel). A klienskód megjeleníti a hitelesítési jogkivonatot a X-ZUMO-AUTH fejlécben.

Az ügyfélböngészők esetében az App Service automatikusan átirányítja az összes hitelesítés nélküli felhasználót a következőre /.auth/login/<provider>: . A felhasználókat egy vagy több /.auth/login/<provider> hivatkozással is megjelenítheti az alkalmazásba való bejelentkezéshez a választott szolgáltatójuk használatával.

Engedélyezési viselkedés

Az Azure Portalon különböző viselkedésekkel konfigurálhatja az App Service-t, ha egy bejövő kérés nincs hitelesítve. A következő szakaszok ismertetik a beállításokat.

Fontos

Alapértelmezés szerint ez a funkció csak hitelesítést biztosít, nem engedélyezést. Előfordulhat, hogy az alkalmazásnak továbbra is engedélyezési döntéseket kell hoznia az itt konfigurált ellenőrzések mellett.

Erősen korlátozott hozzáférés

  • Hitelesítés nélküli kérések engedélyezése: Ez a beállítás letiltja az alkalmazáskódba irányuló nem hitelesített forgalom engedélyezését. Hitelesített kérések esetén az App Service a HTTP-fejlécekben található hitelesítési információkat is átadja.

    Ez a beállítás nagyobb rugalmasságot biztosít a névtelen kérések kezeléséhez. Lehetővé teszi például, hogy több bejelentkezési szolgáltatót is megjelenítsen a felhasználók számára. Azonban kódot kell írnia.

  • Hitelesítés megkövetelése: Ez a beállítás elutasítja az alkalmazásba irányuló nem hitelesített forgalmat. A konkrét végrehajtandó műveletet a cikk későbbi, nem hitelesített kérések szakaszában adhatók meg.

    Ezzel a beállítással nem kell hitelesítési kódot írnia az alkalmazásban. A felhasználó jogcímeinek vizsgálatával kezelheti a finomabb engedélyezést, például a szerepkörspecifikus engedélyezést.

    Figyelemfelhívás

    A hozzáférés ilyen módon való korlátozása az alkalmazás összes hívására vonatkozik, ami nem feltétlenül kívánatos olyan alkalmazások esetében, amelyek nyilvánosan elérhető kezdőlapot szeretnének, mint sok egyoldalas alkalmazásban. Ha kivételekre van szükség, konfigurálnia kell a kizárt elérési utakat egy konfigurációs fájlban.

    Megjegyzés:

    Ha a Microsoft identitásszolgáltatóját használja a szervezet felhasználói számára, az alapértelmezett viselkedés az, hogy a Microsoft Entra-bérlő bármely felhasználója tokent kérhet az alkalmazáshoz. Az alkalmazást konfigurálhatja a Microsoft Entra-ban , ha korlátozni szeretné az alkalmazáshoz való hozzáférést egy meghatározott felhasználói csoportra. Az App Service néhány alapvető beépített engedélyezési ellenőrzést is kínál, amelyek segíthetnek bizonyos ellenőrzésekkel. A Microsoft Entra engedélyezésével kapcsolatos további információkért tekintse meg a Microsoft Entra engedélyezési alapjait.

Nem hitelesített kérések

  • HTTP 302 Talált átirányítás: ajánlott webhelyekhez: Átirányítja a műveletet az egyik konfigurált identitásszolgáltatóhoz. Ezekben az esetekben a rendszer átirányít egy böngésző klienst /.auth/login/<provider> a választott szolgáltató számára.
  • HTTP 401 Nem engedélyezett: API-khoz ajánlott: Választ adHTTP 401 Unauthorized vissza, ha a névtelen kérés natív mobilalkalmazásból származik. Az elutasítást úgy is beállíthatja, hogy az minden kérésre vonatkozzon HTTP 401 Unauthorized.
  • HTTP 403 Tiltott: Úgy konfigurálja az elutasítást, hogy minden kéréshez legyen HTTP 403 Forbidden .
  • HTTP 404 Nem található: Úgy konfigurálja az elutasítást, hogy minden kéréshez legyen HTTP 404 Not found .

Token tároló

Az App Service egy beépített token tárolót biztosít. A tokentár egy adattár, amely a webalkalmazások, API-k vagy natív mobilalkalmazások felhasználóihoz társított tokeneket tárolja. Ha engedélyezi a hitelesítést bármelyik szolgáltatóval, az alkalmazás azonnal hozzáférhet ehhez a token tárolóhoz.

Ha az alkalmazáskódnak a felhasználó nevében kell hozzáférnie ezektől a szolgáltatóktól származó adatokhoz, általában kódot kell írnia ezeknek a jogkivonatoknak az alkalmazáson belüli gyűjtéséhez, tárolásához és frissítéséhez. A műveletek többek között a következők lehetnek:

  • Tegye közzé a hitelesített felhasználó Facebook-idővonalán.
  • Olvassa el a felhasználó vállalati adatait a Microsoft Graph API használatával.

A jogkivonat-tárolóval egyszerűen lekérheti a jogkivonatokat, amikor szüksége van rájuk, és utasítja az App Service-t, hogy frissítse őket, amikor lejárnak.

Az azonosító jogkivonatok, a hozzáférési jogkivonatok és a frissítési jogkivonatok a hitelesített munkamenethez gyorsítótárban vannak. Csak a társított felhasználó érheti el őket.

Ha nem kell jogkivonatokkal dolgoznia az alkalmazásban, letilthatja a jogkivonat-tárolót az alkalmazás Beállítások>hitelesítés oldalán.

Naplózás és nyomkövetés

Ha engedélyezi az alkalmazásnaplózást, a hitelesítési és engedélyezési nyomkövetések közvetlenül megjelennek a naplófájlokban. Ha olyan hitelesítési hibát lát, amely nem várt, a meglévő alkalmazásnaplókban kényelmesen megtalálhatja az összes részletet.

Ha engedélyezi a sikertelen kérések nyomon követését, pontosan láthatja, hogy a hitelesítési és engedélyezési modul milyen szerepet játszhat egy sikertelen kérésben. A nyomkövetési naplókban keressen hivatkozásokat egy nevű EasyAuthModule_32/64modulra.

Kereszt-helyszíni kérelem hamisítás mérséklése

Az App Service-hitelesítés csökkenti a helyek közötti hamisítást, ha megvizsgálja az ügyfélkéréseket az alábbi feltételek teljesülése esetén:

  • Ez egy POST munkamenet-cookie-ján keresztül hitelesített kérés.
  • A kérés egy ismert böngészőből származik, amelyet a HTTP-fejléc User-Agent határoz meg.
  • A HTTP Origin vagy a HTTP Referer fejléc hiányzik, vagy nincs az átirányításra jóváhagyott külső domainek konfigurált listájában.
  • A HTTP-fejléc Origin hiányzik, vagy nem szerepel a több forrásból származó erőforrásmegosztás (CORS) konfigurált listájában.

Ha egy kérés teljesíti ezeket a feltételeket, az App Service-hitelesítés automatikusan elutasítja azt. Ezt a kockázatcsökkentési logikát megkerülheti úgy, hogy hozzáadja a külső tartományt az átirányítási listához a Beállítások>hitelesítése>Hitelesítési beállítások>szerkesztése engedélyezett külső átirányítási URL-címek című témakörben.

Védett erőforrás metaadatai (előzetes verzió)

Az App Service az RFC 9728-ban meghatározott OAuth 2.0 védett erőforrás-metaadatokat képes kiszolgálni. Ez segíthet az OAuth 2.0-ügyfeleknek megérteni az alkalmazással való interakciót. Ez szükséges a Model Context Protocol (MCP) kiszolgálójának engedélyezéséhez.

Megjegyzés:

A védett erőforrás metaadatainak támogatása jelenleg előzetes verzióban érhető el, és a konfigurálás módja megváltozhat, mielőtt a szolgáltatás általánosan elérhető lenne.

Az előzetes verzió időtartama alatt engedélyezheti az alapértelmezett védett erőforrás-metaadat-dokumentumokat úgy, hogy konfigurálja az WEBSITE_AUTH_PRM_DEFAULT_WITH_SCOPESalkalmazásbeállítást az alkalmazás által igényelt hatókörök vesszővel tagolt listájával. Ha például engedélyezi az App Service-nek a Microsoft Entra-szolgáltató konfigurálását, az egy olyan hatókört állít be, mint a api://<client-id>/user_impersonation, a <client-id> helyére az alkalmazásregisztráció tényleges ügyfélazonosítóját állítva be.

Az alapértelmezett védett erőforrás-metaadat-dokumentum a következő tulajdonságokat tartalmazza:

Ingatlan Description
resource Annak a végpontnak megfelelő erőforrás-URI, amelyhez a védett erőforrás metaadatait hozzáférték.
authorization_servers A konfigurált identitásszolgáltatók engedélyezési kiszolgálóinak listája.
scopes_supported Az alkalmazásbeállításban WEBSITE_AUTH_PRM_DEFAULT_WITH_SCOPES megadott hatókörök listája.

Az alapértelmezett konfiguráció használatakor további tulajdonságok nem támogatottak.

Az alapértelmezett védett erőforrás-metaadat-dokumentum konfigurálása azt is módosítja, hogy az App Service hogyan kezeli az API-k nem hitelesített kéréseit. Amikor az alkalmazás engedélyezési kihívást állít ki, az tartalmazza a védett erőforrás metaadatainak URL-címét, amelyet az ügyfél ezután lekérhet és feldolgozhat. A kihívás magában foglalja az alkalmazásbeállításban WEBSITE_AUTH_PRM_DEFAULT_WITH_SCOPES konfigurált hatóköröket is.

Az Azure Front Door használatának szempontjai

Ha az Azure App Service-t az Azure Front Door mögötti hitelesítéssel vagy más fordított proxykkal használja, fontolja meg az alábbi műveleteket.

Az Azure Front Door gyorsítótárazásának letiltása

Tiltsa le az Azure Front Door gyorsítótárazását a hitelesítési munkafolyamatban.

Az Azure Front Door-végpont használata átirányításokhoz

Az App Service általában nem érhető el közvetlenül, amikor az Azure Front Door által van kitéve. Ezt a viselkedést megakadályozhatja például úgy, hogy felfedi az App Service-t az Azure Private Link használatával az Azure Front Door Premiumban. Annak megakadályozása, hogy a hitelesítési munkafolyamat közvetlenül átirányítsa a forgalmat az App Service-be. További információ: Átirányítási URI.

Győződjön meg arról, hogy az App Service a megfelelő átirányítási URI-t használja

Bizonyos konfigurációkban az App Service a teljes tartománynevét (FQDN) használja átirányítási URI-ként az Azure Front Door teljes tartományneve helyett. Ez a konfiguráció problémát okoz, ha az ügyfél az Azure Front Door helyett az App Service-be lesz átirányítva. A módosításhoz állítsa be a(z) forwardProxy értéket Standard-re, hogy az App Service tiszteletben tartsa az Azure Front Door által beállított X-Forwarded-Host fejlécet.

Más fordított proxyk, például az Azure Application Gateway vagy a nem Microsoft-termékek eltérő fejléceket használhatnak, és más forwardProxy beállítást igényelnek.

A konfigurációt nem módosíthatja forwardProxy az Azure Portal használatával. A következőt kell használnia az rest:

Exportálási beállítások

az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method get > auth.json

Frissítési beállítások

Keres:

"httpSettings": {
  "forwardProxy": {
    "convention": "Standard"
  }
}

Győződjön meg arról, hogy a convention úgy van beállítva, hogy tiszteletben tartsa az Azure Front Door által használt Standard fejlécet, kijelölve a X-Forwarded-Host értéket.

Importálási beállítások

az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method put --body @auth.json

Ügyféltípus és OAuth-folyamat viselkedése

Bizalmas és nyilvános ügyfél

Ha az identitásszolgáltatóhoz ügyfélkulcs van konfigurálva, az App Service-hitelesítés (Easy Auth) bizalmas ügyfélként működik. Kifejezetten Microsoft Entra-azonosító esetén:

  • Konfigurált ügyfélkóddal: Az App Service a hibrid folyamatot (response_type=code id_token) használja. Ebben a folyamatban az App Service az engedélyezési kódot jogkivonatokra cseréli a titkos kulcs használatával, ami biztosítja a kulcs biztonságát a szerver oldalon.
  • Ügyfélkód konfigurálása nélkül: Az App Service visszaesik az implicit folyamatba (response_type=id_token). Ebben a folyamatban az azonosító kód közvetlenül visszakerül az átirányítás során, kódcsere nélkül.

Ha a forgatókönyv bizalmas ügyfélfolyamattal és biztonságos jogkivonatcsere igényével rendelkezik, győződjön meg arról, hogy az App Service hitelesítési beállításai között konfigurálva van egy ügyféltitok az identitásszolgáltatóhoz.

PKCE (Proof Key for Code Exchange) támogatása

Az App Service-hitelesítés önmagában nem hoz létre PKCE-paramétereket (code_verifier és code_challenge) . Támogatja azonban a PKCE-t, ha az ügyfél megadja a paramétereket a bejelentkezési folyamat indításakor.

A PKCE használatához adja meg a code_challenge és code_challenge_method paramétereket, amikor a felhasználókat a bejelentkezési végpontra irányítja át.

https://<your-app>.azurewebsites.net/.auth/login/<provider>?code_challenge=<value>&code_challenge_method=<method>

Mindkét paramétert együtt kell megadni. Ha csak egy paramétert ad meg, az App Service elutasítja a kérést.

Az engedélyezési kiszolgáló által támogatott code_challenge_method értékek megismeréséhez tekintse meg a hitelesítési kiszolgáló metaadatait, amelyek tartalmazzák a támogatott PKCE kihívási módszereket.

Az RFC 7636 két metódust határoz meg a code_challenge következőből való code_verifiergeneráláshoz:

  • plain: Ugyanaz code_challenge , mint a code_verifier (code_challenge = code_verifier). Ez a metódus közvetlenül, átalakítás nélkül küldi el a hitelesítő értéket. Csak akkor használja plain , ha az ügyfél technikai okokból nem tudja támogatni az SHA-256-ot.
  • S256(ajánlott): A code_challenge a Base64url-kódolt SHA-256 kivonata code_verifier (code_challenge = BASE64URL(SHA256(ASCII(code_verifier)))). Ez a módszer biztonságosabb, mert az eredeti code_verifier soha nem lesz közzétéve az engedélyezési kérelem során.

A code_verifier karakterláncnak 43 és 128 karakter közötti kriptográfiai véletlenszerű sztringnek kell lennie, amely csak nem fenntartott karaktereket használ: A-Z, a-z, 0-9, -, ., _ és ~.

Az engedélyezési kód PKCE-vel való működésével kapcsolatos további információkért lásd a Microsoft identitásplatformját és az OAuth 2.0 engedélyezési kódfolyamatát.

Kapcsolódó tartalom

További információ az App Service-hitelesítésről:

A mintákért lásd:

  • Last updated on