Replies: 1 comment
-
|
My first hunch is to check the logs of whatever proxy Dex is behind if any to make sure the request goes through from DC2 to DC1 properly. I highly doubt that the consistent time comparison function fails here. From the top of my head I can't see why what you are doing shouldn't work unless the application does something weird. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I am working on a deployment of https://github.com/goharbor/harbor, and am testing a setup using two instances deployed in separate Kube clusters behind a load balancer. The way I have it set up right now, they share a Postgres database, consequently, they have the same OIDC configuration. They both point to a Dex instance running in datacenter 1, and have the same client ID and client secret by nature of sharing a database.
When I authenticate using the OIDC provider in datacenter 1, it works fine. However, when I try to log in to instance 2 directly, OIDC authentication fails saying
level=info msg="invalid client_secret on token request for client: Client-Name"in the Dex logs.From what I can tell, it appears to be failing at https://github.com/dexidp/dex/blob/master/server/handlers.go#L734, which was introduced to prevent timing attacks (#1861). I was hoping for an explanation of what is actually causing this to fail, as I am unclear what the ConstantTimeCompare function is doing, and why the comparison it makes would fail only when going from the instance in datacenter 2 to the Dex provider in datacenter 1.
I am trying to work out if what I want to do is even possible within the confines of OIDC spec, and was just hoping to get a better understanding of what is going on in the code.
Additional Notes:
Just a note with some further testing. Sometimes it works (I can log in to datacenter 1, then when I switch to datacenter 2 I stay logged in). Other times, if I log out entirely, then route to datacenter 2 and try logging in I get an error about invalid client credentials, and cannot access either instance. I am not sure if this is something specific to how OIDC works or the application itself.
Beta Was this translation helpful? Give feedback.
All reactions