Skip to content

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

Conversation

anoopgarlapati
Copy link
Contributor

Issue gh-81

Implementation Requirements

  • define interface JwtEncoder
  • provide an implementation of JwtEncoder - NimbusJwtEncoder NOTE: The implementation should use the Nimbus JOSE + JWT library
  • the NimbusJwtEncoder should have a Builder
  • the NimbusJwtEncoder should support HS256 (HMAC using SHA-256)
  • the NimbusJwtEncoder should support RS256 (RSASSA-PKCS1-v1_5 using SHA-256)
  • the NimbusJwtEncoder should have a "KeyManager" that provides the public/private/symmetric keys (also required by Implement JWK Set Endpoint #82)
  • the NimbusJwtEncoder should be used by OAuth2AuthorizationCodeAuthenticationProvider Implement authorization_code AuthenticationProvider #68 to produce a JWS
  • javadoc class and public methods
  • Unit tests

Copy link
Contributor

@jzheaux jzheaux left a 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 {
Copy link
Contributor

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) {
Copy link
Contributor

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?

Copy link
Contributor Author

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();
Copy link
Contributor

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".

Copy link
Contributor Author

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)) {
Copy link
Contributor

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();
Copy link
Contributor

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.

Copy link
Contributor Author

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.

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?

@jgrandja jgrandja added the type: enhancement A general enhancement label Jun 11, 2020
@jgrandja jgrandja added this to the 0.0.1 milestone Jun 11, 2020
@jgrandja jgrandja self-assigned this Jun 11, 2020
ClaimConversionService.getSharedInstance().convert(getHeaders().get(header), Boolean.class);
}

private Boolean containsHeader(String header) {

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;

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()) {

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) {

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.

Copy link

@krajcsovszkig-ms krajcsovszkig-ms left a 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?

@anoopgarlapati
Copy link
Contributor Author

anoopgarlapati commented Jun 30, 2020

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.

@krajcsovszkig-ms
Copy link

@anoopgarlapati great, thanks for your work on this!

@krajcsovszkig-ms
Copy link

Hi @anoopgarlapati , are there any updates on this PR? Do you have an approximate ETA for when it will be ready?

Thanks!

@anoopgarlapati
Copy link
Contributor Author

@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.

@krajcsovszkig-ms
Copy link

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.

@jgrandja
Copy link
Collaborator

@krajcsovszkig-ms I'll be working on it this week and next week. My goal is to have this merged later next week.

@krajcsovszkig-ms
Copy link

That's great, thanks!

@jgrandja
Copy link
Collaborator

Closing in favour of #96

@jgrandja jgrandja closed this Jul 22, 2020
@jgrandja jgrandja removed this from the 0.0.1 milestone Jul 22, 2020
@jgrandja jgrandja added the status: duplicate A duplicate of another issue label Jul 22, 2020
@anoopgarlapati anoopgarlapati deleted the gh-81-jwt-encoder branch October 24, 2020 23:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: duplicate A duplicate of another issue type: enhancement A general enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants