Customize the JWT payload

[enten]

Is it possible to customize the JWT payload?
After code review, I thinks that the answer is no. But I want to be sure.

What do you think about a new configuration option named userPayload which may be used to customize the JWT payload?

userPayload can be an array which contains extra field names to put in payload (next to idField).

To implement that feature, we should factorize the code below (existing into services/local/index.js and services/oauth/index.js) into a new createPayload function which accept user, idField and extraFields (corresponding to new userPayload).

        // replace...
        const payload = {
          id: user.id !== undefined ? user.id : user._id
        };
        // by...
        const payload = createPayload(user, this.options.idField, this.options.userPayload);

Implementation example of createPayload:

function createPayload(user, idField, extraFields) {
  let payload = {
    id: user[idField] || user.id || user._id
  };

  if (!payload.id) {
    // throw error
  }

  if (Array.isArray(extraFields)) {
    extraFields.forEach(fieldName => payload[fieldName] = user[fieldName]);
  }

  return payload;
}

Do you find that feature useful?
The main purpose is to have user data without requesting the database (doesn't need to call populateUser hook for few user data).

[ekryski]

@enten I'm definitely open to it. We actually started down the route of just encoding the whole user in the JWT payload but we found that the JWT could get massive if you aren't selecting specific fields. I think your solution is great so if you want to put together a PR that would be awesome!

Things to do:

• Implement createPayload()
• Test token encryption with all potential options
• Document new idField and extraFields authentication options
• Issue minor release

We'll need to make sure it has a test. I'll be backfilling other tests today so I could help with that.

[enten]

I'm glad you like the idea.
I'm working on my fork to prepare a PR for that.

• Implement createPayload()

After another code review, I prefer another solution due to the file organization: I don't want to create more file dependency for only one function (and I don't know where creates this new dependency).

I suggest to update the token.create method to create(user): because we create a token based on an user (so it's the input).

And we create the payload in token.create before signing it.

What do you think about this modification?

• Test token encryption with all potential options

What do you mean by "potential options"? idField and extraFields?

• Document new idField and extraFields authentication options

The idField option already exists?
I found it in authentication doc.
I believe that its integration is incomplete (see TODO marker here and there)

I suggest extraFields not for the option name but for the param name of the eventual createPayload function. I suggest userPayload for the option name (it's coherent with the related option userEndpoint).

We'll need to make sure it has a test

I'll be happy if I do not break the existing tests. I will need your help for that.

[ekryski]

Closed in v0.6.0 by #109. In order to customize the JWT payload you can do this:

app.configure(authentication({
  token: {
    payload: ['email', 'name'],
  }
}));

[crobinson42]

@ekryski Is there a solution in version 2.1 for adding custom data to the JWT payload?

ie: querying multiple services to gather needed information for the JWT payload before it's issued

[marshallswain]

https://docs.feathersjs.com/guides/auth/recipe.customize-jwt-payload.html

@crobinson42

[CrisLi]

@marshallswain How can add some payloads which come from the query result.

Just like

token: {
    payload: ['email', 'name', 'roles'],
 }

[CrisLi]

Got it

add before hooks

  before: {
    create: [
      auth.hooks.authenticate(['local']),
      (context) => {
        const { params, params: { user = {} } } = context;
        params.payload = {
          id: user['_id'],
          username: user.username,
          org: user.org,
          roles: user.roles
        };
      }
    ]
  }

[RickEyre]

@CrisLi I've done a similar thing in your example, but that's causing my JWT to have the incorrect signature for some reason. Not sure what I'm doing wrong.

[CrisLi]

@RickEyre try to look at my code, it is working fine for me.