Share via


De tolerantie van verificatie en autorisatie vergroten in daemon-toepassingen die u ontwikkelt

Leer hoe u het Microsoft Identity Platform en Microsoft Entra ID kunt gebruiken om de tolerantie van daemon-toepassingen te vergroten. Zoek informatie over achtergrondprocessen, services, server-naar-server-apps en toepassingen zonder gebruikers.

Zie Wat is het Microsoft Identity Platform?

In het volgende diagram ziet u een daemon-toepassing die een aanroep naar het Microsoft Identity Platform maakt.

A daemon application making a call to Microsoft identity platform.

Beheerde identiteiten voor Azure-resources

Als u daemon-apps in Microsoft Azure bouwt, gebruikt u beheerde identiteiten voor Azure-resources die geheimen en referenties verwerken. De functie verbetert de tolerantie door certificaatverloop, rotatie of vertrouwen te verwerken.

Wat zijn beheerde identiteiten voor Azure-resources?

Beheerde identiteiten maken gebruik van langlevende toegangstokens en informatie van het Microsoft Identity Platform om nieuwe tokens te verkrijgen voordat tokens verlopen. Uw app wordt uitgevoerd tijdens het verkrijgen van nieuwe tokens.

Beheerde identiteiten maken gebruik van regionale eindpunten, waardoor storingen buiten de regio worden voorkomen door serviceafhankelijkheden te consolideren. Regionale eindpunten helpen verkeer in een geografisch gebied te behouden. Als uw Azure-resource zich bijvoorbeeld in WestUS2 bevindt, blijft al het verkeer in WestUS2.

Microsoft-verificatiebibliotheek

Als u daemon-apps ontwikkelt en geen beheerde identiteiten gebruikt, gebruikt u de Microsoft Authentication Library (MSAL) voor verificatie en autorisatie. MSAL vereenvoudigt het proces van het opgeven van clientreferenties. Uw toepassing hoeft bijvoorbeeld geen JSON-webtokenverklaringen te maken en te ondertekenen met referenties op basis van certificaten.

Zie het overzicht van de Microsoft Authentication Library (MSAL)

Microsoft.Identity.Web voor .NET-ontwikkelaars

Als u daemon-apps ontwikkelt op ASP.NET Core, gebruikt u de Microsoft.Identity.Web-bibliotheek om autorisatie te vereenvoudigen. Het bevat strategieën voor gedistribueerde tokencache voor gedistribueerde apps die in meerdere regio's worden uitgevoerd.

Meer informatie:

Tokens in cache opslaan en opslaan

Als u MSAL niet gebruikt voor verificatie en autorisatie, zijn er aanbevolen procedures voor het opslaan en opslaan van tokens in de cache. MSAL implementeert en volgt deze aanbevolen procedures.

Een toepassing verkrijgt tokens van een id-provider (IdP) om de toepassing te autoriseren om beveiligde API's aan te roepen. Wanneer uw app tokens ontvangt, bevat het antwoord met de tokens een expires\_in eigenschap waarmee de toepassing wordt aangegeven hoe lang het token in de cache moet worden opgeslagen en opnieuw moet worden gebruikt. Zorg ervoor dat toepassingen de eigenschap gebruiken om de expires\_in levensduur van tokens te bepalen. Controleer of de toepassing geen API-toegangstoken probeert te decoderen. Het gebruik van het token in de cache voorkomt onnodig verkeer tussen een app en een Microsoft Identity Platform. Gebruikers worden aangemeld bij uw toepassing voor de levensduur van het token.

HTTP 429- en 5xx-foutcodes

Gebruik de volgende secties voor meer informatie over HTTP 429- en 5xx-foutcodes

HTTP 429

Er zijn HTTP-fouten die van invloed zijn op tolerantie. Als uw toepassing een HTTP 429-foutcode ontvangt, te veel aanvragen, beperkt het Microsoft-identiteitsplatform uw aanvragen, waardoor uw app geen tokens ontvangt. Zorg ervoor dat uw apps geen token proberen te verkrijgen totdat het antwoordveld Opnieuw proberen is verlopen. De 429-fout geeft vaak aan dat de toepassing tokens niet correct in de cache opscachet en opnieuw gebruikt.

HTTP 5xx

Als een toepassing een HTTP 5x-foutcode ontvangt, mag de app geen lus voor snelle nieuwe pogingen invoeren. Zorg ervoor dat toepassingen wachten totdat het veld Opnieuw proberen is verlopen. Als het antwoord geen header Opnieuw proberen na geeft, gebruikt u een exponentieel uitstel bij de eerste nieuwe poging, ten minste 5 seconden na het antwoord.

Wanneer er een time-out optreedt voor een aanvraag, controleert u of toepassingen het niet onmiddellijk opnieuw proberen. Gebruik de eerder geciteerde exponentieel uitstel opnieuw.

Volgende stappen