6 ms·
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, u
by 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 agoYeah 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.