MatthewH.10249 (State of Iowa) asked a question.
We have Org2Org between two tenants and have been advised by Okta Professional Services to create a custom attribute to map the UID from the spoke tenant to the hub tenant so we can then store the spoke UID in hub apps for user data association. I don't think we can just store the spoke UID as it is possible that it could collide with a UID in the hub for a different users who do not have a spoke account. We can append something to the spoke UID when mapping to the hub to avoid this conflict. Another option is to perhaps to concatenate the two UIDs for a given user like "spokeUid-hubUid" but I digress.
Regardless of how we make the spoke UID unique in the hub, is there anything like SAML, OIDC middleware, Okta Widget, etc that automatically uses the "sub" claim found in either ID and Access JWTs? I wonder if we need to make sure the "sub" remains unaltered containing just the UID of the hub tenant? If not, I would like to alter the "sub" claim in the hub tenant using an expression on our Auth Server to use the concatenated or appended spoke UID so each of our apps don't have to have extra logic to determine which UID to pull.
It feels dirty to have to do any of this and I wish that Org2Org accounts just shared a unique ID across tenants but I guess that is not how it works. Before we make any "sub" claim mapping changes I want to know if we are shooting ourselves in the foot. We can always just have two different UID attributes for a given user in the hub tenant but it will be a bit more work for app developers to deal with them.
Hello,
Baver here, from the Okta team.
You cannot change the sub claim in the tokens. As this case seems to require a bit of troubleshooting I think the best idea is to open a case with the Okta support team.
Thank you.
Baver Deacu
Baver, it sure seems like the "sub" claim for Access tokens can be changed based on the way it looks on our tenant (see image below). We verified that the Access Token's sub claim value is returning the user name not the UID. We also verified that in the ID Token the sub claim value is returning the UID (Okta GUID) for the same user. We wonder if these should be the same so developers know to always use "sub" values to bind to their application data for a given user.
We had a Support Ticket (01144947) that was closed after Okta Professional Services started to get involved. The support ticket looked to address questions about how to get the spoke UID of a user that is provisioned to a hub via Org2Org. To focus on where and how the app gets the user identifier got us focusing on the "sub" claim in the ID and Access tokens. Okta Professional Services suggested we create a new claim WFIUID to set the spoke UID in on the hub account which we have done. We are now wondering if we should do something with "sub" to hold the WFIUID if it exists else the UID rather than returning the user name or app client id.
No idea why we would ever want the app client id to return as the "sub" claim value thus the reason for this community post. Before we make further changes we want others to comment if they have knowledge of anything dependent on "sub" that would break if the value was not the user name or app client id.