Define a technical profile for a JWT token issuer in an Azure Active Directory B2C custom policy
Note
In Azure Active Directory B2C, custom policies are designed primarily to address complex scenarios. For most scenarios, we recommend that you use built-in user flows. If you've not done so, learn about custom policy starter pack in Get started with custom policies in Active Directory B2C.
Azure Active Directory B2C (Azure AD B2C) emits several types of security tokens as it processes each authentication flow. A technical profile for a JWT token issuer emits a JWT token that is returned back to the relying party application. Usually this technical profile is the last orchestration step in the user journey.
Protocol
The Name attribute of the Protocol element needs to be set to OpenIdConnect. Set the OutputTokenFormat element to JWT.
The following example shows a technical profile for 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>
Input, output, and persist claims
The InputClaims, OutputClaims, and PersistClaims elements are empty or absent. The InutputClaimsTransformations and OutputClaimsTransformations elements are also absent.
Metadata
| Attribute | Required | Description |
|---|---|---|
| issuer_refresh_token_user_identity_claim_type | Yes | The claim that should be used as the user identity claim within the OAuth2 authorization codes and refresh tokens. By default, you should set it to objectId, unless you specify a different SubjectNamingInfo claim type. |
| SendTokenResponseBodyWithJsonNumbers | No | Always set to true. For legacy format where numeric values are given as strings instead of JSON numbers, set to false. This attribute is needed for clients that have taken a dependency on an earlier implementation that returned such properties as strings. |
| token_lifetime_secs | No | Access token lifetimes. The lifetime of the OAuth 2.0 bearer token used to gain access to a protected resource. The default is 3,600 seconds (1 hour). The minimum (inclusive) is 300 seconds (5 minutes). The maximum (inclusive) is 86,400 seconds (24 hours). |
| id_token_lifetime_secs | No | ID token lifetimes. The default is 3,600 seconds (1 hour). The minimum (inclusive) is 300 seconds (5 minutes). The maximum (inclusive) is seconds 86,400 (24 hours). |
| refresh_token_lifetime_secs | No | Refresh token lifetimes. The maximum time period before which a refresh token can be used to acquire a new access token, if your application had been granted the offline_access scope. The default is 120,9600 seconds (14 days). The minimum (inclusive) is 86,400 seconds (24 hours). The maximum (inclusive) is 7,776,000 seconds (90 days). |
| rolling_refresh_token_lifetime_secs | No | Refresh token sliding window lifetime. After this time period elapses the user is forced to reauthenticate, irrespective of the validity period of the most recent refresh token acquired by the application. If you don't want to enforce a sliding window lifetime, set the value of allow_infinite_rolling_refresh_token to true. The default is 7,776,000 seconds (90 days). The minimum (inclusive) is 86,400 seconds (24 hours). The maximum (inclusive) is 31,536,000 seconds (365 days). |
| allow_infinite_rolling_refresh_token | No | If set to true, the refresh token sliding window lifetime never expires. |
| IssuanceClaimPattern | No | Controls the Issuer (iss) claim. One of the values:
|
| AuthenticationContextReferenceClaimPattern | No | Controls the acr claim value.
<Item> with the Key="AuthenticationContextReferenceClaimPattern" exists and the value is None. In your relying party policy, add <OutputClaims> item, add this element <OutputClaim ClaimTypeReferenceId="trustFrameworkPolicy" Required="true" DefaultValue="{policy}" PartnerClaimType="tfp"/>. Also make sure your policy contains the claim type <ClaimType Id="trustFrameworkPolicy"> <DisplayName>trustFrameworkPolicy</DisplayName> <DataType>string</DataType> </ClaimType> |
| RefreshTokenUserJourneyId | No | The identifier of a user journey that should be executed during the refresh an access token POST request to the /token endpoint. |
Cryptographic keys
The CryptographicKeys element contains the following attributes:
| Attribute | Required | Description |
|---|---|---|
| issuer_secret | Yes | The X509 certificate (RSA key set) to use to sign the JWT token. This is the B2C_1A_TokenSigningKeyContainer key you configure in Get started with custom policies. |
| issuer_refresh_token_key | Yes | The X509 certificate (RSA key set) to use to encrypt the refresh token. You configured the B2C_1A_TokenEncryptionKeyContainer key in Get started with custom policies |
Session management
To configure the Azure AD B2C sessions between Azure AD B2C and a relying party application, in the attribute of the UseTechnicalProfileForSessionManagement element, add a reference to OAuthSSOSessionProvider SSO session.
Feedback
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback.
Submit and view feedback for