Azure B2C令牌生成技术问询：Client Credentials Grant与会话唯一属性配置

Great questions about Azure B2C token capabilities—let’s break them down clearly:

1. Service-to-Service Token Generation via Client Credentials Grant #

Azure B2C doesn’t support the standard OAuth 2.0 Client Credentials Grant out of the box with its built-in user flows, but you can absolutely implement this using custom policies. Here’s how to make it work for your gateway:

• First, set up a custom policy that includes a ClientCredentialsIssuer technical profile. This profile handles client authentication and token issuance specifically for service-to-service calls.
• Configure your gateway to send a POST request to your B2C token endpoint (format: https://<your-b2c-tenant>.b2clogin.com/<your-b2c-tenant>.onmicrosoft.com/<your-custom-policy>/oauth2/v2.0/token) with these required parameters:
  • grant_type: client_credentials
  • client_id: Your application’s registered client ID in Azure B2C
  • client_secret: Your application’s client secret
  • scope: The scope defined for your target service (e.g., https://<tenant>.onmicrosoft.com/api/.default)
• The response will return a valid access token that your gateway can use for service-to-service authorization.

2. Adding a Unique Session ID to Token Responses #

Yes, you can inject a unique session-specific attribute (like a session ID) into B2C tokens. The most flexible approach uses custom policies (built-in user flows don’t support dynamic session attributes):

• First, define a claim for the session ID in your policy’s ClaimsSchema section:

  <ClaimType Id="sessionId">
    <DisplayName>Session ID</DisplayName>
    <DataType>string</DataType>
    <UserHelpText>A unique identifier for the user's current session</UserHelpText>
  </ClaimType>
  

• Next, add a claim transformation to generate a unique GUID for the session. Use the CreateRandomString method:

  <ClaimsTransformation Id="GenerateSessionId" TransformationMethod="CreateRandomString">
    <InputParameters>
      <InputParameter Id="randomGeneratorType" DataType="string" Value="GUID" />
    </InputParameters>
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="sessionId" TransformationClaimType="outputClaim" />
    </OutputClaims>
  </ClaimsTransformation>
  

• Attach this transformation to a technical profile that runs during the user authentication flow (e.g., the SelfAsserted-LocalAccountSignin-Email profile for local account logins).
• Finally, ensure the sessionId claim is included in your token by adding it to the OutputClaims section of the RelyingParty element:

  <RelyingParty>
    <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
    <TechnicalProfile Id="PolicyProfile">
      <DisplayName>PolicyProfile</DisplayName>
      <Protocol Name="OpenIdConnect" />
      <OutputClaims>
        <!-- Keep your existing claims here -->
        <OutputClaim ClaimTypeReferenceId="sessionId" />
      </OutputClaims>
      <SubjectNamingInfo ClaimType="sub" />
    </TechnicalProfile>
  </RelyingParty>
  

After setup, every user’s token will include a unique sessionId tied to their login session.

内容的提问来源于stack exchange，提问作者David G