How do I modify the id_token content generated by ADFS? For example, I want to change the "sub" field. Or how do I add a field, for example, I want to add an "on_premises_account" field

Question

I modified the claim rules in the trusted party trust in ADFS so that access_token can be changed, but id_token cannot be changed.

Answer 1

Hello,

AD FS is quite opinionated when it comes to the contents of its id_tokens. In short, while you have a fair amount of control over the claims in an access_token using claim rules in your trusted relying party configuration, modifying the id_token—especially fields like "sub"—is not supported.

Here are some details and considerations:

1. "sub" Claim Behavior

 • The "sub" (subject) claim in id_tokens is automatically generated by AD FS. It’s designed to be a stable, opaque value that uniquely represents the user for that relying party.

 • Because it’s generated internally (often as a hash based on one or more attributes), AD FS does not let you change how it is produced even if you change claim rules—this is by design to ensure consistency and security.

2. Adding Custom Claims (e.g., "on_premises_account")

 • While you may be able to add or transform claims for the access_token through custom claim rules, those rules do not necessarily affect the id_token.

 • AD FS separates how it constructs the id_token and the access_token. For the id_token you’ll find that many claims (other than a few explicitly supported ones) are not modifiable via the usual claim rule interface.

3. Workarounds and Alternatives

 • If you need to include additional application-specific information (like "on_premises_account") in the id_token, one common suggestion is to consider whether that information might be conveyed via another mechanism (such as a separate lookup, or by enhancing your client application to make a call to a userinfo endpoint if available).

 • Some deployments have resorted to building a custom security token service (STS) or insertion of a proxy layer that modifies tokens after AD FS issues them. However, this comes with significant complexity and is generally not recommended because it can break interoperability and security guarantees.

---

If the Answer is helpful, please click "Accept Answer" and upvote it.