Client Schema URI scheme validation: Custom protocol validation logic is too simplistic for native apps

[shahbazshueb]

What happened?

In lib/helpers/client_schema.js, the check for custom URI schemes in native client redirect URIs (see code link) uses if (!protocol.includes('.')) to enforce reverse domain naming. This logic is too simplistic and may:

• Incorrectly reject valid single-word custom schemes (e.g. myapp:)
• Incorrectly accept invalid or poorly structured schemes
• Not correctly enforce the intended reverse domain naming requirement (and protocol includes the colon suffix)

Expected:
The validator should robustly check for the reverse domain naming scheme according to OAuth 2.0 Native App Best Current Practice and reject schemes that do not comply.

Actual:
Currently, any protocol containing a dot passes; any without is rejected, regardless of actual URI structure.

See also: Relevant Code

Version

v9.8.0

Runtime Details

Nodejs v22, macOS

Configuration

Minimal provider config:

{
  application_type: 'native',
  redirect_uris: ['myapp://callback'] // or try 'com.example.app://callback'
}

Steps to reproduce

1. Configure a native app client with various custom URI schemes as redirect URIs.
2. Attempt to register schemes both with and without dots (e.g. cursor://callback, myapp://callback, com.example.app://callback, etc)
3. Observe validation behavior for each.
4. Expected: Only reverse domain name based schemes should be accepted.
5. Actual: Any protocol with a dot is accepted; others are rejected regardless of actual structure.

Required

• I understand this issue tracker is for bug reports only. Questions and support requests will be closed and eventually deleted.
• I agree to follow this project's Code of Conduct

[panva]

Incorrectly reject valid single-word custom schemes (e.g. myapp:)

It's not incorrect, it's intentional per the native apps BCP.

https://datatracker.ietf.org/doc/html/rfc8252#section-7.1
When choosing a URI scheme to associate with the app, apps MUST use a
URI scheme based on a domain name under their control, expressed in
reverse order, as recommended by Section 3.8 of [RFC7595] for
private-use URI schemes.

🤷 yes, it's simplistic, but the rejection of "unclaimable" schemes is intentional

[panva]

At this point, seeing how app vendors couldn't care less about following a BCP the easiest way forward is to not validate custom schemes to follow any format at all.

[shahbazshueb]

Yup. It would make sense to not validate custom schemes or atleast provide a way to bypass it.
Check cursor, it uses the following: cursor://anysphere.cursor-mcp/oauth/callback
Source: https://cursor.com/docs/mcp#static-redirect-url

[panva]

Resolved in https://github.com/panva/node-oidc-provider/releases/tag/v9.8.1