-
Notifications
You must be signed in to change notification settings - Fork 128
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
Token Propagation and OpenID "azp" claim validation issues #1543
Comments
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. |
…laim validation Temporal workaround suggested in (micronaut-projects/micronaut-security#1543)
Temporal workaround suggested in (micronaut-projects/micronaut-security#1543)
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 @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! |
…alidator Temporal workaround suggested in (micronaut-projects/micronaut-security#1543)
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.
The text was updated successfully, but these errors were encountered: