chrastecky, 2 months ago

@thomastospace Not a bad solution.

velkuns, 2 months ago

@thomastospace on my side, I store an hash of N last token generated for a user (because they may use many browser / pc.

To validate auth, I check if JWT is valid and if hash is stored.

So when they change the password, I clear the list of hash, then all the existing JWT are considered as unknown.

And can also be used to force "deconnection" from all devices (by clearing the stored hash list).

bhhaskin, 2 months ago

@thomastospace you really shouldn't keep a jwt around forever. You should have a rolling validation.

thomastospace, 2 months ago

@bhhaskin How should we do the rolling validation?

It's part of an API with a front end application. We save the token in local storage of the client.

bhhaskin, 2 months ago

@thomastospace you are checking to make sure the token is valid when talking to the backend right? You reissue a new token when you validate.

alessandrolai, 2 months ago

@bhhaskin @thomastospace i was thinking exactly this. I was thinking that this saves you in the event your secret gets leaked, or any other kind of security incident, like if the token gets stolen the user can be impersonated.

thomastospace, 2 months ago

@bhhaskin But you can't invalidate a single jwt token without storing all of them right?

At least, I assume you want to invalidate the old one when giving out new ones.

larsvanciental, 2 months ago

@thomastospace side note that the T from JWT already stands for token 😅

The idea sounds good for the random value.
It would also work only by looking at the time the token has been issued, and the last time the password was changed, assuming you're using a secret (you should).

thomastospace, 2 months ago

@larsvanciental Lol, guess the 'jwt token' mistake is not uncommon 😂

What do you mean with secret here? The password?

sn0n, 2 months ago

@thomastospace @larsvanciental https://stackoverflow.com/questions/31309759/what-is-secret-key-for-jwt-based-authentication-and-how-to-generate-it has some info, but that's just from a Google search, I know nothing here. Haha

thomastospace, 2 months ago

@sn0n @larsvanciental That's what I found as well, that's already implemented (and the implementation I use wouldn't work without it 😅 ).

larsvanciental, 2 months ago

@thomastospace @sn0n If your secret doesn't leak, you will be the only one able to validate the signature of your JWT, and you should be good 😊

You can read more here https://jwt.io/introduction

thomastospace, 2 months ago

@larsvanciental Ah yes! We use the public/private key pair for that, which is also mentioned on that page. All good!

heiglandreas, 2 months ago

@thomastospace I'd have used the token creation date but I guess a random string is fine as well

thomastospace, 2 months ago

@heiglandreas Oh of course, we could use that as well! So we don't need the random string at all. That's wonderful.

thomastospace, 2 months ago

Note that this is for an API called by a front-end application. So we need some token authentication instead of the regular cookie way.

meuon, 2 months ago

@thomastospace usually API's use something like a simpler "$key" or API Token, that only exists for that API/provider. Do you need to issued a JWT so that other services by other providers can use the same auth?

cut and paste PHP/Curl Example:

curl_setopt($ch, CURLOPT_HTTPHEADER, array('Content-Type: application/json', 'Accept: application/json', "Authorization: Bearer $key"));

thomastospace, 2 months ago

@meuon We mostly chose JWT since the tokens are persistent and we do not need to store them. There's also a lot of resources available, so implementation is easy.

In the curl example, the JWT token would be at $key.

It's for a login for a frontend application, so regular api key + secret is not preferred.