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

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ý.
  • Subjekt (klientská aplikace) je autorizován.

Poznámka:

Přístupové tokeny jsou ověřovány pouze v těch webových rozhraních API, pro která je 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ěřte cílovou skupinu

Nárok aud 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 GUID.
  • V případě tokenů v1.0 je cílová skupina jedním z URI ID aplikace uvedených ve webovém rozhraní API, které token ověřuje. 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 URI ID aplikace naleznete v tématu Identifikátor URI aplikace.

Ověření tenanta

Vždy zkontrolujte, zda tid v tokenu odpovídá ID tenanta, který se používá k ukládání dat s aplikací. Pokud jsou informace uložené pro aplikaci v kontextu tenanta, mělo by se k nim 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 prvním krokem, ale kontroly předmětu a aktéra popsaného v tomto článku jsou stále nezbytné. Pokud chcete 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ěřit téma

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 nebo oid nároky.

Nebo:

Můžete zkontrolovat, jestli předmět patří do příslušné role nebo skupiny s roles požadavky, scp, groups, wids. Například použijte neměnné hodnoty tid a oid jako kombinovaný klíč pro data aplikace a určete, zda má být uživateli poskytnut přístup.

Položky roles, groups nebo wids se dají použít také k určení, jestli má subjekt autorizaci k provedení operace, i když nejsou vyčerpávajícím seznamem všech způsobů, jak může subjekt získat oprávnění. 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.

Varování

Nikdy nepoužívejte nároky, jako email, preferred_username nebo unique_name k uložení nebo určení, zda by uživatel v přístupovém tokenu měl mít přístup k datům. Tyto nároky nejsou jedinečné a mohou je řídit správci tenantů nebo někdy uživatelé, což je činí nevhodnými pro rozhodování o autorizaci. Jsou použitelné jenom pro účely zobrazení. K autorizaci také nepoužívejte upn deklaraci identity. I když je uživatelský hlavní název (UPN) jedinečný, často se během životnosti uživatele mění, což ho činí nespolehlivým pro autorizaci.

Ověřte herce

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í.

Jsou však případy, kdy se scp v tokenu nenachází. V následujících scénářích byste měli zkontrolovat, zda neexistuje nárok scp:

  • Aplikace daemon / oprávnění pouze pro aplikaci
  • 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 pouze pro aplikace (požadavky z uživatelsky nezávislých aplikací, jako jsou démonové aplikace) a chce autorizovat některou konkrétní aplikaci napříč více tenanty, namísto jednotlivých ID instančního objektu. V takovém případě se nárok appid (pro tokeny v1.0) nebo nárok azp (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

  • Last updated on