Add support for OIDC authentication #586
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 4 commits
July 13, 2025 00:33
Allows users to use an external OIDP identity provider for logging into the admin interface. For users logged in via OIDC, a random secure password is generated and a new option to reveal the password is shown in the web interface for use with subsonic clients.
lava
force-pushed
the
feature/oidc-authentication
branch
from
520ab00 to
dcee305
Compare
|
Very nice to have! |
sentriz
force-pushed
the
master
branch
5 times, most recently
from
7decea6 to
971d22d
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
Passwords are old-school, and many people who are into self-hosting their software already have a centralized identity server for SSO. By offloading authentication to a separate service, we immediately gain support for 2FA, password reset flows, passkey support, identity federation, and whatever else your identity provider of choice offers.
This PR goes a bit beyond the minimal possible OIDC support, but in exchange it gets to a state where all the existing behavior can still be used without disruption when opting for OIDC.
In particular:
password,oidcandoidc-forwardauthentication methods. By default,passwordis selected and the gonic behavior is exactly as it was before this PR.subclaim.oidcandoidc-forwardcorrespond to the two popular choices of deploying OIDC: one is that the app natively supports OIDC and redirects users to the identity provider itself, the other is that something external to the app (like oauth2-proxy) is handling the whole login and just forwards the obtained token which the app then reads. Which one is preferred depends heavily on the other software in use, and in the end they share 95% of the same code, so I just added support for both.rolesclaim in the token), but works for an initial implementation.AI disclaimer
I'm not a Go developer, so most of the actual code was written by Claude. I did however work professionally on implementing OIDC support for various products, and looked over all the generated code to verify it's correct to the best of my ability.