Megosztás a következőn keresztül:


Átirányítási URI (válasz URL-cím) vázlata és korlátozásai

A Microsoft identitásplatformjával integrálható alkalmazások létrehozásakor elengedhetetlen az átirányítási URI-k konfigurálása. Ez a cikk átfogó útmutatót nyújt az URI ajánlott eljárásainak, támogatott konfigurációinak és korlátainak átirányításához. Akár webes, mobil- vagy asztali alkalmazást fejleszt, ez a cikk segít megfelelően konfigurálni az átirányítási URI-kat a biztonsági követelményeknek megfelelően.

Mi az átirányítási URI?

Az átirányítási URI vagy válasz URL-cím az a hely, ahol a Microsoft Entra hitelesítési kiszolgáló elküldi a felhasználót, miután sikeresen engedélyezte és megkapta a hozzáférési jogkivonatot. A felhasználó bejelentkezéséhez az alkalmazásnak egy paraméterként megadott átirányítási URI-val kell bejelentkezési kérelmet küldenie, így miután a felhasználó sikeresen bejelentkezett, a hitelesítési kiszolgáló átirányítja a felhasználót, és hozzáférési jogkivonatot ad ki a bejelentkezési kérelemben megadott átirányítási URI-nak.

Éles webalkalmazásokban például az átirányítási URI gyakran nyilvános végpont, ahol az alkalmazás fut, például https://contoso.com/auth-response. A fejlesztés során gyakori, hogy azt a végpontot is hozzáadja, ahol az alkalmazást helyileg futtatja, például https://127.0.0.1/auth-response vagy http://localhost/auth-response. Győződjön meg arról, hogy a szükségtelen fejlesztési környezetek/átirányítási URI-k nincsenek közzétéve az éles alkalmazásban. Ezt úgy teheti meg, hogy külön alkalmazásregisztrációkat végez a fejlesztéshez és a termelési környezethez.

Miért kell az átirányítási URI-okat hozzáadni egy alkalmazásregisztrációhoz?

Biztonsági okokból a hitelesítési kiszolgáló nem irányítja át a felhasználókat, és nem küld jogkivonatokat olyan URI-ra, amely nem szerepel az alkalmazásregisztrációban. A Microsoft Entra bejelentkezési kiszolgálói csak átirányítják a felhasználókat, és jogkivonatokat küldenek az alkalmazásregisztrációhoz hozzáadott URI-k átirányításához. Ha a bejelentkezési kérelemben megadott átirányítási URI nem egyezik az alkalmazásban hozzáadott átirányítási URI-kkal, hibaüzenetet kap, például AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application: .

A hibakódokkal kapcsolatos további információkért tekintse meg a Microsoft Entra hitelesítési és engedélyezési hibakódjait.

Hozzá kellene adnom egy átirányítási URI-t egy alkalmazásregisztrációhoz?

Az alkalmazás által használt engedélyezési protokolltól függ, hogy hozzá kell-e adni átirányítási URI-t az alkalmazásregisztrációhoz. Ha az alkalmazás a következő engedélyezési protokollokat használja, hozzá kell adnia a megfelelő átirányítási URI-kat az alkalmazásregisztrációhoz:

Nem kell átirányítási URI-kat hozzáadnia az alkalmazásregisztrációhoz, ha az alkalmazás az alábbi engedélyezési protokollokat vagy funkciókat használja.

Melyik platformhoz kell hozzáadni az átirányítási URI-(ka)t?

Ha az éppen létrehozott alkalmazás egy vagy több átirányítási URI-t tartalmaz az alkalmazásregisztrációban, engedélyeznie kell egy nyilvános ügyfélfolyamat-konfigurációt. Az alábbi táblázatok útmutatást nyújtanak arról, hogy a platformnak megfelelően, amelyen az alkalmazást építi, milyen átirányítási URI típusokat kell vagy nem kell hozzáadnia.

Webalkalmazás átirányítási URI-konfigurációja

Az alkalmazás típusa Tipikus nyelvek/keretrendszerek Platform átirányítási URI hozzáadásához az alkalmazásregisztrációban
Egy hagyományos webalkalmazás, ahol az alkalmazáslogika nagy része a kiszolgálón történik Node.js, web, ASP.NET, Python, Java, ASP.NET Core, PHP, Ruby, Blazor Server Világháló
Egyoldalas alkalmazás, amelyben a felhasználói felület logikájának nagy része a webkiszolgálóval kommunikáló webböngészőben történik, elsősorban webes API-k használatával JavaScript, Angular, React, Blazor WebAssembly, Vue.js Egyoldalas alkalmazás (SPA)

Mobil- és asztali alkalmazások átirányítási URI-konfigurációja

Az alkalmazás típusa Tipikus nyelvek/keretrendszerek Platform átirányítási URI hozzáadásához az alkalmazásregisztrációban
A táblázat alatt felsorolt forgatókönyveket nem tartalmazó iOS- vagy macOS-alkalmazás Swift, Objective-C IOS/macOS
Android-alkalmazás Java vagy Kotlin Android
Mobileszközön vagy asztali gépen natív módon futó alkalmazás Node.js elektron, Windows desktop, UWP, React Native, Android, iOS/macOS Mobil- és asztali alkalmazások

Ha az alábbi módszerek egyikével hoz létre iOS-alkalmazást, a Mobil és asztali alkalmazások platform használatával adjon hozzá átirányítási URI-t:

  • nyílt forráskód SDK-kat (AppAuth) használó iOS-alkalmazások
  • Nem támogatott többplatformos technológiát használó iOS-alkalmazások (Flutter)
  • Az OAuth-protokollokat közvetlenül megvalósító iOS-alkalmazások
  • többplatformos technológiát használó macOS-alkalmazások, amelyek nem támogatottak (Electron)

Átirányítási URI-t nem igénylő alkalmazások

Az alkalmazás típusa Példák/jegyzetek Társított OAuth-folyamat
Billentyűzet nélküli eszközökön futó alkalmazások Intelligens TV-n, IoT-eszközön vagy nyomtatón futó alkalmazások Az eszköz kódfolyamata további információ
A jelszavakat kezelő alkalmazások közvetlenül lépnek be, ahelyett, hogy átirányítanák a felhasználókat az Entra által üzemeltetett bejelentkezési webhelyre, és lehetővé teszi, hogy az Entra biztonságosan kezelje a felhasználói jelszót. Ezt a folyamatot csak akkor érdemes használni, ha más biztonságosabb folyamatok, például az engedélyezési kódfolyamatok nem életképesek, mert nem olyan biztonságosak. Erőforrás-tulajdonosi jelszó hitelesítési folyamat további információ
Asztali vagy mobil alkalmazások windowsos vagy Windows-tartományhoz csatlakoztatott gépen (AD vagy Azure AD-hez csatlakoztatott) a Windows integrált hitelesítéssel a webes fiókkezelő helyett. Asztali vagy mobilalkalmazás, amelyet automatikusan be kell jelentkezni, miután a felhasználó entrai hitelesítő adatokkal jelentkezett be a windowsos PC-rendszerbe További információ a Windows integrált hitelesítési folyamatról

Milyen korlátozások vonatkoznak a Microsoft Entra-alkalmazások átirányítási URI-jaira?

A Microsoft Entra alkalmazásmodell a következő korlátozásokat határozza meg az URI-k átirányítására:

  • Az átirányítási URI-knak a sémával httpskell kezdődniük, néhány localhost átirányítási URI-k kivételével.

  • Az átirányítási URI-k megkülönböztetik a kis- és nagybetűket, és meg kell egyeznie a futó alkalmazás URL-elérési útjának esetével.

    Példák:

    • Ha az alkalmazás útvonalának részeként szerepel .../abc/response-oidc, ne adja meg az átirányítási URI-ben a .../ABC/response-oidc-t. Mivel a webböngésző megkülönbözteti a kis- és nagybetűket, a .../abc/response-oidc-hoz társított cookie-k kizárhatók, ha a betűméret-különbségekkel rendelkező .../ABC/response-oidc URL-re irányítják át.
  • Az útvonalszegmenssel nem konfigurált átirányítási URI-k záró perjellel ('/) jelennek meg a válaszban. Ez csak akkor érvényes, ha a válasz mód query vagy fragment.

    Példák:

    • https://contoso.com vissza van adva, mint https://contoso.com/
    • http://localhost:7071 vissza van adva, mint http://localhost:7071/
  • Az útvonalszegmenseket tartalmazó átirányítási URI-k végére nincs záró perjel hozzáfűzve a válaszban.

    Példák:

    • https://contoso.com/abc vissza van adva, mint https://contoso.com/abc
    • https://contoso.com/abc/response-oidc vissza van adva, mint https://contoso.com/abc/response-oidc
  • Az átirányítási URI-k nem támogatják a speciális karaktereket – ! $ ' ( ) , ;

  • Az átirányítási URI-k nem támogatják a nemzetközi tartományneveket

Átirányítási URI-k és URI-hosszak maximális száma

Az átirányítási URI-k maximális száma biztonsági okokból nem állítható fel. Ha a forgatókönyv több átirányítási URI-t igényel, mint a megengedett maximális korlát, a megoldásként tekintse az alábbi állapotparaméter-megközelítést . Az alábbi táblázat a Microsoft Identitásplatform alkalmazásregisztrációhoz hozzáadható átirányítási URI-k maximális számát mutatja.

Bejelentkezett fiókok Átirányítási URI-k maximális száma Leírás
Microsoft munkahelyi vagy iskolai fiókok bármely szervezet Microsoft Entra-bérlőjében 256 signInAudienceaz alkalmazásjegyzék mezője az AzureADMyOrg vagy az AzureADMultipleOrgs értékre van állítva
Személyes Microsoft-fiókok, munkahelyi és iskolai fiókok 100 signInAudience az alkalmazásjegyzék mezője az AzureADandPersonalMicrosoftAccount értékre van állítva

Az alkalmazásregisztrációhoz hozzáadott átirányítási URI-khoz legfeljebb 256 karakter használható.

Átirányítási URI-k az alkalmazás és a szolgáltatásvezérlő objektumaiban

  • Mindig adjon hozzá átirányítási URI-kat csak az alkalmazásobjektumhoz.
  • Soha ne adjon hozzá átirányítási URI-értékeket a szolgáltatásnévhez, mert ezek az értékek eltávolíthatók, amikor a szolgáltatásnév objektum szinkronizálódik az alkalmazásobjektummal. Ez a két objektum közötti szinkronizálást aktiváló frissítési művelet miatt fordulhat elő.

Lekérdezési paraméter támogatása átirányítási URI-kban

A lekérdezési paraméterek az átirányítási URI-kban engedélyezettek olyan alkalmazások esetében, amelyek csak munkahelyi vagy iskolai fiókkal jelentkeznek be.

A lekérdezési paraméterek nem engedélyezettek az átirányítási URI-kban olyan alkalmazásregisztrációk esetében, amelyek úgy vannak konfigurálva, hogy személyes Microsoft-fiókkal, például Outlook.com (Hotmail), Messenger, OneDrive, MSN, Xbox Live vagy Microsoft 365 fiókkal jelentkezzenek be a felhasználókba.

Alkalmazásregisztrációs bejelentkezési célközönség Támogatja a lekérdezési paramétereket az átirányítási URI-ban
Csak ebben a szervezeti címtárban lévő fiókok (csak Contoso – Egyetlen bérlő)
Bármely szervezeti címtárban lévő fiókok (Bármely Microsoft Entra-címtár – Több-bérlős)
Bármely szervezeti címtárban (Bármely Microsoft Entra címtárban – Több-bérlős) és személyes Microsoft-fiókokban (például Skype- és Xbox-fiókokban) lévő fiókok
Csak személyes Microsoft-fiókok

Támogatott sémák

HTTPS: A HTTPS-séma (https://) minden HTTP-alapú átirányítási URI-hoz támogatott.

HTTP: A HTTP-séma (http://) csak a localhost URI-k esetében támogatott, és csak az aktív helyi alkalmazásfejlesztés és -tesztelés során használható.

Példaátirányítási URI Érvényesség
https://contoso.com Érvényes
https://contoso.com/abc/response-oidc Érvényes
https://localhost Érvényes
http://contoso.com/abc/response-oidc Érvénytelen
http://localhost Érvényes
http://localhost/abc Érvényes

Localhost-kivételek

Az RFC 8252 8.3 és 7.3 szakasza szerint a "visszacsatolás" vagy a "localhost" átirányítási URI-k két különleges szemponttal járnak:

  1. http Az URI-sémák elfogadhatók, mert az átirányítás soha nem hagyja el az eszközt. Ezért mindkét URI elfogadható:
    • http://localhost/myApp
    • https://localhost/myApp
  2. A natív alkalmazások által gyakran megkövetelt rövid élettartamú porttartományok miatt a portösszetevőt (például :5001:443) figyelmen kívül hagyja a rendszer az átirányítási URI-nak való megfelelés érdekében. Ennek eredményeképpen az összes ilyen URI egyenértékűnek minősül:
    • http://localhost/MyApp
    • http://localhost:1234/MyApp
    • http://localhost:5000/MyApp
    • http://localhost:8080/MyApp

Fejlesztési szempontból ez néhány dolgot jelent:

  • Ne regisztráljon több átirányítási URI-t, ahol csak a port különbözik. A bejelentkezési kiszolgáló tetszőlegesen kiválaszt egyet, és az adott átirányítási URI-hoz társított viselkedést használja (például hogy web-, native- vagy spa-típusú átirányításról van-e szó).

    Ez különösen akkor fontos, ha különböző hitelesítési folyamatokat szeretne használni ugyanabban az alkalmazásregisztrációban, például az engedélyezési kód megadását és az implicit folyamatot. Ahhoz, hogy a megfelelő válasz viselkedést társítsa az egyes átirányítási URI-khoz, a bejelentkezési kiszolgálónak képesnek kell lennie különbséget tenni az átirányítási URI-k között, és ezt nem teheti meg, ha csak a port különbözik.

  • Ha több átirányítási URI-t szeretne regisztrálni a localhoston a különböző folyamatok teszteléséhez a fejlesztés során, különböztetje meg őket az URI elérési út összetevőjének használatával. Például http://localhost/MyWebApp nem egyezik meg http://localhost/MyNativeApp-val.

  • Az IPv6 visszacsatolási címe ([::1]) jelenleg nem támogatott.

Részesítse előnyben a 127.0.0.1-et a localhosttal szemben.

Ha meg szeretné akadályozni, hogy az alkalmazás hibásan konfigurált tűzfalak vagy átnevezett hálózati adapterek miatt törjön fel, használja az IP-konstans visszacsatolási címet 127.0.0.1 az átirányítási URI-ban ahelyett localhost, hogy . Például: https://127.0.0.1.

Az Azure Portal Átirányítási URI-szövegmezője azonban nem használható visszacsatolásalapú átirányítási URI hozzáadásához, amely a sémát http használja:

A visszautasított http-alapú visszairányítási URI-t megjelenítő hiba párbeszédpanel az Azure portálon

Ha olyan átirányítási URI-t szeretne hozzáadni, amely a visszacsatolási címmel használja a http127.0.0.1 sémát, jelenleg módosítania kell a replyUrlsWithType attribútumot az alkalmazásjegyzékben.

Helyettesítő karakterek korlátozásai átirányítási URI-kban

Az olyan helyettesítő URI-k, mint például https://*.contoso.com, kényelmesek lehetnek, de biztonsági okokból kerülni kell őket. Az OAuth 2.0 specifikációja (az RFC 6749 3.1.2 szakasza) szerint az átirányítási végpont URI-jának abszolút URI-nak kell lennie. Ha egy konfigurált helyettesítő karakter URI-je megegyezik az átirányítási URI-val, az átirányítási URI-ban lévő lekérdezési sztringek és töredékek eltávolításra kerülnek.

A helyettesítő karakterek URI-jai jelenleg nem támogatottak a személyes Microsoft-fiókokba, illetve munkahelyi vagy iskolai fiókokba való bejelentkezésre konfigurált alkalmazásregisztrációkban. Azonban helyettesítő URI-k engedélyezettek olyan alkalmazások esetén, amelyek csak munkahelyi vagy iskolai fiókok bejelentkezésére vannak konfigurálva a szervezet Microsoft Entra-bérlőjében.

Ha a munkahelyi vagy iskolai fiókokba bejelentkező alkalmazásregisztrációkhoz helyettesítő karaktereket tartalmazó átirányítási URI-kat szeretne hozzáadni, használja az alkalmazásjegyzék-szerkesztőt Alkalmazásregisztrációk az Azure Portalon. Bár a jegyzékszerkesztő használatával lehetőség van átirányítási URI beállítására helyettesítő karakterrel, javasoljuk, hogy tartsa be az RFC 6749 3.1.2 szakaszát. és csak abszolút URI-kat használjon.

Ha a forgatókönyv több átirányítási URI-t igényel, mint a megengedett maximális korlát, fontolja meg az alábbi állapotparaméter-megközelítést a helyettesítő karakterek átirányítási URI-jának hozzáadása helyett.

Állapotparaméter használata

Ha több altartománya van, és a forgatókönyv megköveteli, hogy sikeres hitelesítés esetén a felhasználókat arra az oldalra irányítsa át, ahonnan elindultak, az állapotparaméter használata hasznos lehet.

Ebben a megközelítésben:

  1. Hozzon létre egy "megosztott" átirányítási URI-t alkalmazásonként az engedélyezési végponttól kapott biztonsági jogkivonatok feldolgozásához.
  2. Az alkalmazás alkalmazásspecifikus paramétereket (például az altartomány URL-címét, ahonnan a felhasználó származik, vagy bármilyen, a márkajelzéshez hasonló információt) küldhet az állapotparaméterben. Állapotparaméter használata esetén az RFC 6749 10.12 szakaszában megadott CSRF-védelemmel szemben kell védekezni.
  3. Az alkalmazásspecifikus paraméterek tartalmazzák az összes olyan információt, amely ahhoz szükséges, hogy az alkalmazás a felhasználó számára megfelelő felhasználói élményt jelenítsen meg, azaz a megfelelő alkalmazásállapot létrehozásához. A Microsoft Entra engedélyezési végpontja eltávolítja a HTML-t az állapotparaméterből, ezért győződjön meg arról, hogy nem ad át HTML-tartalmat ebben a paraméterben.
  4. Amikor a Microsoft Entra ID választ küld a "megosztott" átirányítási URI-nak, az állapotparamétert visszaküldi az alkalmazásnak.
  5. Az alkalmazás ezután az állapotparaméter értékével meghatározhatja, hogy melyik URL-címre küldje tovább a felhasználót. Győződjön meg arról, hogy érvényesíti a CSRF-védelmet.

Figyelmeztetés

Ez a módszer lehetővé teszi, hogy a sérült ügyfél módosítsa az állapotparaméterben küldött további paramétereket, ezáltal átirányítja a felhasználót egy másik URL-címre, amely az RFC 6819-ben leírt nyílt átirányítási fenyegetés . Ezért az ügyfélnek meg kell védenie ezeket a paramétereket az állapot titkosításával vagy más módon történő ellenőrzésével, például a tartománynévnek az átirányítási URI-ban való érvényesítésével a jogkivonattal szemben.

Következő lépések

Tudnivalók az alkalmazásregisztrációs alkalmazásjegyzékről.