Id-tokens zijn een type beveiligingstoken dat fungeert als bewijs van verificatie, waarbij wordt bevestigd dat een gebruiker is geverifieerd. Met informatie in id-tokens kan de client controleren of een gebruiker is wie hij of zij beweert te zijn, vergelijkbaar met naamtags tijdens een conferentie. De autorisatieserver geeft id-tokens uit die claims bevatten die informatie over de gebruiker bevatten. Ze kunnen naast of in plaats van een toegangstoken worden verzonden en zijn altijd JWT-indeling (JSON Web Token).
Id-tokens verschillen van toegangstokens, die fungeren als bewijs van autorisatie. Vertrouwelijke clients moeten id-tokens valideren. U moet geen id-token gebruiken om een API aan te roepen.
Toepassingen van derden zijn bedoeld om id-tokens te begrijpen. Id-tokens mogen niet worden gebruikt voor autorisatiedoeleinden. Toegangstokens worden gebruikt voor autorisatie. De claims die door id-tokens worden geleverd, kunnen worden gebruikt voor UX in uw toepassing, als sleutels in een database en toegang bieden tot de clienttoepassing. Zie de naslaginformatie over id-tokenclaims voor meer informatie over de claims die worden gebruikt in een id-token. Zie Beveiligde toepassingen en API's voor meer informatie over autorisatie op basis van claims door claims te valideren.
Tokenindelingen
Er zijn twee versies van id-tokens beschikbaar in het Microsoft Identity Platform: v1.0 en v2.0. Deze versies bepalen de claims die zich in het token bevinden. De v1.0- en v2.0-id-tokens hebben verschillen in de informatie die ze bevatten. De versie is gebaseerd op het eindpunt van waaruit het is aangevraagd. Nieuwe toepassingen moeten gebruikmaken van v2.0.
Standaard is een id-token één uur geldig. Na één uur moet de client een nieuw id-token verkrijgen.
U kunt de levensduur van een ID-token aanpassen om te bepalen hoe vaak de clienttoepassing de toepassingssessie verloopt en hoe vaak de gebruiker moet worden geverifieerd op de achtergrond of interactief. Lees configureerbare tokenlevensduur voor meer informatie.
Tokens valideren
Als u een id-token wilt valideren, kan uw client controleren of er met het token is geknoeid. Het kan ook de verlener valideren om ervoor te zorgen dat de juiste verlener het token heeft teruggestuurd. Omdat id-tokens altijd een JWT-token zijn, bestaan er veel bibliotheken om deze tokens te valideren. U moet een van deze bibliotheken gebruiken in plaats van dit zelf te doen. Alleen vertrouwelijke clients moeten id-tokens valideren. Zie Beveiligde toepassingen en API's voor meer informatie door claims te valideren.
Openbare toepassingen (code die volledig wordt uitgevoerd op een apparaat of netwerk dat u niet bepaalt, zoals de browser of het thuisnetwerk van een gebruiker), profiteert niet van het valideren van het id-token. In dit geval kan een kwaadwillende gebruiker de sleutels onderscheppen en bewerken die worden gebruikt voor validatie van het token.
De volgende JWT-claims moeten worden gevalideerd in het id-token na het valideren van de handtekening op het token. Uw tokenvalidatiebibliotheek kan ook de volgende claims valideren:
Tijdstempels: de iat, nbfen exp tijdstempels moeten allemaal vóór of na de huidige tijd vallen, indien van toepassing.
Doelgroep: de aud claim moet overeenkomen met de app-id voor uw toepassing.
Nonce: de nonce claim in de nettolading moet overeenkomen met de niet-ceparameter die tijdens de eerste aanvraag aan het /authorize eindpunt is doorgegeven.
Beschrijf de belangrijkste concepten achter Microsoft Entra geverifieerde ID. Krijg inzicht in gedecentraliseerde id's en hoe ze worden gebruikt om referenties uit te geven en te verifiëren.
Demonstreer de functies van Microsoft Entra ID om identiteitsoplossingen te moderniseren, hybride oplossingen te implementeren en identiteitsbeheer te implementeren.