You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a project I'm working on we are using custom claims and JWT in our solution. We've encoded group membership in a custom top-level claim called "principals". This custom claim can be of some size and when it's automatically mirrored back to the ext structure the JWT get twice as big. Eventually the situation popped up where the size of the JWT was to big for browsers (4096-4097 byte limit usually) to transfer to the back end. As a result of this the JWT get partially transfered and the receiving backend is unable to validate and decode the token.
Describe your ideal solution
An ideal solution would be to introduce another configuration flag for hydra, which allows us to disable / enable this custom claim mirroring functionality.
A configuration flag for allowing custom top level claims already exist: oauth2.allowed_top_level_claims , adding another flag oauth2.mirror_top_level_claims: true / false (default: true) would enable us to reduce the size of the JWT token. This won't solve our issue permanently, but at least it would reduce the chance of it ever occuring. Accodring to #1974 this mirroring functionality is supposed to be a temporary solution to maintain backward compability. This suggested solution won't remove this backward compability, only allow users to disable it if wanted (default enabled).
Workarounds or alternatives
A alternative solution for us is forking hydra and adding this functionality to our fork. We really don't want to maintain our own fork, so having this functionality in upstream sources would be preferable for us.
Version
v1.10.5
Additional Context
No response
The text was updated successfully, but these errors were encountered:
I'm currently evaluating ory/hydra for our use-case. The only roadblock thus far is, that the mirroring of jwt claims blows up our already big jwts even further. Would a PR that introduces this config (mirror_top_level_claims) have any chance?
I've created the PR. It's closely aligned to what @tlyng did, but updates all snapshots and tests for it. I was not able to join slack (I never got the invite). Could I get another invite to further discuss the PR there?
Preflight checklist
Describe your problem
In a project I'm working on we are using custom claims and JWT in our solution. We've encoded group membership in a custom top-level claim called "principals". This custom claim can be of some size and when it's automatically mirrored back to the
ext
structure the JWT get twice as big. Eventually the situation popped up where the size of the JWT was to big for browsers (4096-4097 byte limit usually) to transfer to the back end. As a result of this the JWT get partially transfered and the receiving backend is unable to validate and decode the token.Describe your ideal solution
An ideal solution would be to introduce another configuration flag for hydra, which allows us to disable / enable this custom claim mirroring functionality.
A configuration flag for allowing custom top level claims already exist:
oauth2.allowed_top_level_claims
, adding another flagoauth2.mirror_top_level_claims: true / false (default: true)
would enable us to reduce the size of the JWT token. This won't solve our issue permanently, but at least it would reduce the chance of it ever occuring. Accodring to #1974 this mirroring functionality is supposed to be a temporary solution to maintain backward compability. This suggested solution won't remove this backward compability, only allow users to disable it if wanted (default enabled).Workarounds or alternatives
A alternative solution for us is forking hydra and adding this functionality to our fork. We really don't want to maintain our own fork, so having this functionality in upstream sources would be preferable for us.
Version
v1.10.5
Additional Context
No response
The text was updated successfully, but these errors were encountered: