Overzicht van tokens in Azure Active Directory B2C

Artikel
04/24/2023

Azure Active Directory B2C (Azure AD B2C) verzendt verschillende typen beveiligingstokens wanneer elke verificatiestroom wordt verwerkt. In dit artikel worden de indeling, beveiligingskenmerken en inhoud van elk type token beschreven.

Tokentypen

Azure AD B2C ondersteunt de OAuth 2.0- en OpenID Connect-protocollen, die gebruikmaken van tokens voor verificatie en veilige toegang tot resources. Alle tokens die in Azure AD B2C worden gebruikt, zijn JSON-webtokens (JWT's) die asserties bevatten van informatie over de bearer en het onderwerp van het token.

De volgende tokens worden gebruikt in de communicatie met Azure AD B2C:

Id-token : een JWT die claims bevat die u kunt gebruiken om gebruikers in uw toepassing te identificeren. Dit token wordt veilig verzonden in HTTP-aanvragen voor communicatie tussen twee onderdelen van dezelfde toepassing of service. U kunt de claims in een id-token naar eigen goeddunken gebruiken. Ze worden meestal gebruikt om accountgegevens weer te geven of om beslissingen over toegangsbeheer te nemen in een toepassing. De id-tokens die zijn uitgegeven door Azure AD B2C zijn ondertekend, maar niet versleuteld. Wanneer uw toepassing of API een id-token ontvangt, moet de handtekening worden gevalideerd om te bewijzen dat het token authentiek is. Uw toepassing of API moet ook enkele claims in het token valideren om te bewijzen dat het geldig is. Afhankelijk van de scenariovereisten kunnen de claims die door een toepassing worden gevalideerd variëren, maar uw toepassing moet in elk scenario enkele algemene claimvalidaties uitvoeren.
Toegangstoken : een JWT die claims bevat die u kunt gebruiken om de verleende machtigingen voor uw API's te identificeren. Toegangstokens zijn ondertekend, maar niet versleuteld. Toegangstokens worden gebruikt om toegang te bieden tot API's en resourceservers. Wanneer uw API een toegangstoken ontvangt, moet de handtekening worden gevalideerd om te bewijzen dat het token authentiek is. Uw API moet ook enkele claims in het token valideren om te bewijzen dat het geldig is. Afhankelijk van de scenariovereisten kunnen de claims die door een toepassing worden gevalideerd variëren, maar uw toepassing moet in elk scenario enkele algemene claimvalidaties uitvoeren.
Vernieuwingstoken : vernieuwingstokens worden gebruikt voor het verkrijgen van nieuwe id-tokens en toegangstokens in een OAuth 2.0-stroom. Ze bieden uw toepassing langdurige toegang tot resources namens gebruikers zonder tussenkomst van die gebruikers. Vernieuwingstokens zijn ondoorzichtig voor uw toepassing. Ze worden uitgegeven door Azure AD B2C en kunnen alleen worden geïnspecteerd en geïnterpreteerd door Azure AD B2C. Ze hebben een lange levensduur, maar uw toepassing mag niet worden geschreven met de verwachting dat een vernieuwingstoken een bepaalde periode meegaat. Vernieuwingstokens kunnen op elk gewenst moment om verschillende redenen ongeldig worden gemaakt. De enige manier voor uw toepassing om te weten of een vernieuwingstoken geldig is, is door te proberen het in te wisselen door een tokenaanvraag in te dienen bij Azure AD B2C. Wanneer u een vernieuwingstoken inwisselt voor een nieuw token, ontvangt u een nieuw vernieuwingstoken in het tokenantwoord. Sla het nieuwe vernieuwingstoken op. Het vernieuwingstoken dat u eerder in de aanvraag hebt gebruikt, wordt vervangen. Deze actie zorgt ervoor dat uw vernieuwingstokens zo lang mogelijk geldig blijven. Toepassingen met één pagina die gebruikmaken van de autorisatiecodestroom met PKCE hebben altijd een vernieuwingstokenlevensduur van 24 uur. Meer informatie over de gevolgen voor de beveiliging van vernieuwingstokens in de browser.

Eindpunten

Een geregistreerde toepassing ontvangt tokens en communiceert met Azure AD B2C door aanvragen naar deze eindpunten te verzenden:

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

Beveiligingstokens die uw toepassing ontvangt van Azure AD B2C kunnen afkomstig zijn van de /authorize eindpunten of/token. Wanneer id-tokens worden verkregen van de:

/authorize eindpunt, wordt dit gedaan met behulp van de impliciete stroom, die vaak wordt gebruikt voor gebruikers die zich aanmelden bij op JavaScript gebaseerde webtoepassingen. Als uw app echter gebruikmaakt van MSAL.js 2.0 of hoger, schakelt u impliciete stroomtoestemming niet in uw app-registratie in, omdat MSAL.js 2.0+ de autorisatiecodestroom met PKCE ondersteunt.
/token eindpunt, wordt dit gedaan met behulp van de autorisatiecodestroom, waardoor het token verborgen blijft in de browser.

Claims

Wanneer u Azure AD B2C gebruikt, hebt u nauwkeurige controle over de inhoud van uw tokens. U kunt gebruikersstromen en aangepaste beleidsregels configureren om bepaalde sets gebruikersgegevens in claims te verzenden die vereist zijn voor uw toepassing. Deze claims kunnen standaardeigenschappen bevatten, zoals displayName en emailAddress. Uw toepassingen kunnen deze claims gebruiken om gebruikers en aanvragen veilig te verifiëren.

De claims in id-tokens worden niet in een bepaalde volgorde geretourneerd. Nieuwe claims kunnen op elk gewenst moment worden geïntroduceerd in id-tokens. Uw toepassing mag niet breken als er nieuwe claims worden geïntroduceerd. U kunt ook aangepaste gebruikerskenmerken opnemen in uw claims.

De volgende tabel bevat de claims die u kunt verwachten in id-tokens en toegangstokens die zijn uitgegeven door Azure AD B2C.

Naam	Claim	Voorbeeldwaarde	Beschrijving
Doelgroep	`aud`	`90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6`	Identificeert de beoogde ontvanger van het token. Voor Azure AD B2C is de doelgroep de toepassings-id. Uw toepassing moet deze waarde valideren en het token afwijzen als het niet overeenkomt. Doelgroep is synoniem met resource.
Verlener	`iss`	`https://<tenant-name>.b2clogin.com/775527ff-9a37-4307-8b3d-cc311f58d925/v2.0/`	Identificeert de beveiligingstokenservice (STS) die het token maakt en retourneert. Het identificeert ook de map waarin de gebruiker is geverifieerd. Uw toepassing moet de claim van de verlener valideren om ervoor te zorgen dat het token afkomstig is van het juiste eindpunt.
Uitgegeven om	`iat`	`1438535543`	Het tijdstip waarop het token is uitgegeven, weergegeven in epoch time.
Verlooptijd	`exp`	`1438539443`	Het tijdstip waarop het token ongeldig wordt, aangegeven in epoch-tijd. Uw toepassing moet deze claim gebruiken om de geldigheid van de levensduur van het token te controleren.
Niet eerder	`nbf`	`1438535543`	Het tijdstip waarop het token geldig wordt, weergegeven in epoch-tijd. Deze tijd is meestal hetzelfde als het tijdstip waarop het token is uitgegeven. Uw toepassing moet deze claim gebruiken om de geldigheid van de levensduur van het token te controleren.
Versie	`ver`	`1.0`	De versie van het id-token, zoals gedefinieerd door Azure AD B2C.
Code-hash	`c_hash`	`SGCPtt01wxwfgnYZy2VJtQ`	Een code-hash die alleen is opgenomen in een id-token wanneer het token samen met een OAuth 2.0-autorisatiecode wordt uitgegeven. Een code-hash kan worden gebruikt om de echtheid van een autorisatiecode te valideren. Zie de OpenID Connect-specificatie voor meer informatie over het uitvoeren van deze validatie.
Hash van toegangstoken	`at_hash`	`SGCPtt01wxwfgnYZy2VJtQ`	Een toegangstoken-hash die alleen in een id-token is opgenomen wanneer het token samen met een OAuth 2.0-toegangstoken wordt uitgegeven. Een hash van een toegangstoken kan worden gebruikt om de echtheid van een toegangstoken te valideren. Zie de OpenID Connect-specificatie voor meer informatie over het uitvoeren van deze validatie.
Nonce	`nonce`	`12345`	Een nonce is een strategie die wordt gebruikt om tokenherhalingsaanvallen te beperken. Uw toepassing kan een nonce opgeven in een autorisatieaanvraag met behulp van de `nonce` queryparameter. De waarde die u in de aanvraag opgeeft, wordt alleen ongewijzigd verzonden in de `nonce` claim van een id-token. Met deze claim kan uw toepassing de waarde verifiëren op basis van de waarde die is opgegeven in de aanvraag. Uw toepassing moet deze validatie uitvoeren tijdens het id-tokenvalidatieproces.
Onderwerp	`sub`	`884408e1-2918-4cz0-b12d-3aa027d7563b`	De principal waarover het token informatie bevestigt, zoals de gebruiker van een toepassing. Deze waarde is onveranderbaar en kan niet opnieuw worden toegewezen of opnieuw worden gebruikt. Het kan worden gebruikt om autorisatiecontroles veilig uit te voeren, bijvoorbeeld wanneer het token wordt gebruikt voor toegang tot een resource. De onderwerpclaim wordt standaard gevuld met de object-id van de gebruiker in de map.
Referentie voor verificatiecontextklasse	`acr`	Niet van toepassing	Alleen gebruikt met oudere beleidsregels.
Beleid voor vertrouwensframework	`tfp`	`b2c_1_signupsignin1`	De naam van het beleid dat is gebruikt om het id-token te verkrijgen.
Verificatietijd	`auth_time`	`1438535543`	Het tijdstip waarop een gebruiker voor het laatst referenties heeft ingevoerd, weergegeven in epoch-tijd. Er is geen discriminatie tussen die verificatie als een nieuwe aanmelding, een sessie voor eenmalige aanmelding (SSO) of een ander aanmeldingstype. De `auth_time` is de laatste keer dat de toepassing (of gebruiker) een verificatiepoging heeft gestart tegen Azure AD B2C. De methode die wordt gebruikt om te verifiëren, is niet gedifferentieerd.
Bereik	`scp`	`Read`	De machtigingen die aan de resource zijn verleend voor een toegangstoken. Meerdere verleende machtigingen worden gescheiden door een spatie.
Geautoriseerde partij	`azp`	`975251ed-e4f5-4efd-abcb-5f1a8f566ab7`	De toepassings-id van de clienttoepassing die de aanvraag heeft geïnitieerd.

Configuratie

De volgende eigenschappen worden gebruikt voor het beheren van de levensduur van beveiligingstokens die worden verzonden door Azure AD B2C:

Toegang & Levensduur van id-token (minuten): de levensduur van het OAuth 2.0 Bearer-token dat wordt gebruikt om toegang te krijgen tot een beveiligde resource. De standaardwaarde is 60 minuten. Het minimum (inclusief) is 5 minuten. Het maximum (inclusief) is 1440 minuten.
Levensduur van vernieuwingstoken (dagen): de maximale periode waarvoor een vernieuwingstoken kan worden gebruikt om een nieuw toegangs- of id-token te verkrijgen. De periode omvat ook het verkrijgen van een nieuw vernieuwingstoken als uw toepassing het offline_access bereik heeft gekregen. De standaardwaarde is 14 dagen. Het minimum (inclusief) is een dag. Het maximum (inclusief) is 90 dagen.
Levensduur van sliding window vernieuwen van token (dagen): nadat deze periode is verstreken, wordt de gebruiker gedwongen opnieuw te verifiëren, ongeacht de geldigheidsperiode van het meest recente vernieuwingstoken dat door de toepassing is verkregen. Deze kan alleen worden opgegeven als de switch is ingesteld op Gebonden. Deze moet groter zijn dan of gelijk zijn aan de waarde van de levensduur van het vernieuwingstoken (dagen). Als de schakeloptie is ingesteld op Geen verlooptijd, kunt u geen specifieke waarde opgeven. De standaardwaarde is 90 dagen. Het minimum (inclusief) is een dag. Het maximum (inclusief) is 365 dagen.

De volgende use cases worden ingeschakeld met behulp van deze eigenschappen:

Toestaan dat een gebruiker voor onbepaalde tijd aangemeld blijft bij een mobiele toepassing, zolang de gebruiker voortdurend actief is in de toepassing. U kunt de levensduur van het verschuifbare venster van het vernieuwingstoken (dagen) instellen op Geen verloop in uw gebruikersstroom voor aanmelding.
Voldoe aan de beveiligings- en nalevingsvereisten van uw branche door de juiste levensduur van het toegangstoken in te stellen.

Deze instellingen zijn niet beschikbaar voor gebruikersstromen voor wachtwoordherstel.

Compatibiliteit

De volgende eigenschappen worden gebruikt voor het beheren van tokencompatibiliteit:

Claim van verlener (iss): deze eigenschap identificeert de Azure AD B2C-tenant die het token heeft uitgegeven. De standaardwaarde is https://<domain>/{B2C tenant GUID}/v2.0/. De waarde van https://<domain>/tfp/{B2C tenant GUID}/{Policy ID}/v2.0/ bevat id's voor zowel de Azure AD B2C-tenant als de gebruikersstroom die is gebruikt in de tokenaanvraag. Als uw toepassing of bibliotheek Azure AD B2C nodig heeft om te voldoen aan de OpenID Connect Discovery 1.0-specificatie, gebruikt u deze waarde.
Onderwerpclaim (subclaim): deze eigenschap identificeert de entiteit waarvoor het token informatie bevestigt. De standaardwaarde is ObjectID, waarmee de sub claim in het token wordt gevuld met de object-id van de gebruiker. De waarde van Niet ondersteund wordt alleen opgegeven voor compatibiliteit met eerdere versies. Het is raadzaam om over te schakelen naar ObjectID zodra u dat kunt.
Claim die beleids-id vertegenwoordigt : deze eigenschap identificeert het claimtype waarin de beleidsnaam die wordt gebruikt in de tokenaanvraag wordt ingevuld. De standaardwaarde is tfp. De waarde van acr wordt alleen opgegeven voor compatibiliteit met eerdere versies.

Pass-through

Wanneer een gebruikerstraject wordt gestart, ontvangt Azure AD B2C een toegangstoken van een id-provider. Azure AD B2C gebruikt dat token om informatie over de gebruiker op te halen. U schakelt een claim in uw gebruikersstroom in om het token door te geven aan de toepassingen die u registreert in Azure AD B2C. Uw toepassing moet een aanbevolen gebruikersstroom gebruiken om te profiteren van het doorgeven van het token als een claim.

Azure AD B2C ondersteunt momenteel alleen het doorgeven van het toegangstoken van OAuth 2.0-id-providers, waaronder Facebook en Google. Voor alle andere id-providers wordt de claim leeg geretourneerd.

Validatie

Als u een token wilt valideren, moet uw toepassing zowel de handtekening als de claims van het token controleren. Er zijn veel opensourcebibliotheken beschikbaar voor het valideren van JWT's, afhankelijk van uw voorkeurstaal. Het is raadzaam deze opties te verkennen in plaats van uw eigen validatielogica te implementeren.

Handtekening valideren

Een JWT bevat drie segmenten, een koptekst, een hoofdtekst en een handtekening. Het handtekeningsegment kan worden gebruikt om de echtheid van het token te valideren, zodat het kan worden vertrouwd door uw toepassing. Azure AD B2C-tokens worden ondertekend met behulp van industriestandaard asymmetrische versleutelingsalgoritmen, zoals RSA 256.

De header van het token bevat informatie over de sleutel en versleutelingsmethode die worden gebruikt om het token te ondertekenen:

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

De waarde van de alg-claim is het algoritme dat is gebruikt om het token te ondertekenen. De waarde van de claim kind is de openbare sleutel die is gebruikt om het token te ondertekenen. Op elk gewenst moment kan Azure AD B2C een token ondertekenen met behulp van een set openbare en persoonlijke sleutelparen. Azure AD B2C roteert de mogelijke set sleutels periodiek. Uw toepassing moet worden geschreven om deze belangrijke wijzigingen automatisch af te handelen. Een redelijke frequentie om te controleren op updates van de openbare sleutels die door Azure AD B2C worden gebruikt, is elke 24 uur. Als u onverwachte sleutelwijzigingen wilt afhandelen, moet uw toepassing worden geschreven om de openbare sleutels opnieuw op te halen als deze een onverwachte waarde voor kinderen ontvangt.

Azure AD B2C een OpenID Connect-metagegevenseindpunt heeft. Met behulp van dit eindpunt kunnen toepassingen tijdens runtime informatie opvragen over Azure AD B2C. Deze informatie omvat eindpunten, tokeninhoud en tokenondertekeningssleutels. Uw Azure AD B2C-tenant bevat een JSON-metagegevensdocument voor elk beleid. Het metagegevensdocument is een JSON-object dat verschillende nuttige informatie bevat. De metagegevens bevatten jwks_uri, waarmee de locatie wordt opgegeven van de set openbare sleutels die worden gebruikt om tokens te ondertekenen. Deze locatie wordt hier opgegeven, maar het is het beste om de locatie dynamisch op te halen met behulp van het metagegevensdocument en het parseren van jwks_uri:

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

Het JSON-document op deze URL bevat alle openbare-sleutelgegevens die op een bepaald moment worden gebruikt. Uw app kan de kid claim in de JWT-header gebruiken om de openbare sleutel in het JSON-document te selecteren die wordt gebruikt om een bepaald token te ondertekenen. Vervolgens kan handtekeningvalidatie worden uitgevoerd met behulp van de juiste openbare sleutel en het aangegeven algoritme.

Het metagegevensdocument voor het B2C_1_signupsignin1 beleid in de contoso.onmicrosoft.com tenant bevindt zich op:

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

Als u wilt bepalen welk beleid is gebruikt om een token te ondertekenen (en waar u de metagegevens moet aanvragen), hebt u twee opties. Ten eerste wordt de beleidsnaam opgenomen in de tfp (standaard) of acr claim (zoals geconfigureerd) in het token. U kunt claims uit de hoofdtekst van de JWT parseren door base-64 de hoofdtekst te decoderen en de JSON-tekenreeks die het resultaat is te deserialiseren. De tfp claim of acr is de naam van het beleid dat is gebruikt om het token uit te geven. De andere optie is om het beleid te coderen in de waarde van de state parameter wanneer u de aanvraag uitgeeft en het vervolgens te decoderen om te bepalen welk beleid is gebruikt. Beide methoden zijn geldig.

Azure AD B2C maakt gebruik van het RS256-algoritme, dat is gebaseerd op de RFC 3447-specificatie. De openbare sleutel bestaat uit twee onderdelen: de RSA-modulus (n) en de openbare RSA-exponent (e). U kunt waarden programmatisch converteren n naar e een certificaatindeling voor tokenvalidatie.

Een beschrijving van het uitvoeren van handtekeningvalidatie valt buiten het bereik van dit document. Er zijn veel opensourcebibliotheken beschikbaar om u te helpen een token te valideren.

Claims valideren

Wanneer uw toepassingen of API een id-token ontvangt, moet het ook verschillende controles uitvoeren op de claims in het id-token. De volgende claims moeten worden gecontroleerd:

doelgroep : controleert of het id-token bedoeld was om aan uw toepassing te worden gegeven.
niet vóór en verlooptijd : controleert of het id-token niet is verlopen.
uitgever: controleert of het token is uitgegeven aan uw toepassing door Azure AD B2C.
nonce : een strategie voor het beperken van tokenherhaling van aanvallen.

Raadpleeg de OpenID Connect-specificatie voor een volledige lijst met validaties die uw toepassing moet uitvoeren.

Volgende stappen

Meer informatie over het gebruik van toegangstokens.

Delen via