Toepassingen en API's beveiligen door claims te valideren

  • Artikel

Interactie met tokens is een kernonderdeel van het bouwen van toepassingen om gebruikers te autoriseren. In overeenstemming met het Zero Trust-principe voor toegang met minimale bevoegdheden is het essentieel dat toepassingen de waarden van bepaalde claims valideren die aanwezig zijn in het toegangstoken bij het uitvoeren van autorisatie.

Met autorisatie op basis van claims kunnen toepassingen ervoor zorgen dat het token de juiste waarden bevat voor zaken zoals de tenant, het onderwerp en de actor die aanwezig zijn in het token. Dat gezegd hebbende, kan autorisatie op basis van claims complex lijken, gezien de verschillende methoden om te gebruiken en scenario's om bij te houden. In dit artikel wordt het autorisatieproces op basis van claims vereenvoudigd, zodat u ervoor kunt zorgen dat uw toepassingen voldoen aan de veiligste procedures.

Om ervoor te zorgen dat uw autorisatielogica veilig is, moet u de volgende informatie in claims valideren:

  • De juiste doelgroep wordt opgegeven voor het token.
  • De tenant-id van het token komt overeen met de id van de tenant waarin gegevens worden opgeslagen.
  • Het onderwerp van het token is geschikt.
  • De actor (client-app) is geautoriseerd.

Notitie

Toegangstokens worden alleen gevalideerd in de web-API's waarvoor ze zijn verkregen door een client. De client mag geen toegangstokens valideren.

Zie Toegangstokens voor Microsoft Identity Platform voor meer informatie over de claims die in dit artikel worden genoemd.

De doelgroep valideren

De aud claim identificeert de beoogde doelgroep van het token. Voordat u claims valideert, moet u altijd controleren of de waarde van de aud claim in het toegangstoken overeenkomt met de web-API. De waarde kan afhankelijk zijn van de wijze waarop de client het token heeft aangevraagd. De doelgroep in het toegangstoken is afhankelijk van het eindpunt:

  • Voor v2.0-tokens is de doelgroep de client-id van de web-API. Het is een GUID.
  • Voor v1.0-tokens is de doelgroep een van de appID-URI's die zijn gedeclareerd in de web-API waarmee het token wordt gevalideerd. Bijvoorbeeld, api://{ApplicationID}of een unieke naam die begint met een domeinnaam (als de domeinnaam is gekoppeld aan een tenant).

Zie de URI van de toepassings-id voor meer informatie over de appID-URI van een toepassing.

De tenant valideren

Controleer altijd of het tid in een token overeenkomt met de tenant-id die wordt gebruikt voor het opslaan van gegevens met de toepassing. Wanneer informatie wordt opgeslagen voor een toepassing in de context van een tenant, mag deze alleen later in dezelfde tenant worden geopend. Sta nooit toe dat gegevens in de ene tenant toegankelijk zijn vanuit een andere tenant.

Validatie van de tenant is alleen de eerste stap en de controles op onderwerp en actor die in dit artikel worden beschreven, zijn nog steeds vereist. Als u alle gebruikers in een tenant wilt autoriseren, is het raadzaam deze gebruikers expliciet toe te voegen aan een groep en deze te autoriseren op basis van de groep. Door bijvoorbeeld alleen de tenant-id en de aanwezigheid van een oid claim te controleren, kan uw API per ongeluk alle service-principals in die tenant autoriseren naast gebruikers.

Het onderwerp valideren

Bepaal of het tokenonderwerp, zoals de gebruiker (of de toepassing zelf voor een token dat alleen voor een app geldt), is geautoriseerd.

U kunt controleren op specifieke claims of oid op specifieke sub claims.

Of

U kunt controleren of het onderwerp deel uitmaakt van een geschikte rol of groep met de roles, groups, wids claims. Gebruik bijvoorbeeld de onveranderbare claimwaarden tid en oid als een gecombineerde sleutel voor toepassingsgegevens en bepaal of een gebruiker toegang moet krijgen.

De rolesof groupswids claims kunnen ook worden gebruikt om te bepalen of het onderwerp autorisatie heeft om een bewerking uit te voeren. Een beheerder kan bijvoorbeeld gemachtigd zijn om naar een API te schrijven, maar niet een normale gebruiker, of de gebruiker kan een bepaalde actie uitvoeren in een groep. De wid claim vertegenwoordigt de tenantbrede rollen die aan de gebruiker zijn toegewezen vanuit de rollen die aanwezig zijn in de ingebouwde Microsoft Entra-rollen. Zie Ingebouwde rollen in Microsoft Entra voor meer informatie.

Waarschuwing

Gebruik nooit claims zoals email, preferred_username of unique_name om op te slaan of te bepalen of de gebruiker in een toegangstoken toegang moet hebben tot gegevens. Deze claims zijn niet uniek en kunnen worden beheerd door tenantbeheerders of soms door gebruikers, waardoor ze ongeschikt zijn voor autorisatiebeslissingen. Ze zijn alleen bruikbaar voor weergavedoeleinden. Gebruik de upn claim ook niet voor autorisatie. Hoewel de UPN uniek is, verandert deze vaak gedurende de levensduur van een gebruikersprincipaal, waardoor deze onbetrouwbaar is voor autorisatie.

De actor valideren

Een clienttoepassing die namens een gebruiker (ook wel de actor genoemd) handelt, moet ook worden geautoriseerd. Gebruik de scp claim (bereik) om te controleren of de toepassing gemachtigd is om een bewerking uit te voeren. De machtigingen in scp moeten worden beperkt tot wat de gebruiker daadwerkelijk nodig heeft en volgt de principes van minimale bevoegdheden.

Er zijn echter exemplaren waar scp het token niet aanwezig is. Controleer op de afwezigheid van de scp claim voor de volgende scenario's:

  • Alleen daemon-apps/app-machtigingen
  • Id-tokens

Zie Bereiken en machtigingen in het Microsoft Identity Platform voor meer informatie over bereiken en machtigingen.

Notitie

Een toepassing kan alleen-app-tokens verwerken (aanvragen van toepassingen zonder gebruikers, zoals daemon-apps) en een specifieke toepassing in meerdere tenants autoriseren in plaats van afzonderlijke service-principal-id's. In dat geval kan de appid claim (voor v1.0-tokens) of de azp claim (voor v2.0-tokens) worden gebruikt voor onderwerpautorisatie. Wanneer u deze claims gebruikt, moet de toepassing er echter voor zorgen dat het token rechtstreeks voor de toepassing is uitgegeven door de idtyp optionele claim te valideren. Alleen tokens van het type app kunnen op deze manier worden geautoriseerd, omdat gedelegeerde gebruikerstokens mogelijk kunnen worden verkregen door andere entiteiten dan de toepassing.

Volgende stappen