Background/Situation
The OAuth subject (the sub claim) is the identifier JetBrains IDE Services uses to recognize a returning user. Migrating an on-premises identity provider such as ADFS issues a new OAuth subject for every user, so a migrated user would normally appear to IDE Services as a brand-new account. With non-floating (per-user) licenses, which cannot be revoked and reassigned frequently, a new account means a lost license, lost settings, and interrupted access.
Question
After an ADFS server migration changes the OAuth subject for every user, how does JetBrains IDE Services keep returning users matched to their existing accounts, licenses, and settings?
Answer
IDE Services does not rely on the OAuth subject alone. It also matches a returning user by the email claim. When a user signs in with a new OAuth subject, IDE Services looks for an existing account with the same email; on a match, it re-links the login to that account and updates the stored OAuth subject to the new value. The original account, license, and settings are preserved, and no manual license revocation is required.
For this email-based re-linking to work across an ADFS migration:
The email claim is what re-links the subject
- The new ADFS server must issue tokens that include the user's email as a claim.
- The email in the token must match the email stored for the account in the IDE Services administration UI. Matching is case-insensitive.
- A missing or mismatched email defeats re-linking: IDE Services treats the new subject as a new user and creates a separate account.
Point JWT validation at the new ADFS environment
- Keep the existing JWT validation configuration and update the
jwt-certs-urlparameter to the new ADFS environment's signing keys or JWKS endpoint.
Use a version with case-insensitive email matching
- Earlier IDE Services versions compared emails case-sensitively, which broke re-linking when the case differed.
- Use a build from the
2026.*release or newer, or confirm with JetBrains support whether the installed version includes the fix.
Validate with a trial migration
- Migrate one or two test accounts against the new ADFS environment.
- Have the test users sign in through the new ADFS server.
- Verify in the administration UI that each account is re-linked, the stored OAuth subject is updated, and licenses and settings are retained.
Comments
0 comments
Please sign in to leave a comment.