OH3: Benefits when API key over Basic Auth Locally


I have more of a general question in that I am having some trouble understanding what, if any, benefit using an API token over Basic Authentication would have locally?

For example, in the Android application, I have the local server URL set to https://IP:PORT with Basic Authentication enabled on the server. This is working without issue but is there a reason to use an API token over Basic Authentication in this scenario? Is more risk introduced if I then use the OH cloud service for remote access with Basic Authentication still enabled on the server? (I am not yet making use of NGINX and my own SSL but I do not have any plans to open my OH server to the internet directly without setting that up first or using the OH cloud service.)

If someone listens to your requests it’s possible to extract the password from the basic auth header.
This is a possible threat if you e.g. reuse the password for different services.
When an attacker can listen to your request with both the API Token and Basic Auth it’s possible to gain access to your installation. So neither is “better” for securing the OH installation.
Basic Auth is (a little bit) faster than the API Token, so if you are doing many request per sec it might be noticable.

I think the OH cloud connection works in a different way so auth is not a factor there (but I am not sure).

I appreciate the clarification, thank you!

Indeed. The way the connection with the cloud works is as follows (based on my understanding of similar systems and not necessarily looking at the code so I might have something wrong).

First of all the main problem to get over with remote access like this is to eliminate the need for the user to punch a hole in their firewall to accept connections from the Internet at large. But if you eliminate the ability to connect that means that the openHAB Cloud Server cannot directly initiate a connection to your openHAB instance.

To get over that hurdle, it’s not the Cloud Server that initiates the connection, it’s your individual openHAB instance that initiates the connection. Your home gateway/firewall won’t block openHAB from connection to another server on the Internet. If it did you wouldn’t be reading this forum right now.

So your openHAB instance connects to the Cloud Server using the Cloud Connector add-on. It presents a UUID and Secret to authenticate itself with the Cloud Server. At this point secure two-way communication exists between your OH instance and the Cloud Server (end-to-end encrypted using TLS I believe).

The Cloud Connector is an add-on running on openHAB. It proxies the web server that is built into openHAB. That means that all the HTTP commands sent to home.myopenhab.org are sent along that connection established by the Cloud Connector add-on and then passed from the add-on to openHAB itself. Because the Cloud Connector is already a part of OH running in the same process as OH, it doesn’t need to authenticate. It’s just a go-between.

That’s why you need to authenticate again as an admin user in MainUI after authenticating with myopenhab.org. Your OH doesn’t know anything about that authentication.

When you then in a browser or phone app connect to myopenhab.org, you are authenticating with the Cloud Service, not your home openHAB instance. You prove you own your openHAB instance by providing the UUID and Secret generated by your openHAB instance. That ties your instance to your myopenhab.org account. The connection between your instance and the Cloud Server is already securely established and the Cloud Connector will act as a reverse proxy between myopenhab.org and your OH instance, allowing you access to your OH instance.

But the OH built in authorization and authentication remains in place and depending on your settings you still need to log in again using your local credentials.

1 Like

Got it, thank you for the detailed explanation!