Skip to content
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

Verify azp claim #355

Open
manjinder-mckc opened this issue Oct 21, 2022 · 5 comments
Open

Verify azp claim #355

manjinder-mckc opened this issue Oct 21, 2022 · 5 comments

Comments

@manjinder-mckc
Copy link

manjinder-mckc commented Oct 21, 2022

Is there a specific reason, verifier does not support verifying azp claim? It could be possible for some scenarios that client is explicitly required to verify that azp claim matches ClientID. Can we add support for verifying that by any chance, it does not have to be enforced and can be optional (via verifier config) to satisfy certain use cases for say custom providers.

@ericchiang
Copy link
Collaborator

There's not a strong reason. I've only seen azp used in relatively niche scenarios where you still want to verify the audience rather than authorizing party.

Do you have a use case in mind? What's the desired security outcome?

@manjinder-mckc
Copy link
Author

We have a custom Identity Provider, that for some reason supports other entities as ‘aud’ rather than ClientID, and the authorized party sends ClientID as part of ‘azp’ in the token, and requires us to validate that instead of aud.

I understand that perhaps this not a very common use case, but hoping it can still be beneficial to others. If we can provide optional config attribute to validate ‘azp’ to match ClientID.

@ericchiang
Copy link
Collaborator

Today you can pull the 'azp' claim out of the IDToken with the Claims() method and do your validation on that.

https://pkg.go.dev/github.com/coreos/go-oidc/v3/oidc#IDToken.Claims

It does appear that the azp claim is supposed to be validated after the token endpoint call

"If an azp (authorized party) Claim is present, the Client SHOULD verify that its client_id is the Claim Value."

https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation

The problem is that this package can be used by both the server requesting the token and other service that might want to validate the token later. For the former, you want to verify 'azp' matches your client_id. For the latter, you'd want to validate 'aud'.

So yeah, maybe we should have an "authorizing party" validation option?

@manjinder-mckc
Copy link
Author

Makes sense i believe. We can make it optional to satisfy both server and client implementations, and the verifier config can be adjusted accordingly.
Aldo, thanks for suggesting the Claims method.

@ericchiang
Copy link
Collaborator

Another thought is that we could have a method like:

func (v *IDTokenVerifier) VerifyToken(ctx context.Context, token *oauth2.Token) (*IDToken, error)

That did the right thing with the authorizing party claim. Might be a bit subtle though... Let me think about this a little

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants