Delen via

Tokens beheren voor Zero Trust

In zero Trust-toepassingsontwikkeling is het belangrijk om specifiek de intentie van uw toepassing en de bijbehorende resourcetoegangsvereisten te definiëren. Uw app moet alleen de toegang aanvragen die nodig is om naar behoren te functioneren. Dit artikel helpt u, als ontwikkelaar, bij het bouwen van beveiliging in uw toepassingen met id-tokens, toegangstokens en beveiligingstokens die uw app kan ontvangen van het Microsoft Identity Platform.

Zorg ervoor dat uw toepassing voldoet aan het Zero Trust-principe van minimale bevoegdheden en voorkomt gebruik op manieren die uw intentie in gevaar kunnen houden. Beperk gebruikerstoegang met Just-In-Time en Just-Enough-Access (JIT/JEA), op risico gebaseerd adaptief beleid en gegevensbeveiliging. Scheid de gevoelige en krachtige secties van uw app. Geef alleen geautoriseerde gebruikerstoegang tot deze gebieden op. Beperk gebruikers die uw toepassing en de mogelijkheden in uw app kunnen gebruiken.

Bouw minimale bevoegdheden in op de wijze waarop uw toepassing id-tokens beheert die worden ontvangen van het Microsoft Identity Platform. Met informatie in id-tokens kunt u controleren of een gebruiker is wie hij of zij beweert te zijn. De gebruiker of de organisatie kan verificatievoorwaarden opgeven, zoals MFA, beheerde apparaten en juiste locaties.

Maak het eenvoudig voor uw klanten om autorisaties voor uw app te beheren. Verminder de overhead voor het maken en configureren van gebruikers en handmatige processen. Met automatische inrichting van gebruikers kunnen IT-beheerders het maken, onderhouden en verwijderen van gebruikersidentiteiten automatiseren in doelidentiteitsarchieven. Uw klanten kunnen automatisering baseren op wijzigingen in gebruikers en groepen met app-inrichting of HR-gestuurde inrichting in Microsoft Entra-id.

Tokenclaims gebruiken in uw apps

Gebruik claims in id-tokens voor gebruikerservaring in uw toepassing als sleutels in een database. Geef toegang tot de clienttoepassing. Het id-token is de kernextensie die Door OpenID Connect (OIDC) wordt gemaakt voor OAuth 2.0. Uw app kan id-tokens naast of in plaats van toegangstokens ontvangen.

In het standaardpatroon voor autorisatie van beveiligingstokens kan de toepassing met een uitgegeven id-token informatie over de gebruiker ontvangen. Gebruik het id-token niet als autorisatieproces voor toegang tot resources. De autorisatieserver verstrekt id-tokens die claims bevatten met gebruikersgegevens die het volgende bevatten.

  • De audience (aud) claim is de client-id van uw app. Accepteer alleen tokens voor uw API-client-id.
  • De tid claim is de ID van de tenant die het token heeft uitgegeven. De oid claim is een onveranderbare waarde die de gebruiker uniek identificeert. Gebruik de unieke combinatie van de tid en oid claims als een sleutel wanneer u gegevens aan de gebruiker wilt koppelen. Gebruik deze claimwaarden om uw gegevens weer te verbinden met de gebruikers-id in Microsoft Entra-id.
  • De sub claim is een onveranderbare waarde die de gebruiker uniek identificeert. De onderwerpclaim is ook uniek voor uw toepassing. Als u de sub claim gebruikt om gegevens te koppelen aan de gebruiker, is het onmogelijk om van uw gegevens te gaan en deze te verbinden met een gebruiker in Microsoft Entra ID.

Uw apps kunnen het openid bereik gebruiken om een id-token aan te vragen bij het Microsoft Identity Platform. De OIDC-standaard bepaalt het openid bereik, samen met de indeling en inhoud van het id-token. OIDC specificeert deze bereiken:

  • Gebruik het openid bereik om de gebruiker aan te melden en een sub claim toe te voegen aan het id-token. Deze scopes bieden een gebruikers-ID die uniek is voor de app en de gebruiker en roepen het UserInfo-eindpunt aan.
  • Met email het bereik wordt een email claim met het e-mailadres van de gebruiker toegevoegd aan het id-token.
  • Het profile bereik voegt claims toe met basisprofielkenmerken van de gebruiker (naam, gebruikersnaam) aan het id-token.
  • Met offline_access het bereik kan de app toegang krijgen tot gebruikersgegevens, zelfs wanneer de gebruiker niet aanwezig is.

De Microsoft Authentication Library (MSAL) voegt altijd de openid, e-mail en profile scopes toe aan elke tokenaanvraag. Hierdoor retourneert MSAL altijd een id-token en een toegangstoken voor elke aanroep naar AcquireTokenSilent of AcquireTokenInteractive. MSAL vraagt altijd het offline_access bereik aan. Het Microsoft Identity Platform retourneert offline_access altijd een bereik, zelfs wanneer de aanvragende app het offline_access bereik niet opgeeft.

Microsoft gebruikt de OAuth2-standaard om toegangstokens te verlenen. De OAuth2-standaard geeft aan dat u een token ontvangt, maar er wordt geen tokenindeling opgegeven of wat er in het token moet staan. Wanneer uw toepassing toegang nodig heeft tot een resource die door Microsoft Entra ID wordt beveiligd, moet deze een bereik gebruiken dat door de resource is gedefinieerd.

Microsoft Graph definieert bijvoorbeeld het User.Read bereik waarmee de toepassing toegang verleent tot het volledige gebruikersprofiel van de huidige gebruiker en de naam van de tenant. Microsoft Graph definieert machtigingen voor het volledige scala aan functionaliteit dat beschikbaar is in die API.

Na autorisatie retourneert het Microsoft Identity Platform een toegangstoken naar uw toepassing. Wanneer u de resource aanroept, biedt uw app dit token als onderdeel van de autorisatieheader van de HTTP-aanvraag aan de API.

Levensduur van tokens beheren

Toepassingen kunnen een sessie voor een gebruiker maken nadat de verificatie is voltooid met Microsoft Entra-id. Gebruikerssessiebeheer bepaalt hoe vaak een gebruiker herhaalverificatie nodig heeft. Zijn rol bij het houden van een expliciet geverifieerde gebruiker voor de app met de juiste bevoegdheid en voor de juiste hoeveelheid tijd is van cruciaal belang. De levensduur van de sessie moet zijn gebaseerd op de exp claim in het id-token. De exp claim is het tijdstip waarop het id-token verloopt en de tijd waarna u het token niet meer kunt gebruiken om de gebruiker te verifiëren.

Respecteer altijd de levensduur van het token zoals opgegeven in het tokenantwoord voor toegangstokens of de exp claim in het id-token. Voorwaarden die de levensduur van tokens bepalen, kunnen aanmeldingsfrequentie voor een onderneming omvatten. Uw toepassing kan de levensduur van het token niet configureren. U kunt geen tokenlevensduur aanvragen.

In het algemeen moet u ervoor zorgen dat tokens geldig en niet verlopen zijn. De doelgroepclaim (aud) moet overeenkomen met uw client-id. Zorg ervoor dat het token afkomstig is van een vertrouwde verlener. Als u een API met meerdere tenants hebt, kunt u ervoor kiezen om te filteren, zodat alleen specifieke tenants uw API kunnen aanroepen. Zorg ervoor dat u de levensduur van het token afdwingt. Controleer de claims nbf (niet vóór) en exp (verlooptijd) om te verzekeren dat de huidige tijd binnen de waarden van deze claims valt.

Richt u niet op uitzonderlijk lange of korte sessies. Laat de toegestane id-tokenlevensduur deze beslissing stimuleren. Als u de sessies van uw app actief houdt buiten tokenvaliditeit, worden de regels, beleidsregels en zorgen geschonden die een IT-beheerder ertoe hebben aangezet om een geldigheidsduur van een token in te stellen om onbevoegde toegang te voorkomen. Korte sessies verlagen de kwaliteit van de gebruikerservaring en verhogen niet noodzakelijkerwijs het beveiligingsniveau. Populaire frameworks zoals ASP.NET stellen u in staat om time-outs voor sessies en cookies in te stellen op basis van de Microsoft Entra ID-tokenverlooptijd. Volg de verlooptijd van het token van de id-provider om ervoor te zorgen dat de sessies van uw gebruiker nooit langer zijn dan het beleid dat de id-provider bepaalt.

Tokens cachen en vernieuwen

Vergeet niet om tokens op de juiste manier te cachen. MSAL slaat tokens automatisch in de cache op, maar de tokens hebben levensduur. Gebruik tokens gedurende de volledige levensduur en sla ze op de juiste manier in de cache op. Wanneer u herhaaldelijk om hetzelfde token vraagt, leidt throtteling ertoe dat uw toepassing minder responsief wordt. Als uw app misbruikt van de tokenuitgifte, wordt de tijd om nieuwe tokens uit te geven aan uw app langer.

MSAL-bibliotheken beheren de details van het OAuth2-protocol, inclusief de mechanismen voor het vernieuwen van tokens. Als u MSAL niet gebruikt, moet u ervoor zorgen dat uw bibliotheek van keuze effectief gebruik maakt van vernieuwingstokens.

Wanneer uw client een toegangstoken verkrijgt voor toegang tot een beveiligde resource, ontvangt deze een vernieuwingstoken. Gebruik het vernieuwingstoken om nieuwe toegangs-/vernieuwingstokenparen te verkrijgen nadat het huidige toegangstoken is verlopen. Gebruik vernieuwingstokens om extra toegangstokens voor andere bronnen te verkrijgen. Vernieuwingstokens zijn gebonden aan een combinatie van gebruiker en client (niet aan een resource of tenant). U kunt een vernieuwingstoken gebruiken om toegangstokens te verkrijgen voor elke combinatie van resource en tenant waar uw app machtigingen heeft.

Tokenfouten en bugs beheren

Uw toepassing mag nooit proberen de inhoud van een toegangstoken te valideren, decoderen, inspecteren, interpreteren of onderzoeken. Deze bewerkingen zijn strikt de verantwoordelijkheid van de resource-API. Als uw app de inhoud van een toegangstoken probeert te onderzoeken, is het zeer waarschijnlijk dat uw toepassing wordt onderbreekt wanneer het Microsoft Identity Platform versleutelde tokens uitgeeft.

Zelden mislukt een aanroep om een token op te halen vanwege problemen zoals netwerk-, infrastructuur- of verificatieservicefouten of storingen. Verhoog de tolerantie van verificatie in uw toepassing als er een tokenovernamefout optreedt door de volgende aanbevolen procedures te volgen:

  • Lokale cache en beveiligde tokens met versleuteling.
  • Geef geen beveiligingsartefacten door, zoals tokens op niet-beveiligde kanalen.
  • Begrijp en onderneem actie op uitzonderingen en servicereacties van de identiteitsaanbieder.

Ontwikkelaars hebben vaak vragen over het zoeken in tokens om problemen op te sporen, zoals het ontvangen van een 401-fout bij het aanroepen van de resource. Naarmate meer versleutelde tokens voorkomen dat u in een toegangstoken kijkt, moet u alternatieven vinden voor het zoeken in toegangstokens. Voor foutopsporing biedt het tokenantwoord dat het toegangstoken bevat de informatie die u nodig hebt.

Controleer in uw code op foutklassen in plaats van afzonderlijke foutgevallen. U kunt bijvoorbeeld gebruikersinteractie afhandelen die vereist is in plaats van afzonderlijke fouten wanneer het systeem geen machtiging verleent. Omdat u deze afzonderlijke gevallen misschien mist, is het beter om te controleren op een classificatie zoals gebruikersinteractie in plaats van afzonderlijke foutcodes in te gaan.

Mogelijk moet u terugvallen op AcquireTokenInteractive en claim-uitdagingen bieden die de AcquireTokenSilent-aanroep vereist. Dit zorgt voor effectief beheer van de interactieve aanvraag.

Volgende stappen 

  • Last updated on