sub claim vs upn claim

[olijaun]

Hi

I've read the spec and I still don't understand what's the point of the "upn".

The MP-JWT spec says: "upn": A human readable claim that uniquely identifies the subject or user principal of the token, across the MicroProfile services the token will be accessed with.

The JWT spec says: 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. The "sub" value is a case-sensitive string containing a StringOrURI value. Use of this claim is OPTIONAL.

If understand this correctly then the only difference is that a upn has to be only unique accross the services the token will be accessed with; contrary to sub that can be unique in the context of the issuer or globally.

So what does globally mean? Does globally mean that it must be something like an Email or a (hopefully) unique UUID?

What would be an example for a UPN then? It could of course also be an Email as well because if it is globally unique then it is also unique across the services the token will be accessed with.

But why can't it just be a sub claim then? Because there might be different issuers? Do you have a practical example for this? What would be the reason to have multiple issuers? And if you have: how can you assure that the value is unique across all of them? Because they are all controlled by the same company?

Can someone give me a concrete example where you would have either a sub claim AND a upn or only a upn?

Thanks and regards
Oliver

[sberyozkin]

Hi @olijaun

upn is a MP JWT specific claim more analogous to name or preferred_username, sub is just the last resource fallback, it can't be usefully used to for example, interact with the user, it is a number or hexadecimal sequence etc

[olijaun]

Hi @sberyozkin

Thank for your response. Now you're confusing me even more.

You say that upn is more analogous to preferred_username. The OpenID Spec says: "Therefore, other Claims such as [...] preferred_username and[sic] MUST NOT be used as unique identifiers for the End-User."

The MP-JWT spec says that the upn is "A human readable claim that uniquely identifies the subject or user principal of the token, across the MicroProfile services the token will be accessed with."

So it doesn't seem to me that they are analogous. ups has to be unique but preferred_username doesn't have to.

"sub" has to be locally unique... whatever this means exactly. But I still don't see the need for UPN. If you need something unique there is the "sub" claim. If you need something like a username then us use "preferred_username" (which is part of the OpenID standard).

Why is there a need for UPN?

Regards
Oliver

[sberyozkin]

@olijaun that claim was added in the 1.0 version, so I'll let original authors to clarify. I'll just add to what I said above is that MP JWT is not OIDC. In any case, you don't have to use it if you find it confusing, thanks

[sberyozkin]

@olijaun sorry, misread your comment. So, yes, it is an MP JWT specific claim, it does not have to be used if the oidc claims specified in the fallback spec text are available. It was an attempt I guess to standardise when tokens are not produced by OIDC providers

[olijaun]

hi @sberyozkin

Ah, ok. I see. In the first version it was not exclusively for OIDC... That makes sense then... although now that the spec is referring exclusively to OIDC it is somehow confusing. Maybe it should be mentioned that the UPN exists for historical reason. Currently the spec says: "To meet those requirements, we introduce 2 new claims to the MP-JWT "upn": A human readable claim [...]". So if one reads the spec this might give the impression that the UPN must be important, which is not the case (anymore). Maybe that could be improved.

But thanks for the explanation!

Regards
Oliver

[sberyozkin]

Np, while Keycloak does support this claim, I'm not sure how many other providers do. I can imagine though it can be hard to introduce such a text, this spec is not depending on OIDC, it is more like an opinionated JWT spec, with some important claims expected to be set, etc. Self signed tokens are quite typical in MP JWT as well

[olijaun]

I don't want to be picky but the current version of the spec (2.1) states: "This specification outlines a proposal for using OpenID Connect (OIDC) based JSON Web Tokens (JWT) for Role Based Access Control (RBAC) of microservice endpoints."

So even if they are not "OIDC" what does it mean to be OIDC-based? "sub" is a mandatory claim. If it is OIDC based, then it does have the "sub" claim.

On the projects main page it says "This specification outlines how the signed JWT tokens issued by OIDC and other trusted providers can be verified and their claims used for Role Based Access Control (RBAC) of microservice endpoints."

This seems to be a contradiction to me.