JWT handling

[hotab]

It looks like JWTs are somewhat-mishandled by the library.

After generating the JWT, it is stored exactly as-is in the database, and then checked by loading them from the database. This limits their use. Consider the following scenario:

Server A and Server B both issue tokens. Server B (our server) wants to accept both tokens issued by Server A and itself. The admin might want to use JWTs to resolve that. Server A issues the token, but then our server won't be able to accept it, even though it will be a valid JWT.

That aside, one of the biggest upsides of JWT is simplified token storage - the server now can be relieved of this burden, which is, again, limited in this case.

The correct behavior should be storing a token id inside the token itself, and then allowing a blacklist based on token ids.
One possible approach (Auth0): https://auth0.com/blog/blacklist-json-web-token-api-keys/

[ThundR67]

Yes, the point of JWT is to not store it in a DB, therefore, the library should at least give you options of not storing JWT.

[mikepc]

The main idea behind a Bearer token is that the client holds the authorization. There is no reason that the server should store this whatsoever. As long as server A and server B are using the same encryption secret, both servers (regardless of language, OS, whatever) should be able to decode the and validate the token.

The most important part about this is that in a scenario where you are going client -> service -> service -> service , each service can retain this bearer token through the entire call process so the same authorization logic applies across the board.

I have absolutely no idea why you would ever want to database the JWT. I can see databasing the access_token property so that you can validate the JWT against an authorization server, or the refresh_token to re-issue a new JWT before the old one expires. But that's about it.