-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow application to accept JWS and JWE tokens #290
Comments
Another breaking change that is needed to make use of the spec in all situations. |
I do not think it is a good idea. It is mostly a theoretical argument IMHO. That would mean that either of the applications can accept both the encrypted and signed or signed only tokens at the same time. But as I said earlier I don't think this represents a realistic security policy requirement. |
My concern is we can easily slip into supporting a totally dynamic token decryption/verification process, as I've already said, the headers may have all the data including the inlined JWKs - why not support the token decryption with the private key included in the headers - this will be a step backwards. |
@rdebusscher Another likely problem with it is that it will have a performance impact, the implementations will have to do the first round of parsing by checking if it is a JWS or JWE sequence. If it is a JWE sequence, they'd have to parse the decrypted sequence and check if it is JWS. I doubt support of this kind of dynamics is needed. But indeed, lets review it for 3.0 |
Currently, when the property
mp.jwt.decrypt.key.location
is specified, signed tokens must be rejected. But this means that a service that is part of two or more applications, a basic concept of a microservice architecture, that has different token schemas can't function properly. (now you need to duplicate the service with a different configuration)The text was updated successfully, but these errors were encountered: