3 ms·

Right. You can't logout, and you can't extend the expiration time without the user granting an "offline access" scope during the login process. So WHY exactly

Right. You can't logout, and you can't extend the expiration time without the user granting an "offline access" scope during the login process. So WHY exactly is this better than a simple distributed session store (e.g. Redis or whatever), with a browser header or signed cookie as the cache key? That's the underlying premise of all this recent discussion that eludes me. It seems an argument could certainly be made that you don't need to use sessions if you don't need sessions. But you kinda DO need sessions if you do need sessions. I think all of these recent blogs hand-wave over that, and much of the recent "JWT instead of sessions" chatter is people just repeating a mantra that they read in blog posts because it seems like the hot new mantra.

stephenhuey 10y ago
Another benefit is providing a standard way to access multiple services at once with a single token. It is possible to force a logout on the server side if a problem arises, and you wouldn't need to store these invalidated tokens in the database because it'd likely be a small blacklist you make available to all the servers (and a blacklisted token would be in that list only until the expiration time).
- StevePerkins 10y ago
  > access multiple services at once with a single token If you're talking about multiple microservices under your own control, then they could all work with your distributed session store just as easily (if not more so). If you're talking about SSO across multiple third-party services, then perhaps JWT could be a nicer solution than SAML. However, here you're talking about a single-digit percentage of edge cases. Not enough to declare "JWT over sessions" as a general rule.
jayd16 10y ago
I think your issue is that you're trying to wrap Google's auth in your own jwt implementation. This setup can only prove your own trust of the tokens you create. You can have a user auth with google and provide you a user id, you can then slap that id into a token and know that you gave that token to the right user and the info inside that token is what you put there. It does NOT let you keep other sessions alive on its own. You won't be able to get around Google's expiry this way if you need a valid auth to Google's APIs. What it does do is let you auth a user through google once at the beginning of your own app's session, and not have to keep track of session in your own database or hit google multiple times in a user session.

stephenhuey 10y ago

Another benefit is providing a standard way to access multiple services at once with a single token. It is possible to force a logout on the server side if a problem arises, and you wouldn't need to store these invalidated tokens in the database because it'd likely be a small blacklist you make available to all the servers (and a blacklisted token would be in that list only until the expiration time).

StevePerkins 10y ago
> access multiple services at once with a single token If you're talking about multiple microservices under your own control, then they could all work with your distributed session store just as easily (if not more so). If you're talking about SSO across multiple third-party services, then perhaps JWT could be a nicer solution than SAML. However, here you're talking about a single-digit percentage of edge cases. Not enough to declare "JWT over sessions" as a general rule.

jayd16 10y ago

I think your issue is that you're trying to wrap Google's auth in your own jwt implementation. This setup can only prove your own trust of the tokens you create. You can have a user auth with google and provide you a user id, you can then slap that id into a token and know that you gave that token to the right user and the info inside that token is what you put there. It does NOT let you keep other sessions alive on its own. You won't be able to get around Google's expiry this way if you need a valid auth to Google's APIs. What it does do is let you auth a user through google once at the beginning of your own app's session, and not have to keep track of session in your own database or hit google multiple times in a user session.