Share via

Tokens beheren voor Zero Trust

  • Artikel

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 en geef alleen geautoriseerde gebruikerstoegang tot deze gebieden. 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 het leveren van een MFA, het gebruik van een beheerd apparaat en de juiste locatie.

Maak het eenvoudig voor uw klanten om autorisaties voor uw app te beheren. Verminder de overhead van de gebruikersinrichting en de noodzaak van 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 UX in uw toepassing, als sleutels in een database en geef toegang tot de clienttoepassing. Het id-token is de kernextensie die door OpenID Verbinding maken (OIDC) wordt gebruikt 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 doelgroep (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. U kunt deze claimwaarden gebruiken 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 bereiken bieden een gebruikers-id die uniek is voor de app en de gebruiker en die het eindpunt UserInfo aanroept.
  • 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 bereiken 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 opnieuw verificatie 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 moeten 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 nbf claims (niet vóór) en de exp (verlooptijd) om ervoor te zorgen dat de huidige tijd binnen de waarden van deze twee 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 verminderen de gebruikerservaring en verhogen niet noodzakelijkerwijs het beveiligingspostuur. Populaire frameworks zoals ASP.NET u toestaan om sessie- en cookietime-outs in te stellen van de verlooptijd van het id-token van Microsoft Entra ID. Door de verlooptijd van het token van de id-provider te volgen, zorgt u ervoor dat de sessies van uw gebruiker nooit langer zijn dan het beleid dat de id-provider dicteert.

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. Als u herhaaldelijk om hetzelfde token vraagt, zorgt beperking ervoor dat uw toepassing minder responsief wordt. Als uw app misbruik maakt van de tokenuitgifte, wordt de tijd die nodig is voor het uitgeven van nieuwe tokens 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 resources te verkrijgen. Vernieuwingstokens zijn gebonden aan een combinatie van gebruikers en clients (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 fouten 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 kan een aanroep om een token op te halen mislukken 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.
  • Informatie over uitzonderingen en servicereacties van de id-provider.

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 AcquireTokenInteractive op claims die nodig zijn voor de AcquireTokenSilent aanroep. Dit zorgt voor effectief beheer van de interactieve aanvraag.

Volgende stappen