Open ArnauAregall opened 10 months ago
Thanks for the detailed issue report. I need to check it further. However, I recommend you not turn off the whole idtoken validator.
Instead, you can do a Bean Replacement and override the method causing issues.
@Singleton
@Replaces(IdTokenClaimsValidator.class)
public class IdTokenClaimsValidatorReplacement extends IdTokenClaimsValidator {
@Override
protected boolean validateAzp(@NonNull Claims claims,
@NonNull String clientId,
@NonNull List<String> audiences) {
// do custom logic
}
}
Thanks for your answer @sdelamo, I'll try the custom bean replacement approach and get back with feedback.
Hello @sdelamo, I confirm the suggested bean replacement approach suits as temporal workaround for my issue.
Here is the aforementioned example but with Kotlin that worked fine for me with the custom azp
claim validation.
@Singleton
@Replaces(IdTokenClaimsValidator::class)
class CustomIdTokenClaimsValidator<T>(oauthClientConfigurations: Collection<OauthClientConfiguration>): IdTokenClaimsValidator<T>(oauthClientConfigurations) {
override fun validateAzp(claims: Claims, clientId: String, audiences: MutableList<String>): Boolean {
if (audiences.size < 2) {
return true
}
return parseAzpClaim(claims)
.filter { clientId.equals(it, ignoreCase = true) || audiences.containsIgnoreCase(it) }
.isPresent
}
}
private fun List<String>.containsIgnoreCase(element: String): Boolean {
return this.any { it.equals(element, ignoreCase = true) }
}
Thanks again for your answer!
Issue description
Hello,
I have a use case where two Micronaut services are secured using OpenID (
idtoken
) with an OAuth2 issuer (Keycloak) within the same realm.Each service is configured to use it's own realm client.
At application level, one service calls the other using HTTP client interfaces, using JWT Token Propagation feature.
identity-service:
pet-service (calls
identity-service
):The OAuth clients have configured scopes so the
aud
claims of the JWT token contains the twoclient-id
s.Example decoded JWT payload:
The issue I'm experiencing is the following:
The Authorized Party claim (
azp
) of the token is thepet-service
, and whenpet-service
performs the authenticated HTTP call toidentity-service
endpoints using the Token Propagation feature,identity-service
runs theio.micronaut.security.oauth2.client.IdTokenClaimsValidator
and fails at thevalidateAzp
step, even though the audiences validation is successful.I've verified that disabling
openid
claims validation onidentity-service
via configuration is a bypass to the issue.I have also noticed recent clarifications in regards to
azp
were added to OpenID specs, and if I got it right theazp
should only be validated when using extensions beyond the scope of the spec.As framework core committers, which approach would you recommend to solve this issue?
Do you believe
IdTokenClaimsValidator#validateAzp
should be revisited after OpenID spec clarifications perhaps?Thanks a lot in advance. Arnau.