REQ: Helper method to provide direct access to JWT payload

[nathanchase]

What problem does this feature solve?

Instead of making a separate call to an API endpoint for user data, it would be nice to be able to simply access the username that already exists inside the encoded JWT data object.

A simple function like the following (that takes advantage of jwtDecode) would suffice:

function getPayload(token) {
    var payload = null;

    try {
      payload = token ? jwtDecode(token) : null;
    } catch (_) {}

    return payload;
  }

This will provide the JWT's data object, like:

{ 
   username: "JohnDoe",
   scope: "user"
}

What does the proposed changes look like?

Offer a method to access the JWT payload directly

_{This feature request is available on Nuxt community (#c185)}

[jimpsson]

Are you really sure it is a good idea?

As far as I know, the base64 encoded subject, that's baked into every token, should because of security implications only contain as little user information as possible.

The logged in user object gets fetched using the JWT the user got from the login response.

Only user.id or similar should be used as the token subject, because the client side will fetch the rest of the user object from the server and set it in the client. Meaning that your server does the important stuff, and keeping certain operations to the server where it belongs.

You can obviously could do it like you described, but as far as I know, even the JWT spec. says that the base64 decoded data should not be trusted unless you also can verify data using your secret key, but that would mean you've to store secret key information within the browser, and that would be a very bad idea...

[nathanchase]

I have a user ID in the token, but it's a long GUID that's not related to the username.

There's a single unique_name key/value in the token that contains the username. I require that username for the API's user endpoint (it has to request the user at /api/user/{username}). Just hitting /api/user won't work - even if I send it with the Authorization token. It has to have a username.

"The logged in user object gets fetched using the JWT the user got from the login response."

Right - that's what I'm saying - I have to get inside the token to get the username to be able to fetch the user object from the API. My only option is to parse the token server-side which then calls the user endpoint with the correct required username - hence the required use of jwtDecode to get to the "unique_name" value it contains.

[pi0]

Hi. Sorry for short answer it's late night. But the decodeJWT option is coming soon by #192. (Originally implemented by #182)

[pi0]

My only option is to parse the token server-side which then calls the user endpoint with the correct required username - hence the required use of jwtDecode to get to the "unique_name" value it contains.

A serious security note is that you CANNOT TRUST ON JWT WITHOUT CHECKING THE SIGNATURE.

[Prophasi]

Generally I agree with these warnings about verifying JWTs. However, @nathanchase is referring to the client reading claims in the JWT produced by a server-side API, and:

• If the client can't trust what the server hands it, we couldn't use it as an API at all (every call's payload would be suspect)
• To ensure the server's identity, we use SSL/TLS
• Even if the client were given bad data, it can't use it to access protected data, because the server validates the JWT on every authenticated call

Having said that, it's good to know that decodeJWT is on its way.

[timstapl]

@pi0 Is there any update on this issue? it looks like #192 and #182 are both either closed or merged, however I don't see their changes in the current release.

It looks simple enough to implement locally, but I'd prefer to use it baked into the auth-module if possible.