Zvýšení odolnosti ověřování a autorizace v klientských aplikacích, které vyvíjíte
Naučte se vytvářet odolnost klientských aplikací, které používají platformu Microsoft Identity Platform a Microsoft Entra ID k přihlašování uživatelů a provádění akcí jménem těchto uživatelů.
Použití knihovny Microsoft Authentication Library (MSAL)
Knihovna MICROSOFT Authentication Library (MSAL) je součástí platformy Microsoft Identity Platform. MSAL získává, spravuje, ukládá do mezipaměti a aktualizuje tokeny; používá osvědčené postupy pro odolnost. MSAL pomáhá vývojářům vytvářet zabezpečená řešení.
Víc se uč:
- Přehled knihovny Microsoft Authentication Library
- Co je platforma Microsoft Identity Platform?
- dokumentace k platformě Microsoft identity platform
MSAL ukládá tokeny do mezipaměti a používá bezobslužný model získávání tokenů. MSAL serializuje mezipaměť tokenů v operačních systémech, které nativně poskytují zabezpečené úložiště, jako je Univerzální platforma Windows (UPW), iOS a Android. Přizpůsobte chování serializace při použití:
- Microsoft.Identity.Web
- MSAL.NET
- MSAL pro Javu
- MSAL pro Python
Víc se uč:
Serializace mezipaměti tokenů v MSAL.NET
Vlastní serializace mezipaměti tokenů v MSAL pro Python.
Microsoft Identity
Pokud používáte MSAL, podporuje se ukládání tokenů do mezipaměti, obnovení a tiché získávání. K získání tokenů pro ověřování použijte jednoduché vzory. Existuje podpora pro mnoho jazyků. Najděte ukázku kódu ukázky kódu platformy Microsoft Identity Platform.
try
{
result = await app.AcquireTokenSilent(scopes, account).ExecuteAsync();
}
catch(MsalUiRequiredException ex)
{
result = await app.AcquireToken(scopes).WithClaims(ex.Claims).ExecuteAsync()
}
Knihovna MSAL dokáže aktualizovat tokeny. Když platforma Microsoft Identity Platform vydá dlouhodobý token, může klientovi odeslat informace o aktualizaci tokenu (refresh_in). Aplikace se spustí, když je starý token platný, ale další získání tokenu trvá déle.
Vydané verze MSAL
Doporučujeme vývojářům vytvořit proces, který bude používat nejnovější verzi MSAL, protože ověřování je součástí zabezpečení aplikací. Tento postup použijte pro knihovny ve vývoji a vylepšete odolnost aplikací.
Vyhledejte nejnovější verzi a poznámky k verzi:
microsoft-authentication-library-for-js
microsoft-authentication-library-for-dotnet
microsoft-authentication-library-for-python
microsoft-authentication-library-for-java
microsoft-authentication-library-for-objc
microsoft-authentication-library-for-android
microsoft-identity-web
Odolné vzory pro zpracování tokenů
Pokud msAL nepoužíváte, použijte odolné vzory pro zpracování tokenů. Knihovna MSAL implementuje osvědčené postupy.
Obecně platí, že aplikace využívající moderní ověřování volají koncový bod k načtení tokenů, které ověřují uživatele, nebo autorizaci aplikace k volání chráněných rozhraní API. MSAL zpracovává ověřování a implementuje vzory za účelem zlepšení odolnosti. Pokud nepoužíváte knihovnu MSAL, postupujte podle pokynů v této části pro osvědčené postupy. V opačném případě msAL implementuje osvědčené postupy automaticky.
Záložní autentizační systém Microsoft Entra ID zajišťuje odolnost aplikací, které používají podporované protokoly a toky. Další informace o požadavcích na to, aby se dalo využít zálohovací ověřování, naleznete v části Požadavky na aplikace pro systém zálohovacího ověřování.
Tokeny mezipaměti
Ujistěte se, že aplikace ukládají tokeny přesně do mezipaměti z platformy Microsoft Identity. Jakmile aplikace obdrží tokeny, má odpověď HTTP s tokeny vlastnost expires_in
, která označuje dobu trvání ukládání do mezipaměti a kdy ji znovu použít. Ověřte, že se aplikace nepokoušá dekódovat přístupový token rozhraní API.
Tokeny uložené v mezipaměti brání zbytečnému provozu mezi aplikací a platformou Microsoft Identity Platform. Díky tomuto scénáři je aplikace méně náchylná k selháním získání tokenů snížením počtu volání získání tokenu. Tokeny uložené v mezipaměti zlepšují výkon aplikace, protože aplikace blokuje získávání tokenů méně často. Uživatelé zůstanou přihlášení k vaší aplikaci po celou dobu života tokenu.
Serializace a zachování tokenů
Zajistěte, aby aplikace bezpečně serializovaly mezipaměť tokenů, aby zachovaly tokeny mezi instancemi aplikace. Znovu použijte tokeny během jejich životnosti. Obnovovací tokeny a přístupové tokeny se vydávají po mnoho hodin. Během této doby můžou uživatelé aplikaci spustit několikrát. Po spuštění aplikace ověřte, že hledá platný přístup nebo obnovovací token. Tím se zvyšuje odolnost aplikací a výkon.
Víc se uč:
Ujistěte se, že trvalé úložiště tokenů má řízení přístupu a šifrování ve vztahu k identitě vlastníka uživatele nebo procesu. V různých operačních systémech existují funkce úložiště přihlašovacích údajů.
Tiché získání tokenů
Ověření uživatele nebo načtení autorizace pro volání rozhraní API zahrnuje několik kroků na platformě Microsoft Identity Platform. Například uživatelé, kteří se přihlašuje poprvé, zadají přihlašovací údaje a provedou vícefaktorové ověřování. Každý krok má vliv na prostředek, který službu poskytuje. Nejlepší uživatelské prostředí s nejmenšími závislostmi je tiché získání tokenu.
Získání tichého tokenu začíná platným tokenem z mezipaměti tokenů aplikace. Pokud neexistuje žádný platný token, aplikace se pokusí získat token pomocí dostupného obnovovacího tokenu a koncového bodu tokenu. Pokud není dostupná žádná možnost, aplikace získá token pomocí parametru prompt=none
. Tato akce používá koncový bod autorizace, ale pro uživatele se nezobrazí žádné uživatelské rozhraní. Pokud je to možné, platforma Microsoft Identity Platform poskytuje aplikaci token bez zásahu uživatele. Pokud žádná metoda nevytvoří token, uživatel se musí ručně znovu ověřit.
Poznámka
Obecně platí, že aplikace nepoužívají výzvy, jako je přihlášení a souhlas. Tyto výzvy nutí uživatele k interakci, když není nutná žádná interakce.
Zpracování kódu odpovědi
Informace o kódech odpovědí najdete v následujících částech.
Kód odpovědi HTTP 429
Existují chybové odpovědi, které ovlivňují odolnost. Pokud vaše aplikace obdrží kód odpovědi HTTP 429 (Příliš mnoho požadavků), platforma Microsoft Identity Platform omezuje vaše požadavky. Pokud aplikace provádí příliš mnoho požadavků, omezuje se, aby aplikace nemohla přijímat tokeny. Nepovolte aplikaci pokusit se o získání tokenu před tím, než vyprší Retry-After pole odezvy. Často odpověď 429 naznačuje, že aplikace nesprávně ukládá do mezipaměti a znovu používá tokeny. Ověřte, jak se tokeny ukládají do mezipaměti a znovu se používají v aplikaci.
Kód odpovědi HTTP 5x
Pokud aplikace obdrží kód odpovědi HTTP 5x, nesmí aplikace zadávat rychlou smyčku opakování. Pro zpracování odpovědi 429 použijte stejný postup. Pokud se nezobrazí žádná Retry-After hlavička, implementujte exponenciální opakování pokusů při prvním pokusu alespoň 5 sekund po odpovědi.
Když vyprší časový limit požadavku, okamžité opakování se nedoporučuje. Implementujte exponenciální odklad opakování, přičemž první opakování proběhne nejdříve 5 sekund po odpovědi.
Načítání informací souvisejících s autorizací
Mnoho aplikací a rozhraní API potřebuje k autorizaci informace o uživatelích. Dostupné metody mají výhody a nevýhody.
Odznaky
Tokeny identit a přístupové tokeny mají standardní deklarace identity, které poskytují informace. Pokud jsou v tokenu potřebné informace, nejúčinnější technikou jsou deklarace identity tokenů, protože brání jinému síťovému volání. Menší počet síťových volání zvyšuje odolnost.
Víc se uč:
Poznámka
Některé aplikace volají koncový bod Údaje o uživateli (UserInfo) k načtení údajů o ověřeném uživateli. Informace v tokenu ID jsou nadmnožinou informací z koncového bodu UserInfo. Povolte aplikacím, aby místo volání koncového bodu UserInfo používaly token ID.
Rozšíření standardních deklarací identity tokenů pomocí volitelných deklarací identity, jako jsou skupiny. Možnost Skupina aplikací zahrnuje skupiny přiřazené k aplikaci. Možnosti Všechny nebo skupiny zabezpečení zahrnují skupiny z aplikací ve stejném tenantovi, které můžou do tokenu přidávat skupiny. Vyhodnoťte účinek, protože může negovat efektivitu žádostí o skupiny v tokenu tím, že způsobí bloužení tokenu a vyžaduje více volání pro získání skupin.
Víc se uč:
Doporučujeme používat a zahrnout role aplikací, které zákazníci spravují pomocí portálu nebo rozhraní API. Přiřaďte role uživatelům a skupinám, abyste mohli řídit přístup. Při vystavení tokenu se přiřazené role nacházejí v atributu rolí tokenu. Informace odvozené z tokenu brání dalším voláním rozhraní API.
Podívejte se, Do své aplikace přidejte role aplikace a přijměte je v tokenu
Přidejte nároky na základě informací o tenantovi. Například rozšíření má ID uživatele specifické pro podniky.
Přidání informací z adresáře do tokenu je efektivní a zvyšuje odolnost tím, že snižuje závislosti. Neřeší problémy s odolností kvůli nemožnosti získat token. Přidejte volitelné nároky pro primární scénáře aplikace. Pokud aplikace vyžaduje informace pro funkce správy, může aplikace podle potřeby získat informace.
Microsoft Graph
Microsoft Graph má jednotný koncový bod rozhraní API pro přístup k datům Microsoftu 365 o vzorech produktivity, identitách a zabezpečení. Aplikace používající Microsoft Graph můžou k autorizaci používat informace o Microsoftu 365.
Aplikace vyžadují pro přístup k Microsoftu 365 jeden token, což je odolnější než předchozí rozhraní API pro komponenty Microsoft 365, jako je Microsoft Exchange nebo Microsoft SharePoint, které vyžadovaly více tokenů.
Při používání rozhraní Microsoft Graph API použijte sadu Microsoft Graph SDK, která zjednodušuje vytváření odolných aplikací, které přistupují k Microsoft Graphu.
Viz přehled sady Microsoft Graph SDK
Pro autorizaci zvažte použití deklarací tokenů místo některých volání Microsoft Graphu. Žádosti o skupiny, role aplikací a volitelné deklarace identity v tokenech Microsoft Graph pro autorizaci vyžaduje více síťových volání, která spoléhají na platformu Microsoft Identity Platform a Microsoft Graph. Pokud ale vaše aplikace jako datovou vrstvu spoléhá na Microsoft Graph, pak Microsoft Graph pro autorizaci nepředstavuje větší riziko.
Použití ověřování zprostředkovatele na mobilních zařízeních
Na mobilních zařízeních zprostředkovatel ověřování, jako je Microsoft Authenticator, zlepšuje odolnost. Zprostředkovatel ověřování používá primární obnovovací token (PRT) s deklaracemi identity o uživateli a zařízení. Pro autentizační tokeny použijte PRT k přístupu k jiným aplikacím ze zařízení. Když PRT požádá o přístup k aplikaci, Microsoft Entra ID důvěřuje zařízení a požadavkům MFA. Tím se zvyšuje odolnost tím, že snížíte kroky pro ověření zařízení. Uživatelé nejsou vyzváni více výzvami vícefaktorového ověřování na stejném zařízení.
Podívejte se, Co je primární obnovovací token?
MSAL podporuje ověřování zprostředkovatele. Víc se uč:
- SSO prostřednictvím zprostředkovatele ověřování v systému iOS
- Povolte jednotné přihlašování mezi aplikacemi na Androidu pomocí MSAL
Průběžné vyhodnocování přístupu
Průběžné vyhodnocování přístupu (CAE) zvyšuje zabezpečení a odolnost aplikací pomocí dlouhodobých tokenů. U caE se přístupový token odvolá na základě kritických událostí a vyhodnocení zásad, nikoli krátkých životností tokenů. U některých rozhraní API prostředků se rizika a zásady vyhodnocují v reálném čase, takže CAE zvyšuje životnost tokenu až na 28 hodin. MSAL aktualizuje dlouhodobé tokeny.
Víc se uč:
- průběžné vyhodnocování přístupu
- zabezpečení aplikací pomocí průběžného vyhodnocování přístupu
- vyhodnocení kritické události
- vyhodnocení zásad podmíněného přístupu
- Jak používat rozhraní API s podporou caE v aplikacích
Pokud vyvíjíte rozhraní API prostředků, přejděte na openid.net
pro Sdílené signály –Bezpečný Webhooks Framework, což je rámec pro webové háky.