Allow application to accept JWS and JWE tokens

[rdebusscher]

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)

[rdebusscher]

Another breaking change that is needed to make use of the spec in all situations.

[sberyozkin]

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.

[sberyozkin]

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. Lets review this task for MP JWT 3.0

[sberyozkin]

@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