Open jgrandja opened 7 years ago
Related #4434
This is by no means production-ready but i created a small PoC gist how one could use nimbus jose jwt for doing encryption/decryption on JWTs issued by the spring authorization server. Basically just inherting from JwtAccessTokenConverter and overrode the encode & decode methods. Signing / Signature Verification is still done by Spring, the current implementation just parses the (encoded) output of the upstream encode method (which obviously is detrimental to performance) as a SignetJWT and encrypts it.
https://gist.github.com/salgmachine/352799a6052b02901982dcbf85d30346
is there any concrete timeline on when to expect official JWE support through spring security?
@salgmachine Thanks for the sample!
Our plan is to start work on the Authorization Server sometime early-mid 2019 with the plan on introducing support in 5.3. I'm not sure if JWE will be supported in the initial release though. We still need to plan the MVP for Authorization Server.
However, we are targeting 5.2 for JWE support on the Resource Server side. This issue addresses that feature so you can keep track of progress here.
Any update on this issue? We are very anxious to start working with JWE instead of rolling our own. Does this also deal with publishing a JWKS from Spring so we can implement this in our Authentication Service?
@svanschooten Not yet. We're trying to get this into 5.2 but we're working on other priorities at the moment.
Does this also deal with publishing a JWKS
No. Jwk is not related to this issue. That would be an Authorization Server feature.
@salgmachine @svanschooten What is the authorization server you are using that issues encrypted JWTs? Or are you planning on rolling your own? (Note that this ticket is Resource Server-focused)
@jzheaux For the PoC I just used a spring oauth2 auth server with a custom JwtAccessTokenConverter (I think .. been some time since I did this) I'm not planning to use this in production, was really more of a "what would it take" kind of thing, I'd rather delegate this stuff to the framework when it becomes available :)
@jgrandja, @jzheaux We are using Ping Federate for our authentication federation, creating a singular token for multiple login types such as EHerkenning (Dutch login method based on your bsn/ssn for government linked companies), Azure AD and a local database.
The resource server has to either: A) Be able to serve a JWKS so the AS can get the public key and encrypt, so the RS can decrypt B) Be able to consume a configured key/certificate so it can decrypt the token
@jgrandja
No. Jwk is not related to this issue. That would be an Authorization Server feature
Why exactly? If the Resource Server wants to be able to decrypt the tokens it needs the private key, so it should publish the public key for the Authentication Server to use, right?
@svanschooten
If the Resource Server wants to be able to decrypt the tokens it needs the private key, so it should publish the public key for the Authentication Server to use, right?
Yes this makes sense. This is an interesting use case and we would like to learn more. Quite honestly, we've been struggling finding use cases for JWE. From our initial research so far, it doesn't seem to be widely used so we're debating on bringing in this support for 5.2 until it's more widely adopted as JWS is.
Can you point us to the PingFederate docs or any other references that can help us understand this use case further or any other use cases around JWE?
@jgrandja I agree, most of the webtoken standard is defined to have easily inspectable tokens containing non-private information. But since we are dealing with some quasi-sensitive information (such as a ssn/bsn pseudonym) we do not want to minimize the information leakage. Adoption is very sparse, since most secure platforms roll their own secure data channel (either encrypted in a token or through backchannels).
As for the ping federate documentation, that is very sparse, though in the token settings I can set a JWKS uri for JWE, so I guess they adhere to RFC7516? Otherwise this link is the most of their documentation on JWE itself.
If you need any help, I would be happy to assist if I can!
After some research, I've only found one authorization server that supports JWE, which is PingIdentity.
Additionally, numerous common authorization servers have little to no support for JWE and some have indicated that they have no plans for it either.
Until we have two mainstream authorization servers that implement JWE, it'll be challenging to confirm that we've got our implementation correct.
As such, for the time being, I've added a sample that demonstrates how to configure Spring Security Resource Server for JWE.
In the meantime, is there a second mainstream authorization server that supports JWE?
Hello - There is another IdP that supports JWE ( they suggest using JWE ). The IdP in question is NetIQ access manager, here is the relevant info:
Are there any current plans for supporting JWE? Thanks!
We should provide support for encrypting / decrypting the claims set of a JWE (JSON Web Encryption).