Overwegingen voor hoge beschikbaarheid in MSAL.NET

Raadpleeg eerst de documentatie over Stromen voor clientreferenties voor de stroom voor clientreferenties.

Een API op een hoger niveau gebruiken

MSAL is een API op lager niveau. Als u een nieuwe app schrijft, kunt u overwegen het hogere niveau Microsoft.Identitity.Web te gebruiken dat standaardintegratie biedt met ASP.NET Core en ASP.NET Classic.

De nieuwste MSAL gebruiken

Gebruik de nieuwste MSAL om de bugfixes en prestatieverbeteringen op te halen. Semantische versiebeheerregels worden gevolgd.

U wilt ook controleren of u Microsoft Identity Web moet gebruiken, een bibliotheek op een hoger niveau voor web-apps en web-API's, die veel doet wat hieronder wordt beschreven voor uw. Zie Een versie van MSAL.NET kiezen, waarin een beslissingsstructuur wordt voorgesteld om de beste oplossing te kiezen, afhankelijk van uw platform en beperkingen.

De tokencache gebruiken

Standaardgedrag: MSAL slaat de tokens in het geheugen op. Elk ConfidentialClientApplication exemplaar heeft een eigen interne tokencache. De in-memorycache kan verloren gaan, bijvoorbeeld als de objectinstantie wordt vrijgegeven of de hele toepassing wordt gestopt.

Aanbeveling: Alle apps moeten hun tokencaches behouden. Web-apps en web-API's moeten gebruikmaken van een L1/L2-tokencache waarbij L2 een gedistribueerde store is zoals Redis voor het afhandelen van de schaal. Desktop-apps moeten een juiste serialisatiestrategie voor tokencache gebruiken.

Standaardgedrag: MSAL onderhoudt een secundaire ADAL-tokencache voor migratiescenario's tussen ADAL en MSAL. ADAL-cachebewerkingen zijn erg traag. Aanbeveling: Schakel ADAL-cache uit als u niet geïnteresseerd bent in migratie vanuit ADAL. Dit zorgt voor een BIG prestatieverbetering - zie de prestatiemetingen hier.

Voeg toe WithLegacyCacheCompatibility(false) bij het samenstellen van uw app om ADAL-caching uit te schakelen.

Bewaking toevoegen rond MSAL-bewerkingen

MSAL maakt belangrijke metrische gegevens beschikbaar als onderdeel van het object AuthenticationResult.AuthenticationResultMetadata :

Logging

Luister naar berichten op Warning- en Error-niveau afkomstig uit MSAL-logboeken. Dit kunnen stille fouten zijn of dringende aanbevelingen om een andere configuratie te gebruiken. Het wordt niet aanbevolen om Verbose logging in een productieomgeving in te schakelen, omdat dit veel berichten genereert en de prestaties beïnvloedt.

Meer informatie over logboekregistratie vindt u in de handleiding voor logboekregistratie in MSAL.NET.

Beleid voor opnieuw proberen

Standaardgedrag: MSAL probeert mislukte 5xx-aanvragen eenmaal opnieuw.

Aanbeveling:

• Raadpleeg onze beleidsdocumentatie voor opnieuw proberen voor het schrijven van een beleid voor opnieuw proberen met Polly

Eén vertrouwelijke client per sessie

Het is raadzaam om bij elke sessie een nieuwe ConfidentialClientApplication te gebruiken en op dezelfde manier te serialiseren: één tokencache per sessie. Dit is goed schaalbaar en verbetert ook de beveiliging. In de officiële voorbeelden ziet u hoe u dit doet. U moet tokencaching zo configureren dat dit goed werkt.

HttpClient

Standaardgedrag: MSAL-gemaakt HttpClient schaalt niet goed voor websites/web-API, waarbij we aanraden om een ClientApplication object te hebben voor elke gebruikerssessie.

Aanbeveling: Geef uw eigen schaalbare HttpClientFactory op. Voor .NET Core adviseren we u om de System.Net.Http.IHttpClientFactory te injecteren. Dit wordt in meer detail beschreven in de handleiding Voor het bieden van uw eigen HttpClient, het ondersteunen van HTTP-proxy's en het aanpassen van headers voor gebruikersagents en in de documentatie van de .NET

Proactieve vernieuwing van tokens

Doel

Verhoog de beschikbaarheid van toepassingen door langerlevende toegangstokens uit te geven en ervoor te zorgen dat ze eerder worden vernieuwd dan hun vervaldatum.

Status quo

Standaard geeft Microsoft Entra ID toegangstokens met een verlooptijd van 1 uur uit. Als er een Microsoft Entra storing optreedt wanneer een token moet worden vernieuwd, mislukt MSAL. De fout wordt doorgegeven aan de aanroepende toepassing en heeft invloed op de beschikbaarheid.

Proces

Om de beschikbaarheid te verbeteren, probeert MSAL ervoor te zorgen dat een app altijd nieuwe niet-verlopen tokens heeft. Microsoft Entra storingen zelden langer dan een paar uur duren, dus als MSAL kan garanderen dat een token altijd ten minste een paar uur beschikbaarheid heeft, wordt de toepassing niet beïnvloed door de Microsoft Entra storing.

Als u tokens met een lange levensduur wilt ophalen, moet u uw tenant configureren (opmerking: interne Microsoft tenants zijn al geconfigureerd). Voor client_credentials (service 2 service) is dit voldoende. Voor gebruikersreferenties moet u ook CAE - /azure/active-directory/conditional-access/concept-continuous-access-evaluation configureren.

Wanneer Microsoft Entra ID een token met een lange levensduur retourneert, bevat het een refresh_in veld. Het is over het algemeen ingesteld op de helft van de vervaldatum van het toegangstoken.

Opmerking: Vanaf MSAL 4.37.0 en hoger kunt u deze waarde bekijken door de AuthenticationResult.AuthenticationResultMetadata.RefreshOn te inspecteren.

Daarnaast kunt u een tokenlevensduur van meer dan de standaardtijd van 1 uur configureren, zoals beschreven in configureerbare tokenlevensduur in de Microsoft identity platform (preview).

Wanneer u aanvragen voor hetzelfde token indient, bijvoorbeeld wanneer MSAL een token uit de cache kan leveren, controleert MSAL automatisch de refresh_in waarde. Als dat het geval is, doet MSAL op de achtergrond een tokenaanvraag naar Microsoft Entra ID, maar retourneert het bestaande, geldige token aan de toepassing. In het onwaarschijnlijke geval dat de verversing op de achtergrond mislukt (bijvoorbeeld door een storing bij Microsoft Entra), heeft dit geen gevolgen voor de app.

Certificaatrotatie

Certificaten voor de vertrouwelijke client-app moeten om veiligheidsredenen worden geroteerd (gebruik geen geheimen in prod!). Er zijn verschillende manieren om certificaatrotatie te verwerken, in volgorde van de meest voorkeur tot het minste:

1. Een beheerde identiteit gebruiken

Met een beheerde identiteit wordt vertrouwensrelatie tot stand gebracht door uw app in Azure te hosten. Er zijn geen geheime gegevens die onderhouden moeten worden en geen certificaten die geroteerd moeten worden.

2. De logica voor certificaatafhandeling Microsoft.Identity.Web gebruiken

Gebruik in web-apps en web-API's Microsoft.Identity.Webeen API op een hoger niveau via MSAL. Het verwerkt certificaatrotatie wanneer het certificaat wordt opgeslagen in Azure Key Vault en verwerkt ook beheerde identiteitscases.

Meer informatie vindt u in de certificaten in Microsoft. Identity.Web Guide.

Dit is de voorkeursoplossing voor niet-Microsoft interne services die gebruikmaken van ASP.NET Core.

3. (Alleen voor intern gebruik door Microsoft) Vertrouw op certificaten op basis van onderwerpnaam/verlener.

Met dit mechanisme kan Microsoft Entra ID een certificaat identificeren op basis van SN/I in plaats van een vingerafdruk (x5t). Het is een stop-gap oplossing; er zijn geen plannen om het beschikbaar te maken voor niet-Microsoft toepassingen.

Dit is de voorkeursoplossing voor Microsoft interne services die geen beheerde identiteit kunnen gebruiken.