3 ms·

This articles doesn't acknowledge where JWTs really shine: Authentication across a cloud of services, esp. a microservice architecture. JWTs allow a session t

by luhn 10y ago

This articles doesn't acknowledge where JWTs really shine: Authentication across a cloud of services, esp. a microservice architecture. JWTs allow a session to be shared across all of the services without any shared state.

foxbarrington 10y ago
Totally, we started doing that and haven't looked back. Btw, if anyone is looking for an easy way to get going with Node.js check out https://github.com/davidguttman/authentic https://github.com/davidguttman/authentic
joepie91_ 10y ago
I intentionally didn't address this in the article (and went for the "download server" example instead), because there's too much risk of people implementing my (simplified) description verbatim, and ending up with a whole host of security issues. To address your usecase: This is perfectly possible without using JWTs as a session store. Your individual services will be either stateful or stateless. If they are stateless, you can simply use single-use tokens that are issued by the application server, and the entire concept of "sessions" doesn't exist as far as that service is concerned. The only thing it cares about, is whether any particular one operation is authorized. If they are stateful, you can simply maintain a separate session for each of the services. You then use a short-lived JWT token (issued by the application server) to authorize the creation of a session on a non-application-server. The client exchanges this for a session on the non-application-server. This way you essentially get the best of both worlds. Of course that leaves you to still have to implement (relatively complex) revocation infrastructure yourself for the stateful services, but that's inherent to a distributed architecture.
gouggoug 10y ago
It does actually acknowledge it, at the end of the post: "So... what is JWT good for, then?"
ZoFreX 10y ago
Your architecture being microservices doesn't change the problems with using JWTs (or any "session" system based on signing things): you can't revoke them. I am pretty confident being unable to revoke tokens will start to be a problem with any sufficiently large websites: you don't just need to scale in terms of traffic, but also in terms of people doing bad things. If you're at this sort of scale, adding in another service that validates sessions is not a lot of work. Either your microservices that need authentication could have a library added to talk to this service, or you could put everything that needs auth behind something that validates the requests as they come in. Vulcand looks like it makes this easy (I haven't used it personally, but I've worked on a system that works similarly using an F5 device). Sooner or later, you _will_ regret not being able to revoke sessions.
- numbsafari 10y ago
  You can (and should) use a revocation list. This is really no different than doing invalidation/revocation of stored sessions because you have the same job of sending the session/token ID out to all dependencies. But, instead of keeping a giant memory store of all sessions in sync across clusters, you only have to keep a short lived list of revoked tokens. Less noise, less memory, same difference.
  - ZoFreX 10y ago
    Say an account gets hijacked, I want to invalidate all the sessions. How do I do it? I have no list of all the sessions that are currently out there for them. Also: I am thoroughly unconvinced that keeping a short list of data synced across clusters is in any way easier than keeping a long list of data synced across clusters. It has the same performance requirements and the same distributability requirements. Why is this easier?
    - wtbob 10y ago
      > Say an account gets hijacked, I want to invalidate all the sessions. How do I do it? I have no list of all the sessions that are currently out there for them. The revocation list could include entries of the form (revoke-all-tokens-before USER TIMESTAMP). You can also use stateless tokens and store them in a database until they each expire, and then just list all outstanding tokens for the user in your revocation list. Nothing says you can't use a stateless token and store it. > Also: I am thoroughly unconvinced that keeping a short list of data synced across clusters is in any way easier than keeping a long list of data synced across clusters. It has the same performance requirements and the same distributability requirements. Why is this easier? You have to execute your consensus protocol once for each datum synced across the cluster. It's cheaper to run that protocol once each for a short list of items than it is to run it once each for a long list of items. 'Hey everybody, please invalidate the following item, confirm!' once in a blue moon is cheaper than 'hey everybody, someone logged in, confirm!' over and over again.
arnarbi 10y ago
I don't really see what JWT got to do with it. It's just an encoding format, and whether you put session state in the token is orthogonal.

by luhn 10y ago

foxbarrington 10y ago

Totally, we started doing that and haven't looked back. Btw, if anyone is looking for an easy way to get going with Node.js check out https://github.com/davidguttman/authentic https://github.com/davidguttman/authentic

joepie91_ 10y ago

I intentionally didn't address this in the article (and went for the "download server" example instead), because there's too much risk of people implementing my (simplified) description verbatim, and ending up with a whole host of security issues. To address your usecase: This is perfectly possible without using JWTs as a session store. Your individual services will be either stateful or stateless. If they are stateless, you can simply use single-use tokens that are issued by the application server, and the entire concept of "sessions" doesn't exist as far as that service is concerned. The only thing it cares about, is whether any particular one operation is authorized. If they are stateful, you can simply maintain a separate session for each of the services. You then use a short-lived JWT token (issued by the application server) to authorize the creation of a session on a non-application-server. The client exchanges this for a session on the non-application-server. This way you essentially get the best of both worlds. Of course that leaves you to still have to implement (relatively complex) revocation infrastructure yourself for the stateful services, but that's inherent to a distributed architecture.

gouggoug 10y ago

It does actually acknowledge it, at the end of the post: "So... what is JWT good for, then?"

ZoFreX 10y ago

Your architecture being microservices doesn't change the problems with using JWTs (or any "session" system based on signing things): you can't revoke them. I am pretty confident being unable to revoke tokens will start to be a problem with any sufficiently large websites: you don't just need to scale in terms of traffic, but also in terms of people doing bad things. If you're at this sort of scale, adding in another service that validates sessions is not a lot of work. Either your microservices that need authentication could have a library added to talk to this service, or you could put everything that needs auth behind something that validates the requests as they come in. Vulcand looks like it makes this easy (I haven't used it personally, but I've worked on a system that works similarly using an F5 device). Sooner or later, you _will_ regret not being able to revoke sessions.

numbsafari 10y ago
You can (and should) use a revocation list. This is really no different than doing invalidation/revocation of stored sessions because you have the same job of sending the session/token ID out to all dependencies. But, instead of keeping a giant memory store of all sessions in sync across clusters, you only have to keep a short lived list of revoked tokens. Less noise, less memory, same difference.
- ZoFreX 10y ago
  Say an account gets hijacked, I want to invalidate all the sessions. How do I do it? I have no list of all the sessions that are currently out there for them. Also: I am thoroughly unconvinced that keeping a short list of data synced across clusters is in any way easier than keeping a long list of data synced across clusters. It has the same performance requirements and the same distributability requirements. Why is this easier?
  - wtbob 10y ago
    > Say an account gets hijacked, I want to invalidate all the sessions. How do I do it? I have no list of all the sessions that are currently out there for them. The revocation list could include entries of the form (revoke-all-tokens-before USER TIMESTAMP). You can also use stateless tokens and store them in a database until they each expire, and then just list all outstanding tokens for the user in your revocation list. Nothing says you can't use a stateless token and store it. > Also: I am thoroughly unconvinced that keeping a short list of data synced across clusters is in any way easier than keeping a long list of data synced across clusters. It has the same performance requirements and the same distributability requirements. Why is this easier? You have to execute your consensus protocol once for each datum synced across the cluster. It's cheaper to run that protocol once each for a short list of items than it is to run it once each for a long list of items. 'Hey everybody, please invalidate the following item, confirm!' once in a blue moon is cheaper than 'hey everybody, someone logged in, confirm!' over and over again.

arnarbi 10y ago

I don't really see what JWT got to do with it. It's just an encoding format, and whether you put session state in the token is orthogonal.