feat: OAuth middleware with module loaders for identity/secrets/auth config

[pyramation]

Summary

Refactors the OAuth/SSO middleware from PR #1141 to use the module loader architecture from express-context, addressing the review issues Dan identified.

What changed

New module loaders (packages/express-context/src/loaders/):

• encryptedSecretsLoader — resolves encrypted_secrets_module from metaschema_modules_public to find the correct schema for decrypting secrets (replaces hardcoded metaschema JOIN)
• userAuthLoader — resolves user_auth_module for sign_in/sign_up function names and the schema they live in (no longer assumes privateSchema)
• identityProvidersLoader — resolves identity_providers_module for provider config table location (schema + table name, not hardcoded)

All three are registered in createDefaultRegistry() and added to BuiltinModuleMap for typed useModule() access.

OAuth middleware (graphql/server/src/middleware/oauth.ts):

• Uses req.constructive.useModule() to resolve all per-database config (identity providers, encrypted secrets, user auth, auth settings) — no manual metaschema queries
• Uses req.constructive.withPgClient() for RLS-scoped transactions with automatic pgSettings — replaces manual set_config('jwt.claims.*', ..., false) calls
• Removes express-rate-limit — DB already handles rate limiting via auth_rate_limits / app_settings_rate_limit
• Uses getNodeEnv() from @pgpmjs/env instead of process.env.NODE_ENV
• sign_in_identity / sign_up_identity are called in the userAuth.schemaName — not assumed to be in the RLS privateSchema
• Extracts email_verified from the raw provider profile data (OAuthProfile doesn't expose it directly)

Server wiring (graphql/server/src/server.ts):

• Passes createDefaultRegistry() as loaders to createContextMiddleware() — enables useModule() on req.constructive
• Mounts OAuth routes at /auth

Issues addressed from #1141 review

Comment	Issue	Resolution
#8	getEncryptedSecretsSchema uses fragile metaschema JOIN with privateSchema	Replaced with encryptedSecretsLoader querying encrypted_secrets_module by database_id
#9	process.env.NODE_ENV used directly	Replaced with getNodeEnv() from @pgpmjs/env
#10-11	express-rate-limit is per-process, redundant with DB rate limiting	Removed entirely
#12	Manual set_config('jwt.claims.*') with false (session-level)	Uses withPgClient() which applies pgSettings via SET LOCAL (transaction-scoped)
#13-14	Assumes sign_in_identity/sign_up_identity live in privateSchema	Resolved via userAuthLoader which finds the actual schema from user_auth_module
#15	Hardcoded OAUTH_STATE_MAX_AGE, requireVerifiedEmail, errorRedirectPath	Uses configurable defaults; email_verified extracted from raw profile

Review & Testing Checklist for Human

This is a medium-risk PR since OAuth is a security-sensitive flow and the module loaders are querying real module tables that must exist in the tenant database.

• Verify the SQL in encryptedSecretsLoader, userAuthLoader, and identityProvidersLoader matches the actual metaschema_modules_public table schemas in the deployed databases (column names, JOINs, WHERE clauses)
• Confirm identity_providers_module has a private_schema_id column that JOINs to metaschema_public.schema — the loader assumes this
• Test a full OAuth flow end-to-end: initiate → provider redirect → callback → sign_in_identity → cookie/token set
• Verify withPgClient() correctly scopes the jwt.claims.user_agent and jwt.claims.origin settings to the transaction (the true flag in set_config means transaction-local)
• Confirm createDefaultRegistry() is only called once per server instance (it's called in the constructor, so it should be fine)

Notes

• This is a successor to feat(oauth): OAuth identity sign-in with cross-origin token exchange #1141 which introduced the initial OAuth middleware. This PR rewrites it to leverage the module loader infrastructure that was built in PRs refactor(api): replace inline SQL with modular loader registry #1217 and feat: add billing/inferenceLog/agentChat module loaders + wire into agentic-server #1219.
• The OAuthProfile type from @constructive-io/oauth doesn't include emailVerified — we extract it from profile.raw which contains the original provider response. A follow-up could add emailVerified to the OAuthProfile type.
• The session_credentials table used in generateCrossOriginToken is accessed via userAuth.schemaName — this assumes it lives in the same schema as sign_in_identity. Worth verifying.

Link to Devin session: https://app.devin.ai/sessions/0796902ebeba4f6ea1900d84deab2fc5
Requested by: @pyramation

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[theothersideofgod]

PR #1141 / #1220 - Issues Addressed

---

Issue 1: Don't hardcode schema names, use loaders

Reviewer feedback: Should not assume privateSchema is where auth functions live

Commit	Resolution
ebe0dafd7	userAuthLoader adds sessionCredentialsSchemaName, JOINs session_credentials_table_id to find correct schema
c310328e0	New connectedAccountsLoader resolves schema from connected_accounts_module
b450bd085	oauth.ts uses identityProviders.privateSchemaName instead of hardcoded schema

-- Before: assumed session_credentials in userAuth.schemaName
-- After: JOIN to find correct schema
LEFT JOIN metaschema_public.table sc_table ON sc_table.id = uam.session_credentials_table_id
LEFT JOIN metaschema_public.schema sc_schema ON sc_schema.id = sc_table.schema_id

---

Issue 2: Don't catch IDENTITY_ACCOUNT_NOT_FOUND exception

Reviewer feedback: Using exceptions for control flow is bad practice; query identity existence first

Commit	Resolution
c310328e0	New connectedAccountsLoader provides schema/table info for connected_accounts
b450bd085	oauth.ts callback queries identity existence via ctx.pool before sign-in

// Before: try sign_in → catch IDENTITY_ACCOUNT_NOT_FOUND → sign_up
// After: query first, then decide
let identityExists = false;
if (connectedAccounts) {
  const checkSql = \`
    SELECT 1 FROM "\${connectedAccounts.privateSchemaName}"."\${connectedAccounts.tableName}"
    WHERE service = \$1 AND identifier = \$2
    LIMIT 1
  \`;
  const checkResult = await ctx.pool.query(checkSql, [profile.provider, profile.providerId]);
  identityExists = checkResult.rows.length > 0;
}

if (identityExists) {
  // sign_in_identity
} else {
  // sign_up_identity
}

Why ctx.pool: Bypasses RLS since anonymous users cannot query connected_accounts table

---

Issue 3: session_credentials schema cannot be assumed

Reviewer feedback (PR #1220): session_credentials table may not be in userAuth.schemaName

Commit	Resolution
ebe0dafd7	userAuthLoader adds sessionCredentialsSchemaName field
ebe0dafd7	SQL JOINs session_credentials_table_id → metaschema_public.table → metaschema_public.schema
ebe0dafd7	Falls back to schema_name if JOIN result is null

return {
  schemaName: row.schema_name,
  sessionCredentialsSchemaName:
    row.session_credentials_schema_name || row.schema_name, // fallback
  // ...
};

---

Issue 4: PgInterval handling

Problem: PostgreSQL interval type is parsed by pg library as object {minutes: 10} not string

Commit	Resolution
c6e6a43b0 (prior)	oauth.ts adds parseIntervalToMs for OAuth state cookie
496ed7a01	cookie.ts adds parseIntervalToSeconds for session cookie

---

Issue 5: encryptedSecrets loader using wrong module table

Problem: encryptedSecretsLoader was querying encrypted_secrets_module which doesn't exist; the generator creates app_secrets as part of config_secrets_user_module

Commit	Resolution
317f9c42f	Initial fix attempted config_secrets_org_module (incorrect - that's for org_secrets)
f0b1be4f8	Final fix: Use config_secrets_user_module + hardcode tableName: 'app_secrets'

-- Final SQL in encryptedSecretsLoader
SELECT s.schema_name
FROM metaschema_modules_public.config_secrets_user_module csm
JOIN metaschema_public.schema s ON s.id = csm.schema_id
WHERE csm.database_id = $1

Why hardcode app_secrets: The generator always creates user_secrets and app_secrets in the same schema from config_secrets_user_module. The table name is deterministic.

---

Issue 6: client_secret lookup via non-existent function

Problem: getIdentityProvider called schema.get() function that doesn't exist

Commit	Resolution
2de79a9b1	Use JOIN to fetch client_secret from app_secrets table directly

-- JOIN to get decrypted secret
SELECT
  ip.slug, ip.kind, ip.display_name, ip.enabled, ip.client_id,
  convert_from(secrets.value, 'UTF8') as client_secret,
  ip.authorization_url, ip.token_url, ip.userinfo_url, ip.scopes, ip.pkce_enabled
FROM "${privateSchemaName}"."${tableName}" ip
LEFT JOIN "${encryptedSchema}"."${encryptedTableName}" secrets 
  ON secrets.id = ip.client_secret_id
WHERE ip.slug = $1 AND ip.enabled = true

---

Commit Summary

Commit	Description	Issues
f0b1be4f8	Fix encryptedSecrets to use config_secrets_user_module	#5
2de79a9b1	Use JOIN to fetch client_secret	#6
b450bd085	Identity pre-check via connectedAccounts query	#2
496ed7a01	Handle PgInterval in session cookie config	#4
c310328e0	Add connectedAccounts loader	#1, #2
ebe0dafd7	Add sessionCredentialsSchemaName to userAuth	#1, #3
317f9c42f	Fix encryptedSecrets loader (superseded by f0b1be4)	-
c6e6a43b0	Integrate DB settings for OAuth state cookie	#4
589b6adde	Original OAuth middleware (pyramation)	-

---

Reviewer Comments → Solutions Mapping

This section maps specific reviewer feedback from PR #1141 and #1220 to our implementation commits.

---

From devin-ai-integration (PR #1141 final comment):

Key changes in #1220:

• sign_in_identity / sign_up_identity called in userAuth.schemaName — not assumed to be in the RLS privateSchema

Our solution:

Commit	Resolution
ebe0dafd7	userAuthLoader dynamically resolves sessionCredentialsSchemaName via JOIN
b450bd085	oauth.ts uses identityProviders.privateSchemaName instead of hardcoded schema

---

From devin-ai-integration (PR #1141 "DB Settings Available"):

Replace hardcoded constants:

• OAUTH_STATE_MAX_AGE = 10 * 60 * 1000 → oauth_state_max_age
• requireVerifiedEmail ?? true → oauth_require_verified_email
• errorRedirectPath ?? '/auth/error' → oauth_error_redirect_path

Our solution:

Commit	Resolution
c6e6a43b0	Read oauthStateMaxAge, oauthRequireVerifiedEmail, oauthErrorRedirectPath from authSettings
496ed7a01	cookie.ts handles PgInterval type from PostgreSQL

---

From pyramation review:

"Should not use privateSchema assumption, use loaders instead"
"Should not catch IDENTITY_ACCOUNT_NOT_FOUND, query identity existence first"

Our solution:

Issue	Commit	Resolution
privateSchema assumption	c310328e0, b450bd085	New connectedAccountsLoader, use identityProviders.privateSchemaName
catch exception pattern	b450bd085	Pre-query connected_accounts table via ctx.pool.query()

---

From PR #1220 Review Checklist:

• session_credentials schema cannot be assumed to be in userAuth.schemaName

Our solution:

Commit	Resolution
ebe0dafd7	userAuthLoader JOINs session_credentials_table_id to find correct schema, falls back to schema_name if null

---

Architecture: Loaders vs Runtime Queries

Why the identity check is NOT in a loader:

Loaders (configuration queries):
├── Input: databaseId (fixed per tenant)
├── Output: schema/table names (configuration)
├── Caching: ✅ 5-minute TTL
└── Same result for all requests to same database

Identity Check (business logic query):
├── Input: provider + providerId (varies per request)
├── Output: boolean (exists or not)
├── Caching: ❌ Must be real-time
└── Different params for every OAuth callback

The loader provides the configuration (which schema/table to query), and the middleware executes the business logic (does this specific identity exist).

[devin-ai-integration]

Devin is archived and cannot be woken up. Please unarchive Devin if you want to continue using it.

[pyramation]

this should be made into one of those getModule() calls, no?

[devin-ai-integration]

Review Summary

The initial commit (589b6ad by @pyramation) established a clean module loader pattern. The subsequent commits by @theothersideofgod introduce several issues that break those patterns. Details in inline comments below.

Critical issues:

1. sign_in_identity/sign_up_identity switched from userAuth.schemaName to identityProviders.privateSchemaName — defeats the purpose of the userAuthLoader
2. Encrypted secrets loader changed from encrypted_secrets_module to config_secrets_user_module with hardcoded 'app_secrets' table name — breaks dynamic resolution
3. Replaced the get() decryption function with raw convert_from(secrets.value, 'UTF8') — bypasses the encryption layer
4. ctx.pool.query for identity pre-check bypasses RLS entirely
5. Manual set_config('jwt.claims.*') calls inside withPgClient — withPgClient already handles pgSettings via SET LOCAL, so these should be passed through the existing pgSettings infrastructure rather than manually setting GUC variables
6. Duplicate PgInterval type and interval parsing logic (defined locally in oauth.ts and also in express-context types + cookie.ts)
7. The getIdentityProvider function was flagged to be converted into a module loader call — not addressed

[devin-ai-integration]

PgInterval is already defined in @constructive-io/express-context types (and exported). This is a duplicate definition — should import from the shared types instead of redefining it locally.

[devin-ai-integration]

This parseIntervalToMs is near-identical to parseIntervalToSeconds in cookie.ts. Should be a single shared utility rather than duplicated parsing logic in two files.

[devin-ai-integration]

This replaces userAuth.schemaName with identityProviders.privateSchemaName for calling sign_in_identity / sign_up_identity. The original code deliberately used userAuth.schemaName because the whole point of the userAuthLoader is to resolve exactly which schema the auth functions live in. Using identityProviders.privateSchemaName defeats the purpose of having a separate userAuthLoader — it goes back to assuming these functions live in a schema determined by an unrelated module.

[devin-ai-integration]

Two issues here:

1. Wrong table — app_secrets vs user_secrets
The encryptedSecrets loader was changed to hardcode tableName: 'app_secrets', but identity_providers.client_secret_id is a UUID pointer into user_secrets, not app_secrets. The rotate_identity_provider_secret procedure writes to user_secrets (with owner_id = provider_id, name = 'oauth_client_secret', algo = 'pgp'). app_secrets is a different table with different columns (key_id, namespace_id) for admin-level secrets.

2. convert_from(secrets.value, 'UTF8') bypasses PGP decryption
OAuth client secrets are stored with algo = 'pgp' — the BEFORE INSERT trigger PGP-encrypts the value using owner_id as the symmetric key. Raw convert_from will return encrypted garbage.

The correct approach is to call the generated user_secrets_get function which handles decryption based on the algo field:

"${schemaName}".user_secrets_get('oauth_client_secret', NULL, ip.id) as client_secret

This calls pgp_sym_decrypt(value, owner_id::text) internally for PGP-encrypted rows.

[devin-ai-integration]

This queries connected_accounts via ctx.pool.query — bypasses RLS entirely. The original pattern kept the entire sign-in/sign-up flow inside withPgClient which applies pgSettings via SET LOCAL.

[devin-ai-integration]

withPgClient already applies pgSettings (role, claims, request_id) via SET LOCAL. These manual set_config('jwt.claims.*') calls should go through the existing pgSettings infrastructure rather than manually setting GUC variables inside the transaction.

[devin-ai-integration]

This replaces userAuth.schemaName with identityProviders.privateSchemaName for calling sign_in_identity / sign_up_identity. The original code deliberately used userAuth.schemaName because the whole point of the userAuthLoader is to resolve which schema the auth functions live in. Using identityProviders.privateSchemaName defeats the purpose of having a separate userAuthLoader.

[devin-ai-integration]

Inconsistency: generateCrossOriginToken still uses modules.userAuth.schemaName for session_credentials, but sign_in/sign_up were switched to identityProviders.privateSchemaName. If the schema resolution needed to change, it should be consistent.

[devin-ai-integration]

Switching to config_secrets_user_module is correct (per Dan's guidance), but two issues:

1. Hardcoded 'app_secrets' — breaks the dynamic resolution pattern. The config_secrets_user_module table already has table_id — should resolve the table name via the table_id JOIN like the other loaders do, rather than hardcoding.

2. Wrong table for OAuth — identity_providers.client_secret_id points to user_secrets (the table registered in config_secrets_user_module.table_id), NOT app_secrets. The rotate_identity_provider_secret procedure writes to user_secrets with owner_id = provider_id. app_secrets is a different table with key_id/namespace_id columns for admin-level application secrets.

The loader should resolve the user_secrets table (which is what config_secrets_user_module.table_id points to), and the OAuth middleware should call the generated user_secrets_get('oauth_client_secret', NULL, ip.id) function to decrypt.

[theothersideofgod]

Fix Summary

Thanks for the review! Here's what was addressed:

✅ Fixed

Comment	Commit	Description
@pyramation: getIdentityProvider should be a loader	fce5a68	Added identityProviderConfigLoader — loads all enabled providers into a Map for O(1) lookup
@devin: PgInterval duplicate	f5be21a	Removed local definition, import from @constructive-io/express-context
@devin: parseIntervalToMs duplicate	f5be21a	Exported parseIntervalToSeconds from cookie.ts, oauth.ts uses * 1000
@devin: app_secrets vs user_secrets	58f153e	Changed to user_secrets (verified identity_providers.client_secret_id points to user_secrets)
@devin: ctx.pool bypasses RLS	f5be21a	Removed connectedAccounts pre-check, switched to exception-based flow (try sign_in_identity, catch IDENTITY_ACCOUNT_NOT_FOUND, then sign_up_identity)
@devin: schemaName inconsistency for session_credentials	f5be21a	Changed to sessionCredentialsSchemaName (verified session_credentials is in auth_private)

💬 Not Changed (With Reason)

Comment	Reason
@devin: should use userAuth.schemaName not privateSchemaName	Verified that sign_in_identity is in identity_providers_module.private_schema_id (auth_private), not user_auth_module.schema_id (auth_public). Devin's suggestion was incorrect.
@devin: manual set_config should use pgSettings	user_agent and origin are OAuth-specific claims not in the standard pgSettings. Manual setting is required.

---

Please review the new commits. Let me know if there are any issues!