6 ms·

As a casual reader not familiar with problem of large JWT scopes, I suggest the strength of the argument for this proposal could be improved by explaining exact

by shoo 6y ago

As a casual reader not familiar with problem of large JWT scopes, I suggest the strength of the argument for this proposal could be improved by explaining exactly why larger JWT tokens cause problems in practice, defining some metrics or benchmarks that can be used to measure the impact of the problem, then comparing the proposed solution to the baseline approach using those metrics. E.g. are large JWT tokens bad because they take longer to send? Then compare durations between both implementations. Or are large JWT tokens bad because they exceed some maximum supported token size? Then compare how many scopes are supported by the standard approach and new approach before hitting limit. Another thought: the proposed compression scheme requires that each token producer & consumer needs to depend upon a centralised scope list that defines the single source of truth of which scope is associated with which index for all scopes in the ecosystem. If we assume we've set that up, why not generalise and say the centralised shared scope list is actually a centralised JWT compression standard that defines how to compress and decompress the entire JWT. This could be implemented as something like https://facebook.github.io/zstd/ https://facebook.github.io/zstd/ running in dictionary compression mode, where a custom compression dictionary is created that is good at compressing the expected distribution of possible JWT values. As long as each JWT producer and consumer is using the same version of the centrally managed compression dictionary the compression & decompression could still occur locally. In practise in any given JWT ecosystem perhaps there's a subset of scopes that commonly appear together. If common enough that entire subset of common scopes could be encoded in 1 or 0 bits using a custom compression scheme tuned to the frequency of observed JWT scopes, instead of compressing each scope independently.

rmedaer 6y ago
Hi shoo, thanks for your feedback. At this point in time this is only a proposal. A proposal which needs to be challenged. So thanks again for your useful feedback. Indeed the goal is to limit the size of JWT tokens. I can't tell you if it really improves the performances for now. I already started a spreadsheet to compare the bitmap scope list against the space-separated list. Although I need some real examples and metrics to do a relevant analysis of the impact. One of the questions you raised is about the scopes commonly used. Should we defined a shared dictionary/registry ? Maybe. I would propose to open an issue on Github to discuss about that. Here it is: https://github.com/rmedaer/rmedaer.github.io/issues/2 https://github.com/rmedaer/rmedaer.github.io/issues/2 If there is more interest in this proposal, I would propose to create a dedicated repository where ~~I~~ we could discuss, compare and challenge it. Kind regards,
- magicalhippo 6y ago
  > Indeed the goal is to limit the size of JWT tokens. At work we just implemented some M2M auth using JWT[1]. The other party requires a full certificate chain as our identification and RS256 as algorithm, so our "compact" tokens end up around 8k in size. At least the auth token we get back lasts a couple of minutes. [1]: https://difi.github.io/felleslosninger/maskinporten_protocol_jwtgrant.html https://difi.github.io/felleslosninger/maskinporten_protocol...
  - rmedaer 6y ago
    I see that you have a lot of scopes (https://github.com/difi/felleslosninger/blob/ad9ef79b4fef61f741cdfb296ac5f975167f81bf/_docs/ID-porten/oidc/oidc_protocol_scope.md https://github.com/difi/felleslosninger/blob/ad9ef79b4fef61f...). Especially from 3rd parties (https://integrasjon.difi.no/scopes/all https://integrasjon.difi.no/scopes/all https://integrasjon-ver2.difi.no/scopes/all https://integrasjon-ver2.difi.no/scopes/all) Do you have some statistics about that ? For instance, do you know how many scopes are usually requested, on average ?
    - magicalhippo 6y ago
      Unfortunately not. We're just outsiders, using Maskinporten to get an auth token to be used against the REST API of some other gov't agency. For that we use one of two scopes, prod scope or test scope, as they (the agency we talk to) haven't narrowed it down further yet. But if you're interested maybe try to contact the Difi folks running Maskinporten, from my impression there's a high chance there's someone willing to share there. Maskinporten is being phased in as the primary M2M auth solution for any Norwegian gov't agency, so they're bound to get a lot more "users" (agencies), and hence scopes, going forward.
- tmzt 6y ago
  What about using a .well-known path and standarizing via internet draft heading towards RFC. (Assuming there's even a registry for these paths.) The format could be a simple json file listing supported dictionary items in order grouped by the key used in the JWT json itself. Maybe a special claim could point to the url or use "wk" as a special value to direct it to the .well-known path on the issuer?
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
cbanek 6y ago
Where I work we run JWT, and I've been bitten by the giant JWT tokens all the time. While HTTP doesn't specify a max header length, many implementations insert one along the way. So I've had to find places where nginx is truncating tokens, etc. I think node also has another place you have to set to make sure you can expand the default header length as well.
- eyelidlessness 6y ago
  Wait, nginx just truncates when it reaches its max length, rather than error? Wow that is surprising and dangerous.
to11mtm 6y ago
Practically speaking, you don't want JWTs over around 6 or 7KB unless there's a good reason. The justification for that number is that JWTs may or may not need to be included in headers. More headers may or may not be added if Proxies/LBs/etc are involved between communicating machines. Some webservers have default header limits around 8kb, and that's how we get to this number.

by shoo 6y ago

rmedaer 6y ago

Hi shoo, thanks for your feedback. At this point in time this is only a proposal. A proposal which needs to be challenged. So thanks again for your useful feedback. Indeed the goal is to limit the size of JWT tokens. I can't tell you if it really improves the performances for now. I already started a spreadsheet to compare the bitmap scope list against the space-separated list. Although I need some real examples and metrics to do a relevant analysis of the impact. One of the questions you raised is about the scopes commonly used. Should we defined a shared dictionary/registry ? Maybe. I would propose to open an issue on Github to discuss about that. Here it is: https://github.com/rmedaer/rmedaer.github.io/issues/2 https://github.com/rmedaer/rmedaer.github.io/issues/2 If there is more interest in this proposal, I would propose to create a dedicated repository where ~~I~~ we could discuss, compare and challenge it. Kind regards,

magicalhippo 6y ago
> Indeed the goal is to limit the size of JWT tokens. At work we just implemented some M2M auth using JWT[1]. The other party requires a full certificate chain as our identification and RS256 as algorithm, so our "compact" tokens end up around 8k in size. At least the auth token we get back lasts a couple of minutes. [1]: https://difi.github.io/felleslosninger/maskinporten_protocol_jwtgrant.html https://difi.github.io/felleslosninger/maskinporten_protocol...
- rmedaer 6y ago
  I see that you have a lot of scopes (https://github.com/difi/felleslosninger/blob/ad9ef79b4fef61f741cdfb296ac5f975167f81bf/_docs/ID-porten/oidc/oidc_protocol_scope.md https://github.com/difi/felleslosninger/blob/ad9ef79b4fef61f...). Especially from 3rd parties (https://integrasjon.difi.no/scopes/all https://integrasjon.difi.no/scopes/all https://integrasjon-ver2.difi.no/scopes/all https://integrasjon-ver2.difi.no/scopes/all) Do you have some statistics about that ? For instance, do you know how many scopes are usually requested, on average ?
  - magicalhippo 6y ago
    Unfortunately not. We're just outsiders, using Maskinporten to get an auth token to be used against the REST API of some other gov't agency. For that we use one of two scopes, prod scope or test scope, as they (the agency we talk to) haven't narrowed it down further yet. But if you're interested maybe try to contact the Difi folks running Maskinporten, from my impression there's a high chance there's someone willing to share there. Maskinporten is being phased in as the primary M2M auth solution for any Norwegian gov't agency, so they're bound to get a lot more "users" (agencies), and hence scopes, going forward.
tmzt 6y ago
What about using a .well-known path and standarizing via internet draft heading towards RFC. (Assuming there's even a registry for these paths.) The format could be a simple json file listing supported dictionary items in order grouped by the key used in the JWT json itself. Maybe a special claim could point to the url or use "wk" as a special value to direct it to the .well-known path on the issuer?

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

cbanek 6y ago

Where I work we run JWT, and I've been bitten by the giant JWT tokens all the time. While HTTP doesn't specify a max header length, many implementations insert one along the way. So I've had to find places where nginx is truncating tokens, etc. I think node also has another place you have to set to make sure you can expand the default header length as well.

eyelidlessness 6y ago
Wait, nginx just truncates when it reaches its max length, rather than error? Wow that is surprising and dangerous.

to11mtm 6y ago

Practically speaking, you don't want JWTs over around 6 or 7KB unless there's a good reason. The justification for that number is that JWTs may or may not need to be included in headers. More headers may or may not be added if Proxies/LBs/etc are involved between communicating machines. Some webservers have default header limits around 8kb, and that's how we get to this number.