-
Notifications
You must be signed in to change notification settings - Fork 393
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
Issuer URL is not normalized for comparison #155
Comments
Issuers are exact strings.
https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest However, the issuer value returned by the metadata must exactly match the original issuer string. This check is strict, but often helps us identify mis-configurations (#154, #121). Probably better for us to make the docstrings stress this more. But I don't think we should do any normalization during comparison. |
Both of those mis-configurations would be still be caught if the terminating The normalization is especially annoying because some issuers have terminating As a result without the normalization in the check itself I will be calling the |
It seems odd to do this normalization here, but not elsewhere. I could provide an issuer URL It also seems odd to be using this package just to validate issuer URLs. I could see someone wanting to create an |
I'm trying to be defensive from a user input validation perspective. I think the best option is to do the full validation by calling NewProvider when the user tries to input the issue value and rejecting the value if NewProvider returns an error. It's annoying mostly because I am passing the value off to another service and the values in this library don't serialize well due to all the fields being unexported. So I have to call NewProvider in that service too which sort of seems wrong to me. |
Okay this seems to be boiling down to "I want to use this package without doing the discovery call." I could see a couple possible APIs. First we could expose the internal fields and let a user create a verifier directly from the KeysURL. // Provider ...
//
// Providers must be built using NewProvider.
type Provider struct {
// Expose existing, unexported fields.
Issuer string
AuthURL string
TokenURL string
UserInfoURL string
KeysURL string
// contains filtered or unexported fields
}
// NewVerifier returns an IDTokenVerifier that uses the public keys provided at keysURL to
// verify ID token signatures.
//
// It's recommended to use Provider.Verifier to create verifiers instead, since those will share a cache
// of keys common to the provider, instead of per verifier. NewVerifier should be only be used when
// discovery has been performed out-of-band.
func NewVerifier(ctx context.Context, config *Config, issuerURL, keysURL string) *IDTokenVerifier Or we could let a user create a provider directly through a keyed struct constructor. type Provider struct {
// Expose existing, unexported fields.
Issuer string
AuthURL string
TokenURL string
UserInfoURL string
KeysURL string
// Ctx for this provider. Can only be set before calling Verifier.
Ctx context.Context
// raw claims. Only populated by NewProvider.
raw []byte
// keySet, if nil, will be built using the KeysURL and Ctx fields on the first call to Verifier.
once sync.Once
keySet *remoteKeySet
} I think I prefer the first API change. |
I've decided I want to validate the user input early anyway. So I'll call NewProvider twice. Once to validate on input and then again in the other service where I want to actually use the provider. No API change is necessary. Feel free to consider this a user experience report and close. Thanks for your time and your help, it is appreciated and has helped me come to a decent decision. |
The NewProvider function takes an issuer argument and creates the config URL from it with
Then later the issuer is checked against that returned by the config endpoint.
If an issuer of
https://issuer.com/
is passed in but the config endpoint returnshttps://issuer.com
as the issuer, then this comparison will fail even though these are clearly the same issuer.I suggest normalizing the issuer url for the comparison (e.g. like this):
Does this sound appropriate? If so I can make the change and PR it.
The text was updated successfully, but these errors were encountered: