ProxyAuth domain with forward_auth on localhost results in OIDC invalid_redirect_uri #177
Labels
No labels
bug
chore
documentation
enhancement
help
in-progress
question
ready-for-release
released
translation
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
adam/gate#177
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Describe the bug:
Trying to access a localhost domain/path covered by a ProxyAuth rule, with Caddy set to forward_auth, leads to an OIDC error.
To Reproduce:
Voidauth
One ProxyAuth domain
*/*with any group assigned or none at allCaddy
Caddyfile, where
$DOMAIN=localhostTest
Attempt to access
https://organizr.localhost.Expected behavior:
I assume Voidauth should be sending me to the login page. The logs and screenshot were taken from an incognito window, so a fresh session. I don't know why it's going to an OIDC flow.
Database Driver:
SQLite
Screenshots:
Additional context:
I might just be an idiot, this stuff is far outside my realm of expertise. It's possible this is just a limitation of using localhost as a domain? This was just for evaluating functionality before moving to production. I decided to YOLO it and things seem to work fine using my real domain.
Hello! Thank you for opening an issue and writing out your config and logs, it helps a lot with troubleshooting. That is a weird error you are getting, I wonder if it could be due to using *.localhost for testing? Part of the ProxyAuth process does use the same validators for redirecting as the OIDC Clients, but you should never see this error. Internally large parts of the ProxyAuth process have changed in the latest release however, so if you get the chance to re-test after updating to v1.5.0 please let me know if you are still getting an error, and if the error message has changed.
The error has definitely changed!
Again, with ProxyAuth set to
*/*and accessing any subdomain, in this example it's home.localhost I now see:error "ProxyAuth root hostname home.localhost does not equal APP_URL root hostname id.localhost"Which is a 400 response to the GET request to home.localhost. I don't see Caddy attempting to actually perform the forward_auth and redirect to id.localhost, as I saw in my original post.
Interesting! I wasn't actually expecting you to get that error, but it explains what is going on. There is a long answer below, but the short answer is that VoidAuth doesn't think that it would be able to set the required session cookie from
id.localhostthat could be read fromhome.localhostin order for ProxyAuth to work. It is either correct and it would not be able to set a cookie onlocalhostthat could be read by both, or there is an issue and this could actually work. Either way, you should not see this error in a real environment where you own the domain ex.id.example.comandhome.example.comwould both have base domainexample.comand all would be well.Please let me know if you also see this error in a non-testing environment where you are using a real domain.
Longer Answer Here:
ProxyAuth depends upon VoidAuth (accessed from
id.example.com) being able to set a cookie (x-voidauth-session-uid) on its base domain (example.com) and that cookie be read by the reverse-proxy while accessing the protected domain (home.example.com). That 'sticky' cookie that can be set by VoidAuth and read by reverse-proxy drives the ForwardAuth process in every SSO provider. In practice, that means that VoidAuth can only protect sites that are on the same base domain, otherwise browsers will reject the cookie and you will be sent back to the login page or in a never-ending loop. To prevent this, VoidAuth will show that error if you are attempting to protect a domain that does not share a base domain with the$APP_URL. In this case, I would have expected the base domain of bothid.localhostandhome.localhostto belocalhost, though things always get weird with cookies and localhost.I see, that definitely explains the message. It does all work fine in production at my real domain.
The briefest of searches lead me to https://stackoverflow.com/a/74554894 which indicates cookie sharing across subdomains needs to be done with a domain on a global TLD.
I'd test the workaround with localhost.com pointed to 127.0.0.1 but Caddy has special logic for the domain localhost and I think I just blew up my letsencrypt ratelimit trying to issue certs for localhost.com lol
I suspect it would work just fine though and that your implementation isn't at fault. Not sure if there's anything actionable here. Maybe a more clear error message? Or a callout in the docs? Or nothing at all.
Playing around some more, setting
$DOMAIN=localhost.localhostallows everything to work with no other configuration needed, the only practical difference is I access services as https://home.localhost.localhost for example. This works great for testing and evaluating VoidAuth itself as well as service integrations.Feel free to close this issue if you don't want to add this as a suggestion somewhere. I think this issue has enough keywords that anyone in this niche will stumble on it and find my solution.