How to change the ResponseType

[alexjose]

Hi,

I want to add some user info into my JWT. It can be done by changing the response type of the authorization server with bearer token supporting extra params.

Ref: https://github.com/thephpleague/oauth2-server/blob/master/tests/ResponseTypes/BearerTokenResponseWithParams.php

But I am not sure how can I change the response type inside the passport.

[craigpaul]

Passport can't really set additional (private) claims the way it is now. In fact, Passport makes use of the php league's League\OAuth2\Server\Entities\Traits\AccessTokenTrait to convert the token to a trait.

/**
 * Generate a JWT from the access token
 *
 * @param CryptKey $privateKey
 *
 * @return string
 */
public function convertToJWT(CryptKey $privateKey)
{
    return (new Builder())
        ->setAudience($this->getClient()->getIdentifier())
        ->setId($this->getIdentifier(), true)
        ->setIssuedAt(time())
        ->setNotBefore(time())
        ->setExpiration($this->getExpiryDateTime()->getTimestamp())
        ->setSubject($this->getUserIdentifier())
        ->set('scopes', $this->getScopes())
        ->sign(new Sha256(), new Key($privateKey->getKeyPath(), $privateKey->getPassPhrase()))
        ->getToken();
}

You'll notice the ->set('scopes', $this->getScopes()) call, that is how a private claim is set using Lcobucci\JWT\Builder. So, short of a pull request to override convertToJWT() on Laravel\Passport\Bridge\AccessToken with some method of adding custom claims, there is no way currently to do so.

[alexjose]

Thank you for the reply @craigpaul.

Is there any plans to do this implementation any soon?

[craigpaul]

Wouldn't know, you'd have to ask one of the contributors I suppose? @taylorotwell ?

[wayne5w]

Have the same need. League\OAuth2 provides for extra params (see below) but I don't see how I can override AuthorizationServer::getResponseType since that is in the PassportServiceProvider.

/**
* Add custom fields to your Bearer Token response here, then override
* AuthorizationServer::getResponseType() to pull in your version of
* this class rather than the default.
*
* @param AccessTokenEntityInterface $accessToken
*
* @return array
*/
protected function getExtraParams(AccessTokenEntityInterface $accessToken)
{
return [];
}

[themsaid]

Hello everyone, looking into this issue but I'm curious to know what type of custom claims can be attached to a token also how do you normally attach those claims while creating the token?

Thank you

[craigpaul]

@themsaid Private claims can be anything that two parties agree on using, they are not limited to a predefined set of keys. Read more about the payload here.

Private claims: These are the custom claims created to share information between parties that agree on using them.

As for how they are normally attached, I'm not sure what you mean, if you're talking about how they are represented in the payload, then here is an example.

{
  "aud": "1",
  "jti": "4ee513a9e858b3b47d09bd5bd522af6bc463fdeb47b6b036b2a2f28ba5b022039f5fe1be61b24aea",
  "iat": 1479267759,
  "nbf": 1479267759,
  "exp": 1480563759,
  "sub": "1",
  "scopes": [],
  // private claims below
  "name": "Taylor Otwell",
  "admin": true,
}

As for how to attach them to the token, we can either attach parameters to the response or attach custom claims to the JWT as they are two different things. To attach parameters to the response we can override the getExtraParams() method like @wayne5w mentioned. If the goal is to attach custom claims to the JWT, then overriding the convertToJWT() method as I've shown above would be the route to take. Personally the convertToJWT() method makes much more sense as it actually attaches it as a claim on the token.

Hope that answers your question, if not let me know and I'll help with whatever I can.

[themsaid]

@craigpaul thank you for the detailed explanation, that answers my questions :)

I believe the desired behaviour here is to attach custom claims to the JWT, I just need some real world example so that I can work on a proposal with a valid use case, do you have any in mind?

[craigpaul]

@themsaid I've never personally had a use case for this so I have no idea what a valid example would be. Hopefully @alexjose or @wayne5w have an idea of what they were looking for.

[i906]

In my use case, my app user has resources that can be accessed through devices or APIs.
The user then can set which resources would be available to which devices.

Let say the user has 3 resources: A, B, C and 2 devices: 1, 2.
Device 1 can access A and B, device 2 can only access C.

I was hoping a token can be created like:

$scopes = [
  'get-resources',
];

$claims = [
  'resources' => ['A', 'B'],
];

// Pass token to device
$token = $user->createToken('Device 1', $scopes, $claims)->accessToken;

Then I would get the claims from the token and validate them in policies, requests or controllers.

$claims = $user->token()->claims;

[chris-rs]

I think this feature is really interesting if the token is consumed by a distant resource service, which relies on valid tokens from the authorization service.
With custom claims the authorization service can inform the resource service about the user. The resource service can act based on the claims. For instance user roles, but user data could also be provided to create a user record at the resource service.

[frankmichel]

I would love to use this feature as well when consuming my own API.

[lloy0076]

I've managed to duplicate this code and test that I can see 'dsl' = 'rules' appears in the resulting JWT.

I'm thinking if we add a:

public function __construct($userIdentifier, array $scopes = [], other_claims = [])

...that simply iterated through those claims we're somewhat there.

IF someone thinks this is a good idea, then I'll fork this and fiddle about.

IF someone would be willing to help me figure out how to get a test rig setup and to make the test to test this (there are tests I'm sure and I wouldn't want to introduce a change without them), I'd be really appreciative.

[RDelorier]

I think allowing custom claims would really make the access token much more useful. Rather than only being able to authenticate requests to the api it would allow us to display additional user information without pounding the api for the same simple information over and over.

Static website use case

My user interface is a single page application which is build and served from a cdn. All authentication is handled by my auth service which is running on passport.

Each time the page loads I want to show the current users name and avatar in the header, as well as limit some ui elements based on the roles of the user. Currently I make an ajax call with the token to fetch the user data. With custom claims that ajax call would go away and I could just use something like jwt-decode to get the information I need from the access token itself.

Resource server use case

In addition to the auth service and the front end I have multiple resource servers that must all authorize requests using the auth service as the source of truth.

When a user wants to update a restricted resource I must verify the user has the correct permission to do so. This means I need to make a request to the auth service to retrieve the users permissions before I can proceed. If the permissions were available on the access token then I could use the public key from my auth service to verify and decode the access token then I would have all the information I needed to continue.

Websockets

When users connect to my site I want to connect them to a web socket once they are authenticated, I also want to add their name to a list of online users. Given only the access token I need to again requests the users basic info (name, avatar) from my auth service. If this information were on the access token that would not be necessary. Just like the resource server my socket server could use my auth services public key to validate and decode the token giving me all the information necessary.

@themsaid I hope these use cases are helpful. I'm currently accomplishing this by registering a custom AccessTokenRepository but it would be nice If someone could find a clean way to implement this as a core feature. Here is a gist of my current setup in case it helps https://gist.github.com/RDelorier/9ec45bbb595b7e21c30df80c34b03cac