Bug: OAuth client secret inconsistency between UI copy value, request payload, and persisted DB value

[hatsuyuki280]

Self Checks

• I have read the Contributing Guide and Language Policy.
• This is only for bug report, if you would like to ask a question, please head to Discussions.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report, otherwise it will be closed. / 请使用英语提交，否则会被关闭。
• Please do not modify this template :) and fill in all the required fields.

Cloudreve version

4.14.1 #50349bf

Pro or Community Edition

Pro

Database type

MySQL

Browser and operating system

Chrome 145.0.7632.76

Steps to reproduce

Describe the bug

When creating a custom OAuth client from the admin web UI, the secret value is inconsistent across different stages:

1. Secret shown/copied in UI
2. Secret sent in request payload (PUT /api/v4/admin/oauthClient, client.secret)
3. Secret persisted in DB (oauth_clients.secret)

These values should represent one final secret for the same client, but they differ.
As a result, using the UI-copied secret can fail token exchange with Invalid client secret.

To Reproduce

1. Go to Admin -> OAuth -> New.
2. Click Refresh for secret and copy the displayed value.
3. Submit creation.
4. In browser network tab, inspect:
   • PUT /api/v4/admin/oauthClient request body (client.secret present)
   • GET /api/v4/admin/oauthClient/{id} response (metadata only, no secret)
5. Query DB table oauth_clients for the created row by guid.
6. Compare values from UI copy / request payload / DB persisted secret.

Environment

• Cloudreve version: v4.14.1 Pro
• Browser: Chrome 145 on macOS
• DB: MySQL
• Reverse proxy/CDN: Cloudflare

Additional context

• I can provide HAR/timestamps privately.
• Secrets/tokens are redacted in this report for security.
• This appears to be a server-side consistency issue in create/refresh/persist flow, not a client OAuth parameter typo.

✔️ Expected Behavior

For one created OAuth client, secret must be deterministic and consistent:

• either backend persists submitted client.secret,
• or backend generates one and returns that exact persisted value once for copy.

In all cases, the secret users copy from UI should be the same value used by server validation.

❌ Actual Behavior

For a newly created client:

• UI copied secret != request payload secret OR
• request payload secret != DB persisted secret

Observed created client example:

• id=6
• guid=32bea26d-43c9-40d9-8493-31405c4cb557
• PUT /api/v4/admin/oauthClient succeeded (code=0)
• DB row exists, but persisted oauth_clients.secret does not match expected copied value

Addition context information

No response

[hatsuyuki280]

Sanitized Evidence Chain (no site URL, no user credentials)

• All hostnames, account identifiers, passwords, cookies, and tokens are removed.
• API paths, timestamps, IDs/GUIDs, and secret values are kept for reproducibility.

1. UI behavior during OAuth client creation

   • Secret shown after clicking Refresh: hge0I2ECEVmCCUYOZCFRWmoxGERMSCfI
   • Secret obtained via Copy action: wYS2q9zhhd2Ox53lKmgUFD4mFFNnIrns
   • (In another observation, browser password manager captured: FsbZjGVJsBzN7rJPwJxCfaMBh6rnObPE)

2. Create request (HAR)

   • Request: PUT /api/v4/admin/oauthClient
   • Request body includes:
     • client.id = 0
     • client.name = "test"
     • client.secret = "wYS2q9zhhd2Ox53lKmgUFD4mFFNnIrns"
     • redirect_uris = ["#"]
     • scopes = ["openid"]
   • Response: HTTP 200, {"code":0,...}

3. Immediate readback (HAR)

   • Request: GET /api/v4/admin/oauthClient/6
   • Response includes:
     • id = 6
     • guid = 32bea26d-43c9-40d9-8493-31405c4cb557
   • Secret is not returned by this endpoint (metadata only).

4. Database persisted record

   • Table: oauth_clients
   • Row: id=6, guid=32bea26d-43c9-40d9-8493-31405c4cb557
   • Persisted secret = wc2yGAmfgr6N5NEdTpk9qYsP871WoYFp

5. Consistency check (same client record)

   • UI refresh value: hge0I2ECEVmCCUYOZCFRWmoxGERMSCfI
   • Request payload value: wYS2q9zhhd2Ox53lKmgUFD4mFFNnIrns
   • DB persisted value: wc2yGAmfgr6N5NEdTpk9qYsP871WoYFp
   • Result: values are different (UI != request payload != DB).

6. Observed impact

   • OAuth token exchange has failed with Invalid client secret in related runs, consistent with the mismatch above.

[dosubot]

Hi @hatsuyuki280! I'm Dosu and I’m helping the cloudreve team.

Thanks for the detailed evidence chain! I found the root cause in the frontend codebase.

Root Cause: The secret input field in OAuthClientForm.tsx has an onChange handler that can overwrite the generated secret whenever user interaction occurs (clicks, typing, or browser autofill):

const onSecretChange = useCallback((e: React.ChangeEvent<HTMLInputElement>) => {
  setClient((p: GetOAuthClientResponse) => ({ ...p, secret: e.target.value }));
}, [setClient]);

This creates a race condition where:

1. Refresh generates a secret via onGenerateSecret
2. Any interaction with the field triggers onSecretChange, which overwrites the state with the current input value
3. Copy reads from values.secret (potentially stale or different)
4. Submit sends whatever modifiedValues.secret contains at that moment

Your observation that the browser password manager captured yet another value (FsbZjGVJsBzN7rJPwJxCfaMBh6rnObPE) strongly suggests autofill is triggering the onChange handler and corrupting the generated secret.

Simplest fix: Make the secret field read-only and only allow changes via the Refresh button:

<DenseFilledTextField
  value={values.secret || ""}
  slotProps={{
    input: {
      readOnly: true,  // Prevents onChange from firing
      // ... existing config
    }
  }}
  // Remove: onChange={onSecretChange}
/>

This would ensure the generated secret remains consistent across display, copy, and submission.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}