Översikt över token i Azure Active Directory B2C

Artikel
04/24/2023

Azure Active Directory B2C (Azure AD B2C) genererar olika typer av säkerhetstoken när varje autentiseringsflöde bearbetas. I den här artikeln beskrivs format, säkerhetsegenskaper och innehåll för varje typ av token.

Tokentyper

Azure AD B2C stöder protokollen OAuth 2.0 och OpenID Connect, som använder token för autentisering och säker åtkomst till resurser. Alla token som används i Azure AD B2C är JSON-webbtoken (JWT) som innehåller intyg om information om ägarnamnet och ämnet för token.

Följande token används vid kommunikation med Azure AD B2C:

ID-token – en JWT som innehåller anspråk som du kan använda för att identifiera användare i ditt program. Denna token skickas säkert i HTTP-begäranden för kommunikation mellan två komponenter i samma program eller tjänst. Du kan använda anspråken i en ID-token som du tycker passar. De används ofta för att visa kontoinformation eller för att fatta beslut om åtkomstkontroll i ett program. ID-token som utfärdats av Azure AD B2C är signerade, men de är inte krypterade. När ditt program eller API tar emot en ID-token måste den verifiera signaturen för att bevisa att token är autentiserad. Ditt program eller API måste också verifiera några anspråk i token för att bevisa att den är giltig. Beroende på scenariokraven kan de anspråk som verifieras av ett program variera, men programmet måste utföra några vanliga anspråksvalideringar i varje scenario.
Åtkomsttoken – en JWT som innehåller anspråk som du kan använda för att identifiera de beviljade behörigheterna för dina API:er. Åtkomsttoken signeras, men de krypteras inte. Åtkomsttoken används för att ge åtkomst till API:er och resursservrar. När ditt API tar emot en åtkomsttoken måste den verifiera signaturen för att bevisa att token är autentiserad. Ditt API måste också verifiera några anspråk i token för att bevisa att den är giltig. Beroende på scenariokraven kan de anspråk som verifieras av ett program variera, men programmet måste utföra några vanliga anspråksvalideringar i varje scenario.
Uppdateringstoken – Uppdateringstoken används för att hämta nya ID-token och åtkomsttoken i ett OAuth 2.0-flöde. De ger ditt program långsiktig åtkomst till resurser för användarnas räkning utan att kräva interaktion med dessa användare. Uppdateringstoken är täckande för ditt program. De utfärdas av Azure AD B2C och kan endast inspekteras och tolkas av Azure AD B2C. De är långlivade, men ditt program bör inte skrivas med förväntningen att en uppdateringstoken kommer att pågå under en viss tidsperiod. Uppdateringstoken kan när som helst ogiltigförklaras av olika orsaker. Det enda sättet för ditt program att veta om en uppdateringstoken är giltig är att försöka lösa in den genom att göra en tokenbegäran till Azure AD B2C. När du löser in en uppdateringstoken för en ny token får du en ny uppdateringstoken i tokensvaret. Spara den nya uppdateringstoken. Den ersätter den uppdateringstoken som du tidigare använde i begäran. Den här åtgärden garanterar att dina uppdateringstoken förblir giltiga så länge som möjligt. Ensidesprogram som använder auktoriseringskodflödet med PKCE har alltid en livslängd för uppdateringstoken på 24 timmar. Läs mer om säkerhetskonsekvenserna av uppdateringstoken i webbläsaren.

Slutpunkter

Ett registrerat program tar emot token och kommunicerar med Azure AD B2C genom att skicka begäranden till dessa slutpunkter:

https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/authorize
https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/token

Säkerhetstoken som ditt program tar emot från Azure AD B2C kan komma från slutpunkterna /authorize eller /token . När ID-token hämtas från:

/authorize slutpunkt görs det med hjälp av det implicita flödet, som ofta används för användare som loggar in på JavaScript-baserade webbprogram. Men om din app använder MSAL.js 2.0 eller senare ska du inte aktivera implicit flödesbidrag i appregistreringen eftersom MSAL.js 2.0+ stöder auktoriseringskodflödet med PKCE.
/token slutpunkten görs det med hjälp av auktoriseringskodflödet, som håller token dold från webbläsaren.

Anspråk

När du använder Azure AD B2C har du detaljerad kontroll över innehållet i dina token. Du kan konfigurera användarflöden och anpassade principer för att skicka vissa uppsättningar användardata i anspråk som krävs för ditt program. Dessa anspråk kan innehålla standardegenskaper som displayName och emailAddress. Dina program kan använda dessa anspråk för att autentisera användare och begäranden på ett säkert sätt.

Anspråken i ID-token returneras inte i någon viss ordning. Nya anspråk kan när som helst introduceras i ID-token. Ditt program bör inte gå sönder när nya anspråk introduceras. Du kan också inkludera anpassade användarattribut i dina anspråk.

I följande tabell visas de anspråk som du kan förvänta dig i ID-token och åtkomsttoken som utfärdats av Azure AD B2C.

Name	Begär	Exempelvärde	Description
Målgrupp	`aud`	`90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6`	Identifierar den avsedda mottagaren av token. För Azure AD B2C är målgruppen program-ID:t. Programmet bör verifiera det här värdet och avvisa token om den inte matchar. Målgrupp är synonymt med resurs.
Utfärdare	`iss`	`https://<tenant-name>.b2clogin.com/775527ff-9a37-4307-8b3d-cc311f58d925/v2.0/`	Identifierar säkerhetstokentjänsten (STS) som konstruerar och returnerar token. Den identifierar också katalogen där användaren autentiserades. Ditt program bör verifiera utfärdarens anspråk för att se till att token kommer från lämplig slutpunkt.
Utfärdat på	`iat`	`1438535543`	Den tid då token utfärdades, representerad i epoktid.
Förfallotid	`exp`	`1438539443`	Tiden då token blir ogiltig, representerad i epoktid. Ditt program bör använda det här anspråket för att verifiera giltigheten för tokenlivslängden.
Inte före	`nbf`	`1438535543`	Den tid då token blir giltig, representerad i epoktid. Den här gången är vanligtvis samma tid som token utfärdades. Ditt program bör använda det här anspråket för att verifiera giltigheten för tokenlivslängden.
Version	`ver`	`1.0`	Den version av ID-token som definieras av Azure AD B2C.
Kodhash	`c_hash`	`SGCPtt01wxwfgnYZy2VJtQ`	En kodhash som ingår i en ID-token endast när token utfärdas tillsammans med en OAuth 2.0-auktoriseringskod. En kodhash kan användas för att verifiera auktoriseringskodens äkthet. Mer information om hur du utför den här verifieringen finns i OpenID Connect-specifikationen.
Hash för åtkomsttoken	`at_hash`	`SGCPtt01wxwfgnYZy2VJtQ`	En åtkomsttoken-hash som ingår i en ID-token endast när token utfärdas tillsammans med en OAuth 2.0-åtkomsttoken. En åtkomsttoken-hash kan användas för att verifiera äktheten för en åtkomsttoken. Mer information om hur du utför den här verifieringen finns i OpenID Connect-specifikationen
Nonce	`nonce`	`12345`	En nonce är en strategi som används för att minimera tokenreprisattacker. Ditt program kan ange en nonce i en auktoriseringsbegäran med hjälp av frågeparametern `nonce` . Värdet som du anger i begäran genereras oförändrad i anspråket `nonce` för en ID-token. Med det här anspråket kan ditt program verifiera värdet mot det värde som anges i begäran. Programmet bör utföra den här verifieringen under valideringsprocessen för ID-token.
Ämne	`sub`	`884408e1-2918-4cz0-b12d-3aa027d7563b`	Huvudkontot som token anger information om, till exempel användaren av ett program. Det här värdet är oföränderligt och kan inte tilldelas om eller återanvändas. Den kan användas för att utföra auktoriseringskontroller på ett säkert sätt, till exempel när token används för att komma åt en resurs. Som standard fylls ämnesanspråket med objekt-ID:t för användaren i katalogen.
Referens för autentiseringskontextklass	`acr`	Inte tillämpligt	Används endast med äldre principer.
Princip för förtroenderamverk	`tfp`	`b2c_1_signupsignin1`	Namnet på principen som användes för att hämta ID-token.
Autentiseringstid	`auth_time`	`1438535543`	Den tid då en användare senast angav autentiseringsuppgifter, representerad i epoktid. Det finns ingen diskriminering mellan att autentiseringen är en ny inloggning, en session med enkel inloggning (SSO) eller en annan inloggningstyp. `auth_time` är den senaste gången programmet (eller användaren) initierade ett autentiseringsförsök mot Azure AD B2C. Metoden som används för att autentisera är inte differentierad.
Omfång	`scp`	`Read`	De behörigheter som beviljats till resursen för en åtkomsttoken. Flera beviljade behörigheter avgränsas med ett blanksteg.
Auktoriserad part	`azp`	`975251ed-e4f5-4efd-abcb-5f1a8f566ab7`	Program-ID för klientprogrammet som initierade begäran.

Konfiguration

Följande egenskaper används för att hantera livslängden för säkerhetstoken som genereras av Azure AD B2C:

Tillgång & ID-tokenlivslängd (minuter) – Livslängden för den OAuth 2.0-ägartoken som används för att få åtkomst till en skyddad resurs. Standardvärdet är 60 minuter. Det minsta (inklusive) är 5 minuter. Maxgränsen (inklusive) är 1 440 minuter.
Livslängd för uppdateringstoken (dagar) – Den maximala tidsperiod som en uppdateringstoken kan användas för att hämta en ny åtkomst- eller ID-token. Tidsperioden omfattar även att hämta en ny uppdateringstoken om programmet har beviljats omfånget offline_access . Standardvärdet är 14 dagar. Minimivärdet (inklusivt) är en dag. Maximalt (inklusivt) är 90 dagar.
Livslängd för skjutfönster för uppdateringstoken (dagar) – Efter den här tidsperioden tvingas användaren att autentisera på nytt, oavsett giltighetsperioden för den senaste uppdateringstoken som hämtats av programmet. Den kan bara anges om växeln är inställd på Begränsad. Den måste vara större än eller lika med värdet För uppdateringstokens livslängd (dagar). Om växeln är inställd på Ingen förfallodatum kan du inte ange ett specifikt värde. Standardvärdet är 90 dagar. Minimivärdet (inklusivt) är en dag. Det maximala antalet (inklusive) är 365 dagar.

Följande användningsfall är aktiverade med hjälp av följande egenskaper:

Tillåt att en användare förblir inloggad i ett mobilprogram på obestämd tid, så länge användaren kontinuerligt är aktiv i programmet. Du kan ställa in Livslängd för skjutfönster för uppdateringstoken (dagar) till Ingen förfallotid i användarflödet för inloggning.
Uppfylla branschens säkerhet och efterlevnadskrav genom att ange lämplig livslängd för åtkomsttoken.

De här inställningarna är inte tillgängliga för användarflöden för lösenordsåterställning.

Kompatibilitet

Följande egenskaper används för att hantera tokenkompatibilitet:

Utfärdaranspråk (iss) – Den här egenskapen identifierar den Azure AD B2C-klient som utfärdade token. Standardvärdet är https://<domain>/{B2C tenant GUID}/v2.0/. Värdet https://<domain>/tfp/{B2C tenant GUID}/{Policy ID}/v2.0/ för innehåller ID:n för både Azure AD B2C-klientorganisationen och användarflödet som användes i tokenbegäran. Om ditt program eller bibliotek behöver Azure AD B2C för att vara kompatibelt med OpenID Connect Discovery 1.0-specifikationen använder du det här värdet.
Ämnesanspråk (under) – Den här egenskapen identifierar den entitet som token hävdar information för. Standardvärdet är ObjectID, som fyller i anspråket sub i token med användarens objekt-ID. Värdet stöds inte endast för bakåtkompatibilitet. Vi rekommenderar att du växlar till ObjectID så snart du kan.
Anspråk som representerar princip-ID – Den här egenskapen identifierar anspråkstypen som principnamnet som används i tokenbegäran fylls i i. Standardvärdet är tfp. Värdet acr för anges endast för bakåtkompatibilitet.

Direkt

När en användarresa startar tar Azure AD B2C emot en åtkomsttoken från en identitetsprovider. Azure AD B2C använder denna token för att hämta information om användaren. Du aktiverar ett anspråk i ditt användarflöde för att skicka token till de program som du registrerar i Azure AD B2C. Ditt program måste använda ett rekommenderat användarflöde för att kunna skicka token som ett anspråk.

Azure AD B2C stöder för närvarande endast överföring av åtkomsttoken för OAuth 2.0-identitetsprovidrar, inklusive Facebook och Google. För alla andra identitetsprovidrar returneras anspråket tomt.

Validering

För att verifiera en token bör ditt program kontrollera både tokens signatur och anspråk. Många bibliotek med öppen källkod är tillgängliga för validering av JWT beroende på önskat språk. Vi rekommenderar att du utforskar dessa alternativ i stället för att implementera din egen valideringslogik.

Verifiera signatur

En JWT innehåller tre segment, en rubrik, en brödtext och en signatur. Signatursegmentet kan användas för att verifiera tokens äkthet så att den kan vara betrodd av ditt program. Azure AD B2C-token signeras med hjälp av asymmetriska krypteringsalgoritmer av branschstandard, till exempel RSA 256.

Tokenhuvudet innehåller information om nyckeln och krypteringsmetoden som används för att signera token:

{
        "typ": "JWT",
        "alg": "RS256",
        "kid": "GvnPApfWMdLRi8PDmisFn7bprKg"
}

Värdet för anspråket alg är algoritmen som användes för att signera token. Värdet för barnanspråket är den offentliga nyckeln som användes för att signera token. Vid en viss tidpunkt kan Azure AD B2C signera en token med någon av en uppsättning offentliga-privata nyckelpar. Azure AD B2C roterar den möjliga uppsättningen nycklar med jämna mellanrum. Ditt program bör skrivas för att hantera dessa nyckeländringar automatiskt. En rimlig frekvens för att söka efter uppdateringar av de offentliga nycklar som används av Azure AD B2C är var 24:e timme. Om du vill hantera oväntade nyckeländringar bör ditt program skrivas för att hämta de offentliga nycklarna igen om det får ett oväntat barnvärde .

Azure AD B2C har en OpenID Connect-metadataslutpunkt. Med den här slutpunkten kan program begära information om Azure AD B2C vid körning. Den här informationen omfattar slutpunkter, tokeninnehåll och tokensigneringsnycklar. Din Azure AD B2C-klientorganisation innehåller ett JSON-metadatadokument för varje princip. Metadatadokumentet är ett JSON-objekt som innehåller flera användbara informationsdelar. Metadata innehåller jwks_uri, vilket ger platsen för den uppsättning offentliga nycklar som används för att signera token. Den platsen tillhandahålls här, men det är bäst att hämta platsen dynamiskt med hjälp av metadatadokumentet och parsa jwks_uri:

https://contoso.b2clogin.com/contoso.onmicrosoft.com/b2c_1_signupsignin1/discovery/v2.0/keys

JSON-dokumentet som finns på den här URL:en innehåller all information om den offentliga nyckeln som används vid ett visst tillfälle. Din app kan använda anspråket kid i JWT-huvudet för att välja den offentliga nyckeln i JSON-dokumentet som används för att signera en viss token. Den kan sedan utföra signaturvalidering med rätt offentlig nyckel och den angivna algoritmen.

Metadatadokumentet B2C_1_signupsignin1 för principen i klientorganisationen contoso.onmicrosoft.com finns på:

https://contoso.b2clogin.com/contoso.onmicrosoft.com/b2c_1_signupsignin1/v2.0/.well-known/openid-configuration

För att avgöra vilken princip som användes för att signera en token (och vart du ska gå för att begära metadata) har du två alternativ. Först inkluderas principnamnet i (standard) eller acr anspråket tfp (enligt konfigurationen) i token. Du kan parsa anspråk från JWT-brödtexten genom att base-64 avkoda brödtexten och avserialisera JSON-strängen som resulterar. Anspråket tfp eller acr är namnet på principen som användes för att utfärda token. Det andra alternativet är att koda principen i värdet för parametern state när du utfärdar begäran och sedan avkoda den för att avgöra vilken princip som användes. Endera metoden är giltig.

Azure AD B2C använder RS256-algoritmen, som baseras på RFC 3447-specifikationen. Den offentliga nyckeln består av två komponenter: RSA-modulus (n) och den offentliga RSA-exponenten (e). Du kan programmatiskt konvertera n värden och e till ett certifikatformat för tokenverifiering.

En beskrivning av hur du utför signaturverifiering ligger utanför omfånget för det här dokumentet. Det finns många bibliotek med öppen källkod som hjälper dig att verifiera en token.

Verifiera anspråk

När dina program eller API tar emot en ID-token bör den också utföra flera kontroller mot anspråken i ID-token. Följande anspråk bör kontrolleras:

audience – Verifierar att ID-token var avsedd att ges till ditt program.
inte före och förfallotid – Verifierar att ID-token inte har upphört att gälla.
issuer – Verifierar att token har utfärdats till ditt program av Azure AD B2C.
nonce – en strategi för riskreducering av tokenuppspelningsattacker.

En fullständig lista över valideringar som programmet ska utföra finns i OpenID Connect-specifikationen.

Nästa steg

Läs mer om hur du använder åtkomsttoken.