feat(oauth): Add CORS support for OAuth device flow with origin validation

[BYK]

Summary

Adds CORS (Cross-Origin Resource Sharing) support for public OAuth clients running in browsers (SPAs, browser-based CLIs) using the device authorization flow. Origins are validated against the OAuth application's allowed_origins configuration.

Changes

• Add OAuthCORSMixin for shared CORS handling logic
• Add CORS headers to /oauth/device/code endpoint for device authorization flow
• Add CORS headers to /oauth/token endpoint for token exchange
• Validate request origins against the application's allowed_origins setting

Motivation

Browser-based applications using the OAuth device flow need CORS support to:

1. Request device codes from /oauth/device/code
2. Poll for tokens at /oauth/token

Implementation

OAuthCORSMixin (oauth_cors_mixin.py)

New mixin class that provides:

• CORS preflight (OPTIONS) handling with Access-Control-Max-Age
• Origin validation against application.get_allowed_origins()
• Configurable cors_allowed_headers and cors_log_tag per endpoint
• Warning logs when origins are rejected

OAuth Endpoints

Both oauth_device_authorization.py and oauth_token.py now use OAuthCORSMixin:

• Device authorization: cors_allowed_headers = "Content-Type"
• Token endpoint: cors_allowed_headers = "Content-Type, Authorization"

Origin Validation Behavior

Scenario	Result
OPTIONS preflight	Allow all origins (app unknown yet, POST validates)
POST with allowed_origins configured, origin matches	✅ Allow
POST with allowed_origins configured, origin doesn't match	❌ Reject (no CORS header)
POST with empty allowed_origins	❌ Reject (must be configured)
POST with no Origin header (native client)	No CORS headers sent

Security Considerations

✅ Security model:

• Origins MUST be explicitly configured in allowed_origins for CORS to work
• Native clients (no Origin header) work without CORS headers
• Access-Control-Allow-Credentials is intentionally NOT set
• Without credentials, browsers won't send cookies with requests

❌ We intentionally do NOT:

• Allow all origins by default (must be configured)
• Set Access-Control-Allow-Credentials: true
• Allow credentialed CORS requests from arbitrary origins

RFC References

• RFC 8628 §5.6 - Native Clients: Public clients that cannot securely store a client secret
• RFC 6749 §2.1 - Client Types: Defines public vs confidential clients

Usage

To enable browser CORS for an OAuth application:

1. Go to the OAuth application settings
2. Add allowed origins to the Allowed Origins field (space-separated)
3. Browser requests from those origins will now work

[dcramer]

is this correct? we had cors support before via allowed domains. allowing any domain to use a public credential creates a phishing attack

[BYK]

is this correct? we had cors support before via allowed domains. allowing any domain to use a public credential creates a phishing attack

We don't have a website field for public apps. We can add one and limit it to that. Not sure I see the phishing attack angle tho as we limit the cookies?

[dcramer]

Ah I understand - why would a public app (a CLI) be using the browser to query things? security vuln exists nomatter what here

[dcramer]

attack being: i take your public client ID, create a domain like sentry.gg and trick you into logging into it, masquerading as the sentry cli

[BYK]

attack being: i take your public client ID, create a domain like sentry.gg and trick you into logging into it, masquerading as the sentry cli

Can I not do that by just adding sentry.gg as my domain in a confidential app?

[BYK]

Security Fix: Bind Public Clients to homepage_url

Good catch @dcramer! You're right that returning ["*"] for all public clients creates a client impersonation vulnerability.

The Attack Vector

An attacker could:

1. Take our legitimate public client_id (e.g., Sentry CLI's)
2. Create a phishing domain like sentry.gg
3. Complete OAuth device flow - user authenticates thinking it's the real CLI
4. Make API requests with the token, impersonating the legitimate app

Why Confidential Clients Are Different

Can I not do that by just adding sentry.gg as my domain in a confidential app?

With confidential clients, the attacker would need both:

• The client_id (public)
• The client_secret (private, never shared)

Without the secret, they can't complete the OAuth flow. That's the key difference.

RFC-Compliant Solution

Per RFC 8252 §8.6:

"Measures such as claimed 'https' scheme redirects MAY be accepted by authorization servers as identity proof"

I've updated get_allowed_origins() to use the existing homepage_url field on ApiApplication:

Client Type	homepage_url	CORS Allowed From
Public	https://cli.sentry.io	Only that origin
Public	None	No CORS (device flow from native apps)
Confidential	N/A	Configured allowed_origins

For Browser CLI

The browser-based CLI will need to:

1. Be hosted at a known domain (e.g., https://cli.sentry.io)
2. Have that domain registered as homepage_url on its public OAuth app

This binds the public client to a specific origin, preventing impersonation.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}