Expected Behavior
NimbusReactiveJwtDecoder should support converting the claim set in a reactive way.
Current Behavior
NimbusReactiveJwtDecoder only supports configuring a blocking/imperative claim set converter (added with #6080).
Context
We use a Spring Cloud Gateway that acts as an OAuth 2 resource server and validates JWTs issued by multiple different authorization servers.
One of these authorization servers issues tokens for which we need to pre-process the claims with information that is not statically available (one of the claims represents an ID that we need to look up in a different system first, and use the response to create additional claims).
Thus, we'd expect something like this in NimbusReactiveJwtDecoder:
public void setReactiveClaimSetConverter(Converter<Map<String, Object>, Mono<Map<String, Object>>> reactiveClaimSetConverter) {
Assert.notNull(reactiveClaimSetConverter, "reactiveClaimSetConvertercannot be null");
this.reactiveClaimSetConverter = reactiveClaimSetConverterSetConverter;
}
Of course the logic in
|
private Jwt createJwt(JWT parsedJwt, JWTClaimsSet jwtClaimsSet) { |
|
try { |
|
Map<String, Object> headers = new LinkedHashMap<>(parsedJwt.getHeader().toJSONObject()); |
|
Map<String, Object> claims = this.claimSetConverter.convert(jwtClaimsSet.getClaims()); |
|
return Jwt.withTokenValue(parsedJwt.getParsedString()) |
|
.headers((h) -> h.putAll(headers)) |
|
.claims((c) -> c.putAll(claims)) |
|
.build(); |
|
} |
|
catch (Exception ex) { |
|
throw new BadJwtException("An error occurred while attempting to decode the Jwt: " + ex.getMessage(), ex); |
|
} |
|
} |
would have to be refactored to perform the conversion in a reactive way.
What do you think?
Expected Behavior
NimbusReactiveJwtDecodershould support converting the claim set in a reactive way.Current Behavior
NimbusReactiveJwtDecoderonly supports configuring a blocking/imperative claim set converter (added with #6080).Context
We use a Spring Cloud Gateway that acts as an OAuth 2 resource server and validates JWTs issued by multiple different authorization servers.
One of these authorization servers issues tokens for which we need to pre-process the claims with information that is not statically available (one of the claims represents an ID that we need to look up in a different system first, and use the response to create additional claims).
Thus, we'd expect something like this in
NimbusReactiveJwtDecoder:Of course the logic in
spring-security/oauth2/oauth2-jose/src/main/java/org/springframework/security/oauth2/jwt/NimbusReactiveJwtDecoder.java
Lines 182 to 194 in 53bc6a7
What do you think?