Overzicht van tokens en claims
Een gecentraliseerde id-provider is vooral handig voor apps die wereldwijd gebruikers hebben die zich niet noodzakelijkerwijs aanmelden vanuit het bedrijfsnetwerk. Het 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. Resources valideren toegangstokens om toegang te verlenen tot een clienttoepassing. Zie Toegangstokens in het Microsoft Identity Platform voor meer informatie.
- 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 in het Microsoft Identity Platform voor meer informatie.
- Id-token : id-tokens worden als onderdeel van een OpenID Connect-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 in het Microsoft-identiteitsplatform voor meer informatie over hoe id-tokens worden opgegeven in het Microsoft Identity Platform.
Veel bedrijfstoepassingen gebruiken SAML om gebruikers te verifiëren. Zie de naslaginformatie over SAML-token voor informatie over SAML-asserties.
Tokens valideren
Het is aan de toepassing waarvoor het token is gegenereerd, de web-app die zich heeft aangemeld bij de gebruiker of de web-API die wordt aangeroepen om het token te valideren. De autorisatieserver ondertekent het token met een persoonlijke sleutel. De autorisatieserver publiceert de bijbehorende openbare sleutel. Om een token te 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. Raadpleeg het artikel Beveiligde toepassingen en API's voor meer informatie door het artikel claims te valideren.
U wordt aangeraden waar mogelijk de ondersteunde Microsoft Authentication Libraries (MSAL) te gebruiken. Hiermee wordt het verkrijgen, vernieuwen en valideren van tokens voor u geïmplementeerd. Het implementeert ook detectie van tenantinstellingen en -sleutels die compatibel zijn met standaarden met behulp van het OpenID-detectiedocument van de tenant. MSAL ondersteunt veel verschillende toepassingsarchitecturen en -platforms, waaronder .NET, JavaScript, Java, Python, Android en iOS.
Tokens zijn slechts gedurende een beperkte tijd geldig, dus de autorisatieserver biedt vaak een paar tokens. Er wordt een toegangstoken geleverd, dat toegang heeft tot de toepassing of beveiligde resource. Er wordt een vernieuwingstoken opgegeven, 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, ontvangt deze een nieuw toegangstoken en een nieuw vernieuwingstoken. Wanneer de autorisatieserver het vernieuwingstoken ontvangt, geeft deze alleen een ander toegangstoken uit als de gebruiker nog steeds is geautoriseerd.
JSON-webtokens en -claims
Het Microsoft Identity Platform implementeert beveiligingstokens als JSON-webtokens (JWT's) die claims bevatten. Omdat 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 worden aangeduid als een JWT-claim of een JSON-webtokenclaim.
Claims zijn naam- of waardeparen die feiten over het tokenonderwerp doorgeven. Een claim kan bijvoorbeeld feiten bevatten over de beveiligingsprincipaal die door de autorisatieserver is geverifieerd. 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 de volgende verschillende taken:
- Het token valideren
- De tenant van het tokenonderwerp identificeren
- Gebruikersgegevens weergeven
- De autorisatie van het onderwerp bepalen
Een claim bestaat uit sleutel-waardeparen die de volgende typen informatie bieden:
- Beveiligingstokenserver die het token heeft gegenereerd
- Datum waarop het token is gegenereerd
- Onderwerp (zoals de gebruiker, maar geen daemons)
- Doelgroep, de app waarvoor het token is gegenereerd
- App (de client) die om het token heeft gevraagd
Tokeneindpunten en verleners
Microsoft Entra ID ondersteunt twee tenantconfiguraties: een personeelsconfiguratie die is bedoeld voor intern gebruik en beheert werknemers en zakelijke gasten, en een klantconfiguratie die is geoptimaliseerd voor het isoleren van consumenten en partners in een beperkte externe adreslijst. Hoewel de onderliggende identiteitsservice identiek is voor zowel tenantconfiguraties, zijn de aanmeldingsdomeinen en de verlenende instantie voor externe tenants anders. Hierdoor kunnen toepassingen werknemers en werkstromen voor externe id's gescheiden houden, indien nodig.
Microsoft Entra workforce-tenants verifiëren zich bij login.microsoftonline.com met tokens die zijn uitgegeven door sts.windows.net. Tenanttokens voor werknemers zijn over het algemeen uitwisselbaar tussen tenants en toepassingen met meerdere tenants, zolang onderliggende vertrouwensrelaties deze interoperabiliteit toestaan. Externe Microsoft Entra-tenants maken gebruik van tenant-eindpunten van het formulier {tenantname}.ciamlogin.com. Toepassingen die zijn geregistreerd bij externe tenants moeten op de hoogte zijn van deze scheiding om tokens correct te ontvangen en te valideren.
Elke Microsoft Entra-tenant publiceert een bekende metagegevens die compatibel zijn met standaarden. Dit document bevat informatie over de naam van de uitgever, de verificatie- en autorisatie-eindpunten, ondersteunde bereiken en claims. Voor externe tenants is het document openbaar beschikbaar op: https://{tenantname}.ciamlogin.com/{tenantid}/v2.0/.well-known/openid-configuration. Dit eindpunt retourneert een verlenerwaarde https://{tenantid}.ciamlogin.com/{tenantid}/v2.0.
Autorisatiestromen en verificatiecodes
Afhankelijk van hoe uw client is gebouwd, kan deze een of meer van de verificatiestromen gebruiken die worden ondersteund door het Microsoft Identity Platform. De ondersteunde stromen kunnen verschillende tokens en autorisatiecodes produceren en vereisen verschillende tokens om ze te laten werken. De volgende tabel bevat een overzicht.
| Stroom | Vereist | Id-token | Toegangstoken | Token vernieuwen | Autorisatiecode |
|---|---|---|---|---|---|
| Stroom voor autorisatiecode | 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) |
Zie ook
Volgende stappen
- Zie Verificatie versus autorisatie voor meer informatie over de basisconcepten van verificatie en autorisatie.