Overzicht van tokens in Azure Active Directory B2C

Notitie

In Azure Active Directory B2C zijn aangepaste beleidsregels voornamelijk ontworpen om complexe scenario's aan te pakken. Voor de meeste scenario's raden we u aan ingebouwde gebruikersstromen te gebruiken. Als u dit nog niet hebt gedaan, vindt u meer informatie over aangepaste beleidsstartpakketten in Aan de slag met aangepaste beleidsregels in Active Directory B2C.

Azure Active Directory B2C (Azure AD B2C) verzendt verschillende typen beveiligingstokens terwijl 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-Verbinding maken protocollen, die gebruikmaken van tokens voor verificatie en beveiligde toegang tot resources. Alle tokens die worden gebruikt in Azure AD B2C 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 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 gebruiken zoals u dat ziet. Ze worden vaak gebruikt om accountgegevens weer te geven of om beslissingen te nemen over toegangsbeheer in een toepassing. Id-tokens zijn ondertekend, maar de id-tokens zijn niet versleuteld. Wanneer uw toepassing of API een id-token ontvangt, moet deze de handtekening valideren om te bewijzen dat het token authentiek is. Uw toepassing of API moet ook enkele claims in het token valideren om te bewijzen dat deze 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 worden niet versleuteld. Toegangstokens worden gebruikt om toegang te bieden tot API's en resourceservers. Wanneer uw API een toegangstoken ontvangt, moet deze de handtekening valideren om te bewijzen dat het token authentiek is. Uw API moet ook enkele claims in het token valideren om te bewijzen dat deze 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 gedurende een bepaalde periode zal duren. Vernieuwingstokens kunnen om verschillende redenen ongeldig worden gemaakt. De enige manier om te weten of een vernieuwingstoken geldig is, is door een tokenaanvraag naar Azure AD B2C te verzenden. Wanneer u een vernieuwingstoken voor een nieuw token inwisselt, ontvangt u een nieuw vernieuwingstoken in het tokenantwoord. Sla het nieuwe vernieuwingstoken op. Het vervangt het vernieuwingstoken dat u eerder in de aanvraag hebt gebruikt. Met deze actie kunt u garanderen 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 of /token eindpunten. Wanneer id-tokens worden verkregen van het volgende:

  • /authorize het eindpunt wordt uitgevoerd met behulp van de impliciete stroom, die vaak wordt gebruikt voor gebruikers die zich aanmelden bij webtoepassingen op basis van JavaScript. 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 ondersteunt met PKCE.
  • /token het eindpunt wordt uitgevoerd met behulp van de autorisatiecodestroom, waardoor het token verborgen blijft in de browser.

Claims

Wanneer u Azure AD B2C gebruikt, hebt u gedetailleerde controle over de inhoud van uw tokens. U kunt gebruikersstromen en aangepaste beleidsregels configureren om bepaalde sets gebruikersgegevens te verzenden in claims 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 geretourneerd in een bepaalde volgorde. 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 weigeren als dit 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 bouwt 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 op iat 1438535543 Het tijdstip waarop het token is uitgegeven, weergegeven in epoch time.
Verlooptijd exp 1438539443 Het tijdstip waarop het token ongeldig wordt, weergegeven in tijdsperiode. 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 tijdsperiode. 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 is opgenomen in een id-token alleen wanneer het token wordt uitgegeven samen met een OAuth 2.0-autorisatiecode. Een code-hash kan worden gebruikt om de echtheid van een autorisatiecode te valideren. Zie de OpenID-Verbinding maken specificatie voor meer informatie over het uitvoeren van deze validatie.
Hash van toegangstoken at_hash SGCPtt01wxwfgnYZy2VJtQ Een toegangstoken-hash die is opgenomen in een id-token alleen wanneer het token wordt uitgegeven samen met een OAuth 2.0-toegangstoken. Een toegangstoken-hash kan worden gebruikt om de echtheid van een toegangstoken te valideren. Zie de OpenID Verbinding maken specificatie voor meer informatie over het uitvoeren van deze validatie
Nonce nonce 12345 Een nonce is een strategie die wordt gebruikt om tokenherplayaanvallen 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 doorgevoerd in de nonce claim van een id-token. Met deze claim kan uw toepassing de waarde controleren op basis van de waarde die is opgegeven in de aanvraag. Uw toepassing moet deze validatie uitvoeren tijdens het validatieproces van het id-token.
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.
Naslaginformatie over 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 de laatste keer referenties heeft ingevoerd, weergegeven in tijdsperiode. Er is geen discriminatie tussen die verificatie als een nieuwe aanmelding, een eenmalige aanmeldingssessie (SSO) of een ander aanmeldingstype. De auth_time laatste keer dat de toepassing (of gebruiker) een verificatiepoging heeft gestart voor 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 gestart.

Configuratie

De volgende eigenschappen worden gebruikt voor het beheren van 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 het vernieuwingstoken (dagen): de maximale periode voordat 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 één dag. Het maximum (inclusief) is 90 dagen.

  • Levensduur van vernieuwtokenschuifvenster (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 schakeloptie is ingesteld op Gebonden. Deze moet groter zijn dan of gelijk zijn aan de levensduur van het vernieuwingstoken (dagen). Als de schakeloptie is ingesteld op Nee, kunt u geen specifieke waarde opgeven. De standaardwaarde is 90 dagen. Het minimum (inclusief) is één dag. Het maximum (inclusief) is 365 dagen.

De volgende gebruiksvoorbeelden 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 schuifvenster vernieuwen (dagen) instellen op Geen verloop in uw aanmeldingsgebruikersstroom.
  • Voldoen 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:

  • Verlenerclaim (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/ 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 Verbinding maken Discovery 1.0-specificatie, gebruikt u deze waarde.

  • Onderwerpclaim (sub): 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 is alleen beschikbaar 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 is alleen beschikbaar 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 biedt momenteel alleen ondersteuning voor 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 om 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 asymmetrische versleutelingsalgoritmen, zoals RSA 256.

De header van het token bevat informatie over de sleutel en versleutelingsmethode die wordt 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 kid-claim 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-persoonlijke sleutelparen. Azure AD B2C roteert regelmatig de mogelijke set sleutels. Uw toepassing moet worden geschreven om deze belangrijke wijzigingen automatisch af te handelen. Een redelijke frequentie om te controleren op updates voor 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 een kind ontvangt.

Azure AD B2C heeft een OpenID Verbinding maken metagegevenseindpunt. Met dit eindpunt kunnen toepassingen tijdens runtime informatie aanvragen over Azure AD B2C. Deze informatie omvat eindpunten, tokeninhoud en ondertekeningssleutels voor tokens. 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 voor het ondertekenen van tokens. Deze locatie wordt hier gegeven, maar u kunt de locatie het beste dynamisch ophalen 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 te selecteren in het JSON-document dat 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

U hebt twee opties om te bepalen welk beleid is gebruikt om een token te ondertekenen (en waar u de metagegevens wilt aanvragen). Eerst wordt de beleidsnaam opgenomen in de tfp (standaard) of acr claim (zoals geconfigureerd) in het token. U kunt claims parseren uit de hoofdtekst van de JWT door base-64 decodering van de hoofdtekst en deserialiseren van de JSON-tekenreeks die resulteert. De tfp of acr claim 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 verzendt en deze 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 programmatisch waarden 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 opensource-bibliotheken 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 is 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 replay-aanvallen voor tokens.

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

Volgende stappen

Meer informatie over het gebruik van toegangstokens.