OIDC federation?

IngwiePhoenix commented

2025-10-18 03:09:38 -05:00

(Migrated from github.com)

Describe your idea for an enhancement:

VoidAuth solves so many of my previous many questions about SSO in a homelab. The only thing it is missing is a way to bind with third parties. The main one for me, is Discord - and there is a lovely project that maps their OAuth2 API to OIDC, so the groups claim becomes guilds - and so, you can group-filter by the servers someone is in. This way, I want to filter access by people to specific services.

Project: https://github.com/celsiusnarhwal/snowflake

So, my feature request is quite simple: Users may log in with a "federated" OIDC, with their information stored/synced into VoidAuth, so I can use the ProxyAuth semantics to authenticate "local" and "remote" users.

Describe alternatives you've considered:

I haven't heared of something that would fit in here, sorry...

Additional context:

My entire homelab lives in Kubernetes with a few exceptions. Within, there are a few services that do not have authentication - like Pinchflat - that I want to/need to protect so my friends can safely access it. Since most of my friends are on Discord (I own two small servers) I want to use Discord as a hacky RBAC solution x)
Other services like Grafana can just use OIDC, so that's simple enough.

I have been trying so hard for so long to find a solution to get both local and remote users under the same roof and properly authZ'd per domain/route per group (= role). @.@ VoidAuth looks awesome, has ltierally all the features I want - except remote users. Very, very cool project!

### Describe your idea for an enhancement: VoidAuth solves **so many** of my previous many questions about SSO in a homelab. The only thing it is missing is a way to bind with third parties. The main one for me, is Discord - and there is a lovely project that maps their OAuth2 API to OIDC, so the `groups` claim becomes `guilds` - and so, you can group-filter by the servers someone is in. This way, I want to filter access by people to specific services. Project: https://github.com/celsiusnarhwal/snowflake So, my feature request is quite simple: Users may log in with a "federated" OIDC, with their information stored/synced into VoidAuth, so I can use the ProxyAuth semantics to authenticate "local" and "remote" users. ### Describe alternatives you've considered: I haven't heared of something that would fit in here, sorry... ### Additional context: My entire homelab lives in Kubernetes with a few exceptions. Within, there are a few services that do not have authentication - like Pinchflat - that I want to/need to protect so my friends can safely access it. Since most of my friends are on Discord (I own two small servers) I want to use Discord as a hacky RBAC solution x) Other services like Grafana can just use OIDC, so that's simple enough. I have been trying _so hard_ for so long to find a solution to get both local and remote users under the same roof and properly authZ'd per domain/route per group (= role). @.@ VoidAuth looks awesome, has ltierally all the features I want - except remote users. Very, very cool project!

❤️ 3

notquitenothing commented

2025-11-08 16:22:52 -06:00

(Migrated from github.com)

OIDC federation sounds very cool, and may be something I look into soon ™️

I suspect support would require significant rewriting, so it may be a while

OIDC federation sounds very cool, and may be something I look into soon ™️ I suspect support would require significant rewriting, so it may be a while

👍 3

IngwiePhoenix commented

2025-11-08 16:48:49 -06:00

(Migrated from github.com)

All good - glad you took a look at it. :)

rexjohannes commented

2026-02-01 18:03:21 -06:00

(Migrated from github.com)

Yes, WebFinger support would be nice.

starfishpatkhoo commented

2026-02-02 09:09:55 -06:00

(Migrated from github.com)

Just wanted to add my +1 to this...

Just FYI..

Tinyauth

No user management, based on a list of users in a flat file...
When used with OIDC providers, user-group / ACL management only works with docker labels and custom OAuth Providers (meaning NOT for Google or GitHub)

OAuth2-Proxy

Requires third-party OIDC providers, no user-group / ACL management at all (or DIY it fully)

Pocket-ID

Passkey only, OIDC provider only, does not work with third-party ODIC providers

Kanidm

OIDC provider, management is via logging-in via a CLI ...

Rauthy

Upstream ODIC provider supported - GitHub and Google currently (20260202)!
But Rauthy is designed to support OIDC clients, much more so than forward_auth proxies
And it's very much more complicated to configure, with more complex documentation and less examples

Authentik / Keycloak / Authelia

Sooo heavy..

My point being that VoidAuth fills a niche in this space, and being able to easily let users authenticate via password, passkey or "login with google" is really a big deal. So yes, I hope you guys manage to get to this item one day.. 😄

Just wanted to add my +1 to this... Just FYI.. Tinyauth - No user management, based on a list of users in a flat file... - When used with OIDC providers, user-group / ACL management only works with docker labels and custom OAuth Providers (meaning _NOT_ for Google or GitHub) OAuth2-Proxy - Requires third-party OIDC providers, no user-group / ACL management at all (or DIY it fully) Pocket-ID - Passkey only, OIDC provider only, does not work with third-party ODIC providers Kanidm - OIDC provider, management is via logging-in via a CLI ... Rauthy - Upstream ODIC provider supported - GitHub and Google currently (20260202)! - But Rauthy is designed to support OIDC clients, much more so than forward_auth proxies - And it's very much more complicated to configure, with more complex documentation and less examples Authentik / Keycloak / Authelia - Sooo heavy.. My point being that VoidAuth fills a niche in this space, and being able to easily let users authenticate via password, passkey or "login with google" is really a big deal. So yes, I hope you guys manage to get to this item one day.. 😄

👍 2

t-lessy commented

2026-02-03 04:42:26 -06:00

(Migrated from github.com)

Yeah, it would be great! The only thing I miss in VoidAuth is capability to merge several accounts into one. On my services, I prefer users to have no additional login-management, but log in with ready accounts.

Also, is there a chance it would be too complicated? Like, there's so many providers, even more small-to-medium regional services. I personally use Yandex and Github, but VK (for example) is overcomplicated because of being B2B. How will VoidAuth choose, which service will be included, and which will not? PRs? Requests?
Think it would be easier to use some universal model, which will be adapted in Docs for one of the providers. Would like to write Yandex guide, if this model would be chosen.

Yeah, it would be great! The only thing I miss in VoidAuth is capability to merge several accounts into one. On my services, I prefer users to have no additional login-management, but log in with ready accounts. Also, is there a chance it would be too complicated? Like, there's so many providers, even more small-to-medium regional services. I personally use Yandex and Github, but VK (for example) is overcomplicated because of being B2B. How will VoidAuth choose, which service will be included, and which will not? PRs? Requests? Think it would be easier to use some universal model, which will be adapted in Docs for one of the providers. Would like to write Yandex guide, if this model would be chosen.

notquitenothing commented

2026-06-11 18:22:06 -05:00

(Migrated from github.com)

I think before this can be worked there would need to be some decisions about the implementation:

Where will admins access interface for adding new OIDC Providers and what will that look like, I lean towards a WebUI admin page that would be compatible with generic and eventually common templates for identity providers
Will new users be created when they don't exist, and if so how to configure mapping between third-party providers and VoidAuth for things like groups or claims that are non-standard
Will existing users be able to add external providers to their accounts, and if so what happens if they choose a provider+account that has already been attached to another account
Will existing user details ever be updated based on a external provider after initial account creation

I am open to suggestions, there is currently no timeline for this functionality

I think before this can be worked there would need to be some decisions about the implementation: 1. Where will admins access interface for adding new OIDC Providers and what will that look like, I lean towards a WebUI admin page that would be compatible with generic and eventually common templates for identity providers 2. Will new users be created when they don't exist, and if so how to configure mapping between third-party providers and VoidAuth for things like groups or claims that are non-standard 3. Will existing users be able to add external providers to their accounts, and if so what happens if they choose a provider+account that has already been attached to another account 4. Will existing user details ever be updated based on a external provider after initial account creation I am open to suggestions, there is currently no timeline for this functionality

👀 1

IngwiePhoenix commented

2026-06-11 18:56:35 -05:00

(Migrated from github.com)

A few insights I can offer:

WebUIs are often the easiest choice. If you do want to use environment variables on the deployment, look at Grafana's - I think they are the cleanest implementation. The second best is ArgoCD, which allows you to map OIDC groups straight into roles. I see those two as great implementations - different in design, but very clean and versatile. As for templates; in most cases the only real differences are known URL paths. For example with Keycloak: https://$keycloakUrl/realms/$realmName/.well-known/openid-configuration. For OIDC providers that do not offer this (of which I genuenly don't know any), those URLs are often default paths. So basically, a dropdown that pre-fills parts of a form, is effectively half the way.
Again, Grafana and ArgoCD do this well - unknown groups can be mapped to a default group/role. Most often, user sync happens each time the OIDC flow is triggered - as in, when a token/object is obtained and you get to read out the claims.
Vaultwarden uses E-Mail address matching to make this work - that said, their OIDC implementation is very new. In Grafana and KeepHQ however, the same principal is applied; use a common demoninator, match remote versus local, merge - and optionally store a (refresh-)token to the respective provider.
Basically 3. :)

Those are just my insights from setting up a whole crapton of those over the years at my company, doing the mappings and whatnot. For example; I am mapping our Windows Active Directory to Keycloak Groups via their group-mapper, which I can then use in ArgoCD to determine that anyone with the group "Department-Technician" should have admin rights - whilst certain others have moderation permissions and the rest is plain read-only. But, different applications handle things...well, differently.

The groups claim is kinda universal; roles I have not met a whole lot so far. Other claims like openid, profile and email are very common.

I hope this helps! =)

A few insights I can offer: 1. WebUIs are often the easiest choice. If you _do_ want to use environment variables on the deployment, look at Grafana's - I think they are the cleanest implementation. The second best is ArgoCD, which allows you to map OIDC groups straight into roles. I see those two as great implementations - different in design, but very clean and versatile. As for templates; in most cases the only real differences are known URL paths. For example with Keycloak: `https://$keycloakUrl/realms/$realmName/.well-known/openid-configuration`. For OIDC providers that do not offer this (of which I genuenly don't know any), those URLs are often default paths. So basically, a dropdown that pre-fills parts of a form, is effectively half the way. 2. Again, Grafana and ArgoCD do this well - unknown groups can be mapped to a default group/role. Most often, user sync happens each time the OIDC flow is triggered - as in, when a token/object is obtained and you get to read out the claims. 3. Vaultwarden uses E-Mail address matching to make this work - that said, their OIDC implementation is very new. In Grafana and KeepHQ however, the same principal is applied; use a common demoninator, match remote versus local, merge - and optionally store a (refresh-)token to the respective provider. 4. Basically 3. :) Those are just my insights from setting up a whole crapton of those over the years at my company, doing the mappings and whatnot. For example; I am mapping our Windows Active Directory to Keycloak Groups via their group-mapper, which I can then use in ArgoCD to determine that anyone with the group "Department-Technician" should have admin rights - whilst certain others have moderation permissions and the rest is plain read-only. But, different applications handle things...well, differently. The `groups` claim is kinda universal; `roles` I have not met a whole lot so far. Other claims like `openid`, `profile` and `email` are very common. I hope this helps! =)

Rows
Columns

OIDC federation? #144

Describe your idea for an enhancement:

Describe alternatives you've considered:

Additional context: