I know syncthing has some options for authentication but I think one important one is missing: OpenID Connect.
I am working with syncthing in a team and would like to use OpenID Connect to allow access to Syncthing.
I am somewhat familiar with how the protocol works and I am also considering providing an implementation - but I have almost 0 go knowledge and little time to learn it.
Here is how I see it from a functionality point of view:
My primary OpenID Connect implementations are (in order) Keycloak, Azure AD, Github
Setup Auth:
Admin will register an OpenID Connect application - public client or private client ?! (probably public for the Syncthing web UI)
Admin will configure Syncthing to trust JWT tokens issued by the IdP
JWT token could contain groups that Syncthing can make use of in case Authorization / permissions are implemented. As a bare minimum, Syncthing should allow access only to members of a group
Use:
User will access Syncthing UI using browser
Syncthing will redirect browser to IdP for auth
IdP will redirect browser back with signed JWT token
Browser will send token with every request to Syncthing
Syncthing will make authentication / authorization requests based on signed token
The Syncthing authentication could work using multiple authentication engines.
The first one that returns true should win.
This way Syncthing could be setup with:
I’ve done fair amount of integration work with OIDC lately for various reasons, and I can see the attraction but I’m not super fond of adding this to Syncthing. It’s a whole bunch of moving parts for something that in the end doesn’t even have a concept of different users or roles…
What you can do already today is put Syncthing behind something like oauth2-proxy.
I see your point.
I am under the impression that OIDC has matured lately.
I’m not contradicting you points, just want to discuss this a bit more.
I have used oath2-proxy before and I think it’s a workaround for situations where the app was not built with authentication in mind - which is not the case for Syncthing.
It’s an extra service to maintain.
From my point of view I would choose OIDC over LDAP for example.
One idea to provide these plugins is to rely on web assembly.
Maybe an interface can be designed in such a way that wasm modules could be loaded, initialized and then used as middlware.
WASM is sandboxed - but maybe not mature enough (yet) to be used as such.
The advantage would be that any programming language that can compile to WASM can be used to implement the middleware.
I don’t know how the WASM module would access internet.
I know there is work on WASI for this but not sure how usable it is.
