Översikt över token och anspråk
En centraliserad identitetsprovider är särskilt användbar för appar som har globala användare som inte nödvändigtvis loggar in från företagets nätverk. Microsofts identitetsplattform autentiserar användare och tillhandahåller säkerhetstoken, till exempel åtkomsttoken, uppdateringstoken och ID-token. Med säkerhetstoken kan ett klientprogram komma åt skyddade resurser på en resursserver.
- Åtkomsttoken – en åtkomsttoken är en säkerhetstoken som utfärdats av en auktoriseringsserver som en del av ett OAuth 2.0-flöde. Den innehåller information om användaren och den resurs som token är avsedd för. Informationen kan användas för att komma åt webb-API:er och andra skyddade resurser. Resurser validerar åtkomsttoken för att bevilja åtkomst till ett klientprogram. Mer information finns i Åtkomsttoken i Microsofts identitetsplattform.
- Uppdateringstoken – Eftersom åtkomsttoken bara är giltiga under en kort tidsperiod utfärdar auktoriseringsservrar ibland en uppdateringstoken samtidigt som åtkomsttoken utfärdas. Klientprogrammet kan sedan byta ut den här uppdateringstoken mot en ny åtkomsttoken vid behov. Mer information finns i Uppdatera token i Microsofts identitetsplattform.
- ID-token – ID-token skickas till klientprogrammet som en del av ett OpenID Connect-flöde. De kan skickas tillsammans med eller i stället för en åtkomsttoken. ID-token används av klienten för att autentisera användaren. Mer information om hur Microsofts identitetsplattform problem-ID-token finns i ID-token i Microsofts identitetsplattform.
Många företagsprogram använder SAML för att autentisera användare. Information om SAML-försäkran finns i REFERENS för SAML-token.
Verifiera token
Det är upp till programmet som token genererades för, webbappen som loggade in på användaren eller webb-API:et som anropas för att verifiera token. Auktoriseringsservern signerar token med en privat nyckel. Auktoriseringsservern publicerar motsvarande offentliga nyckel. För att verifiera en token verifierar appen signaturen med hjälp av den offentliga auktoriseringsserverns offentliga nyckel för att verifiera att signaturen skapades med hjälp av den privata nyckeln. Mer information finns i artikeln Säkra program och API:er genom att verifiera anspråk .
Vi rekommenderar att du använder microsofts autentiseringsbibliotek (MSAL) som stöds när det är möjligt. Detta implementerar förvärv, uppdatering och validering av token åt dig. Den implementerar också standardkompatibel identifiering av klientinställningar och nycklar med hjälp av klientorganisationens välkända openID-identifieringsdokument. MSAL stöder många olika programarkitekturer och plattformar, inklusive .NET, JavaScript, Java, Python, Android och iOS.
Token är endast giltiga under en begränsad tid, så auktoriseringsservern tillhandahåller ofta ett par token. En åtkomsttoken tillhandahålls som kommer åt programmet eller den skyddade resursen. En uppdateringstoken tillhandahålls, som används för att uppdatera åtkomsttoken när åtkomsttoken är nära att upphöra att gälla.
Åtkomsttoken skickas till ett webb-API som ägartoken i Authorization rubriken. En app kan tillhandahålla en uppdateringstoken till auktoriseringsservern. Om användarens åtkomst till appen inte har återkallats får den en ny åtkomsttoken och en ny uppdateringstoken. När auktoriseringsservern tar emot uppdateringstoken utfärdar den endast en annan åtkomsttoken om användaren fortfarande har behörighet.
JSON-webbtoken och anspråk
Microsofts identitetsplattform implementerar säkerhetstoken som JSON-webbtoken (JWT) som innehåller anspråk. Eftersom JWT:er används som säkerhetstoken kallas den här typen av autentisering ibland för JWT-autentisering.
Ett anspråk ger försäkran om en entitet, till exempel ett klientprogram eller resursägare, till en annan entitet, till exempel en resursserver. Ett anspråk kan också kallas ett JWT-anspråk eller ett JSON-webbtokenanspråk.
Anspråk är namn- eller värdepar som förmedlar fakta om tokenämnet. Ett anspråk kan till exempel innehålla fakta om säkerhetsobjektet som auktoriseringsservern autentiserade. Anspråken som finns i en specifik token beror på många saker, till exempel typen av token, vilken typ av autentiseringsuppgifter som används för att autentisera ämnet och programkonfigurationen.
Program kan använda anspråk för följande olika uppgifter:
- Validera token
- Identifiera tokenämnets klientorganisation
- Visa användarinformation
- Fastställa subjektets auktorisering
Ett anspråk består av nyckel/värde-par som tillhandahåller följande typer av information:
- Säkerhetstokenserver som genererade token
- Datum då token genererades
- Ämne (som användaren, men inte daemoner)
- Målgrupp, som är den app som token genererades för
- App (klienten) som bad om token
Tokenslutpunkter och utfärdare
Microsoft Entra-ID stöder två klientkonfigurationer: En personalkonfiguration som är avsedd för intern användning och hanterar anställda och företagsgäster samt en kundkonfiguration som är optimerad för att isolera konsumenter och partners i en begränsad extern katalog. Den underliggande identitetstjänsten är identisk för båda klientkonfigurationerna, men inloggningsdomänerna och tokenutfärdarutfärdarna för externa klienter skiljer sig åt. På så sätt kan program hålla arbetsstyrkan och externa ID-arbetsflöden åtskilda om det behövs.
Microsoft Entra-personalklientorganisationer autentiserar på login.microsoftonline.com med token som utfärdats av sts.windows.net. Klienttoken för personal är vanligtvis utbytbara mellan klientorganisationer och program för flera klientorganisationer så länge underliggande förtroenderelationer tillåter den här samverkan. Externa Microsoft Entra-klientorganisationer använder klientslutpunkter i formuläret {tenantname}.ciamlogin.com. Program som är registrerade i externa klienter måste vara medvetna om den här separationen för att kunna ta emot och verifiera token korrekt.
Varje Microsoft Entra-klientorganisation publicerar välkända metadata som är kompatibla med standarder. Det här dokumentet innehåller information om utfärdarnamnet, autentiserings- och auktoriseringsslutpunkterna, omfång och anspråk som stöds. För externa klienter är dokumentet offentligt tillgängligt på: https://{tenantname}.ciamlogin.com/{tenantid}/v2.0/.well-known/openid-configuration. Den här slutpunkten returnerar ett utfärdarvärde https://{tenantid}.ciamlogin.com/{tenantid}/v2.0.
Auktoriseringsflöden och autentiseringskoder
Beroende på hur klienten skapas kan den använda ett eller flera av de autentiseringsflöden som stöds av Microsofts identitetsplattform. De flöden som stöds kan skapa olika token och auktoriseringskoder och kräva olika token för att få dem att fungera. Följande tabell innehåller en översikt.
| Flow | Kräver | ID-token | Åtkomsttoken | Uppdateringstoken | Auktoriseringskod |
|---|---|---|---|---|---|
| Auktoriseringskodflöde | x | x | x | x | |
| Implicit flöde | x | x | |||
| Hybrid-OIDC-flöde | x | x | |||
| Inlösen av uppdateringstoken | Uppdateringstoken | x | x | x | |
| On-Behalf-Of-flöde | Åtkomsttoken | x | x | x | |
| Klientautentiseringsuppgifter | x (endast app) |
Se även
Nästa steg
- Mer information om de grundläggande begreppen autentisering och auktorisering finns i Autentisering kontra auktorisering.