Problem
The OAuth/SSO flow is currently duplicated across apps and is partly mixed into app-specific code. We should centralize the auth-server/client behavior in packages/sso so me and admin use the same auth primitives and configuration.
Specific Code To Centralize
The reusable auth flow currently lives in app-local wrappers that mostly just build config and forward to AuthClient:
apps/me/src/lib/auth/oauth.tsapps/admin/src/lib/auth/oauth.ts
Those wrappers are thin enough that they should be replaced by package-level helpers or a small package config adapter.
The app entrypoints that should consume the shared package instead of owning auth primitives directly are:
apps/me/src/app/api/auth/login/route.tsapps/me/src/app/api/auth/callback/route.tsapps/me/src/app/api/auth/logout/route.tsapps/me/src/app/api/auth/me/route.tsapps/me/src/lib/auth/server.tsapps/admin/src/lib/auth/server.tsapps/admin/src/lib/auth/cookies.tsapps/admin/src/lib/auth/session.ts
Scope
Move shared SSO/auth concerns into packages/sso, likely including:
- OAuth/OIDC config types
- Auth URL generation
- PKCE helpers
- token exchange/refresh/revoke helpers
- userinfo fetch helpers
- shared env parsing or config normalization for the auth server URL and client credentials
Keep app-specific behavior in the apps themselves:
- cookie storage / retrieval
- Next.js route handlers and middleware
- app-specific redirect handling
- app-specific session shaping
Goal
Make apps/me and apps/admin consume the shared SSO package rather than each owning its own copy of the auth flow logic.
Acceptance Criteria
packages/sso exposes a reusable API for auth flow primitives.apps/me and apps/admin use the package instead of local duplicated SSO logic.- Tests cover the shared auth helpers and the app integrations that remain app-specific.
- No behavior change for existing login / refresh / logout flows.
Notes
This should probably be done incrementally so we can preserve existing behavior in staging while moving only the reusable parts first.
Problem
The OAuth/SSO flow is currently duplicated across apps and is partly mixed into app-specific code. We should centralize the auth-server/client behavior in
packages/ssosomeandadminuse the same auth primitives and configuration.Specific Code To Centralize
The reusable auth flow currently lives in app-local wrappers that mostly just build config and forward to
AuthClient:apps/me/src/lib/auth/oauth.tsapps/admin/src/lib/auth/oauth.tsThose wrappers are thin enough that they should be replaced by package-level helpers or a small package config adapter.
The app entrypoints that should consume the shared package instead of owning auth primitives directly are:
apps/me/src/app/api/auth/login/route.tsapps/me/src/app/api/auth/callback/route.tsapps/me/src/app/api/auth/logout/route.tsapps/me/src/app/api/auth/me/route.tsapps/me/src/lib/auth/server.tsapps/admin/src/lib/auth/server.tsapps/admin/src/lib/auth/cookies.tsapps/admin/src/lib/auth/session.tsScope
Move shared SSO/auth concerns into
packages/sso, likely including:Keep app-specific behavior in the apps themselves:
Goal
Make
apps/meandapps/adminconsume the shared SSO package rather than each owning its own copy of the auth flow logic.Acceptance Criteria
packages/ssoexposes a reusable API for auth flow primitives.apps/meandapps/adminuse the package instead of local duplicated SSO logic.Notes
This should probably be done incrementally so we can preserve existing behavior in staging while moving only the reusable parts first.