Support OIDC

[EvilBlood]

Hello,
I think OICD for login would be a good extension for your tool. In many environments a service like Authentik (https://goauthentik.io) is used as OIDC provider. This would allow the tool to connect well with SSO.

[csh0101]

I'm interesting in this. if you have no time or energy to support this, maybe i do this job. @jmattheis

[jmattheis]

Hmm, maybe this is only a documentation issue. Screego doesn't necessary need users, because you can disable the login:

server/screego.config.example

Lines 66 to 71 in c652513

	# Defines when a user login is required
	# Possible values:
	# all: User login is always required
	# turn: User login is required for TURN connections
	# none: User login is never required
	SCREEGO_AUTH_MODE=turn

When setting the value of the auth mode to none, then a guest user has the same permissions as a logged-in user. Combining this with a reverse proxy supporting forward like described in here https://goauthentik.io/docs/providers/proxy/forward_auth you can already protect screego via SSO.

[nogweii]

How would someone set up authenticated TURN and Prometheus Metrics when the auth mode is set to none?

[jmattheis]

What do you mean with authenticated turn? Prometheus is unaffected by the SCREEGO_AUTH_MODE setting, you'd have to create a user like you'd do with SCREEGO_AUTH_MODE=turn.

[nogweii]

Referencing the example config: "turn: User login is required for TURN connections", but if you set up a proxy to handle OIDC authentication, how would those users authenticate to the built-in TURN server? (I'm expecting that you wouldn't suggest proxying TURN through the proxy.)

Looking into it, maybe the recommendation in that situation would be to use an external TURN server with a shared secret.

[jmattheis]

It basically just works out of the box and should be secure. The TURN credentials are separate from the user credentials and will be generated on demand for new connections, even if SCREEGO_AUTH_MODE=none is used. Screego will transfer these generated credentials to authenticated users via http/WebSocket. So only users that can access the http site can obtain turn credentials and SCREEGO_AUTH_MODE determines whether an additional user login is required.

So users that aren't allowed to access the http site, cannot get valid credentials to use the builtin turn server.

[nogweii]

will be generated on demand for new connections, even if SCREEGO_AUTH_MODE=none is used

Ah, that wasn't immediately clear to me. Thanks!

---

So, to restate this thread, as an alternative to natively supporting OIDC within screego, folks can do the following:

1. Set SCREEGO_AUTH_MODE to none
2. Put a reverse proxy in front of the server that does the OpenID Connect authentication
3. Have screego only bind to the local network so it doesn't accidentally get exposed directly (so listening on the loopback interface, or on a UNIX socket)
4. Bind the built-in TURN server to the external network interface, if users want to do that. Or, configure screego to use an external turn server if that is preferred.
5. Create a user credential and put it into the configuration even though it's not being used for the primary user authentication so that Prometheus Metrics can be protected as well

All that remains then is documenting this as an example. There are too many reverse proxies and deployment options, so perhaps a docker-compose.yml file with screego & oauth2-proxy?

[jmattheis]

@nogweii Yes, thanks for summarizing. Point 5 is optional and only needed if you have prometheus metrics enabled.