Dela via


Ö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:

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:

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.

Diagram över en app som anropar till Microsofts identitetsplattform, via en tokencache på enheten som kör programmet.

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.

Diagram över Microsofts identitetsplattform tjänster som hjälper dig att slutföra användarautentisering eller auktorisering.

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.

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?

Diagram över en app som anropar Microsofts identitetsplattform, via en tokencache och tokenlagring, samt autentiseringskoordinator på den enhet som kör programmet.

MSAL har stöd för asynkron autentisering. Läs mer:

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:

Om du utvecklar resurs-API:er går du till openid.net för Delade signaler – ett säkert webhooks-ramverk.

Nästa steg