Översikt över token i Azure Active Directory B2C

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ållet i 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 informationskontroller om ägaren och tokens ämne.

Följande token används i kommunikationen 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. Den här 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 ser lämpligt. 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 det 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 det är giltigt. Beroende på scenariokraven kan de anspråk som verifieras av ett program variera, men ditt program 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 är signerade, men de är inte krypterade. Å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 äkta. Ditt API måste också verifiera några anspråk i token för att bevisa att det är giltigt. Beroende på scenariokraven kan de anspråk som verifieras av ett program variera, men ditt program 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 behöva interagera med dessa användare. Uppdateringstoken är ogenomskinliga 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 refresh token kommer att vara giltig under en viss tidsperiod. Uppdateringstoken kan när som helst ogiltigförklaras av flera skäl. 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 det uppdateringstokenet som du tidigare använde i begäran. Den här åtgärden hjälper till att garantera 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 på 24 timmar för uppdateringstoken. 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-tokens hämtas från:

• /authorize slutpunkt görs det med 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 din appregistrering eftersom MSAL.js 2.0+ stöder auktoriseringskodflödet med PKCE.
• /token slutpunkten görs med hjälp av auktoriseringskodflödet, vilket 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 påståenden kan när som helst introduceras i ID-tokens. Ditt program ska inte gå sönder när nya klagomål 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.

Konfiguration

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

• Livslängd för åtkomst- och ID-token (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. Minimivärdet (inklusive) är 5 minuter. Maximalt (inkluderande) är 1 440 minuter.

• Livslängd för uppdateringstoken (dagar) – Den maximala tidsperiod innan 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 ditt program har beviljats omfånget offline_access . Standardvärdet är 14 dagar. Minimivärdet (inklusive) är en dag. Maximalt (inklusive) är 90 dagar.

• Livslängd för skjutfönster för uppdateringstoken (dagar) – Efter den här tidsperioden tvingas användaren att autentisera igen, oavsett giltighetsperioden för den senaste uppdateringstoken som hämtats av programmet. Det 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å Inget utgångsdatum kan du inte ange något specifikt värde. Standardvärdet är 90 dagar. Minimivärdet (inklusive) är en dag. Maximalt (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 är kontinuerligt aktiv i programmet. Du kan ange livslängden för uppdateringstokens glidande fönster (dagar) till Inget utgångsdatum 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:

• Issuer (iss) claim – Den här egenskapen identifierar Azure AD B2C-instansen 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/ inkluderar ID:n för både Azure AD B2C-klienten och användarflödet som användes i tokenförfrågan. 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 (sub) – Den här egenskapen identifierar vilken entitet för vilken token hävdar information. Standardvärdet är ObjectID, som fyller anspråket sub i token med användarens objekt-ID. Värdet Stöds inte tillhandahålls 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. 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 den token för att hämta information om användaren. Du aktiverar ett anspråk i användarflödet för att överföra token till de applikationer som du registrerar i Azure AD B2C. Din applikation måste använda ett rekommenderat användarflöde för att kunna överföra token som ett krav.

Azure AD B2C stöder för närvarande endast överföring av åtkomsttoken för OAuth 2.0-identitetsprovidrar, däribland 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.

Huvudet på token 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 alg-anspråket ä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. När som helst kan Azure AD B2C signera en token med någon av en uppsättning offentliga-privata nyckelpar. Azure AD B2C roterar regelbundet den möjliga uppsättningen nycklar. Programmet ska 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. För att hantera oväntade nyckeländringar bör programmet skrivas för att återhämta de offentliga nycklarna om det får ett oväntat nyckel-ID.

Azure AD B2C har en Slutpunkt för OpenID Connect-metadata. Med den här slutpunkten kan program begära information om Azure AD B2C under körning. Den här informationen omfattar slutpunkter, tokeninnehåll och tokensigneringsnycklar. Din Azure AD B2C-klient 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 finns här, men det är bäst att hämta den dynamiskt med hjälp av metadatadokumentet och att analysera 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 offentlig nyckelinformation som används vid en viss tidpunkt. 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 signaturverifiering med rätt offentlig nyckel och den angivna algoritmen.

Metadatadokumentet för B2C_1_signupsignin1-principen i contoso.onmicrosoft.com-klientorganisationen 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 tfp (standard) eller acr anspråket (enligt konfigurationen) i token. Du kan utvinna information från JWT:s innehåll genom att base64-avkoda dess innehåll och deserialisera JSON-strängen som skapas. Anspråket tfp eller acr är namnet på policyn som användes för att utfärda tokenen. 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. Båda metoderna är validerade.

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 och e värden 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 de också utföra flera kontroller mot anspråken i ID-token. Följande anspråk bör kontrolleras:

• audience – Verifierar att ID-token är avsedd att ges till din applikation.
• 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 att minska risken för tokenuppspelningsattacker.

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

Relaterat innehåll

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