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

Další informace:

• 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

Další informace:

• Serializace mezipaměti tokenů

• Serializace mezipaměti tokenů v MSAL.NET

• Serializace mezipaměti vlastních tokenů v MSAL pro Javu

• Serializace mezipaměti vlastních tokenů v MSAL pro Python

  

Pokud používáte KNIHOVNU MSAL, podporuje se ukládání tokenů do mezipaměti, aktualizace a tiché získá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 na platformě Microsoft Identity Platform.

C#

try
{
    result = await app.AcquireTokenSilent(scopes, account).ExecuteAsync();
}
catch(MsalUiRequiredException ex)
{
    result = await app.AcquireToken(scopes).WithClaims(ex.Claims).ExecuteAsync()
}

JavaScript

return myMSALObj.acquireTokenSilent(request).catch(error => {
    console.warn("silent token acquisition fails. acquiring token using redirect");
    if (error instanceof msal.InteractionRequiredAuthError) {
        // fallback to interaction when silent call fails
        return myMSALObj.acquireTokenPopup(request).then(tokenResponse => {
            console.log(tokenResponse);

            return tokenResponse;
        }).catch(error => {
            console.error(error);
        });
    } else {
        console.warn(error);
    }
});

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, pro osvědčené postupy použijte pokyny v této části. V opačném případě msAL implementuje osvědčené postupy automaticky.

Tokeny mezipaměti

Zajistěte, aby tokeny mezipaměti aplikací byly přesné z platformy Microsoft Identity Platform. Jakmile aplikace obdrží tokeny, má odpověď HTTP s tokeny expires_in vlastnost, která označuje dobu 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.

Další informace:

• Aktualizace přístupových tokenů

• Tokeny Microsoft Identity Platform pro identitu

  

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

Bezobslužné 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 získání tichého 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í k dispozici žá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 nemá za následek token, uživatel ručně znovu vytvoří ověření.

Poznámka:

Obecně platí, že aplikace nepoužívají výzvy, jako je přihlášení a souhlas. Tyto výzvy vynutí interakci uživatele, pokud 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 snižuje vaše požadavky. Pokud aplikace provádí příliš mnoho požadavků, omezuje se, aby aplikace nemohla přijímat tokeny. Nepovolte aplikaci, aby se pokusila o získání tokenu před dokončením doby odezvy po opakování . Odpověď 429 často značí, že aplikace neukládají do mezipaměti a správně se nepoužívají 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 odpověď 429 použijte stejné zpracování. Pokud se nezobrazí žádná hlavička Opakovat až po, implementujte exponenciální opakování opakování s prvním opakováním aspoň 5 sekund po odpovědi.

Když vyprší časový limit požadavku, okamžité opakování se nedoporučuje. Implementujte exponenciální opakování opakování s prvním opakováním aspoň 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.

Tokeny

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í je vyšší odolností.

Další informace:

• Tokeny Microsoft Identity Platform pro ID
• Tokeny Microsoft Identity Platform pro identitu

Poznámka:

Některé aplikace volají koncový bod UserInfo k načtení deklarací identity 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 Skupiny 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.

Další informace:

• Zadání volitelných deklarací identity do aplikace
• Konfigurace volitelných deklarací identity skupin

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 deklaraci identity rolí tokenu. Informace odvozené z tokenu brání dalším voláním rozhraní API.

Podívejte se, přidejte do aplikace role aplikace a získejte je v tokenu.

Přidejte deklarace identity 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řidání volitelných deklarací identity 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í identity 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, není microsoft Graph pro autorizaci 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 přístup k jiným aplikacím ze zařízení použijte PRT. Když prT požádá o přístup k aplikaci, Microsoft Entra ID důvěřuje svému zařízení a deklarací identity 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. Další informace:

• Jednotné přihlašování prostřednictvím zprostředkovatele ověřování v iOSu
• Povolení jednotného přihlašování mezi aplikacemi v 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ů, protože rizika a zásady se vyhodnocují v reálném čase, caE zvyšuje životnost tokenu až 28 hodin. MSAL aktualizuje dlouhodobé tokeny.

Další informace:

• 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 ve vašich aplikacích

Pokud vyvíjíte rozhraní API prostředků, přejděte do openid.net části Sdílené signály – Zabezpečená architektura Webhooků.

Další kroky

• Jak používat rozhraní API s podporou caE ve vašich aplikacích
• Zvýšení odolnosti ověřování a autorizace v aplikacích démonů, které vyvíjíte
• Zajištění odolnosti v infrastruktuře správy identit a přístupu
• Zajištění odolnosti v identitě zákazníka a správě přístupu pomocí Azure AD B2C