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 terwijl de beveiliging van toepassingen met minimale bevoegdheden wordt verhoogd.

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 ook autorisatiegegevens opnemen in het token van Microsoft Entra ID.

Autorisatie op toepassingsniveau

It-professionals kunnen autorisatie op app-niveau toevoegen zonder het token aan te passen en de ontwikkelaar geen code toe te voegen.

IT-professionals kunnen voorkomen dat tokens worden uitgegeven aan elke app in de tenant met behulp van de vereiste vlag voor gebruikerstoewijzing om ervoor te zorgen dat alleen een set gebruikers zich bij de toepassing kan aanmelden. 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 claimtoewijzing.

Optionele claims

Optionele claims geven aan welke claims u wilt dat Microsoft Entra ID naar uw toepassing in tokens wordt verzonden. 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.
• Aangepaste claims voor uw toepassing toevoegen en openen.

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 toepassing met meerdere tenants 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 1 is, heeft de gebruiker een gastclassificatie. Als u gasten wilt blokkeren, blokkeert u tokens met acct==1.

Claimtoewijzing

In Microsoft Entra ID vertegenwoordigen beleidsobjecten sets regels voor afzonderlijke toepassingen of op alle toepassingen in een organisatie. Met een claimtoewijzingsbeleid worden de claims gewijzigd die door Microsoft Entra ID in tokens worden opgegeven voor specifieke toepassingen.

U gebruikt claimtoewijzing voor tenantspecifieke informatie die geen schema heeft (bijvoorbeeld EmployeeID, DivisionName). Claimtoewijzing is van toepassing op service-principalniveau dat door de tenantbeheerder wordt beheerd. Claimtoewijzing komt overeen met de bedrijfs-app of de service-principal voor die toepassing. Elke tenant kan een eigen claimtoewijzing hebben.

Als u een Line-Of-Business-toepassing ontwikkelt, kunt u specifiek bekijken 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 afdelingsnaam van een gebruiker (geen standaardveld in Microsoft Entra ID) in hun on-premises Active Directory heeft, kunt u Microsoft Entra Verbinding maken gebruiken om deze te synchroniseren met Microsoft Entra-id.

U kunt een van de standaardextensiekenmerken gebruiken om die informatie te bevatten. U kunt uw token definiëren met een claim voor een afdelingsnaam die u kunt opstellen 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 tenant die de naam van de afdeling in kenmerk zeven plaatst.

Aanpassing van token 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 u in het token kunt plaatsen, is hetzelfde voor elk van deze token. Welk token u wilt aanpassen, is afhankelijk van het token dat uw app gaat gebruiken.

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 probeert een toegangstoken te decoderen of te inspecteren dat uw client-app ontvangt als autorisatie om een API aan te roepen.

Toegangstokens aanpassen

Als 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 om de flexibiliteit en controle te verbeteren en tegelijkertijd de beveiliging van nul vertrouwensrelaties met minimale bevoegdheden te vergroten.

Volgende stappen

• Toewijzing van B2B-samenwerkingsclaims beschrijft ondersteuning voor Microsoft Entra ID voor het aanpassen van de claims die worden uitgegeven in het SAML-token voor B2B-samenwerkingsgebruikers.
• Pas app SAML-tokenclaims aan wanneer een gebruiker zich verifieert bij een toepassing via het Microsoft Identity Platform met behulp van het SAML 2.0-protocol.
• API Protection beschrijft aanbevolen procedures voor het beveiligen van uw API via registratie, het definiëren van machtigingen en toestemming en het afdwingen van toegang om uw Zero Trust-doelstellingen te bereiken.
• Met best practices voor autorisatie kunt u de beste autorisatie-, machtigings- en toestemmingsmodellen voor uw toepassingen implementeren.
• Gebruik best practices voor identiteits- en toegangsbeheer van Zero Trust in de ontwikkelingslevenscyclus van uw toepassing om veilige toepassingen te maken.