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
- 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
- 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:
- plain user/pass credentials
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.
There is a go library certified for OIDC GitHub - zitadel/oidc: Easy to use OpenID Connect client and server library written for Go and certified by the OpenID Foundation .
The flow we should support is PKCE - supported by go oidc library - Proof Key for Code Exchange by OAuth Public Clients
IMO the go library + some glue code should be enough to make the implementation work.
Does Syncthing allow loading plugins/middle-ware for auth?
In this case the functionality might be provided and maintained outside Syncthing core.
This might be an escape hatch to allow extensibility without burdening Syncthing development.
I found this GitHub - hashicorp/go-plugin: Golang plugin system over RPC. .
== Crazy idea bellow
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.
I found that istio has something that looks exactly like this.
It’s using WASM Plugins for authn Istio / Wasm Plugin
Istio is written in go GitHub - istio/istio: Connect, secure, control, and observe services. .
Features started to pop up in 2021.
These are the references I found:
I also wonder if we could use webassembly CGI - wcgi Announcing WCGI: WebAssembly + CGI .
The idea is that plugins could be wasm modules that implement wcgi.
We could run the wcgi script and pass the request to that, get the response.