3 ms·

The moment you have a centralized xxx, you need a distributed DB, your use of JWT has become pointless and you can just go back to sessions without all the comp

by jiofih 6y ago

The moment you have a centralized xxx, you need a distributed DB, your use of JWT has become pointless and you can just go back to sessions without all the complexity. This is why you can’t have a blacklist of manually expired tokens, one of the most commonly raised issues in JWT.

shoo 6y ago
I agree that adding new dependencies on external central services, or things that need to be centrally coordinated, is something we'd generally want to avoid, unless adding the dependencies gives us a lot of value in excess of the costs. But, isn't there's a difference between needing to centrally coordinate a common protocol vs central management of state of individual tokens? JWT protocol itself can be regarded as some centralised definition of how different services agree to interoperate with JWT tokens, that all token producers and consumers must implement. It doesn't logically follow that we need a distributed DB that must be queried at runtime when processing tokens to implement JWT support. Similarly for nonstandard variations on JWT protocol that are independent of the state stored in any given token -- all services would need to embed some library that can understand the new (centrally defined) protocol, but there would not need to be any dependency on an external database at runtime. Even with standard usage of JWT tokens, does there not need to be some degree of agreement and coordination between token producers about what a particular scope string means & agreement between different services in the same ecosystem not to use the same scope string to mean two completely different things?
- rmedaer 6y ago
  > need to be some degree of agreement and coordination between token producers about what a particular scope string means & agreement between different services (...) I agree with you on this point. Actually there are already some "common" scopes, for instance OpenID Connect defines some scopes ("openid", "profile", "email", ...): https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims https://openid.net/specs/openid-connect-core-1_0.html#ScopeC... However I don't think (to be confirmed) there is a IANA registry for scopes (source: https://www.iana.org/protocols https://www.iana.org/protocols) But there is one for claims in JWT: https://www.iana.org/assignments/jwt/jwt.xhtml#claims https://www.iana.org/assignments/jwt/jwt.xhtml#claims
- Peeda 6y ago
  Yeah the centralized protocol should be easy to manage because it's largely static. I'd add a b_scope_ver type field. As scopes are added it gets incremented. A static doc describing the version can be fetched and cached permanently on demand when a new version is seen, maybe. Can even serve the static docs out of s3 even.
aasasd 6y ago
A common protocol is more like code being deployed, not data. Even though there are gradations in how much you do of one versus the other, and you can ship code as data in the db—you don't have to do that.

by jiofih 6y ago

shoo 6y ago

I agree that adding new dependencies on external central services, or things that need to be centrally coordinated, is something we'd generally want to avoid, unless adding the dependencies gives us a lot of value in excess of the costs. But, isn't there's a difference between needing to centrally coordinate a common protocol vs central management of state of individual tokens? JWT protocol itself can be regarded as some centralised definition of how different services agree to interoperate with JWT tokens, that all token producers and consumers must implement. It doesn't logically follow that we need a distributed DB that must be queried at runtime when processing tokens to implement JWT support. Similarly for nonstandard variations on JWT protocol that are independent of the state stored in any given token -- all services would need to embed some library that can understand the new (centrally defined) protocol, but there would not need to be any dependency on an external database at runtime. Even with standard usage of JWT tokens, does there not need to be some degree of agreement and coordination between token producers about what a particular scope string means & agreement between different services in the same ecosystem not to use the same scope string to mean two completely different things?

rmedaer 6y ago
> need to be some degree of agreement and coordination between token producers about what a particular scope string means & agreement between different services (...) I agree with you on this point. Actually there are already some "common" scopes, for instance OpenID Connect defines some scopes ("openid", "profile", "email", ...): https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims https://openid.net/specs/openid-connect-core-1_0.html#ScopeC... However I don't think (to be confirmed) there is a IANA registry for scopes (source: https://www.iana.org/protocols https://www.iana.org/protocols) But there is one for claims in JWT: https://www.iana.org/assignments/jwt/jwt.xhtml#claims https://www.iana.org/assignments/jwt/jwt.xhtml#claims
Peeda 6y ago
Yeah the centralized protocol should be easy to manage because it's largely static. I'd add a b_scope_ver type field. As scopes are added it gets incremented. A static doc describing the version can be fetched and cached permanently on demand when a new version is seen, maybe. Can even serve the static docs out of s3 even.

aasasd 6y ago

A common protocol is more like code being deployed, not data. Even though there are gradations in how much you do of one versus the other, and you can ship code as data in the db—you don't have to do that.