WorkOS auth follow-up: unify oRPC auth, harden OpenCode OAuth, add identity rate limits

[anand-testcompare]

Goal

Finish the WorkOS-based auth foundation across Sketchi surfaces by making the remaining API/auth behavior consistent, explicit, and enforceable.

Already shipped

• WorkOS AuthKit is integrated in the web app.
• Sign-in/sign-out UI exists and protected web routes redirect to sign-in.
• The OpenCode plugin supports WorkOS device-flow login.
• Convex persists end-user identity in users.
• Diagram sessions/threads and icon libraries already enforce basic ownership and visibility checks.
• Private/public icon-library visibility exists, along with admin/public-editor allowlists.

Remaining scope

1. Unified API auth context

The oRPC/API layer still needs a clean, explicit auth model.

• Support the real inbound auth shapes we actually want to keep:
  • authenticated web requests
  • WorkOS bearer-token requests from OpenCode / API clients
• Normalize requests to one internal auth subject shape:
  • externalId
  • userId
  • authMethod
• Return clean 401/403 behavior for protected operations.
• Keep explicitly public endpoints anonymous by design.

2. OpenCode OAuth hardening

The device-flow foundation exists, but the end-to-end behavior still needs to be hardened and clarified.

• Verify refresh/expiry behavior end-to-end.
• Verify logout / token invalidation expectations.
• Ensure plugin requests map to the same user identity seen in web.
• Tighten docs so the OpenCode auth behavior is unambiguous.

3. Authorization hardening

• Make ownership/authorization checks consistent across diagram and icon-library mutations.
• Codify the long-term policy for:
  • admin users
  • public icon-library editors
  • ordinary authenticated users
• Remove any remaining route/handler ambiguity about which operations require auth.

4. Identity-based protections

• Add rate limiting on sensitive write/generation paths by identity.
• Add basic audit logging for auth failures and abuse-relevant events.

Non-goals

• No custom API key system for now.
• No M2M/service-account auth.
• No broad auth redesign unrelated to the current WorkOS-based user model.

If a concrete automation use case later proves OAuth insufficient, API-key work can be reopened as its own issue.

Implementation strategy

1. Tighten the oRPC auth boundary so request authentication is explicit and normalized.
2. Harden the OpenCode OAuth/device-flow behavior and document it properly.
3. Consolidate authorization checks and admin/editor policy enforcement.
4. Add rate limiting and basic audit logging on the important protected paths.

Acceptance criteria

• Protected API operations authenticate consistently for supported clients.
• Public routes remain public by design.
• OpenCode OAuth behaves predictably for sign-in, expiry, and user identity mapping.
• Diagram/icon-library writes enforce the intended ownership/admin/editor rules.
• Sensitive write/generation paths are rate-limited by identity.
• Auth failures and abuse-relevant events are observable.

Test plan

• convex: authorization checks for diagram sessions/threads and icon libraries.
• api: protected oRPC routes reject missing/invalid auth and accept valid auth.
• manual: web sign-in/sign-out, protected-route redirects, OpenCode device-flow sign-in, and post-login access verification.