`oidc-issuer-url` option assumes OIDC discovery to be in well-known format while FusionAuth is not

[alank976]

FusionAuth exposes an OpenID Connect Discovery endpoint like this: http://example.com/.well-known/openid-configuration/d7d09513-a3f5-401c-9685-34ab6c552453 Somehow it comes with a trailing tenant ID.

I tried passing the exact URL to odic-issuer-url but no luck. Here are my oauth2-proxy logs:

[2023/04/29 11:23:44] [provider.go:55] Performing OIDC Discovery...
[2023/04/29 11:23:44] [main.go:60] ERROR: Failed to initialise OAuth2 Proxy: error intiailising provider: could not create provider data: error building OIDC ProviderVerifier: could not get verifier builder: error while discovery OIDC configuration: failed to discover OIDC configuration: error performing request: Get "http://example.com/.well-known/openid-configuration/d7d09513-a3f5-401c-9685-34ab6c552453/.well-known/openid-configuration": dial tcp 127.0.0.1:80: connect: connection refused

So I reckon it's assuming the discovery endpoint is always appending /.well-known/openid-configuration for me but it won't work well unless there is a complex template engine behind the scene (which I doubt it...)

Expected Behavior

Is there any alternative to configure an unconventional OIDC discovery endpoint?

Current Behavior

I cannot find how to configure that alternatively :(

Possible Solution

Any existing alternative I have missed?

Steps to Reproduce (for bugs)

N/A

Context

Configuring an oauth2-proxy with FusionAuth

Your Environment

It's just yet another k8s environment (I am using KinD with a few CoreDNS and /etc/hosts tweak though if that helps)

• Version used:

image: quay.io/oauth2-proxy/oauth2-proxy:v7.4.0

[kr4sv]

Have you tried --skip-oidc-discovery and setting the login, redeem and jwks url explicitly?

[alank976]

Yeah I did. But after skipping OIDC discovery, I kind of lose the control over the key algorithms verification of oauth2-proxy.

I have also asked a question about that in a closed issue below.

https://github.com/oauth2-proxy/oauth2-proxy/issues/2074#issuecomment-1528773200

[mooreds]

@alank976 as of FusionAuth 1.46.0, we support the tenant Id before the openid-configuration path segment.

http://localhost:9011/c2ae5811-14b0-4734-a4cc-c8ea9a8ae0b8/.well-known/openid-configuration is equivalent to

http://localhost:9011/.well-known/openid-configuration/c2ae5811-14b0-4734-a4cc-c8ea9a8ae0b8

Please give it a try and let us know how it goes.

[alank976]

@mooreds Thanks! Didn't notice there's a new release of FusionAuth with this alias thing. I just tried it out but there's a strange port 9011 floating around somewhere...

My oauth2-proxy helm values:

config:
  clientID: c1725ff6-4ebf-4f89-adf1-36e5711129b4
  clientSecret: <redacted>
extraArgs:
  provider: oidc
  oidc-issuer-url: http://auth.example.com/d7d09513-a3f5-401c-9685-34ab6c552453 # Not a real DNS record but my personal "hack" via /etc/hosts and ingress
  show-debug-on-error: "true"
  silence-ping-logging: "true"
  pass-access-token: "true"
  pass-authorization-header: "true"

My fusionauth helm values.yaml

image:
  tag: 1.46.0
service: 
  port: 80

My app's ingress (created via Helm):

ingress:
  enabled: true
  annotations:
    nginx.ingress.kubernetes.io/auth-url: "http://$host/oauth2/auth"
    nginx.ingress.kubernetes.io/auth-response-headers: X-Auth-Request-User,X-Auth-Request-Email,X-Auth-Request-Access-Token,Authorization,X-Forwarded-User,X-Forwarded-Groups,X-Forwarded-Email,X-Forwarded-Preferred-Username,X-Forwarded-Access-Token
    nginx.ingress.kubernetes.io/auth-signin: "http://$host/oauth2/start?rd=$escaped_request_uri"
  className: nginx
  hosts:
    - host: app.example.com
      paths:
        - path: "/"
          pathType: ImplementationSpecific

When I hit `http://app.example.com/oauth2/start?rd=%2F`` (/oauth2 is ingressed to oauth2-proxy), it responded 302 with

http://auth.example.com:9011/oauth2/authorize?approval_prompt=force&client_id=c1725ff6-4ebf-4f89-adf1-36e5711129b4&redirect_uri=https%3A%2F%2Fapp.example.com%2Foauth2%2Fcallback&response_type=code&scope=openid+email+profile&state=zw-0efmP1lOLYDpqFjMzSW__RSzV_R8ZNZDnmgpjFYs%3A%2F

I cannot understand how the oauth2-proxy is configured to carry the fusionauth default port 9011 (not to mention I configured its k8s service to expose 80...) for the /authorize endpoint...The only lead I have is the OIDC discovery endpoint but it looks alright too...i.e. not carrying port 9011 in my oauth2 Response of http://auth.example.com/d7d09513-a3f5-401c-9685-34ab6c552453/.well-known/openid-configuration/

{
authorization_endpoint: "http://auth.example.com/oauth2/authorize"
...
}

I am running out of idea 🤯 @mooreds Could I pick your brain, please? 😢

[mooreds]

Hmmm. I wonder if it is related to https://github.com/FusionAuth/fusionauth-issues/issues/2250

https://fusionauth.io/docs/v1/tech/admin-guide/proxy-setup#headers-to-set has some details.

I'm not super familiar with OAuth2-proxy, but this doc https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/overview/

indicates you might want to use the --reverse-proxy extra arg to make sure FusionAuth receives the port it appears to be running on.

[github-actions[bot]]

This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.

[mooreds]

@alank976 did you try this with FusionAuth > 1.46 ?

[github-actions[bot]]

This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.

[github-actions[bot]]

This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.

[mooreds]

@tuunit do you have a specific question?

[tuunit]

@mooreds I was just going through my usual routine of keeping the bot and labels in check. Unfortunately, my backlog is rather full and none of the maintainers have access to a FusionAuth instance. Therefore we have to rely on community feedback and help. If you identify a bug feel free to open a pull request.

While quickly glancing at the description and comments I noticed the following:

oidc-issuer-url: http://auth.example.com/d7d09513-a3f5-401c-9685-34ab6c552453 # Not a real DNS record but my personal "hack" via /etc/hosts and ingress

I cannot understand how the oauth2-proxy is configured to carry the fusionauth default port 9011 (not to mention I configured its k8s service to expose 80...) for the /authorize endpoint

Which indicates a rather weird network setup to me. @alank976 why do you need to configure your /etc/hosts? Where is your FusionAuth hosted in relation to your oauth2-proxy. Shouldn't there be a network resolution possible via <fusion-auth-service>.svc.<namespace>.cluster.local or an internal DNS server? Regarding the port 9011: I don't know about FusionAuth but a lot of applications redirect to their "correct" url depending on what is configured as their hostname.

[github-actions[bot]]

This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.