Zabezpečení aplikací a rozhraní API ověřováním deklarací identity

  • Článek

Interakce s tokeny je základní součástí vytváření aplikací pro autorizaci uživatelů. V souladu se zásadou nulová důvěra (Zero Trust) pro nejméně privilegovaný přístup je nezbytné, aby aplikace při autorizaci ověřují hodnoty určitých deklarací identity, které jsou přítomné v přístupovém tokenu.

Autorizace na základě deklarací identity umožňuje aplikacím zajistit, aby token obsahoval správné hodnoty pro věci, jako je tenant, předmět a objekt actor, které jsou přítomné v tokenu. To znamená, že autorizace na základě deklarací identity se může zdát složitá vzhledem k různým metodám využití a scénářům pro sledování. Tento článek má v úmyslu zjednodušit proces autorizace na základě deklarací identity, abyste mohli zajistit, aby vaše aplikace dodržovaly nejbezpečnější postupy.

Abyste měli jistotu, že je logika autorizace zabezpečená, musíte ověřit následující informace v deklarací identity:

  • Pro token se zadává příslušná cílová skupina.
  • ID tenanta tokenu odpovídá ID tenanta, ve kterém jsou uložená data.
  • Předmět tokenu je vhodný.
  • Objekt actor (klientská aplikace) je autorizovaný.

Poznámka:

Přístupové tokeny se ověřují pouze ve webových rozhraních API, pro která klient získal. Klient by neměl ověřovat přístupové tokeny.

Další informace o deklarací identity uvedených v tomto článku najdete v tématu Přístupové tokeny platformy Microsoft Identity Platform.

Ověření cílové skupiny

Deklarace aud identity identifikuje zamýšlenou cílovou skupinu tokenu. Před ověřením deklarací identity musíte vždy ověřit, že hodnota aud deklarace identity obsažená v přístupovém tokenu odpovídá webovému rozhraní API. Hodnota může záviset na tom, jak klient požadoval token. Cílová skupina v přístupovém tokenu závisí na koncovém bodu:

  • Pro tokeny v2.0 je cílovou skupinou ID klienta webového rozhraní API. Je to identifikátor GUID.
  • V případě tokenů v1.0 je cílová skupina jednou z identifikátorů URI id aplikace deklarovaných ve webovém rozhraní API, které token ověří. Například api://{ApplicationID}nebo jedinečný název začínající názvem domény (pokud je název domény přidružený k tenantovi).

Další informace o identifikátoru URI ID aplikace naleznete v tématu Identifikátor URI ID aplikace.

Ověření tenanta

Vždy zkontrolujte, že tid token v tokenu odpovídá ID tenanta použitému k ukládání dat s aplikací. Pokud jsou informace uložené pro aplikaci v kontextu tenanta, měly by se k ní znovu přistupovat později ve stejném tenantovi. Nikdy nepovolujte přístup k datům v jednom tenantovi z jiného tenanta.

Ověření tenanta je pouze prvním krokem a stále se vyžadují kontroly předmětu a objektu actor popsaného v tomto článku. Pokud máte v úmyslu autorizovat všechny uživatele v tenantovi, důrazně doporučujeme tyto uživatele explicitně přidat do skupiny a autorizovat na základě skupiny. Například pouze kontrolou ID tenanta a přítomností oid deklarace identity může vaše rozhraní API neúmyslně autorizovat všechny instanční objekty v tomto tenantovi kromě uživatelů.

Ověření předmětu

Určete, jestli je subjekt tokenu, například uživatel (nebo samotná aplikace pro token jen pro aplikaci), autorizovaný.

Můžete zkontrolovat konkrétní sub deklarace identity nebo oid deklarace identity.

Nebo:

Můžete zkontrolovat, zda subjekt patří do příslušné role nebo skupiny s rolesdeklarací identity , groupswids . Použijte například neměnné hodnoty tid deklarací identity a oid jako kombinovaný klíč pro data aplikace a určete, jestli má být uživateli udělen přístup.

K rolesurčení, widsgroups zda má subjekt autorizaci k provedení operace, lze použít také deklarace identity. Správce může mít například oprávnění k zápisu do rozhraní API, ale ne k běžnému uživateli nebo může být ve skupině, která může provést nějakou akci. Deklarace wid identity představuje role pro celého tenanta přiřazené uživateli z rolí, které jsou přítomné v předdefinovaných rolích Microsoft Entra. Další informace najdete v tématu Předdefinované role Microsoft Entra.

Upozorňující

Nikdy nepoužívejte deklarace identity, jako emailje , preferred_username nebo unique_name k uložení nebo určení, jestli má mít uživatel v přístupovém tokenu přístup k datům. Tyto deklarace identity nejsou jedinečné a můžou je řídit správci tenantů nebo někdy uživatelé, což je nevhodné pro rozhodnutí o autorizaci. Jsou použitelné pouze pro účely zobrazení. K autorizaci také nepoužívejte upn deklaraci identity. Hlavní název uživatele (UPN) je sice jedinečný, ale v průběhu životnosti objektu zabezpečení uživatele se často mění, takže není zodpovědný za autorizaci.

Ověření objektu actor

Klientská aplikace, která působí jménem uživatele (označovaného jako aktér), musí být také autorizovaná. scp Pomocí deklarace identity (oboru) ověřte, že aplikace má oprávnění k provedení operace. Oprávnění scp by měla být omezena na to, co uživatel skutečně potřebuje, a dodržovat zásady nejnižších oprávnění.

V tokenu však existují výskyty, kde scp se token nenachází. U následujících scénářů byste měli zkontrolovat, jestli deklarace identity neexistuje scp :

  • Aplikace démona / oprávnění pouze aplikace
  • Tokeny ID

Další informace o oborech a oprávněních najdete v tématu Obory a oprávnění na platformě Microsoft Identity Platform.

Poznámka:

Aplikace může zpracovávat tokeny jen pro aplikace (požadavky z aplikací bez uživatelů, jako jsou aplikace démonů), a chce autorizovat konkrétní aplikaci napříč více tenanty, a ne jednotlivá ID instančního objektu. V takovém případě appid se deklarace identity (pro tokeny v1.0) nebo azp deklarace identity (pro tokeny v2.0) dají použít k autorizaci subjektu. Při použití těchto deklarací identity však musí aplikace zajistit, aby token byl vydán přímo pro aplikaci tím, že ověří volitelnou idtyp deklaraci identity. Tímto způsobem lze autorizovat pouze tokeny typu app , protože delegované tokeny uživatele mohou být potenciálně získány jinými entitami než aplikací.

Další kroky