I am completing work on implementing user impersonation through the oauth2 bearer token.
My question is regarding the sub key in JWT tokens that contains the userkey. I understand that we will no longer be able to impersonate users through the sub field in the JWT claim on 8/1/2017. However, will Atlassian still continue to provide the userkey in the sub field of the claim when making requests to the add-on. We currently use the sub to resolve the user key. I haven’t found anything in the documentation that says this will change, so we are assuming that the userkey will still be available in the token claim. However, I would really like to be sure of this. Please confirm if this is accurate.
Hi @jan.revis,
where did you learn about sub claims not being supported after Aug 1? We rely heavily on this feature in our add-on! I am very surprised we haven’t been warned much more explicitly of this change, knowing that Atlassian has an exhaustive list of add-ons that have been whitelisted to be able to make sub claims.
Thanks,
David
To clarify, that was for Confluence add-ons. I’m not certain if JIRA is affected. I was notified because I am registered as an owner of a white listed add-on.
I have received confirmation that the sub field will still be provided in JWT claims used to sign requests from confluence to the add-on. The sub field will just not be able to perform user impersonation when the add-on makes requests to confluence, so white listed add-ons will act as the add-on user when performing REST calls. We’re supposed to use bearer tokens for user impersonation going forward.
Addon vendors on the whitelist were notified individually about the deprecation in favour of the new OAuth 2.0 functionality. Unfortunately there may have been a mixup with contact info here. I will message you privately to discuss an extension.