OAuth2 (or pretty much any) authentication

Features
#1

I was considering installing aw-server on my cloud server, so all my machines (and soon, hopefully, my phone) can send their data there.

This, of course, would require some kind of authentication, but as I understand ActivityWatch doesnʼt have the notation of users at all.

As I have the knowledge to implement it on the Flask side, I was wondering if the authors are interested in such a feature.

1 Like
#2

We’re definitely interesting in OAuth2 verification and have been thinking of implementing that ourselves aswell, but we have some other hurdles regarding remote access of aw-server which we need to solve to make it a good experience which we need to solve aswell. Querying aw-server from multiple hosts currently works, but the reasons why we are not recommending it is because:

  • We would need HTTPS to make transmission secure (and that’s cumbersome if you are self-hosting)
  • Our watchers are very frequently sending heartbeats to aw-server, to do this locally is already rather expensive and doing so remotely would be even more so. We have plans to batch these heartbeats together before sending them off for performance optimization, but that work is not done.
  • We have not done any extensive security evaluation of aw-server, so before binding aw-server ports for remote access by default we would like to do that.

So we would be very happy to see a OAuth2 PR for aw-server since it will definitely be useful for us in the future, but even with that support added we are still far from wanting to officially recommend people to start opening their aw-servers ports for remote access. We also have plans to have multiple aw-servers which could sync between eachother instead of having a cloud solution, so that’s also worth mentioning.

If you have any further questions we’d be happy to help :slight_smile:

#3
  • We would need HTTPS to make transmission secure (and that’s cumbersome if you are self-hosting)

Itʼs pretty easy with Let’s Encrypt today. However, running Flask runserver in a production environment is questionable, but thatʼs just the matter of documentation.

  • Our watchers are very frequently sending heartbeats to aw-server, to do this locally is already rather expensive and doing so remotely would be even more so. We have plans to batch these heartbeats together before sending them off for performance optimization, but that work is not done.

Thereʼs a monitoring tool called Zabbix, which suffers from the same problem. To counter it, they made a component called Zabbix Proxy. It basically collects all monitoring event and sends them to the server in batches.

I was also thinking if authentication worths anything without the notation of users; and if that happens, one can also define machines, so a relationship can be made between users and machines, and machines and events. This, however, can make the whole architecture a lot more complicated.

#4

Yeah, we’ve been looking at Let’s Encrypt and concluded that it’s probably the best way to go but have not made any progress on it since we are not prioritizing remote access currently.

Since we often use heartbeats and they could technically be merged before being sent, this is our priority since it will save on both aw-server CPU usage, aw-server DB writes as well as network bandwidth. We currently have a queue for aw-client which starts piling up if a client loses connection to aw-server, in the future it might also just let that queue build up batches of 30s data and then send that queue of requests, but that would be the second step in optimizing performance for us (this sounds a bit similar to zabbix proxy).

Yeah it certainly would. You could possibly also have multiple users on one machine which would complicate things even further. We’ll start with only allowing a single user I guess and later on see how requested a multi-user solution would be (let’s hope it isn’t :stuck_out_tongue:)

#5

A reasonable plan could be as follows:

  1. Implement the usage of JWT for basic key-based authentication, so local access can be protected. (this would have minimal impact on code complexity, which is nice)
  2. Enable use of HTTPS, allowing secure key-based authentication from remote machines.

Once that’s done, we could talk about more elaborate authentication schemes, like ones involving OAuth.

#6

+1 for this.

For the time being to accomplish a cloud based solution with security I am going to use SSH tunnels to the Linux server that is hosting the aw-server.

#7

I wanted to chime in on this topic and add the following projects. I use traefik on my own server that terminates TLS/https encryption and routes applications. There is a plugin for traefik to allow/deny connections using a middleware by google/microsoft/github oauth applications. So if you were to use activitywatch in a docker container it would be pretty easy to get HTTPS and some sense of security if you intend to use it over the internet.

1 Like
#8

Hello, can you help me out with some more details on your setup. Attempting to use AW for similar reasons, would appreciate any help