2

The resources on the web I have seen so far suggest that the 'sub' claim in a JWT identifies the principal.

According to this question, at least for some identity provider implementations, one cannot transfer sub values from one identity provider to another should the need arise.

This would suggest that it is better for apps to create their own user_id value for each new user and have that included in the JWT as a custom attribute to be returned by the JWT as described here.

Up to now I have been happily relying on the sub claim but now I need to move to a different identity provider (actually a different user pool still within Cognito) and all my sub values are going to change, outside of my control.

Does anyone know if it is actually recommended practice to NOT allow the 'sub' to leak into application space and to use a custom attribute in the JWT to provide the application-controlled user_id?

1
  • RFC 7519 addresses this. It states that you can establish mutually-agreed upon private claims, so long as you're willing to take the risk of collisions. Commented Dec 3, 2020 at 15:45

1 Answer 1

2

The sub claim, per RFC7519, does indeed "identify the principal". However, its processing is "generally application specific". That means it's hard to reason about its behaviour and semantics in a global way. What's definitely true is that relying on it to be the same between different identity providers (and separate Cognito pools counts as "different identity providers") is almost certainly going to end in tears.

For identity providers that are capable of providing a JWT containing custom claims that can be looked up at token issuance time, adding a custom claim containing the application's concept of "user ID" is one solution. However, if you decide to move to a different identity provider in the future that can't support this, you're back to "tears" territory. It's far better to store a mapping in your application between "the identity provider's sub value" and "the application's concept of user identity", and do the lookup on the JWT after it arrives. You can then store the sub value of multiple identity providers, with their mapping to your application's user identity, and everything ends up nice and tidy.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.