Why is the `sub` claim in the Access Token and ID Token different?

[Nureva]

In the Access Token the sub claim is the email of the user.

In the ID Token the sub claim is the unique identifier of the user.

Why is this?

[Govner]

https://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes

[jrahhali]

I’m sorry, but just providing a link with no additional context is not a helpful answer. The answer may very well be in plain sight in the document you linked to, but I for one, cannot see it (and I imagine I’m not the only one that is still left scratching their heads).

I would like to revive this post, and re-ask the exact same questoin as the OP

[andrea]

As @Govner pointed out, this is per OpenID Connect (OIDC) Spec, which states that…

A Subject Identifier is a locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client.

The sub claim is further defined in RFC 7519, which defines the JSON Web Token format used in for ID tokens (per spec):

The “sub” (subject) claim identifies the principal that is the subject of the JWT. The claims in a JWT are normally statements about the subject. The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique. The processing of this claim is generally application specific.

For the OIDC ID Token, the subject of the token the UUID for the user, to ensure that it is globally unique.

It should be noted that OIDC is an add-on to the OAuth spec which involves defining the new ID Token, but the OAuth Spec itself does not specify a standard/required format for Access Tokens. Many services use “opaque” tokens instead of parsable JWTs, but, like our ID tokens, Okta uses JWTs for Access Tokens as well. Unless you are using a custom authorization server (which allows you to configure the sub claim at the server level, see answer below), the Access token is meant for Okta’s consumption (to access Okta API’s/resources, see details about OAuth for Okta) and the sub is not designed to be configurable.

An answer about where these values come from for tokens issued by Okta were also discussed here: Can Sub claim be configured to be GUID? - #2 by andrea
Can I trust the access token sub claim for identifying user? - #4 by andrea

[mcrobbj-fs]

Would be nice to have your own immutable guid that is the same across both. So it looks like the max size for the id (sub in id token) is 20 is that correct and is their a regex for this?