🚀 Wiredoor now supports authentication with OAuth2 Proxy (Google, GitHub, Authentik, and more)

[dmesad]

Wiredoor now includes full support for OAuth2 Proxy-based authentication.

That means you can now protect any exposed service behind a login screen using your favorite identity provider: Google, GitHub, Authentik, or any OIDC-compliant provider.

How it works

• For each protected domain, Wiredoor dynamically spins up a dedicated oauth2-proxy process with the configured credentials and rules.
• You can define exactly which emails are allowed to access the service.
• Fully compatible with Docker and Kubernetes.

Just set the following environment variables in your .env:

OAUTH2_PROXY_PROVIDER=google
OAUTH2_PROXY_CLIENT_ID=...
OAUTH2_PROXY_CLIENT_SECRET=...

You must register the Redirect URI like `https:///oauth2/callback in your provider's config.

➡️ Perfect for securing internal services like Home Assistant, Grafana, or any private dashboard.

Learn more:

• Wiredoor Docs
• Usage Guide

[Bart1909]

Hi @dmesad ,

next question :D

Is it possible to pass the X-Auth-* or X-Forwarded-* headers to the service? I've tried setting the OAUTH2_PROXY_SET_XAUTHREQUEST=true variable but that seems not to work.

See https://oauth2-proxy.github.io/oauth2-proxy/configuration/integration/

Best regards!

[dmesad]

Yes! You can pass custom headers like X-Auth-* or X-Forwarded-* by configuring OAuth2 Proxy properly. Wiredoor allows you to define global environment variables for all oauth2-proxy instances by setting them directly in your container.

For example, to enable X-Auth-Request-* headers, set the following in your .env and then recreate your container:

OAUTH2_PROXY_SET_XAUTHREQUEST=true

Here's the full list of supported variables and headers:

https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview#environment-variables

If you need to debug, you can check the logs of each OAuth2 Proxy instance at /var/log/nginx/yourdomain.com/oauth2-proxy.stdout.log

Let me know if you'd like help troubleshooting a specific case!

[Bart1909]

Yes I found this, but I think, these headers are not provided to the backend service. For this, the nginx configuration has to be adjusted:
https://oauth2-proxy.github.io/oauth2-proxy/configuration/integration/

    # pass information via X-User and X-Email headers to backend,
    # requires running with --set-xauthrequest flag
    auth_request_set $user   $upstream_http_x_auth_request_user;
    auth_request_set $email  $upstream_http_x_auth_request_email;
    proxy_set_header X-User  $user;
    proxy_set_header X-Email $email;

I could not find this setting in the nginx configuration of wiredoor

[dmesad]

I’ll update Wiredoor to automatically include those headers in the NGINX configuration whenever OAUTH2_PROXY_SET_XAUTHREQUEST=true is set.

That way, headers like X-User, X-Email, and others will be passed correctly to your backend service.

Appreciate your feedback!

[dmesad]

The changes have now been merged!

When you set OAUTH2_PROXY_SET_XAUTHREQUEST=true, Wiredoor will automatically configure NGINX to forward the X-User, X-Email, and related headers to your backend service.

Feel free to pull the latest version and test it out. Let me know if everything works as expected or if you run into any issues!

[Bart1909]

This is working now, very nice! Thank you very much :)

I have some more proposals which might help users like me who are using Authentik (and maybe other providers too):

It would be nice to configure the Auth Provider per Domain and not for the whole wiredoor server. Currently I've one application "Wiredoor" defined in Authentik which I allow for the users. Then in Wiredoor I can grant access to some of the users by their email. So I have to configure the access in two applications.
Another "negative" point about the current solution is that the application dashboard in Authentik can not be used because there is only one "Wiredoor" app defined.

Another suggestion would be to allow groups per Domain like the Emails. With this, I could manage the groups with users in Authentik and then allow this group in Wiredoor. And for new users I do not have to grant access in Wiredoor as the group is already allowed.

[JeslynMcKenzie]

So I'm trying to set this up but I've realized you're really only limited to securing one subdomain using google as a provider. Is that correct?

For example, I want to secure https://dashboard.myapp.com and https://info.myapp.com. In google, since I have to provide redirects back to the full domain name, this seems like it would require multiple Client ID and Secrets, where as Wiredoors configuration is only a singular entry.

Any advice or tips would be appreciated!

[JeslynMcKenzie]

I tried using that property in my .env configuration and it doesn't really skip the OAuth2 Proxy page. Instead if removes everything and creates a hyperlink that says "Found." which when clicked takes you to the Google login page. Is that the expected result in the current Wiredoor version?

[dmesad]

Thanks for testing it out @JeslynMcKenzie!

I experienced the same behavior. It seems like this might be a limitation or quirk in the current version of OAuth2 Proxy. I’ll be looking into whether there’s a proper way to achieve a true redirect-only flow when a single provider like Google is configured.

[dmesad]

Hey @JeslynMcKenzie

The feature to automatically redirect to the default provider is now working correctly. Wiredoor sets the --skip-provider-button=true flag internally, so there's no need to set the OAUTH2_PROXY_SKIP_PROVIDER_BUTTON environment variable manually.
Users are now taken directly to the provider without seeing the OAuth2 Proxy screen.

[JeslynMcKenzie]

Hey @JeslynMcKenzie

The feature to automatically redirect to the default provider is now working correctly. Wiredoor sets the --skip-provider-button=true flag internally, so there's no need to set the OAUTH2_PROXY_SKIP_PROVIDER_BUTTON environment variable manually. Users are now taken directly to the provider without seeing the OAuth2 Proxy screen.

Awesome! If I setup a new tunnel I'll try it out! I ended up throwing an Authentik outpost in front of the service instead as a workaround. If I add a new tunnel I'll add Authentik directly to Wiredoor instead!

As a side note, Wiredoor has been running great as a replacement to Cloudflare Tunnels!

[B08Z]

Hey @JeslynMcKenzie

Could you share how you did this. I gave it a go but it meant that the cli was broken as that hit the authentik challenge.
If you have a work around that would be great.

[buildplan]

@dmesad I'm trying wiredoor, configured OIDC with PocketID all the proxied services work just fine but I can't seem to set OIDC for the wiredoor dashboard itself ... Is this possible? When I try to set OAuth for the dashboard it does not throw any errors but it just doesn't set it to it at all.

[zerodarkzone]

It will not save the Require Authentication checkpox for the wiredoor app.

[zerodarkzone]

I was able to work around it but updating the sqlite database directly.

[dmesad]

After testing it more thoroughly, I realized that enabling OIDC for the Wiredoor dashboard using OAuth2 Proxy currently breaks access for wiredoor-cli, since it relies on unauthenticated API access.

To make this setup work, you’d need to set the OAUTH2_PORXY_SKIP_AUTH_ROUTE variable correctly to allow unauthenticated access to the required API paths used by the CLI. We're planning to implement better support for this directly from the Wiredoor interface soon.

Until then, I’d recommend not enforcing OAuth on the main dashboard unless you're also configuring OAUTH2_PORXY_SKIP_AUTH_ROUTE carefully.

[zerodarkzone]

It should still work locally using local host. I'm I right?

[buildplan]

I realized I could restrict the dashboard domain to trusted up addresses. So I ended up using that. I have now restricted dashboard domain to only the IP addresses I have Wiredoor-CLI installed and home io address.

This gives me a good balance I think.