Dela via

Öka motståndskraften för autentisering och auktorisering i daemonprogram som du utvecklar

  • Artikel

Lär dig hur du använder Microsofts identitetsplattform- och Microsoft Entra-ID:t för att öka motståndskraften för daemonprogram. Hitta information om bakgrundsprocesser, tjänster, server-till-server-appar och program utan användare.

Se Vad är Microsofts identitetsplattform?

Följande diagram illustrerar ett daemonprogram som anropar Microsofts identitetsplattform.

A daemon application making a call to Microsoft identity platform.

Hanterade identiteter för Azure-resurser

Om du skapar daemon-appar i Microsoft Azure använder du hanterade identiteter för Azure-resurser som hanterar hemligheter och autentiseringsuppgifter. Funktionen förbättrar motståndskraften genom att hantera certifikatets förfallodatum, rotation eller förtroende.

Se Vad är hanterade identiteter för Azure-resurser?

Hanterade identiteter använder långlivade åtkomsttoken och information från Microsofts identitetsplattform för att hämta nya token innan token upphör att gälla. Appen körs när du hämtar nya token.

Hanterade identiteter använder regionala slutpunkter, vilket hjälper till att förhindra fel i out-of-region genom att konsolidera tjänstberoenden. Regionala slutpunkter hjälper till att hålla trafiken i ett geografiskt område. Om din Azure-resurs till exempel finns i WestUS2 stannar all trafik i WestUS2.

Microsoft autentiseringsbibliotek

Om du utvecklar daemon-appar och inte använder hanterade identiteter använder du Microsoft Authentication Library (MSAL) för autentisering och auktorisering. MSAL underlättar processen med att ange klientautentiseringsuppgifter. Ditt program behöver till exempel inte skapa och signera JSON-webbtokenkontroller med certifikatbaserade autentiseringsuppgifter.

Se Översikt över Microsoft Authentication Library (MSAL)

Microsoft.Identity.Web för .NET-utvecklare

Om du utvecklar daemon-appar på ASP.NET Core använder du Microsoft.Identity.Web-biblioteket för att underlätta auktoriseringen. Den innehåller strategier för distribuerad tokencache för distribuerade appar som körs i flera regioner.

Läs mer:

Cachelagrar och lagrar token

Om du inte använder MSAL för autentisering och auktorisering finns det metodtips för cachelagring och lagring av token. MSAL implementerar och följer dessa metodtips.

Ett program hämtar token från en identitetsprovider (IdP) för att auktorisera programmet att anropa skyddade API:er. När din app tar emot token innehåller svaret med token en expires\_in egenskap som talar om för programmet hur länge token ska cachelagrats och återanvändas. Se till att program använder expires\_in egenskapen för att fastställa tokens livslängd. Bekräfta att programmet inte försöker avkoda en API-åtkomsttoken. Om du använder den cachelagrade token förhindras onödig trafik mellan en app och Microsofts identitetsplattform. Användarna är inloggade i ditt program under tokens livslängd.

HTTP 429- och 5xx-felkoder

Använd följande avsnitt för att lära dig mer om HTTP 429- och 5xx-felkoder

HTTP 429

Det finns HTTP-fel som påverkar motståndskraften. Om ditt program får en HTTP 429-felkod, För många begäranden, Microsofts identitetsplattform begränsar dina begäranden, vilket hindrar din app från att ta emot token. Se till att dina appar inte försöker hämta en token förrän tiden i fältet Försök efter svar upphör att gälla. 429-felet anger ofta att programmet inte cachelagrar och återanvänder token korrekt.

HTTP 5xx

Om ett program får en HTTP 5x-felkod får appen inte ange en snabb återförsöksloop. Se till att programmen väntar tills återförsöksfältet upphör att gälla. Om svaret inte ger något återförsökshuvud använder 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 bekräftar du att programmen inte försöker igen omedelbart. Använd det tidigare citerade exponentiella säkerhetskopieringsförsöket.

Nästa steg