Sdílet prostřednictvím

Vysvětlení toku implicitního udělení OAuth2 v Azure Active Directory (AD)

  • Článek

Upozornění

Tento obsah je určený pro starší koncový bod Azure AD verze 1.0. U nových projektů použijte Microsoft identity platform.

Implicitní udělení OAuth2 je notoricky proslulé tím, že se jedná o udělení s nejdelším seznamem aspektů zabezpečení ve specifikaci OAuth2. A přesto je to přístup implementovaný ADAL JS a ten, který doporučujeme při psaní aplikací SPA. Co dává? Vše je otázkou kompromisů: a jak se ukázalo, implicitní udělení je nejlepší přístup, který můžete použít pro aplikace, které využívají webové rozhraní API prostřednictvím JavaScriptu z prohlížeče.

Co je implicitní udělení OAuth2?

Typickým udělením autorizačního kódu OAuth2 je udělení autorizace, které používá dva samostatné koncové body. Koncový bod autorizace se používá pro fázi interakce uživatele, jejímž výsledkem je autorizační kód. Koncový bod tokenu pak klient použije k výměně kódu za přístupový token a často také obnovovací token. Webové aplikace musí koncovému bodu tokenu předložit své vlastní přihlašovací údaje aplikace, aby autorizační server mohl klienta ověřit.

Implicitní udělení OAuth2 je variantou jiných udělení autorizace. Umožňuje klientovi získat přístupový token (a id_token při použití OpenId Connect) přímo z koncového bodu autorizace bez kontaktování koncového bodu tokenu a ověření klienta. Tato varianta byla navržena pro javascriptové aplikace spuštěné ve webovém prohlížeči: v původní specifikaci OAuth2 se tokeny vrací ve fragmentu identifikátoru URI. To zpřístupňuje bity tokenu kódu JavaScriptu v klientovi, ale zaručuje, že nebudou zahrnuty do přesměrování na server. V případě implicitního udělení OAuth2 autorizační koncový bod vydá přístupové tokeny přímo klientovi pomocí dříve zadaného identifikátoru URI pro přesměrování. Má také výhodu v tom, že eliminuje všechny požadavky na volání mezi zdroji, které jsou nezbytné v případě, že javascriptová aplikace musí kontaktovat koncový bod tokenu.

Důležitou charakteristikou implicitního udělení OAuth2 je skutečnost, že tyto toky nikdy nevrací obnovovací tokeny klientovi. V další části se dozvíte, jak to není nutné a ve skutečnosti by to byl problém se zabezpečením.

Vhodné scénáře pro implicitní udělení OAuth2

Specifikace OAuth2 deklaruje, že implicitní udělení bylo navrženo k povolení aplikací uživatelských agentů – to znamená javascriptových aplikací spouštěných v prohlížeči. Definující charakteristikou takových aplikací je, že javascriptový kód se používá pro přístup k prostředkům serveru (obvykle webové rozhraní API) a k odpovídající aktualizaci uživatelského prostředí aplikace. Představte si aplikace, jako je Gmail nebo Outlook Web Access: Když vyberete zprávu ze složky Doručená pošta, změní se jenom panel vizualizace zprávy, aby se zobrazil nový výběr, zatímco zbytek stránky zůstane nezměněný. Tato vlastnost je v kontrastu s tradičními webovými aplikacemi založenými na přesměrování, kde každá interakce uživatele vede ke zpětnému odeslání na celou stránku a vykreslení celé stránky odpovědi nového serveru.

Aplikace, které využívají extrémní přístup založený na JavaScriptu, se nazývají jednostránkové aplikace neboli spa. Myšlenkou je, že tyto aplikace obsluhují pouze počáteční stránku HTML a přidružený JavaScript, přičemž všechny následné interakce jsou řízeny voláními webového rozhraní API prováděnými prostřednictvím JavaScriptu. Hybridní přístupy, kdy je aplikace většinou řízená postbackem, ale provádí občasná volání JS, ale nejsou neobvyklé – diskuze o implicitní využití toku je pro tyto přístupy také relevantní.

Aplikace založené na přesměrování obvykle zabezpečují své požadavky prostřednictvím souborů cookie, ale tento přístup nefunguje tak dobře pro javascriptové aplikace. Soubory cookie fungují pouze s doménou, pro kterou byly vygenerovány, zatímco volání JavaScriptu mohou být směrována na jiné domény. Ve skutečnosti tomu tak bude často: představte si aplikace, které vyvolávají Microsoft Graph API, rozhraní API Office nebo azure API – to vše se nachází mimo doménu, ze které se aplikace obsluhuje. Rostoucí trend javascriptových aplikací spočívá v tom, že nemají vůbec žádný back-end a při implementaci svých obchodních funkcí se spoléhají ze 100 % na webová rozhraní API třetích stran.

V současné době je upřednostňovanou metodou ochrany volání webového rozhraní API použití nosného tokenu OAuth2, kdy je každé volání doprovázeno přístupovým tokenem OAuth2. Webové rozhraní API zkontroluje příchozí přístupový token, a pokud v něm najde potřebné obory, udělí přístup k požadované operaci. Implicitní tok poskytuje javascriptovým aplikacím pohodlný mechanismus pro získání přístupových tokenů pro webové rozhraní API a nabízí řadu výhod ve vztahu k souborům cookie:

  • Tokeny je možné spolehlivě získat bez nutnosti volání mezi zdroji – povinná registrace identifikátoru URI přesměrování, na který se tokeny vrací, zaručuje, že tokeny nebudou nahrazeny.
  • Javascriptové aplikace můžou získat tolik přístupových tokenů, kolik potřebují, pro tolik webových rozhraní API, na která cílí – bez omezení domén.
  • Funkce HTML5, jako je relace nebo místní úložiště, poskytují úplnou kontrolu nad ukládáním tokenů do mezipaměti a správou životnosti, zatímco správa souborů cookie je pro aplikaci neprůhledná.
  • Přístupové tokeny nejsou náchylné k útokům csrf (cross-site request forgery).

Tok implicitního udělení nevydává obnovovací tokeny, většinou z bezpečnostních důvodů. Obnovovací token není tak úzce vymezený jako přístupové tokeny, což poskytuje mnohem větší výkon, a tím způsobí mnohem větší poškození v případě, že dojde k úniku. V implicitní toku se tokeny doručují v adrese URL, proto je riziko zachycení vyšší než při udělení autorizačního kódu.

Aplikace JavaScriptu má však k dispozici jiný mechanismus pro obnovení přístupových tokenů bez opakované výzvy uživatele k zadání přihlašovacích údajů. Aplikace může pomocí skrytého prvku iframe provádět nové žádosti o tokeny vůči koncovému bodu autorizace Azure AD: pokud má prohlížeč stále aktivní relaci (čtení: má soubor cookie relace) vůči Azure AD doméně, může žádost o ověření úspěšně proběhnout bez nutnosti interakce uživatele.

Tento model uděluje javascriptové aplikaci možnost nezávisle obnovovat přístupové tokeny a dokonce i získávat nové pro nové rozhraní API (za předpokladu, že pro ně uživatel dříve udělil souhlas). Tím se vyhnete dalšímu zatížení při získávání, údržbě a ochraně artefaktů s vysokou hodnotou, jako je obnovovací token. Artefakt, který umožňuje tiché obnovení, Azure AD soubor cookie relace, se spravuje mimo aplikaci. Další výhodou tohoto přístupu je, že se uživatel může odhlásit z Azure AD pomocí libovolné aplikace přihlášené k Azure AD spuštěné na libovolné kartě prohlížeče. Výsledkem je odstranění souboru cookie relace Azure AD a javascriptová aplikace automaticky ztratí možnost obnovit tokeny pro odhlášeného uživatele.

Je implicitní udělení vhodné pro mou aplikaci?

Implicitní udělení představuje více rizik než jiná udělení a oblasti, které je potřeba věnovat pozornost, jsou dobře zdokumentované (například zneužití přístupového tokenu k zosobnění vlastníka prostředku v implicitní toku a aspekty zabezpečení modelu hrozeb OAuth 2.0). Vyšší rizikový profil je však z velké části způsobený tím, že je určen k tomu, aby umožňoval aplikacím, které spouštějí aktivní kód, který vzdálený prostředek obsluhuje prohlížeči. Pokud plánujete architekturu SPA, nemáte žádné back-endové komponenty nebo máte v úmyslu volat webové rozhraní API prostřednictvím JavaScriptu, doporučujeme pro získání tokenu použít implicitní tok.

Pokud je vaše aplikace nativním klientem, implicitní tok není vhodný. Absence souboru cookie relace Azure AD v kontextu nativního klienta zbavuje vaši aplikaci prostředků pro udržování dlouhodobé relace. To znamená, že vaše aplikace bude opakovaně zobrazovat výzvu uživateli při získávání přístupových tokenů pro nové prostředky.

Pokud vyvíjíte webovou aplikaci, která obsahuje back-end, a využíváte rozhraní API z jeho back-endového kódu, není vhodný ani implicitní tok. Jiné granty vám dávají mnohem více moci. Například udělení přihlašovacích údajů klienta OAuth2 poskytuje možnost získat tokeny, které odrážejí oprávnění přiřazená k samotné aplikaci, na rozdíl od delegování uživatelů. To znamená, že klient má možnost udržovat programový přístup k prostředkům i v případě, že uživatel není aktivně zapojen do relace atd. Nejen to, ale tyto granty poskytují vyšší záruky zabezpečení. Přístupové tokeny například nikdy neprojdou přes uživatelský prohlížeč, neriskují uložení do historie prohlížeče atd. Klientská aplikace může také provádět silné ověřování při žádosti o token.

Další kroky