RFC: Optional OIDC/SSO sign-in (Authentik, Keycloak, etc.) — pros/cons

[Foowy]

Context

There's been some Discord chat about letting ShokoServer authenticate against an external identity provider (Authentik, Keycloak, etc.) instead of — or alongside — local username/password accounts. Opening this as a discussion to weigh it up properly rather than jumping straight to a PR.

To be clear about scope: this would be additive, not a replacement. Local accounts and the existing Auth/SignIn flow would keep working exactly as they do today; OIDC would just be a second, opt-in way to obtain the same kind of API token, off by default, configured after install (not part of first-run setup).

What this would look like technically

ShokoServer's auth model is already a good fit for this: AuthController.SignIn authenticates a user and calls GenerateApiTokenForUser, which mints an opaque API token independent of how the user was authenticated. Adding OIDC means adding a second path into that same token-minting call:

1. A redirect-based OAuth2/OIDC Authorization Code flow (/Auth/Oidc/Challenge → provider → /Auth/Oidc/Callback), using standard discovery (/.well-known/openid-configuration) and JWKS validation — no custom crypto.
2. A new nullable column on JMMUser (e.g. ExternalAuthID) to link an OIDC subject claim to a local account.
3. The WebUI gets an optional "Sign in with SSO" button next to the existing form, shown only when the server reports OIDC is configured.

Common open-source providers this would target

None of these are ShokoServer-specific — the point of OIDC is that any spec-compliant provider works the same way:

• Authentik — full-featured self-hosted IdP, popular in homelab setups, has first-class support in reverse proxies like Caddy/Traefik.
• Keycloak — mature, enterprise-grade, backed by Red Hat, heavier resource footprint.
• Authelia — lighter-weight, historically more forward-auth/proxy-focused but has grown OIDC provider support.
• Zitadel — newer, cloud-native-first, also self-hostable.
• Pocket ID — minimal, passkey-first OIDC provider aimed squarely at homelabs.

Any of these (or a hosted provider like Google/Microsoft/GitHub as an OIDC endpoint) would work without provider-specific code, since it's all just standard OIDC discovery + JWKS.

Pros

• Centralized identity for people already running SSO across their homelab/media stack (Jellyfin, Audiobookshelf, and others already support OIDC) — one account, one password, one place to manage MFA.
• Sidesteps ShokoServer's own credential storage entirely for anyone who uses it — the IdP owns password storage/hashing/rotation, so weaknesses in Shoko's own local-account handling stop being relevant for SSO users.
• Better audit/session control at the IdP level — revoke a user everywhere at once, enforce MFA centrally, etc.
• Doesn't require touching first-run setup — it's a pure opt-in addition, zero impact on anyone who doesn't configure it.

Cons / open questions

• Added complexity and a new dependency (an OIDC/JWT validation library) in a codebase that currently has zero auth dependencies beyond its own token model — more surface area to maintain and keep patched.
• Account linking is a real design question. Auto-creating local accounts from IdP claims is a privilege-escalation risk (anyone in the IdP could become a full Shoko admin) — the safer default is link-only (match by username/email to a pre-existing local account), but that means an admin still has to manually create the local account first, which blunts some of the "just use SSO" appeal.
• Self-hosted single-user installs get little benefit — a lot of Shoko installs are one admin account with no other users; OIDC mainly helps multi-user setups or people who already run centralized auth.
• WebUI complexity — the login page currently has zero redirect flows; this introduces one (full-page navigation away from and back to the SPA), which is a new class of bug surface (state/nonce handling, error redirects, etc.) even though it's kept out of the SPA's normal token-based model as much as possible.
• Testing burden — this is the kind of feature that's hard to meaningfully unit test (it depends on a live IdP's discovery document and token exchange), so verifying it end-to-end needs a real or mocked provider in CI.

Ask

Mainly looking for a read from maintainers/community on:

1. Is this something the project wants at all, given the added dependency/maintenance surface?
2. If so, does "link-only to a pre-existing local account" match expectations, or is there appetite for auto-provisioning (with appropriate guardrails)?
3. Any strong opinions on which provider(s) to test against for CI/documentation purposes?

Happy to open a WIP PR with a working prototype if there's interest — wanted to gauge direction first rather than land a large auth-adjacent PR unsolicited.

[Foowy]

One scope note I should have included up front: this would touch both repos — the OIDC endpoints/settings/DB migration live in ShokoServer, but the login page also needs a small change in Shoko-WebUI (an opt-in SSO button plus handling the redirect back from the provider). Any review/decision here would need to account for changes landing in both places, not just the server.

[da3dsoul]

I'll add one more con: it gives the illusion that shoko is secure. It is not

[da3dsoul]

I say throw the existence of this feature behind a json-only setting. The webui can't read it on connect to know whether to even show the SSO option.

[da3dsoul]

For ease of the webui, you could throw that flag in API/init/status

[Foowy]

that should work, i was thinking a hidden button that only emits it's existence when OIDC is configured, other than that, i would not show. That way it is another point of entry without breaking current user/pass dialog

[harshithmohan]

Just make it a json-only setting and put the disclaimer in the docs

[Foowy]

Looks achievable, will let this discussion bake for 24 hours before working on anything, mainly to get other opinions or last minute "Nope" out of the way.