Add OpenID Connect (OIDC) support for Supabase / Auth0 / Clerk / generic SSO integrations

[Ariz-z]

Problem

Developers building apps on Supabase, Auth0, Clerk, WorkOS, NextAuth, or any generic OIDC-based identity platform can't plug
Fluxer in as a login provider, even though these platforms explicitly support custom OIDC providers (e.g. Supabase's Custom OAuth Provider: https://supabase.com/docs/guides/auth/custom-oauth-providers).

Today Fluxer's OAuth2 is Discord-style (OAuth 2.0 only), not OIDC. For any app using a managed auth platform, this forces developers to either:

• Write a custom OIDC shim that proxies Fluxer (~200+ LOC, needs key management and ID token signing — error-prone), or
• Skip Fluxer login entirely and use Discord / Google / email instead.

The affected audience is anyone building developer-facing apps on Fluxer (bot directories, analytics dashboards, moderation tools, marketplaces) that rely on managed auth providers — which is the majority of modern SaaS stacks.

Fluxer is already ~80% of the way there: /oauth2/userinfo already returns a top-level sub claim, email is scope-gated, and refresh tokens work. Closing the remaining 20% would unlock first-class integration with every major identity platform.

Proposed solution

Add standards-compliant OIDC on top of the existing OAuth2 layer. Concretely:

1. Accept the openid scope on POST /oauth2/token (alongside identify, email, etc.)
2. Return an id_token (signed JWT) in the token response when openid is in the granted scopes. Required claims: iss, sub, aud, exp, iat. Optional: email, email_verified, preferred_username, name, picture.
3. Publish a JWKS endpoint at /.well-known/jwks.json (or /oauth2/jwks) exposing the public signing keys used for the ID tokens, with key rotation support.
4. Publish the OIDC discovery document at /.well-known/openid-configuration, pointing at the existing authorize / /oauth2/token / /oauth2/userinfo / JWKS endpoints and declaring supported scopes, response types, and signing algorithms. This one file is what auto-discovery in Supabase / Auth0 / Clerk reads — it's the difference between "paste an issuer URL and you're done" vs "manually enter five URLs and debug why it doesn't work."

Additionally — minor but related:
5. Add preferred_username and picture claims to the /oauth2/userinfo response when identify is granted (derived from username and avatar URL). Most OIDC clients look for these standard claim names.

Notes (optional)

Relevant docs/endpoints that already exist:

• GET /oauth2/userinfo — already returns top-level sub ✅
• POST /oauth2/token — authorization_code + refresh_token flows work ✅
• GET /.well-known/fluxer — precedent for a well-known discovery pattern ✅

Gap summary:

┌───────────────────────────────────┬──────────────┐
│ OIDC requirement │ Fluxer today │
├───────────────────────────────────┼──────────────┤
│ sub in userinfo │ ✅ │
├───────────────────────────────────┼──────────────┤
│ Refresh tokens │ ✅ │
├───────────────────────────────────┼──────────────┤
│ Email scope │ ✅ │
├───────────────────────────────────┼──────────────┤
│ openid scope │ ❌ │
├───────────────────────────────────┼──────────────┤
│ id_token in token response │ ❌ │
├───────────────────────────────────┼──────────────┤
│ JWKS endpoint │ ❌ │
├───────────────────────────────────┼──────────────┤
│ /.well-known/openid-configuration │ ❌ │
└───────────────────────────────────┴──────────────┘

Reference implementations to look at:

• GitHub's OIDC discovery: https://token.actions.githubusercontent.com/.well-known/openid-configuration
• Google: https://accounts.google.com/.well-known/openid-configuration
• OIDC Core 1.0 spec: https://openidconnect.net/specs/openid-connect-core-1_0.html
• OIDC Discovery 1.0 spec: https://openid.net/specs/openid-connect-discovery-1_0.html

Suggested signing approach:
RS256 with a rotating keypair (one active, one retired), both published in JWKS. Same model everyone else uses.

Scope of change:
This is additive — no breaking changes. Existing OAuth2-only clients continue to work unchanged. Only clients that explicitly
request the openid scope get an ID token back.

Happy to help beta-test once a dev build is available.

Checks

• I searched for existing discussions and didn't find a duplicate.