Beveiligingstokens

  • Artikel
  • 4 minuten om te lezen

Een gecentraliseerde id-provider is met name handig voor apps die gebruikers over de hele wereld hebben die zich niet noodzakelijkerwijs aanmelden vanuit het bedrijfsnetwerk. De Microsoft identity platform verifieert gebruikers en biedt beveiligingstokens, zoals toegangstokens, vernieuwingstokens en id-tokens. Met beveiligingstokens kan een clienttoepassing toegang krijgen tot beveiligde resources op een resourceserver.

Toegangstoken: een toegangstoken is een beveiligingstoken dat is uitgegeven door een autorisatieserver als onderdeel van een OAuth 2.0-stroom . Het bevat informatie over de gebruiker en de resource waarvoor het token is bedoeld. De informatie kan worden gebruikt voor toegang tot web-API's en andere beveiligde resources. Toegangstokens worden gevalideerd door resources om toegang te verlenen tot een client-app. Zie Toegangstokens voor meer informatie over hoe de Microsoft identity platform toegangstokens problemen ondervindt.

Vernieuwingstoken: Omdat toegangstokens slechts een korte periode geldig zijn, geven autorisatieservers soms een vernieuwingstoken uit op hetzelfde moment dat het toegangstoken wordt uitgegeven. De clienttoepassing kan dit vernieuwingstoken vervolgens uitwisselen voor een nieuw toegangstoken wanneer dat nodig is. Zie Tokens vernieuwen voor meer informatie over hoe de Microsoft identity platform vernieuwingstokens gebruikt om machtigingen in te trekken.

Id-token: id-tokens worden als onderdeel van een OpenID-Verbinding maken-stroom naar de clienttoepassing verzonden. Ze kunnen naast of in plaats van een toegangstoken worden verzonden. Id-tokens worden door de client gebruikt om de gebruiker te verifiëren. Zie ID-tokens voor meer informatie over hoe de Microsoft identity platform id-tokens problemen ondervindt.

Notitie

In dit artikel worden beveiligingstokens besproken die worden gebruikt door de protocollen OAuth2 en OpenID Verbinding maken. Veel bedrijfstoepassingen gebruiken SAML om gebruikers te verifiëren. Zie Azure Active Directory naslaginformatie over SAML-token voor informatie over SAML-asserties.

Beveiligingstokens valideren

Het is aan de app waarvoor het token is gegenereerd, de web-app die is aangemeld bij de gebruiker of de web-API die wordt aangeroepen om het token te valideren. Het token wordt ondertekend door de autorisatieserver met een persoonlijke sleutel. De autorisatieserver publiceert de bijbehorende openbare sleutel. Als u een token wilt valideren, verifieert de app de handtekening met behulp van de openbare sleutel van de autorisatieserver om te controleren of de handtekening is gemaakt met behulp van de persoonlijke sleutel.

Tokens zijn slechts gedurende een beperkte tijd geldig. Meestal biedt de autorisatieserver een paar tokens, zoals:

  • Een toegangstoken dat toegang heeft tot de toepassing of beveiligde resource.
  • Een vernieuwingstoken dat wordt gebruikt om het toegangstoken te vernieuwen wanneer het toegangstoken bijna verloopt.

Toegangstokens worden doorgegeven aan een web-API als bearer-token in de Authorization header. Een app kan een vernieuwingstoken opgeven voor de autorisatieserver. Als de gebruikerstoegang tot de app niet is ingetrokken, krijgt deze een nieuw toegangstoken en een nieuw vernieuwingstoken. Dit is hoe het scenario van iemand die de onderneming verlaat, wordt afgehandeld. Wanneer de autorisatieserver het vernieuwingstoken ontvangt, geeft deze geen ander geldig toegangstoken uit als de gebruiker niet meer gemachtigd is.

JSON-webtokens en -claims

De Microsoft identity platform implementeert beveiligingstokens als JSON-webtokens (JWT's) die claims bevatten. Aangezien JWT's worden gebruikt als beveiligingstokens, wordt deze vorm van verificatie ook wel JWT-verificatie genoemd.

Een claim biedt asserties over één entiteit, zoals een clienttoepassing of resource-eigenaar, aan een andere entiteit, zoals een resourceserver. Een claim kan ook een JWT-claim of een JSON-webtokenclaim worden genoemd.

Claims zijn naam- of waardeparen die feiten over het tokenonderwerp doorsturen. Een claim kan bijvoorbeeld feiten bevatten over de beveiligingsprincipaal die is geverifieerd door de autorisatieserver. De claims die aanwezig zijn in een specifiek token, zijn afhankelijk van veel dingen, zoals het type token, het type referentie dat wordt gebruikt om het onderwerp te verifiëren en de toepassingsconfiguratie.

Toepassingen kunnen claims gebruiken voor verschillende taken, zoals:

  • Valideer het token.
  • Identificeer de tenant van het tokenonderwerp.
  • Gebruikersgegevens weergeven.
  • Bepaal de autorisatie van het onderwerp.

Een claim bestaat uit sleutel-waardeparen die informatie bieden, zoals:

  • Beveiligingstokenserver die het token heeft gegenereerd.
  • Datum waarop het token is gegenereerd.
  • Onderwerp (zoals de gebruiker, met uitzondering van daemons).
  • Doelgroep, de app waarvoor het token is gegenereerd.
  • App (de client) die om het token heeft gevraagd. In het geval van web-apps is deze app mogelijk hetzelfde als de doelgroep.

Zie Toegangstokens en id-tokens voor meer informatie over hoe de Microsoft identity platform tokens en claimgegevens implementeert.

Hoe elke stroom tokens en codes verzendt

Afhankelijk van hoe uw client is gebouwd, kan deze een (of meerdere) van de verificatiestromen gebruiken die worden ondersteund door de Microsoft identity platform. Deze stromen kunnen verschillende tokens (ID-tokens, vernieuwingstokens, toegangstokens) en autorisatiecodes produceren. Ze vereisen verschillende tokens om ze te laten werken. Deze tabel bevat een overzicht.

Stroom Vereist Id-token Toegangstoken Token vernieuwen Autorisatiecode
Autorisatiecodestroom x x x x
Impliciete stroom x x
Hybride OIDC-stroom x x
Inwisseling van token vernieuwen Token vernieuwen x x x
Namens-stroom Toegangstoken x x x
Clientreferenties x (alleen app)

Tokens die via de impliciete modus worden uitgegeven, hebben een lengtebeperking omdat ze via de URL worden doorgestuurd naar de browser, waar response_mode of queryfragment. Sommige browsers hebben een limiet voor de grootte van de URL die in de browserbalk kan worden geplaatst en mislukken wanneer deze te lang is. Als gevolg hiervan hebben groups deze tokens geen of wids claims.

Volgende stappen

Zie de volgende artikelen voor meer informatie over verificatie en autorisatie in de Microsoft identity platform: