Överväganden för hög tillgänglighet i MSAL.NET

För klientautentiseringsflödet läser du först dokumentationen om flöden för klientautentisering.

Använda ett API på högre nivå

MSAL är ett API på lägre nivå. Om du skriver en ny app bör du överväga att använda den högre nivån Microsoft.Identitity.Web som ger integrering med ASP.NET Core och ASP.NET Classic.

Använd den senaste MSAL

Använd den senaste MSAL för att hämta felkorrigeringar och prestandaförbättringar. Semantiska versionsregler följs.

Du vill också kontrollera om du bör använda Microsoft Identity Web, ett bibliotek på högre nivå för webbappar och webb-API:er, som gör mycket av det som beskrivs nedan för din. Se Välja en version av MSAL.NET, som föreslår ett beslutsträd för att välja den bästa lösningen beroende på din plattform och begränsningar.

Använd tokencachen

Standardbeteende: MSAL cachelagrar token i minnet. Varje ConfidentialClientApplication instans har en egen intern tokencache. Minnesintern cache kan till exempel gå förlorad om objektinstansen tas bort eller hela programmet stoppas.

Rekommendation: Alla appar bör spara sina tokencacheminnen. Webbappar och webb-API:er bör använda en L1/L2-tokencache där L2 är ett distribuerat arkiv som Redis för att hantera skalning. Skrivbordsappar bör använda en korrekt strategi för tokencache-serialisering.

Standardbeteende: MSAL underhåller en sekundär ADAL-tokencache för migreringsscenarier mellan ADAL och MSAL. ADAL-cacheåtgärder är mycket långsamma. Rekommendation: Inaktivera ADAL-cache om du inte är intresserad av att migrera från ADAL. Detta kommer att ge en stor prestandaförbättring – se prestandamätningar här.

Lägg till WithLegacyCacheCompatibility(false) när du skapar din app för att inaktivera ADAL-cachelagring.

Lägga till övervakning kring MSAL-åtgärder

MSAL exponerar viktiga mått som en del av AuthenticationResult.AuthenticationResultMetadata-objektet :

Logging

Lyssna efter meddelanden på Warning- och Error-nivå från MSAL-loggar. Det kan vara tysta fel eller starka rekommendationer för att använda en annan konfiguration. Vi rekommenderar inte att du anger Verbose loggning i produktion eftersom det ger många meddelanden och påverkar prestanda.

Information om loggning finns i guiden Loggning i MSAL.NET.

Återförsöksprincip

Standardbeteende: MSAL försöker igen med misslyckade 5xx-begäranden en gång.

Rekommendation:

• Se vår dokumentation om principer för återförsök om hur du skapar en princip för återförsök med Polly

En konfidentiell klient per session

Vi rekommenderar att du använder en ny ConfidentialClientApplication på varje session och serialiserar på samma sätt – en tokencache per session. Detta skalar väl och ökar även säkerheten. De officiella exemplen visar hur du gör detta. Du måste konfigurera cachelagring av token för att detta ska fungera korrekt.

HttpClient (på engelska)

Standardbeteende: MSAL-skapade HttpClient skalas inte bra för webbplatser/webb-API där vi rekommenderar att du har ett ClientApplication objekt för varje användarsession.

Rekommendation: Tillhandahåll en egen skalbar HttpClientFactory. På .NET Core rekommenderar vi att du injicerar System.Net.Http.IHttpClientFactory. Detta beskrivs mer detaljerat i guiden Tillhandahålla din egen HttpClient, stöd för HTTP-proxyservrar och anpassning av användaragenthuvuden och i dokumentationen för .NET

Proaktiv tokenförnyelse

Mål

Öka programtillgängligheten genom att utfärda åtkomsttoken med längre livslängd och se till att de uppdateras tidigare än förfallodatumet.

Status quo

Som standard utfärdar Microsoft Entra ID åtkomsttoken med 1 timmes förfallotid. Om ett Microsoft Entra avbrott inträffar när en token behöver uppdateras misslyckas MSAL. Felet sprids till det anropande programmet och påverkar tillgängligheten.

Process

För att förbättra tillgängligheten försöker MSAL se till att en app alltid har nya oexpirerade token. Microsoft Entra avbrott tar sällan mer än några timmar, så om MSAL kan garantera att en token alltid har minst några timmars tillgänglighet kvar påverkas inte programmet av Microsoft Entra avbrott.

För att få token med lång giltighetstid måste du konfigurera din klientorganisation (obs! interna Microsoft-klientorganisationer är redan konfigurerade). För client_credentials (tjänst 2-tjänst) räcker det. För användarautentiseringsuppgifter måste du också konfigurera CAE – /azure/active-directory/conditional-access/concept-continuous-access-evaluation.

När Microsoft Entra ID returnerar en långlivad token innehåller den ett refresh_in fält. Den är vanligtvis inställd på hälften av förfallodatumet för åtkomsttoken.

Obs: Från och med MSAL 4.37.0 kan du se det här värdet genom att granska AuthenticationResult.AuthenticationResultMetadata.RefreshOn.

Dessutom kan du konfigurera en tokenlivslängd på mer än standardvärdet 1 timme, enligt beskrivningen i Konfigurerbara tokenlivslängder i Microsofts identitetsplattform (förhandsversion).

När du gör begäranden om samma token, d.v.s. när MSAL kan hantera en token från cacheminnet, kontrollerar refresh_in MSAL automatiskt värdet. Om den har löpt ut skickar MSAL en tokenbegäran till Microsoft Entra ID i bakgrunden, men returnerar den befintliga, giltiga tokenen till applikationen. Om bakgrundsuppdateringen misslyckas (t.ex. Microsoft Entra avbrott) påverkas inte appen.

Certifikatrotation

Certifikat för den konfidentiella klientappen måste roteras av säkerhetsskäl (använd inte hemligheter i prod!). Det finns flera sätt att hantera rotation av certifikat, i ordning från det mest rekommenderade till det minst rekommenderade:

1. Använda hanterad identitet

Med hanterad identitet upprättas förtroende genom att vara värd för din app i Azure. Det finns inga hemligheter att underhålla och inga certifikat att rotera.

2. Använda logiken för Microsoft.Identity.Web certifikathantering

I webbappar och webb-API:er använder du Microsoft.Identity.Web, ett API på högre nivå över MSAL. Den hanterar certifikatrotation när certifikatet lagras i Azure Key Vault och hanterar även hanterat identitetsfall.

Läs mer i Certifikat i Microsoft. Identity.Web-guide.

Det här är den bästa lösningen för icke-Microsoft interna tjänster med hjälp av ASP.NET Core.

3. (Endast för internt bruk inom Microsoft) Använd certifikat för subjektnamn/utfärdare.

Med den här mekanismen kan Microsoft Entra ID identifiera ett certifikat baserat på SN/I i stället för ett tumavtryck (x5t). Det är en stop-gap-lösning. Det finns inga planer på att göra den tillgänglig för program som inte är Microsoft.

Det här är den bästa lösningen för Microsoft interna tjänster som inte kan använda hanterad identitet.