OAuth security hardening: RFC compliance, PKCE binding, rate limiting (#18305)

## Summary

Follow-up to #18267. Hardens the OAuth implementation with security
fixes identified during audit:

**P0 — Critical:**
- Bind authorization codes to `client_id` in context to prevent auth
code injection (RFC 6749 §4.1.3)
- Store PKCE `code_challenge` directly in auth code context instead of a
separate `CodeChallenge` token — cryptographically binds the challenge
to its code
- Enforce `code_verifier` when `code_challenge` was used during
authorization
- Hash authorization codes (SHA-256) before storage to prevent exposure
if DB is compromised
- Add `Cache-Control: no-store` + `Pragma: no-cache` headers on token
responses (RFC 6749 §5.1)
- Add rate limiting on `/oauth/token` endpoint (20 req/min per client
via existing `ThrottlerService`)

**P1 — High:**
- Return HTTP 401 for `invalid_client` errors instead of 400 (RFC 6749
§5.2)
- Verify refresh tokens belong to the presenting client (cross-client
token theft prevention)
- Limit fields exposed by public `findApplicationRegistrationByClientId`
query to only what the frontend needs (`id`, `name`, `logoUrl`,
`websiteUrl`, `oAuthScopes`)
- Require `API_KEYS_AND_WEBHOOKS` permission for
`createApplicationRegistration` mutation

**P2/P3 — Medium/Low:**
- Add error handling and loading states to frontend Authorize page
- Rename redirect URL param from `authorizationCode` to `code` (RFC
standard)
- Add unit tests for `validateRedirectUri` utility (8 test cases)

## Test plan

- [ ] Existing OAuth integration tests updated for all changes (hashed
codes, context-based PKCE, client binding, 401 status codes, cache
headers)
- [ ] New test: auth code rejected when presented by a different client
- [ ] New test: refresh token rejected when presented by a different
client
- [ ] New test: `code_verifier` required when PKCE was used in
authorization
- [ ] New test: `Cache-Control: no-store` header present on responses
- [ ] New unit tests for `validateRedirectUri` (HTTPS, localhost,
fragments, invalid URIs)
- [ ] Verify frontend authorize page shows errors gracefully


Made with [Cursor](https://cursor.com)

packages/twenty-server/src/engine/core-modules/application/services/application-sync.service.ts

@@ -136,12 +136,26 @@ export class ApplicationSyncService {
         application.applicationRegistrationId,
         manifest.application.universalIdentifier,
         applicationRegistrationMetadata,
+        workspaceId,
       );
 
-    await this.applicationRegistrationService.update({
-      id: applicationRegistrationId,
-      update: applicationRegistrationMetadata,
-    });
+    // Only update registration metadata if this workspace owns it.
+    // Other workspaces that install the same app attach to the existing
+    // registration but must not be able to modify its metadata.
+    if (
+      await this.applicationRegistrationService.isOwnedByWorkspace(
+        applicationRegistrationId,
+        workspaceId,
+      )
+    ) {
+      await this.applicationRegistrationService.update(
+        {
+          id: applicationRegistrationId,
+          update: applicationRegistrationMetadata,
+        },
+        workspaceId,
+      );
+    }
 
     if (manifest.application.serverVariables) {
       await this.applicationRegistrationVariableService.syncVariableSchemas(
@@ -248,6 +262,7 @@ export class ApplicationSyncService {
       websiteUrl?: string;
       termsUrl?: string;
     },
+    workspaceId: string,
   ): Promise<string> {
     if (existingId) {
       return existingId;
@@ -265,6 +280,7 @@ export class ApplicationSyncService {
     const { applicationRegistration: newRegistration } =
       await this.applicationRegistrationService.create(
         { ...metadata, universalIdentifier },
+        workspaceId,
         null,
       );