openidconnect-rs icon indicating copy to clipboard operation
openidconnect-rs copied to clipboard

Need to override discovery document url

Open wt opened this issue 1 year ago • 3 comments

Hey there. I am trying to use this lib (3.5.0 version) to auth to Intuit's sandbox. The discovery url for that system is at this URL: https://developer.api.intuit.com/.well-known/openid_sandbox_configuration.

I looked through the code for openidconnect (both 3.5.0 and main branch). It seems to assume that the discovery doc it located at the issuer url with "/.well-known/openid-configuration" appended to the end. Is there any way I can override the appended part of the url for the discovery document so that I can auth to the intuit sandbox?

Intuit docs are here: https://developer.intuit.com/app/developer/qbo/docs/develop/authentication-and-authorization/oauth-openid-discovery-doc

wt avatar Nov 22 '24 00:11 wt

Hi @wt,

Unfortunately, Intuit isn't following the spec, which is clear about the relationship between the issuer URL and the discovery URL:

OpenID Providers supporting Discovery MUST make a JSON document available at the path formed by concatenating the string /.well-known/openid-configuration to the Issuer.

For sandbox environments, they should be using a distinct issuer URL from their production environment (ideally a different subdomain, but at least a different directory). Having multiple sets of tokens and keys for a given issuer URL can easily lead to security vulnerabilities in client apps, so it's not something I want to support directly in this crate.

As a workaround, you can define a custom HTTP client that rewrites the request URL from the spec-compliant one to the one Intuit expects. The built-in reqwest clients defined here (for the main branch) should provide a starting point for any needed customization. Hope that helps!

ramosbugs avatar Nov 22 '24 01:11 ramosbugs

Thanks. This is really helpful. I definitely see how Intuit's api is not compliant. It's really unfortunate that it's this hard to work around. I wonder if there is room for an example that implements this kind of workaround?

It might also be helpful to have a comment in the code to indicate that the OIDC spec has a MUST requirement for the location of the discovery doc relative to the issuer. At least that way you wouldn't have to rehash this issue ever again? Maybe just a link to this issue?

wt avatar Nov 23 '24 21:11 wt

I wonder if there is room for an example that implements this kind of workaround?

There aren't currently any examples illustrating a custom HTTP client, and I'd welcome one since it's an escape hatch I suggest a lot.

It might also be helpful to have a comment in the code to indicate that the OIDC spec has a MUST requirement for the location of the discovery doc relative to the issuer. At least that way you wouldn't have to rehash this issue ever again? Maybe just a link to this issue?

Agreed

ramosbugs avatar Nov 23 '24 22:11 ramosbugs