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:
- Accept the openid scope on POST /oauth2/token (alongside identify, email, etc.)
- 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.
- 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.
- 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:
- 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:
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.