Správa tokenů pro nulovou důvěryhodnost

Při vývoji aplikací nulové důvěry (Zero Trust) je důležité konkrétně definovat záměr vaší aplikace a požadavky na přístup k prostředkům. Aplikace by měla požadovat pouze přístup, který vyžaduje, aby fungovala podle očekávání. Tento článek vám jako vývojář pomůže integrovat zabezpečení do vašich aplikací pomocí tokenů ID, přístupových tokenů a tokenů zabezpečení , které vaše aplikace může přijímat z platformy Microsoft Identity Platform.

Zajistěte, aby vaše aplikace dodržovala zásadu nulové důvěryhodnosti nejnižší úrovně oprávnění a zabránila použití způsoby, které by mohly ohrozit váš záměr. Omezte přístup uživatelů pomocí technologie Just-In-Time a Just-Enough-Access (JIT/JEA), adaptivních zásad založených na rizikech a ochrany dat. Oddělte citlivé a výkonné oddíly aplikace. Poskytněte přístup pouze autorizovaným uživatelům k těmto oblastem. Omezte uživatele, kteří můžou používat vaši aplikaci, a možnosti, které mají ve vaší aplikaci.

Zabudujte nejnižší oprávnění do způsobu, jakým vaše aplikace spravuje tokeny ID, které přijímá z platformy Microsoft Identity Platform. Informace v tokenech ID umožňují ověřit, že uživatel je tím, za koho se tvrdí. Uživatel nebo jejich organizace můžou zadat podmínky ověřování, jako jsou vícefaktorové ověřování, spravovaná zařízení a správná umístění.

Usnadněte zákazníkům správu autorizací pro vaši aplikaci. Snižte režijní náklady na vytváření a konfiguraci uživatelů a ruční procesy. Automatické zřizování uživatelů umožňuje správcům IT automatizovat vytváření, údržbu a odebírání identit uživatelů v úložištích cílových identit. Vaši zákazníci můžou založit automatizaci na změnách uživatelů a skupin se zřizováním aplikací nebo zřizováním řízeným personálním oddělením v Microsoft Entra ID.

Použijte deklarace tokenů ve vašich aplikacích

Deklarace identity v tokenech ID můžete použít pro uživatelské prostředí v aplikaci jako klíče v databázi. Zadejte přístup k klientské aplikaci. Token ID je základní rozšíření, které OpenID Connect (OIDC) provádí v OAuth 2.0. Vaše aplikace může přijímat tokeny ID vedle přístupových tokenů nebo místo přístupových tokenů.

Ve standardním vzoru autorizace tokenu zabezpečení umožňuje vystavený token ID aplikaci přijímat informace o uživateli. Nepoužívejte token ID jako autorizační proces pro přístup k prostředkům. Autorizační server vydává tokeny ID, které obsahují deklarace identity s informacemi o uživateli, které obsahují následující informace.

  • Deklarace cílové skupiny (aud) je ID klienta vaší aplikace. Přijměte pouze tokeny pro ID klienta rozhraní API.
  • Nárok tid představuje ID tenanta, který token vydal. Nárok oid je neměnná hodnota, která jednoznačně identifikuje uživatele. Použijte jedinečnou kombinaci nároků tid a oid jako klíč, když potřebujete přidružit data k uživateli. Pomocí těchto hodnot deklarací identity připojte data zpět k ID uživatele v Microsoft Entra ID.
  • Deklarace sub identity je neměnná hodnota, která jednoznačně identifikuje uživatele. Deklarace subjektu je také jedinečná pro vaši aplikaci. Pokud k přidružení dat k uživateli použijete sub deklaraci identity, není možné z dat přejít a propojit je s uživatelem v Microsoft Entra ID.

Vaše aplikace můžou použít openid rozsah k vyžádání ID tokenu z platformy Microsoft identity platform. Standard OIDC řídí openid obor spolu s formátem a obsahem tokenu ID. OIDC určuje tyto obory:

  • Pomocí openid rozsahu přihlaste uživatele a přidejte sub deklaraci identity k ID tokenu. Tyto obory poskytují ID uživatele, které je jedinečné pro aplikaci a uživatele a volá koncový bod UserInfo.
  • Obor email přidá email deklaraci identity obsahující e-mailovou adresu uživatele do tokenu ID.
  • Rozsah profile přidá do tokenu ID deklarace se základními atributy profilu uživatele (jméno, uživatelské jméno).
  • Obor offline_access umožňuje aplikaci přistupovat k uživatelským datům i v případě, že uživatel není k dispozici.

Knihovna MSAL (Microsoft Authentication Library) vždy přidává do každého požadavku na token openid, e-mail a profile obory. V důsledku toho MSAL při každém volání AcquireTokenSilent nebo AcquireTokenInteractive vždy vrátí ID token a přístupový token. MSAL vždy požaduje offline_access rozsah. Platforma Microsoft Identity Platform vždy vrací offline_access obor, i když požadovaná aplikace nezadá offline_access obor.

Microsoft používá standard OAuth2 k vydávání přístupových tokenů. Standard OAuth2 říká, že obdržíte token, ale nezadá formát tokenu nebo to, co musí být v tokenu. Když vaše aplikace potřebuje získat přístup k prostředku, který chrání Microsoft Entra ID, měl by použít obor definovaný prostředkem.

Microsoft Graph například definuje User.Read obor, který aplikaci autorizuje k přístupu k úplnému profilu aktuálního uživatele a názvu tenanta. Microsoft Graph definuje oprávnění v celé řadě funkcí dostupných v daném rozhraní API.

Po autorizaci vrátí platforma Microsoft Identity Platform přístupový token pro vaši aplikaci. Když vyvoláte prostředek, vaše aplikace poskytne tento token jako součást autorizační hlavičky požadavku HTTP na rozhraní API.

Správa životností tokenů

Aplikace můžou po úspěšném dokončení ověřování vytvořit relaci pro uživatele s ID Microsoft Entra. Správa uživatelských relací určuje, jak často uživatel potřebuje opakovat ověřování. Jeho role při zachování explicitně ověřeného uživatele před aplikací se správnými oprávněními a pro správnou dobu je zásadní. Životnost relace musí být založená exp na deklaraci identity v tokenu ID. Tvrzení exp udává čas, kdy vyprší platnost tokenu ID, a čas, po němž nelze token dále použít pro ověření uživatele.

Vždy respektujte životnost tokenu , jak je uvedeno v odpovědi tokenu exp pro přístupové tokeny nebo deklaraci identity v tokenu ID. Podmínky, které řídí životnost tokenu, můžou zahrnovat frekvenci přihlašování pro podnik. Vaše aplikace nemůže nakonfigurovat životnost tokenu. Nemůžete požádat o životnost tokenu.

Obecně se ujistěte, že jsou tokeny platné a nevypršelé. Tvrzení o publiku (aud) musí odpovídat vašemu klientskému ID. Ujistěte se, že token pochází od důvěryhodného vystavitele. Pokud máte víceklientské rozhraní API, můžete se rozhodnout filtrovat, aby vaše rozhraní API mohlo volat jenom konkrétní tenanty. Ujistěte se, že vynucujete životnost tokenu. Zkontrolujte nbf (ne dříve) a exp (vypršení platnosti) nároky a ujistěte se, že aktuální čas spadá mezi hodnoty těchto dvou nároků.

Nezaměřujte se na mimořádně dlouhé nebo krátké životnosti relací. Nechte toto rozhodnutí řídit životnost uděleného tokenu ID . Pokud budou relace vaší aplikace aktivní i po vypršení platnosti tokenů, porušuje to pravidla, zásady a obavy, které vedly správce IT k nastavení doby platnosti tokenu, aby zabránil neoprávněnému přístupu. Krátké relace zhoršují uživatelskou zkušenost a nezvyšují nutně stav zabezpečení. Oblíbené frameworky, jako je ASP.NET, umožňují nastavit vypršení časového limitu pro relaci a soubory cookie na základě doby vypršení platnosti tokenu Microsoft Entra ID. Dodržujte čas vypršení platnosti tokenu poskytovatele identity a ujistěte se, že relace uživatele nejsou delší než délku povolenou zásadami, které poskytovatel identity určuje.

Mezipaměti a obnovovací tokeny

Nezapomeňte správně ukládat tokeny do mezipaměti. MsAL automaticky ukládá tokeny do mezipaměti, ale tokeny mají životnost. Používejte tokeny po celou dobu jejich životnosti a odpovídajícím způsobem je ukládejte do mezipaměti. Pokud opakovaně požádáte o stejný token, omezování způsobí, že aplikace přestane reagovat. Pokud vaše aplikace zneužije vystavování tokenů, doba vystavení nových tokenů pro vaši aplikaci se prodlouží.

Knihovny MSAL spravují podrobnosti protokolu OAuth2, včetně mechaniky aktualizace tokenů. Pokud nepoužíváte knihovnu MSAL, ujistěte se, že vaše knihovna efektivně využívá obnovovací tokeny.

Když váš klient získá přístupový token pro přístup k chráněnému prostředku, obdrží obnovovací token. Obnovovací token použijte k získání nových párů přístupových/obnovovacích tokenů po vypršení platnosti aktuálního přístupového tokenu. Obnovovací tokeny slouží k získání dodatečných přístupových tokenů pro jiné prostředky. Obnovovací tokeny jsou vázané na kombinaci uživatele a klienta (ne k prostředku nebo tenantovi). Obnovovací token můžete použít k získání přístupových tokenů v libovolné kombinaci prostředků a tenanta, kde má vaše aplikace oprávnění.

Správa chyb tokenů a závad

Aplikace by se nikdy neměla pokoušet ověřovat, dekódovat, kontrolovat, interpretovat ani zkoumat obsah přístupového tokenu. Tyto operace jsou výhradně odpovědností rozhraní API zdrojů. Pokud se vaše aplikace pokusí prozkoumat obsah přístupového tokenu, je vysoce pravděpodobné, že se vaše aplikace přeruší, když platforma Microsoft Identity Platform vydá šifrované tokeny.

Volání na načtení tokenu zřídka selhává kvůli problémům, jako jsou selhání sítě, infrastruktury nebo ověřovací služby nebo jejich výpadky. Pokud dojde k selhání získání tokenu, zvyšte odolnost prostředí ověřování ve vaší aplikaci podle těchto osvědčených postupů:

  • Místně ukládat tokeny do mezipaměti a zabezpečit je pomocí šifrování.
  • Nepředávejte artefakty zabezpečení, jako jsou tokeny v nezabezpečených kanálech.
  • Seznamte se s výjimkami a odpověďmi služeb od zprostředkovatele identity a zareagujte na ně.

Vývojáři často mají dotazy týkající se nahlížení do tokenů pro ladění problémů, jako je například chyba 401 při volání zdroje. Vzhledem k tomu, že více šifrovaných tokenů vám brání v prohlížení přístupového tokenu, musíte najít alternativy pro hledání uvnitř přístupových tokenů. Pro ladění vám odpověď obsahující přístupový token poskytne potřebné informace.

V kódu zkontrolujte třídy chyb místo jednotlivých případů chyb. Například, když systém neuděluje oprávnění, zaměřte se spíše na zpracování uživatelské interakce než na jednotlivé chyby. Vzhledem k tomu, že byste mohli tyto jednotlivé případy vynechat, je lepší zkontrolovat klasifikátor, jako je interakce uživatele, místo toho, abyste se podívali na jednotlivé kódy chyb.

Možná se budete muset vrátit zpět k AcquireTokenInteractive a poskytnout výzvy k nárokům, které volání AcquireTokenSilent vyžaduje. Tím zajistíte efektivní správu interaktivní žádosti.

Další kroky

  • Last updated on