Should I return user data in an authentication endpoint using JWT?

Question

I implement an auth endpoint which takes an email and password and returns a JWT token. Inside the JWT there is a payload containing the user ID. Does it matter from a REST/JWT standards perspective which of these approaches I take?

1. return the token and let the client request the /users/user_id resource on a callback with the decoded user_id and the token
2. return the entire user object with the token from the /auth endpoint for the convenience of the client.

(my question is implementation/library agnostic and about the api-design pattern)

Answer 1

Yes/No.

End points are functions. From this perspective it doesn't matter what they do as long as the client is aware that this is what will happen, and is happy to deal with the output/outcomes.

So if you write the only client and you have a sequence of six operations that are called in a row, it might make sense to collapse them down into a single call that does it all.

But if you don't write the only client, then there is a good chance that such complex endpoints will make life harder for them. It would be like trying to get a paper and having to verify that you have medical insurance. Its better to have smaller concise operations to allow these other clients to pick and choose how and when.

A middle ground is to offer a small variety of common chains by opt in.

• /auth -> just the JWT token
• /auth?include=user -> JWT token + user details please

---

As for REST, then yes it matters a lot.

The two graces of REST are that the server doesn't have to keep connection state, and that intermediaries can cache the result to distribute to their audience to reduce overall load on the server.

JWT tokens don't fit in this model. You don't want them cached, you don't want them shared.

Other data though might be perfectly fine to cache. Perhaps not confidential user data, but if those details were public user information it would be fine.

Mixing the two types eliminates one of the benefits from a REST system. Not the end of the world, but if you are trying to get the scalability it is an anti-pattern.

Answer 2

If you really want to follow a REST pattern, you should only return the user ID and then have the client request user data in a separate endpoint (every endpoint is responsible for one thing only). This could potentially be tedious/annoying for the client depending on the use case.

If you think that every time the user will want/need their own information after they authenticate, then you might as well just return that info with the authorization call.

For my own applications, I typically just return user info during authentication for convenience and one less call to the server.