Delen via

Tokens aanpassen

Als ontwikkelaar vraagt uw primaire interactie met Microsoft Entra ID een token aan om de gebruiker te identificeren. U vraagt ook een token aan om autorisatie op te halen voor het aanroepen van een web-API. Het web-API-token bepaalt wat die API kan doen wanneer een bepaalde aanvraag wordt uitgevoerd. In dit artikel krijgt u informatie over de informatie die u kunt ontvangen in tokens en hoe u tokens kunt aanpassen. Deze best practices voor Zero Trust-ontwikkelaars verbeteren de flexibiliteit en controle en verhogen de beveiliging van toepassingen met minimale bevoegdheden.

Uw redenen voor het aanpassen van uw toepassingstokens zijn afhankelijk van het proces dat u gebruikt om gedetailleerdere autorisatie in uw toepassingen en API's te stimuleren. U hebt bijvoorbeeld verschillende gebruikersrollen, toegangsniveaus en functionaliteiten in uw app die afhankelijk zijn van gegevens van tokens.

De Microsoft Graph API biedt een robuuste set mapgegevens en -gegevens in Microsoft 365. U kunt een fijnmazig en uitgebreid autorisatiesysteem ontwikkelen door voort te bouwen op de gegevens in Microsoft Graph. U kunt bijvoorbeeld toegang krijgen tot informatie van het groepslidmaatschap van de gebruiker, gedetailleerde profielgegevens, SharePoint en Outlook voor gebruik in uw autorisatiebeslissingen. U kunt autorisatiegegevens opnemen in het token van Microsoft Entra ID.

Autorisatie op toepassingsniveau

It-professionals kunnen autorisatie op app-niveau toevoegen zonder tokenaanpassing of codetoevoegingen.

IT-professionals kunnen voorkomen dat tokens worden uitgegeven aan elke app in de tenant met de vereiste vlag voor gebruikerstoewijzing . Deze aanpak zorgt ervoor dat alleen een set gebruikers zich kan aanmelden bij de toepassing. Zonder deze vlag hebben alle gebruikers in een tenant toegang tot de toepassing. Met deze vlag hebben alleen toegewezen gebruikers en groepen toegang tot de toepassing. Wanneer een toegewezen gebruiker toegang heeft tot de app, ontvangt de app een token. Als de gebruiker geen toewijzing heeft, ontvangt de app geen token. Vergeet niet om tokenaanvragen die geen tokens ontvangen, altijd correct te verwerken.

Aanpassingsmethoden voor tokens

Er zijn twee manieren om tokens aan te passen: optionele claims en toewijzing van claims.

Optionele claims

Optionele claims geven aan welke claims u wilt dat Microsoft Entra ID in tokens naar uw toepassing verzendt. U kunt optionele claims gebruiken voor het volgende:

  • Selecteer meer claims die u wilt opnemen in uw toepassingstokens.
  • Wijzig het gedrag van claims die het Microsoft Identity Platform retourneert in tokens.
  • Voeg aangepaste claims toe en krijg er toegang toe voor uw toepassing.

Optionele claims hangen af van het toepassingsregistratieobject met een gedefinieerd schema. Ze zijn van toepassing op de toepassing, ongeacht waar deze werd uitgevoerd. Wanneer u een multitenant-toepassing schrijft, werken optionele claims goed omdat deze consistent zijn voor elke tenant in Microsoft Entra-id. Een IP-adres is bijvoorbeeld niet tenantspecifiek, terwijl een toepassing een IP-adres heeft.

Gastgebruikers in een tenant kunnen zich standaard ook aanmelden bij uw app. Als u gastgebruikers wilt blokkeren, meldt u zich aan bij de optionele claim (acct). Als dit het is 1, heeft de gebruiker een gastclassificatie. Als u gasten wilt blokkeren, kunt u tokens blokkeren met acct==1.

Beleid voor claimtoewijzing

In Microsoft Entra ID vertegenwoordigen beleidsobjecten sets regels voor afzonderlijke toepassingen of op alle toepassingen in een organisatie. Een claims mapping policy wijzigt de claims die Microsoft Entra ID in tokens uitgeeft voor specifieke toepassingen.

U gebruikt claimtoewijzing voor tenantspecifieke informatie die geen schema heeft (bijvoorbeeld EmployeeID, DivisionName). Claimmapping is van toepassing op het service-principalniveau dat wordt beheerd door de tenantbeheerder. Claims-mapping komt overeen met de enterprise-applicatie of de service-principal voor die toepassing. Elke tenant kan zijn eigen claims-mapping hebben.

Wanneer u een Line-Of-Business-toepassing ontwikkelt, kijkt u specifiek naar wat uw tenant doet (welke specifieke claims uw tenant beschikbaar heeft die u in uw token kunt gebruiken). Als een organisatie bijvoorbeeld de eigenschap van de divisienaam van een gebruiker heeft (geen standaardveld in Microsoft Entra ID) in hun on-premises Active Directory, gebruikt u Microsoft Entra Connect om deze te synchroniseren met Microsoft Entra-id.

Als u deze informatie wilt bevatten, gebruikt u een van de standaardextensiekenmerken. Definieer uw token met een verdelingsnaamclaim die u kunt samenstellen vanuit de bijbehorende extensie (zelfs als dit niet van toepassing is op elke tenant). Een organisatie plaatst bijvoorbeeld de naam van de afdeling in het extensiekenmerk 13.

Met claimtoewijzing kunt u ervoor zorgen dat het werkt voor een andere huurder die de naam van de afdeling in kenmerk zeven plaatst.

Token aanpassing plannen

Welk token u aanpast, is afhankelijk van uw type toepassing: clienttoepassing of API. Er is geen verschil in wat u kunt doen om uw token aan te passen. Wat je in het token kunt plaatsen, is hetzelfde voor elk van deze tokens. Welk token u wilt aanpassen, is afhankelijk van het token dat uw app verbruikt.

Id-tokens aanpassen

Als u een clienttoepassing ontwikkelt, past u het id-token aan omdat dit het token is dat u aanvraagt om de gebruiker te identificeren. Een token behoort tot uw app wanneer de doelgroep (aud) in het token overeenkomt met de client-id van uw toepassing. Voor een clienttoepassing die API's aanroept, maar deze niet implementeert, moet u ervoor zorgen dat u alleen het id-token van uw app aanpast.

Met azure Portal en Microsoft Graph API kunt u ook het toegangstoken voor uw app aanpassen, maar deze aanpassingen hebben geen effect. U kunt een toegangstoken niet aanpassen voor een API die u niet bezit. Vergeet niet dat uw app niet mag proberen een toegangstoken te decoderen of te inspecteren dat uw client-app ontvangt als autorisatie voor het aanroepen van een API.

Toegangstokens aanpassen

Wanneer u een API ontwikkelt, past u het toegangstoken aan omdat uw API toegangstokens ontvangt als onderdeel van de aanroep van de client naar uw API.

Clienttoepassingen passen altijd het id-token aan dat ze ontvangen voor de identiteit van de gebruiker. API's passen de toegangstokens aan die de API ontvangt als onderdeel van de aanroep naar de API.

Groepen en app-rollen

Een van de meest voorkomende autorisatietechnieken is om toegang te baseren op het groepslidmaatschap van een gebruiker of toegewezen rollen. Als u groepsclaims en app-rollen in tokens configureert, ziet u hoe u uw apps configureert met app-roldefinities en beveiligingsgroepen toewijst aan app-rollen. Deze methoden helpen om de flexibiliteit en controle te verbeteren en tegelijkertijd de beveiliging van Zero Trust met minimale bevoegdheden te verhogen.

Volgende stappen 

  • Last updated on