-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Introduce JwtEncoder #87
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
Introduce JwtEncoder #87
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, @anoopgarlapati! I think @jgrandja may have some additional feedback; I'm just going to leave my feedback as comments for the time being.
* @author Anoop Garlapati | ||
* @since 0.0.1 | ||
*/ | ||
public interface KeyManager { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if this should be called KeyService
. Several other interfaces that retrieve resources in Spring Security are services, like UserDetailsService
, OAuth2UserService
, AclService
, etc.
return this.headers; | ||
} | ||
|
||
public String getHeaderAsString(String header) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I realize that these are following the JwtClaimAccessor
pattern; however, I think that it's better to coerce the values to the correct type on write instead of converting them on each read.
Further, I think the JwtClaimAccessor
makes a bit more sense when we are reading a JWT that another library has deserialized and chosen the types for each claim. Since we are the ones serializing in this case, I'm not seeing a huge need for these converters.
Is there any reason that we can't just have one method for now:
public <H> H getHeader(String name) {
return (H) this.headers.get(name)
}
and add the others later on, if needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that since we are the ones serializing we might not need converters. I will simplify this in my next draft.
} | ||
|
||
public NimbusJwtEncoder build() { | ||
Key key = keyManager.getActiveKey(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will getActiveKey
guarantee non-null or should there also be an exception here to indicate that no key was returned? One way to address this would be to change the existing exception message from "Unsupported key provided." to "No supported key provided".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll add an exception here if a key is not returned and also will change the message.
} else if (X5C.equals(name)) { | ||
jwsHeaderBuilder = jwsHeaderBuilder.x509CertChain( | ||
X509CertChainUtils.toBase64List(JSONArrayUtils.parse(headers.getHeaderAsString(X5C)))); | ||
} else if (KID.equals(name)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How would the caller know this? It seems intrinsically tied to which key is used.
} | ||
|
||
public NimbusJwtEncoder build() { | ||
Key key = keyManager.getActiveKey(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the build
method the right place to get the key? I'm thinking about key rotation.
It makes me wonder if the KeyManager
should be in the NimbusJwtEncoder
constructor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I missed this use-case. Yes, we do need to have KeyManager
in the NimbusJwtEncoder
and fetch the active key to create the signer before signing the JWT. I'll make the appropriate changes in the next draft.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think it would be worth trying to find a key from the manager that works with the selected algorithm?
ClaimConversionService.getSharedInstance().convert(getHeaders().get(header), Boolean.class); | ||
} | ||
|
||
private Boolean containsHeader(String header) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this ever be null? Does it have to be a Boolean
?
|
||
public Builder(JwtClaimsSet jwtClaimsSet) { | ||
Assert.notNull(jwtClaimsSet, "jwtClaimsSet cannot be null"); | ||
this.claims = jwtClaimsSet.claims; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
claims
is an unmodifiable map, you should add all its entries to this.claims
instead.
// Parse optional and custom header parameters | ||
Map<String, Object> headersMap = headers.getHeaders(); | ||
try { | ||
for (final String name: headersMap.keySet()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if copying the map and getting each known key via remove
, then only looping over the rest (the custom params) would be a bit nicer.
But if you do it in a loop, IMO you should loop over the entrySet()
to avoid having to get the values separately for the keys you find, and perhaps a switch
would be a little nicer than an if
with this many branches.
return jwsHeaderBuilder.build(); | ||
} | ||
|
||
private JWTClaimsSet createJwtClaimsSet(JwtClaimsSet claimsSet) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This JWTClaimsSet
vs JwtClaimsSet
is a little confusing, it might be a good idea to write out the package name for one of them for clarity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that the client needs this functionality as well, should this go into spring-security-oauth2-jose? Or are the two codebases going to be separate?
@krajcsovszkig-ms Thanks for the review comments. I am close to revising my draft. This is something brought to my attention by @jgrandja as well. I am refactoring the relevant classes into the spring-security-oauth2-jose package in my next draft so that they can be extracted and merged into spring-security seamlessly. |
@anoopgarlapati great, thanks for your work on this! |
Hi @anoopgarlapati , are there any updates on this PR? Do you have an approximate ETA for when it will be ready? Thanks! |
@krajcsovszkig-ms Unfortunately due to my work related project I will not be able to meet the timeline for this task. I have discussed this with @jgrandja and he will be taking this task forward. |
Thanks for getting back! @jgrandja do you have an approximate timeline for this task? Let me know if I can help to move it forward. |
@krajcsovszkig-ms I'll be working on it this week and next week. My goal is to have this merged later next week. |
That's great, thanks! |
Closing in favour of #96 |
Issue gh-81
Implementation Requirements