Agreed. Adding as an improvement

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.

+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.

@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!

@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.

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!

Hence my original comment 🙂

:)

@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.

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

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.