Oauth2-server: Ability to extend the JWT token with information

[leroy0211]

Right now the JWT token has one custom claim called scopes. But it would be a nice feature to add some more claims to the JWT when required.
Like a username, email, user-group, etc.

[Sephster]

Agreed. Adding as an improvement

[simonhamp]

If/when this is available, implementors should be extra cautious about what they store in the JWT - especially if it's not encrypted - but even if it is, maybe things like email address aren't the best things to be putting inside a token. Use OpenID Connect instead.

Also, consider the extra weight that adding new claims will give to your headers - in some cases, larger JWTs could cause unexpected errors.

Personally, I would err on the side of keeping tokens slimmer, choosing to add an extra request to your process for less headaches.

[christiaangoossens]

+1, I implemented this now (for adding a group ID to the token) by extending all the grants, which isn't the nicest for maintainability.

[mtangoo]

@simonhamp
Your concern is genuine, but I think it goes against spirit of this library of allowing flexibility in terms of "engine and tires". A word of warning will suffice for those who want to extends it and if someone extends it without knowing what they are doing, let them shoot their feet!

I suggest some sort of freedom we have in other things get extended there too!

[simonhamp]

@mtangoo I appreciate your point, but I have to disagree. I don't feel that what you suggest is the correct approach. Letting others 'shoot their feet' is one of the factors involved in why there are leaks of billions of people's personal details... we need to help each other improve security and an opinionated stance on the part of widely-used, standards-compliant libraries such as this can make a huge difference on that front.

Flexibility where flexibility is safe and useful, not just for flexibility's sake.

[mtangoo]

we need to help each other improve security and an opinionated stance on the part of widely-used.....Flexibility where flexibility is safe and useful, not just for flexibility's sake.

Thanks for genuine concerns. My point was, putting ability to extend as completely optional and add even a warning that only people who know what they are doing should even venture there. If someone still feels brave to transgress that, then let them shoot their feets for sure.

Am not against helping people to be compliant. But I really get worried when that ends up crippling flexibility.

Cheers!

[simonhamp]

Hence my original comment 🙂

[mtangoo]

:)

[nealoke]

@christiaangoossens do you mind sharing how you did the adding of (in your case) the group ID to the JWT token? I am needing this as well because users have access to multiple accounts. You mentioned extending the Grant types but I'm unsure how.

[rakeev]

@nealoke all you need to do is reimplement AccessTokenEntity::convertToJWT()
Copy it from AccessTokenTrait and adjust as needed
No grant extension needed

[uphlewis]

It would be nice to be able to do this without having to re-implement/copy+paste the guts of AccessTokenTrait::convertToJWT() completely.

How about if we added the following method to AccessTokenTrait:

protected function setCustomScopes(\Lcobucci\JWT\Builder $builder): \Lcobucci\JWT\Builder
{
    return $builder;
}

That gives any descendants the opportunity to simply override the setCustomScopes() method, and then in AccessTokenTrait::convertToJWT() we can run the builder through that method before returning the token.

[andrewmclagan]

Agree with @uphlewis, even if convertToJWT() returned an instance of Builder and not Token we could extend the trait and modify the token returned in __toString()

[ol1s]

Even once you have managed to add custom claims to the JWT, how do you get them back out of the validated request?

Currently BearerTokenValidator is hard-coded to return only 4 specific claims:

// Return the request with additional attributes
return $request
    ->withAttribute('oauth_access_token_id', $token->getClaim('jti'))
    ->withAttribute('oauth_client_id', $token->getClaim('aud'))
    ->withAttribute('oauth_user_id', $token->getClaim('sub'))
    ->withAttribute('oauth_scopes', $token->getClaim('scopes'))

[Radiergummi]

Since the 8.x release, you cannot override convertToJWT anymore, since it's marked private instead of public. @Sephster, is there any specific reason to not make it protected instead? I recognize the intention to keep things safe and prevent users from shooting their own foot, but OTOH I know what I'm doing and _need_ a few custom claims in my tokens, which will be read by other applications.
It'd be nice to have a way to extend tokens without having to reimplement the whole library :(

Edit: Sorry, my bad. By overriding __toString, we can call a custom implementation instead. This still feels awkward, though, and doesn't invalidate the problem highlighted by @ol1s.