OH3 with NGINX Reverse Proxy and Authentication

You would need to create a user other than admin inside OH3, preferrably same name what you use in your oh client app and nginx conf.
Dunno how I think I saw some post here about doing that in Karaf console but I don’t find it any more.
(ping @hmerk I might be mistaken but wasn it you to write that?)

Sorry but I dont understand?

I only wrote that Now there is two levels of security. First is login and pass from nginx and then login and pass for administrator in Main UI.

Sorry @mstormi, it wasn‘t me, but i saw that too. Users need to be added on console atm.

Of course there is if you do not remove it from nginx.
Since you probably want to access without password, you need to create an oh user (and use that on the client side) inside oh3 and disable auth in nginx.

do you find the post?

EDIT: see https://karaf.apache.org/manual/latest-2.x/users-guide/security.html

The post you are looking for is here

sorry but I still dont understand for what is it for?

I want to have secured connections with OPENHAB.

So if I delete this lines from nginx:
auth_basic “Username and Password Required”;
auth_basic_user_file /etc/nginx/.htpasswd;

then I will ony need to log in by login:ass set in OH3?
Will it secure connection for Basic UI also?


it’ll encrypt it with a cert. It won’t do auth again.

That’s a rather bumpy migration path in terms of security.
I had a haproxy setup with OH2 which works as expected.
On OH3, the first thing i had done (for some minutes at least) was to remove the basicauth in haproxy, because i thought, this would be handled by OH3 now.
I was wrong and my KNX/Hue/Zigbee-Setup was exposed to the world.

Will there be a usermanagement/basicauth for REST and basicui on the OH3-Side?



Basic Auth for managing in the REST API is available but turned off by default since in most cases the API Token is more secure.

The Main UI has authentication for management but not for operation. Since the Basic UI is controlled by managed site maps and does not manage OH there is no authentication.

I see. But the iOS App needs a user name and password.
How is this supposed to work?

@Bruce_Osborne wrote it already

There is a setting to enable it:

1 Like

After reading all of this I’m still unclear if it’s possible to have OH3 behave as OH2 w/r to authentication using a reverse-proxy that handles authentication. I just want to turn everything off w/r to authentication and have it work like OH2.
I manage my own identities and authentication with Okta, because I don’t trust that there won’t be some security issue with Openhab (or its included libraries) that exposes my internal network. From the reverse proxies perspective it may be desirable in some cases to go directly to OH3 with no further auth. I have further complexity in that I use browsers that don’t understand or support BasicAuth, yet the smartphone apps use this – not sure if they need to be updated to support bearer tokens or something…

1 Like

This is a common misconception. Token based authentication is not more secure - it is exactly as flawed as basic auth. The only difference is that once an attacker listens to you messages he can extract the password from basic auth while with token he only gets the - well - token.
So if you do not reuse your passwords (something you should actually never do) basic auth is on par with token.

@billfor @boecko
You can use this command in the console
bundle:stop org.openhab.core.io.rest.auth
to disable auth and restore the behavior as it was in OH2.
Unfortunately you have to do this every time you start openhab. I’ve already created an issue in october, but so far not much has happened.


I only had to add these two lines:

	RequestHeader unset Authorization
	Header add Set-Cookie "X-OPENHAB-AUTH-HEADER=true;path=/;Secure"

Note: I use https

1 Like

Generally if you have a Token for a single purpose with restricted authorization for just those purposes it is more secure and more easily isolated. openHAB AAA is currently no where near that level. IT is either unauthenticated read or full Admin access. BTW I work with a commercial AAA system for a good part of my work along with accessing REST APIs for that system and some other things.

Thank you! Traefik 2 doc says removing headers within labels isnt supported yet, good to see Authorization is.

EDIT: found a working configuration where login with OH credentials (as admin) doesn’t cause the blank page error, I had to add:

- traefik.http.middlewares.openhab.headers.customrequestheaders.Authorization=""

Although the x-openhab-auth-header is set, OH3 seems not to care about it once you are logged in and will try to parse your proxy’s Authorization header - which fails of course, making all protected resources return 401 (so all /rest, /tiles, etc.).
OH3 seems to really not be ready to be called stable yet with this and the rest hashing performance issues…

Nevermind, the x-openhab-auth-header must be set to “true” not “1” else OH3 seems to ignore it. Can confirm it sets authorization header to Traefik basicauth, and X-OPENHAB-TOKEN to OH3’s JWT login token.
So my working config for traefik now is:

      - traefik.http.routers.openhab.middlewares=ohauth,oh
      - traefik.http.middlewares.ohauth.basicauth.users=<your htpasswd>
      - traefik.http.middlewares.ohauth.basicauth.removeHeader=true
      - traefik.http.middlewares.oh.headers.customresponseheaders.Set-Cookie=X-OPENHAB-AUTH-HEADER=true
1 Like

Is this still required since OpenHABcloud has all requests set with the following:

//tell OH3 to use alternative Authentication header
res.cookie(‘X-OPENHAB-AUTH-HEADER’, ‘true’)

I’m still getting a blank page on refresh after logging in basic auth then logging into an OH3 account.
It seems like OH3 frontend code only cares about the X-OPENHAB-AUTH cookie when setting it (getting a token from /rest/auth), not when deleting it. Whenever you are logged out of OH3 or cleanSession() is called, ALL your credentials are deleted (accessToken, refreshToken, localStorage user, pass, Vuex $store user, etc.) regardless of whether they belong to OH3 or to the proxy.
The problem on Android WebView is, refreshing the page after the double login (basicauth + OH3 token) causes cleanSession() to be called for some reason. I’ve now seen this on multiple phones and multiple browsers - Vivaldi, Bromite, Chrome and builtin AOSP WebView browser.

I’m not sure why cleanSession() is called, maybe an event thrown on refresh by WebView but not by desktop browsers the devs used when testing. It does seem like the X-OPENHAB-AUTH implementation is incomplete, causing this bug that many others with problems in the App on iOS and Android have been mentioning since 3.0 release.

Currently there is also a bug in chrome that blocks the basic auth credentials to be used when openHAB is accessed via HTTPS and the service work cached the requests. Allow more flexibility in how 401s/407s are handled? · Issue #1132 · whatwg/fetch · GitHub

Posting this here has I suspect others will keep finding this post.

I just configured it to work in HAProxy on pfSense thanks to the information in this thread. You should be able to configure this on the front end or the back end. I configured it on the back end.

Under "Access control lists and actions click to create a new Action and choose “http-request header add”.

  • name: Set-Cookie
  • fmt: XOPENHAB-AUTH-HEADER=1;path=/;Secure

Add another new Action and choose “http-request header delete”

  • name: Authorization

I kept the authorization and authentication configuration on the front end. I also have basic auth turned off in openHAB’s settings. Therefore I need to enter a username and password to bring up the openHAB page at all. Then I need to do it again to log in as an administrator to change any settings. This suites me just fine.