Allow overriding username claim name

[singhman13]

Added an additional configuration parameter to allow overriding the username claim name identifying the JWT payload claim which contains the username. For example, some external providers (Google, Auth0) use the "sub" (Subject) IANA registered claim name. (See RFC 7519.)

Use case: required when the tokens are generated by an external entity (e.g. Auth0 for user management) and need the middleware for verification only.

Was considering if it's worth using "sub" by default instead of "id", so that the default out of the box configuration works for both locally and externally generated tokens (at least those using RFC 7519 recommendations.) Would probably need fallback to "id" if a "sub" claim isn't present to allowing any existing issued tokens to still work. Not sure if it's worth the effort. Also might be a breaking change for some, depending on if request.Env["JWT_PAYLOAD"] "id" claim is being accessed directly, although they should be using request.Env["REMOTE_USER"] instead.

Relevant extracts from RFC 7519 in case anyone is interested.
https://tools.ietf.org/html/rfc7519

4.1. Registered Claim Names

The following Claim Names are registered in the IANA "JSON Web Token
Claims" registry established by Section 10.1. None of the claims
defined below are intended to be mandatory to use or implement in all
cases, but rather they provide a starting point for a set of useful,
interoperable claims. Applications using JWTs should define which
specific claims they use and when they are required or optional. All
the names are short because a core goal of JWTs is for the
representation to be compact.

4.1.2. "sub" (Subject) Claim

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.

[StephanDollberg]

Hi @khalsa72 ,

thanks for the detailed PR and all the explanations. I think that it makes sense to fully move from id to sub. However, as you mentioned this will break existing tokens. On the other hand, I want to keep the middleware simple and not expose to many options to the user.

As such, I will wait with this for jwt-go to release its version three which will create some breakage and at that point we can break our stuff as well and update this.

I will leave this open till then.

Thanks,
Stephan

[singhman13]

Stephan,

There is a common use case for overriding username claim which will benefit from merging this before v3. While the sub claim is usually a unique ID for the provider, additional claims like username or email may also be present.

Depending on your application requirements you might choose to use the sub claim. This way if the user later changes their email address they log into to the same application account.

Alternatively, you might decide that you want to link to the email claim allowing users to authenticate via multiple providers (auth0, Google, etc.) and still have them log into the same application account.

I think it's worth merging the current PR as-is and then switching to "sub" as the default in with jwt-go v3. I haven't updated the default to sub in this PR. Having the ability to override it will always be useful, and since it's an optional parameter, it shouldn't' increase the complexity of using the middleware.

Disclaimer: My opinion is biased as I would like to stop using my fork and switch back to your repo.

Thanks,

-Manpreet

[StephanDollberg]

Hi Manpreet,

I get your point, on the other side I am still resistent of adding too many features and would like to wait for jwt-go to get a feeling of how it would look in the end.

I will think about it.

Cheers,
Stephan

[StephanDollberg]

Hi @khalsa72,

I have thought about it and just don't feel like it makes sense to push this into now. Like I said I want to keep the middleware pretty simple and first want to wait for v3 to see how it would look.

Thanks,
Stephan

[singhman13]

Understood, I can wait till v3.