De tolerantie van verificatie en autorisatie vergroten in clienttoepassingen die u ontwikkelt

Leer hoe u tolerantie bouwt in clienttoepassingen die gebruikmaken van het Microsoft Identity Platform en Microsoft Entra ID om gebruikers aan te melden en acties uit te voeren namens die gebruikers.

MSAL (Microsoft Authentication Library ) gebruiken

De Microsoft Authentication Library (MSAL) maakt deel uit van het Microsoft Identity Platform. MSAL verkrijgt, beheert, caches en vernieuwt tokens; het maakt gebruik van aanbevolen procedures voor tolerantie. MSAL helpt ontwikkelaars bij het maken van veilige oplossingen.

Meer informatie:

• Overzicht van de Microsoft Authentication Library
• Wat is het Microsoft Identity Platform?
• Documentatie voor Microsoft Identity Platform

MSAL slaat tokens in de cache op en maakt gebruik van een patroon voor het ophalen van tokens op de achtergrond. MSAL serialiseert de tokencache op besturingssystemen die systeemeigen beveiligde opslag bieden, zoals Universeel Windows-platform (UWP), iOS en Android. Pas het serialisatiegedrag aan wanneer u het volgende gebruikt:

• Microsoft.Identity.Web
• MSAL.NET
• MSAL voor Java
• MSAL voor Python

Meer informatie:

• Serialisatie van tokencache

• Serialisatie van tokencache in MSAL.NET

• Serialisatie van aangepaste tokencache in MSAL voor Java

• Serialisatie van aangepaste tokencache in MSAL voor Python.

  

Wanneer u MSAL gebruikt, wordt het opslaan van tokens in cache, vernieuwen en op de achtergrond ophalen ondersteund. Gebruik eenvoudige patronen om de tokens voor verificatie te verkrijgen. Er is ondersteuning voor veel talen. Zoek codevoorbeelden op, codevoorbeelden van Het Microsoft Identity Platform.

C#

try
{
    result = await app.AcquireTokenSilent(scopes, account).ExecuteAsync();
}
catch(MsalUiRequiredException ex)
{
    result = await app.AcquireToken(scopes).WithClaims(ex.Claims).ExecuteAsync()
}

JavaScript

return myMSALObj.acquireTokenSilent(request).catch(error => {
    console.warn("silent token acquisition fails. acquiring token using redirect");
    if (error instanceof msal.InteractionRequiredAuthError) {
        // fallback to interaction when silent call fails
        return myMSALObj.acquireTokenPopup(request).then(tokenResponse => {
            console.log(tokenResponse);

            return tokenResponse;
        }).catch(error => {
            console.error(error);
        });
    } else {
        console.warn(error);
    }
});

MSAL kan tokens vernieuwen. Wanneer het Microsoft Identity Platform een langlevend token uitgeeft, kan het informatie naar de client verzenden om het token (refresh_in) te vernieuwen. De app wordt uitgevoerd terwijl het oude token geldig is, maar het duurt langer voordat een ander token wordt opgehaald.

MSAL-releases

Ontwikkelaars wordt aangeraden een proces te bouwen voor het gebruik van de nieuwste MSAL-release, omdat verificatie deel uitmaakt van app-beveiliging. Gebruik deze procedure voor bibliotheken die in ontwikkeling zijn en app-tolerantie verbeteren.

Zoek de nieuwste versie en releaseopmerkingen:

• microsoft-authentication-library-for-js
• microsoft-authentication-library-for-dotnet
• microsoft-authentication-library-for-python
• microsoft-authentication-library-for-java
• microsoft-authentication-library-for-objc
• microsoft-authentication-library-for-android
• microsoft-authentication-library-for-js
• microsoft-identity-web

Tolerante patronen voor tokenafhandeling

Als u MSAL niet gebruikt, gebruikt u tolerante patronen voor het verwerken van tokens. De MSAL-bibliotheek implementeert best practices.

Over het algemeen roepen toepassingen die moderne verificatie gebruiken een eindpunt aan om tokens op te halen die de gebruiker verifiëren, of autoriseren de toepassing om beveiligde API's aan te roepen. MSAL verwerkt verificatie en implementeert patronen om de tolerantie te verbeteren. Als u MSAL niet gebruikt, gebruikt u de richtlijnen in deze sectie voor aanbevolen procedures. Anders implementeert MSAL automatisch aanbevolen procedures.

Tokens in cache plaatsen

Zorg ervoor dat tokens in de cache van apps nauwkeurig worden opgeslagen vanuit het Microsoft Identity Platform. Nadat uw app tokens heeft ontvangen, heeft het HTTP-antwoord met tokens een expires_in eigenschap die de duur aangeeft van de cache en wanneer deze opnieuw moet worden gebruikt. Controleer of de toepassing geen API-toegangstoken probeert te decoderen.

Tokens in cache voorkomen onnodig verkeer tussen een app en het Microsoft Identity Platform. Dit scenario maakt de app minder gevoelig voor tokenovernamefouten door het verminderen van tokenaanroepen. Tokens in de cache verbeteren de prestaties van toepassingen, omdat de app het verkrijgen van tokens minder vaak blokkeert. Gebruikers blijven aangemeld bij uw toepassing voor de levensduur van het token.

Tokens serialiseren en behouden

Zorg ervoor dat apps hun tokencache veilig serialiseren om de tokens tussen app-exemplaren te behouden. Tokens opnieuw gebruiken tijdens hun levensduur. Vernieuwingstokens en toegangstokens worden vele uren uitgegeven. Gedurende deze periode kunnen gebruikers uw toepassing meerdere keren starten. Wanneer een app wordt gestart, controleert u of er naar geldige toegang of een vernieuwingstoken wordt gezocht. Dit verhoogt de tolerantie en prestaties van apps.

Meer informatie:

• De toegangstokens vernieuwen

• Toegangstokens voor Microsoft Identity Platform

  

Zorg ervoor dat permanente tokenopslag toegangsbeheer en versleuteling heeft ten opzichte van de gebruiker-eigenaar of procesidentiteit. Op verschillende besturingssystemen zijn er functies voor referentieopslag.

Tokens op de achtergrond verkrijgen

Het verifiëren van een gebruiker of het ophalen van autorisatie voor het aanroepen van een API omvat meerdere stappen in het Microsoft Identity Platform. Gebruikers die zich bijvoorbeeld voor het eerst aanmelden, voeren referenties in en voeren meervoudige verificatie uit. Elke stap is van invloed op de resource die de service levert. De beste gebruikerservaring met de minste afhankelijkheden is het verkrijgen van tokens op de achtergrond.

Het ophalen van tokens op de achtergrond begint met een geldig token uit de cache van het app-token. Als er geen geldig token is, probeert de app een token te verkrijgen met behulp van een beschikbaar vernieuwingstoken en het tokeneindpunt. Als geen van beide opties beschikbaar is, verkrijgt de app een token met behulp van de prompt=none parameter. Deze actie maakt gebruik van het autorisatie-eindpunt, maar er wordt geen gebruikersinterface weergegeven voor de gebruiker. Indien mogelijk biedt het Microsoft Identity Platform een token aan de app zonder tussenkomst van de gebruiker. Als er geen methode resulteert in een token, voert de gebruiker handmatig opnieuw verificatie uit.

Notitie

In het algemeen moet u ervoor zorgen dat apps geen prompts gebruiken, zoals 'aanmelden' en 'toestemming'. Met deze prompts wordt gebruikersinteractie afgedwongen wanneer er geen interactie is vereist.

Verwerking van antwoordcode

Gebruik de volgende secties voor meer informatie over antwoordcodes.

HTTP 429-antwoordcode

Er zijn foutreacties die van invloed zijn op tolerantie. Als uw toepassing een HTTP 429-antwoordcode ontvangt, worden uw aanvragen beperkt door het Microsoft Identity Platform. Als een app te veel aanvragen doet, wordt deze beperkt om te voorkomen dat de app tokens ontvangt. Sta niet toe dat een app het verkrijgen van tokens probeert te proberen, voordat de reactieveldtijd is voltooid. Vaak geeft een 429-antwoord aan dat de toepassing geen tokens in de cache op de juiste manier in de cache opsneert en opnieuw gebruikt. Controleer of tokens in de cache worden opgeslagen en opnieuw worden gebruikt in de toepassing.

HTTP 5x-antwoordcode

Als een toepassing een HTTP 5x-antwoordcode ontvangt, mag de app geen snelle lus voor opnieuw proberen invoeren. Gebruik dezelfde verwerking voor een 429-antwoord. Als er geen header Opnieuw proberen na verschijnt, implementeert u een exponentieel uitstel met de eerste nieuwe poging, ten minste 5 seconden na het antwoord.

Wanneer er een time-out optreedt voor een aanvraag, worden onmiddellijke nieuwe pogingen afgeraden. Implementeer een exponentiële uitstelbewerking, met de eerste nieuwe poging, ten minste 5 seconden na het antwoord.

Autorisatiegerelateerde informatie ophalen

Veel toepassingen en API's hebben gebruikersgegevens nodig om toestemming te geven. Beschikbare methoden hebben voor- en nadelen.

Tokens

Identiteitstokens en toegangstokens hebben standaardclaims die informatie bieden. Indien nodig bevindt zich informatie in het token, is de meest efficiënte techniek tokenclaims, omdat dat een andere netwerkaanroep voorkomt. Minder netwerkaanroepen zijn gelijk aan betere tolerantie.

Meer informatie:

• Id-tokens voor Microsoft-identiteitsplatform
• Toegangstokens voor Microsoft Identity Platform

Notitie

Sommige toepassingen roepen het UserInfo-eindpunt aan om claims over de geverifieerde gebruiker op te halen. De informatie in het id-token is een superset met gegevens van het eindpunt UserInfo. Schakel apps in om het id-token te gebruiken in plaats van het UserInfo-eindpunt aan te roepen.

Standaardtokenclaims uitbreiden met optionele claims, zoals groepen. De optie Toepassingsgroep bevat groepen die zijn toegewezen aan de toepassing. De opties voor alle of beveiligingsgroepen omvatten groepen uit apps in dezelfde tenant, waarmee groepen aan het token kunnen worden toegevoegd. Evalueer het effect, omdat de efficiëntie van het aanvragen van groepen in het token kan worden ontkend door token-bloat te veroorzaken en meer aanroepen te vereisen om de groepen op te halen.

Meer informatie:

• Geef optionele claims op voor uw app
• Optionele groepenclaims configureren

U wordt aangeraden app-rollen te gebruiken en op te nemen, die klanten beheren met behulp van de portal of API's. Rollen toewijzen aan gebruikers en groepen om de toegang te beheren. Wanneer een token wordt uitgegeven, bevinden de toegewezen rollen zich in de tokenrollenclaim. Informatie die is afgeleid van een token voorkomt meer API-aanroepen.

Bekijk, voeg app-rollen toe aan uw toepassing en ontvang deze in het token

Voeg claims toe op basis van tenantgegevens. Een extensie heeft bijvoorbeeld een ondernemingsspecifieke gebruikers-id.

Het toevoegen van informatie uit de map aan een token is efficiënt en verhoogt de tolerantie door afhankelijkheden te verminderen. Er worden geen tolerantieproblemen opgelost vanwege een onvermogen om een token te verkrijgen. Voeg optionele claims toe voor de primaire scenario's van de toepassing. Als voor de app informatie is vereist voor de beheerfunctionaliteit, kan de toepassing deze informatie indien nodig verkrijgen.

Microsoft Graph

Microsoft Graph heeft een geïntegreerd API-eindpunt voor toegang tot Microsoft 365-gegevens over productiviteitspatronen, identiteit en beveiliging. Toepassingen die Microsoft Graph gebruiken, kunnen Microsoft 365-gegevens gebruiken voor autorisatie.

Voor apps is één token vereist voor toegang tot Microsoft 365, wat toleranter is dan eerdere API's voor Microsoft 365-onderdelen, zoals Microsoft Exchange of Microsoft SharePoint, waarvoor meerdere tokens zijn vereist.

Wanneer u Microsoft Graph API's gebruikt, gebruikt u een Microsoft Graph SDK die het bouwen van tolerante toepassingen vereenvoudigt die toegang hebben tot Microsoft Graph.

Zie het overzicht van Microsoft Graph SDK

Voor autorisatie kunt u tokenclaims gebruiken in plaats van een aantal Microsoft Graph-aanroepen. Groepen, app-rollen en optionele claims in tokens aanvragen. Microsoft Graph voor autorisatie vereist meer netwerkoproepen die afhankelijk zijn van het Microsoft Identity Platform en Microsoft Graph. Als uw toepassing echter afhankelijk is van Microsoft Graph als gegevenslaag, is Microsoft Graph voor autorisatie geen risico meer.

Brokerverificatie gebruiken op mobiele apparaten

Op mobiele apparaten verbetert een verificatiebroker zoals Microsoft Authenticator de tolerantie. De verificatiebroker gebruikt een primair vernieuwingstoken (PRT) met claims over de gebruiker en het apparaat. Gebruik PRT voor verificatietokens voor toegang tot andere toepassingen vanaf het apparaat. Wanneer een PRT toegang tot toepassingen aanvraagt, vertrouwt Microsoft Entra ID zijn apparaat en MFA-claims. Dit verhoogt de tolerantie door de stappen voor het verifiëren van het apparaat te verminderen. Gebruikers worden niet gevraagd om meerdere MFA-prompts op hetzelfde apparaat.

Wat is een primair vernieuwingstoken?

MSAL ondersteunt brokerverificatie. Meer informatie:

• Eenmalige aanmelding via verificatiebroker in iOS
• Eenmalige aanmelding voor meerdere apps inschakelen op Android met MSAL

Continue toegangsevaluatie

Continue toegangsevaluatie (CAE) verhoogt de beveiliging en tolerantie van toepassingen met langlopende tokens. Met CAE wordt een toegangstoken ingetrokken op basis van kritieke gebeurtenissen en beleidsevaluatie, in plaats van korte levensduur van tokens. Voor sommige resource-API's, omdat risico's en beleid in realtime worden geëvalueerd, verhoogt CAE de levensduur van tokens tot 28 uur. MSAL vernieuwt tokens met een lange levensduur.

Meer informatie:

• Continue toegangsevaluatie
• Toepassingen beveiligen met continue toegangsevaluatie
• Evaluatie van kritieke gebeurtenissen
• Evaluatie van beleid voor voorwaardelijke toegang
• CAE-API's gebruiken in uw toepassingen

Als u resource-API's ontwikkelt, gaat u naar openid.net gedeelde signalen: een beveiligd webhooksframework.

Volgende stappen

• CAE-API's gebruiken in uw toepassingen
• De tolerantie van verificatie en autorisatie vergroten in daemon-toepassingen die u ontwikkelt
• Tolerantie bouwen in uw infrastructuur voor identiteits- en toegangsbeheer
• Tolerantie bouwen in uw klantidentiteit en toegangsbeheer met Azure AD B2C