Een technisch profiel definiëren voor een JWT-tokenverlener in een aangepast Azure Active Directory B2C-beleid
Notitie
In Azure Active Directory B2C is aangepast beleid voornamelijk bedoeld om met complexe scenario's om te gaan. Voor de meeste scenario's wordt aangeraden ingebouwde gebruikersstromen te gebruiken. Als u dit nog niet hebt gedaan, vindt u meer informatie over aangepast beleid in het starterspakket 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. Een technisch profiel voor een JWT-tokenverlener verzendt een JWT-token dat wordt geretourneerd naar de relying party-toepassing. Dit technische profiel is meestal de laatste indelingsstap in het gebruikerstraject.
Protocol
Het kenmerk Naam van het element Protocol moet worden ingesteld op OpenIdConnect. Stel het element OutputTokenFormat in op JWT.
In het volgende voorbeeld ziet u een technisch profiel voor JwtIssuer:
<TechnicalProfile Id="JwtIssuer">
<DisplayName>JWT Issuer</DisplayName>
<Protocol Name="OpenIdConnect" />
<OutputTokenFormat>JWT</OutputTokenFormat>
<Metadata>
<Item Key="client_id">{service:te}</Item>
<Item Key="issuer_refresh_token_user_identity_claim_type">objectId</Item>
<Item Key="SendTokenResponseBodyWithJsonNumbers">true</Item>
</Metadata>
<CryptographicKeys>
<Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
<Key Id="issuer_refresh_token_key" StorageReferenceId="B2C_1A_TokenEncryptionKeyContainer" />
</CryptographicKeys>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-jwt-issuer" />
</TechnicalProfile>
Invoer-, uitvoer- en persistente claims
De elementen InputClaims, OutputClaims en PersistClaims zijn leeg of afwezig. De elementen InutputClaimsTransformations en OutputClaimsTransformations zijn ook afwezig.
Metagegevens
| Kenmerk | Vereist | Beschrijving |
|---|---|---|
| issuer_refresh_token_user_identity_claim_type | Ja | De claim die moet worden gebruikt als de claim voor de gebruikersidentiteit binnen de OAuth2-autorisatiecodes en vernieuwingstokens. U moet deze standaard instellen op objectId, tenzij u een ander claimtype SubjectNamingInfo opgeeft. |
| SendTokenResponseBodyWithJsonNumbers | Nee | Altijd instellen op true. Voor verouderde notatie waarbij numerieke waarden worden opgegeven als tekenreeksen in plaats van JSON-getallen, ingesteld op false. Dit kenmerk is nodig voor clients die afhankelijk zijn van een eerdere implementatie die eigenschappen als tekenreeksen heeft geretourneerd. |
| token_lifetime_secs | Nee | Levensduur van toegangstokens. De levensduur van het OAuth 2.0 bearer-token dat wordt gebruikt om toegang te krijgen tot een beveiligde resource. De standaardwaarde is 3600 seconden (1 uur). Het minimum (inclusief) is 300 seconden (5 minuten). Het maximum (inclusief) is 86.400 seconden (24 uur). |
| id_token_lifetime_secs | Nee | Levensduur van id-token. De standaardwaarde is 3600 seconden (1 uur). Het minimum (inclusief) is 300 seconden (5 minuten). Het maximum (inclusief) is seconden 86.400 (24 uur). |
| refresh_token_lifetime_secs | Nee | Levensduur van token vernieuwen. De maximale periode voordat een vernieuwingstoken kan worden gebruikt om een nieuw toegangstoken te verkrijgen, als uw toepassing het offline_access bereik had gekregen. De standaardwaarde is 120.9600 seconden (14 dagen). Het minimum (inclusief) is 86.400 seconden (24 uur). Het maximum (inclusief) is 776.000 seconden (90 dagen). |
| rolling_refresh_token_lifetime_secs | Nee | Levensduur van tokenschuifvenster vernieuwen. Nadat deze periode is verstreken, wordt de gebruiker gedwongen opnieuw te verifiëren, ongeacht de geldigheidsperiode van het meest recente vernieuwingstoken dat is verkregen door de toepassing. Als u de levensduur van een schuifvenster niet wilt afdwingen, stelt u de waarde van allow_infinite_rolling_refresh_token in op true. De standaardwaarde is 776.000 seconden (90 dagen). Het minimum (inclusief) is 86.400 seconden (24 uur). Het maximum (inclusief) is 31.536.000 seconden (365 dagen). |
| allow_infinite_rolling_refresh_token | Nee | Als dit is ingesteld true, verloopt de levensduur van het vernieuwingstokenschuifvenster nooit. |
| IssuanceClaimPattern | Nee | Hiermee bepaalt u de claim Issuer (iss). Een van de waarden:
|
| AuthenticationContextReferenceClaimPattern | Nee | Hiermee bepaalt u de acr claimwaarde.
<Item> Key="AuthenticationContextReferenceClaimPattern" waarde bestaat en de waarde is None. Voeg in uw relying party-beleid item toe <OutputClaims> , voeg dit element <OutputClaim ClaimTypeReferenceId="trustFrameworkPolicy" Required="true" DefaultValue="{policy}" PartnerClaimType="tfp"/>toe. Zorg er ook voor dat uw beleid het claimtype bevat <ClaimType Id="trustFrameworkPolicy"> <DisplayName>trustFrameworkPolicy</DisplayName> <DataType>string</DataType> </ClaimType> |
| RefreshTokenUserJourneyId | Nee | De id van een gebruikerstraject dat moet worden uitgevoerd tijdens het vernieuwen van een POST-aanvraag voor toegangstokens naar het /token eindpunt. |
Cryptografische sleutels
Het element CryptographicKeys bevat deze volgende kenmerken:
| Kenmerk | Vereist | Beschrijving |
|---|---|---|
| issuer_secret | Ja | Het X509-certificaat (RSA-sleutelset) dat moet worden gebruikt om het JWT-token te ondertekenen. Dit is de sleutel die u configureert in Aan de B2C_1A_TokenSigningKeyContainer slag met aangepaste beleidsregels. |
| issuer_refresh_token_key | Ja | Het X509-certificaat (RSA-sleutelset) dat moet worden gebruikt om het vernieuwingstoken te versleutelen. U hebt de sleutel geconfigureerd in Aan de B2C_1A_TokenEncryptionKeyContainer slag met aangepast beleid |
Sessiebeheer
Als u de Azure AD B2C-sessies tussen Azure AD B2C en een relying party-toepassing wilt configureren, voegt u in het kenmerk van het UseTechnicalProfileForSessionManagement element een verwijzing toe naar de OAuthSSOSessionProvider SSO-sessie.