Öka motståndskraften för autentisering och auktorisering i klientprogram som du utvecklar
Lär dig att bygga motståndskraft i klientprogram som använder Microsofts identitetsplattform- och Microsoft Entra-ID:t för att logga in användare och utföra åtgärder för dessa användares räkning.
Använda Microsoft Authentication Library (MSAL)
Microsoft Authentication Library (MSAL) är en del av Microsofts identitetsplattform. MSAL hämtar, hanterar, cachelagrar och uppdaterar token; den använder metodtips för motståndskraft. MSAL hjälper utvecklare att skapa säkra lösningar.
Läs mer:
- Översikt över Microsoft-autentiseringsbiblioteket
- Vad är Microsofts identitetsplattform?
- Microsofts identitetsplattform dokumentation
MSAL cachelagrar token och använder ett mönster för hämtning av tyst token. MSAL serialiserar tokencachen på operativsystem som internt tillhandahåller säker lagring som Universell Windows-plattform (UWP), iOS och Android. Anpassa serialiseringsbeteendet när du använder:
- Microsoft.Identity.Web
- MSAL.NET
- MSAL för Java
- MSAL för Python
Läs mer:
När du använder MSAL stöds cachelagring av token, uppdatering och tyst förvärv. Använd enkla mönster för att hämta token för autentisering. Det finns stöd för många språk. Hitta kodexempel på Microsofts identitetsplattform kodexempel.
try
{
result = await app.AcquireTokenSilent(scopes, account).ExecuteAsync();
}
catch(MsalUiRequiredException ex)
{
result = await app.AcquireToken(scopes).WithClaims(ex.Claims).ExecuteAsync()
}
MSAL kan uppdatera token. När Microsofts identitetsplattform utfärdar en långlivad token kan den skicka information till klienten för att uppdatera token (refresh_in). Appen körs medan den gamla token är giltig, men det tar längre tid för ett annat tokenförvärv.
MSAL-versioner
Vi rekommenderar att utvecklare skapar en process för att använda den senaste MSAL-versionen eftersom autentisering är en del av appsäkerheten. Använd den här metoden för bibliotek under utveckling och förbättra appresiliensen.
Hitta den senaste versionen och viktig information:
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
Elastiska mönster för tokenhantering
Om du inte använder MSAL använder du elastiska mönster för tokenhantering. MSAL-biblioteket implementerar metodtips.
I allmänhet anropar program som använder modern autentisering en slutpunkt för att hämta token som autentiserar användaren eller auktoriserar programmet att anropa skyddade API:er. MSAL hanterar autentisering och implementerar mönster för att förbättra motståndskraften. Om du inte använder MSAL använder du vägledningen i det här avsnittet för bästa praxis. Annars implementerar MSAL metodtips automatiskt.
Cachetoken
Se till att appar cachelagrar token korrekt från Microsofts identitetsplattform. När appen har tagit emot token har HTTP-svaret med token en expires_in
egenskap som anger varaktigheten för cachelagring och när den ska återanvändas. Bekräfta att programmet inte försöker avkoda en API-åtkomsttoken.
Cachelagrade token förhindrar onödig trafik mellan en app och Microsofts identitetsplattform. Det här scenariot gör appen mindre mottaglig för tokenförvärvsfel genom att minska anropen för tokenförvärv. Cachelagrade token förbättrar programmets prestanda eftersom appen blockerar anskaffning av token mindre ofta. Användarna är fortfarande inloggade i ditt program under tokenlivslängden.
Serialisera och bevara token
Se till att appar serialiserar sin tokencache på ett säkert sätt för att bevara token mellan appinstanser. Återanvända token under deras livslängd. Uppdateringstoken och åtkomsttoken utfärdas i många timmar. Under den här tiden kan användarna starta programmet flera gånger. När en app startar bekräftar du att den söker efter giltig åtkomst eller en uppdateringstoken. Detta ökar appens motståndskraft och prestanda.
Läs mer:
Se till att beständig tokenlagring har åtkomstkontroll och kryptering i förhållande till användarens ägare eller processidentiteten. På olika operativsystem finns det funktioner för lagring av autentiseringsuppgifter.
Hämta token tyst
Att autentisera en användare eller hämta auktorisering för att anropa ett API innebär flera steg i Microsofts identitetsplattform. Användare som loggar in för första gången anger till exempel autentiseringsuppgifter och utför en multifaktorautentisering. Varje steg påverkar resursen som tillhandahåller tjänsten. Den bästa användarupplevelsen med minst beroenden är tyst tokenförvärv.
Förvärvet av tyst token börjar med en giltig token från apptokencachen. Om det inte finns någon giltig token försöker appen hämta en token med hjälp av en tillgänglig uppdateringstoken och tokenslutpunkten. Om inget av alternativen är tillgängligt hämtar appen en token med hjälp av parametern prompt=none
. Den här åtgärden använder auktoriseringsslutpunkten, men inget användargränssnitt visas för användaren. Om möjligt tillhandahåller Microsofts identitetsplattform en token till appen utan användarinteraktion. Om ingen metod resulterar i en token autentiserar användaren manuellt igen.
Kommentar
I allmänhet ser du till att appar inte använder uppmaningar som "login" och "consent". Dessa uppmanar framtvinga användarinteraktion när ingen interaktion krävs.
Hantering av svarskod
Använd följande avsnitt för att lära dig mer om svarskoder.
HTTP 429-svarskod
Det finns felsvar som påverkar motståndskraften. Om ditt program får en HTTP 429-svarskod, För många begäranden, begränsar Microsofts identitetsplattform dina begäranden. Om en app gör för många begäranden begränsas den för att förhindra att appen tar emot token. Tillåt inte att en app försöker förvärva token innan svarsfältet Återförsök efter har slutförts. Ofta anger ett 429-svar att programmet inte cachelagrar och återanvänder token korrekt. Bekräfta hur token cachelagras och återanvänds i programmet.
HTTP 5x-svarskod
Om ett program får en HTTP 5x-svarskod får appen inte ange en snabb återförsöksloop. Använd samma hantering för ett 429-svar. Om inget återförsökshuvud visas implementerar du ett exponentiellt återförsök med det första återförsöket, minst 5 sekunder efter svaret.
När en begäran överskrider tidsgränsen avråds omedelbara återförsök. Implementera ett exponentiellt återförsök med det första återförsöket, minst 5 sekunder efter svaret.
Hämtar auktoriseringsrelaterad information
Många program och API:er behöver användarinformation för att auktorisera. Tillgängliga metoder har fördelar och nackdelar.
Token
Identitetstoken (ID) och åtkomsttoken har standardanspråk som ger information. Om nödvändig information finns i token är den mest effektiva tekniken tokenanspråk, eftersom det förhindrar ett annat nätverksanrop. Färre nätverksanrop motsvarar bättre motståndskraft.
Läs mer:
Kommentar
Vissa program anropar UserInfo-slutpunkten för att hämta anspråk om den autentiserade användaren. Informationen i ID-token är en supermängd med information från UserInfo-slutpunkten. Aktivera appar för att använda ID-token i stället för att anropa UserInfo-slutpunkten.
Utöka standardtokenanspråk med valfria anspråk, till exempel grupper. Alternativet Programgrupp innehåller grupper som tilldelats programmet. Alternativen Alla eller Säkerhetsgrupper innehåller grupper från appar i samma klientorganisation, som kan lägga till grupper i token. Utvärdera effekten eftersom den kan göra det svårare att begära grupper i token genom att orsaka uppsvälld token och kräva fler anrop för att hämta grupperna.
Läs mer:
Vi rekommenderar att du använder och inkluderar approller som kunderna hanterar med hjälp av portalen eller API:erna. Tilldela roller till användare och grupper för att styra åtkomsten. När en token utfärdas finns de tilldelade rollerna i anspråket för tokenroller. Information som härleds från en token förhindrar fler API:er-anrop.
Se Lägga till approller i ditt program och ta emot dem i token
Lägg till anspråk baserat på klientinformation. Ett tillägg har till exempel ett företagsspecifikt användar-ID.
Att lägga till information från katalogen till en token är effektivt och ökar motståndskraften genom att minska beroenden. Den hanterar inte motståndskraftsproblem på grund av att det inte går att hämta en token. Lägg till valfria anspråk för programmets primära scenarier. Om appen kräver information för administrativa funktioner kan programmet hämta den informationen efter behov.
Microsoft Graph
Microsoft Graph har en enhetlig API-slutpunkt för åtkomst till Microsoft 365-data om produktivitetsmönster, identitet och säkerhet. Program som använder Microsoft Graph kan använda Microsoft 365-information för auktorisering.
Appar kräver en token för åtkomst till Microsoft 365, vilket är mer motståndskraftigt än tidigare API:er för Microsoft 365-komponenter som Microsoft Exchange eller Microsoft SharePoint som krävde flera token.
När du använder Microsoft Graph-API:er använder du ett Microsoft Graph SDK som förenklar skapandet av motståndskraftiga program som har åtkomst till Microsoft Graph.
Se Översikt över Microsoft Graph SDK
Överväg att använda tokenanspråk i stället för vissa Microsoft Graph-anrop för auktorisering. Begär grupper, approller och valfria anspråk i token. Microsoft Graph för auktorisering kräver fler nätverksanrop som förlitar sig på Microsofts identitetsplattform och Microsoft Graph. Men om ditt program förlitar sig på Microsoft Graph som datalager är Microsoft Graph för auktorisering inte större risk.
Använda asynkron autentisering på mobila enheter
På mobila enheter förbättrar en autentiseringskoordinator som Microsoft Authenticator motståndskraften. Autentiseringskoordinatorn använder en primär uppdateringstoken (PRT) med anspråk om användaren och enheten. Använd PRT för autentiseringstoken för att få åtkomst till andra program från enheten. När en PRT begär programåtkomst litar Microsoft Entra-ID på enhetens och MFA-anspråken. Detta ökar motståndskraften genom att minska stegen för att autentisera enheten. Användare utmanas inte med flera MFA-frågor på samma enhet.
Se, Vad är en primär uppdateringstoken?
MSAL har stöd för asynkron autentisering. Läs mer:
- Enkel inloggning via autentiseringskoordinator på iOS
- Aktivera enkel inloggning mellan appar på Android med MSAL
Utvärdering av kontinuerlig åtkomst
Kontinuerlig åtkomstutvärdering (CAE) ökar programsäkerheten och återhämtningsförmågan med långlivade token. Med CAE återkallas en åtkomsttoken baserat på kritiska händelser och principutvärdering i stället för korta livslängder för token. För vissa resurs-API:er, eftersom risk och princip utvärderas i realtid, ökar CAE tokenlivslängden upp till 28 timmar. MSAL uppdaterar långlivade token.
Läs mer:
- Utvärdering av kontinuerlig åtkomst
- Skydda program med kontinuerlig åtkomstutvärdering
- Utvärdering av kritiska händelser
- Principutvärdering för villkorsstyrd åtkomst
- Använda CAE-aktiverade API:er i dina program
Om du utvecklar resurs-API:er går du till openid.net
för Delade signaler – ett säkert webhooks-ramverk.