I am using Identity server to implement a centralized authentication/login service for all our internal applications and I need to encrypt jwt claims (such as authorization information). System.IdentityModel.Tokens.Jwt 1.5.3 and later versions supports encrypted tokens and I know I can do it myself by implementing custome TokenCreationService and TokenValidator classes
But I don't prefer to maintain those classes while using future versions of IdentityServer and I believe other users may also need to encrypt jwt claims for their projects.
It would be nice that IdentityServer4 has a built-in support for token payload encryption.
<log goes here>
What do you want to encrypt? id_tokens or access_tokens? And why?
@leastprivilege I want to be able to encrypt both id_tokens and access_tokens. I want to pass claims(userId, authorization ifnormation type of things) in jwt tokens between applications but I don't want clientapp/people who has the token to read my claims, at least I don't want them to read the claims easily.
Did you look into reference tokens?
IMO encrypting id_tokens does not make a lot of sense unless you want to hide information from end user (but the id_token is about the end user in essence).
Encrypting access tokens - can make sense - but requires extra key management - reference tokens seem easier here with same effect.
I don't want to make an extra network call to the identity server for every request to read claims, or call identity server once and store that claims on a distributed cache etc.
Even those claims that I want to encrypt aren't very sensitive information, I don't want to give any information to someone else to understand my business flow, or to have a data privacy risk etc.
On the other hand token encryption is not an idea that comes to my mind. There is already a proposed JWE standart (https://tools.ietf.org/html/rfc7516) for that and it is already implemented at System.IdentityModel.Tokens.Jwt so why not at IdentityServer?
Yes, extra key management is required but I don't think it would be a problem.
@alpersogukpinar Maybe you can create custom claim that extends default JWT claims and put your extra data in it. You can encrypt it, encode to base64 and put it to custom claim on IdentityServer side and extract and decrypt it on other side (API). On other side (API) you will exctract your payload from custom claim, decode it and do whatever you want (as example - you may assign decoded claims to user context). So you no need to change something inside IdentityServer. Just override some services to add some custom logic.
It really simple.
If you payload is too big and you will use implicit oauth flow - you should use reference tokens, because browsers has limits for url length. If your token will be too big - it may not fit whole in url. Url length depends on browsers versions that you will support.
One thing that you should do by yourself - is key management for encryption and decryption on both sides. I think DPAPI is the best choice for this.
P.S. - sorry for my English) I just want to help))
I think this is a fair question, Why JWE is not supported ?
Using encrypted claims is not the right answer.
Can you please let us know if there is a plan to support JWE
It's on our todo list. You can do it easily yourself today by replacing the token creation service.
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Most helpful comment
I think this is a fair question, Why JWE is not supported ?
Using encrypted claims is not the right answer.
Can you please let us know if there is a plan to support JWE