fix(oauth): Support public clients for device flow per RFC 8628 §5.6

[betegon]

Summary

Fixes the OAuth 2.0 Device Authorization Grant implementation to properly support public clients as required by RFC 8628.

Problem

The current token endpoint requires client_secret for ALL grant types, including device_code. This breaks the fundamental design of the device flow, which is explicitly designed for public clients (CLIs, native apps, IoT devices) that cannot securely store secrets.

What the RFC Says

RFC 8628 §5.6 - Non-Confidential Clients:

Device clients are generally incapable of maintaining the confidentiality of their credentials, as users in possession of the device can reverse-engineer it and extract the credentials. Therefore, unless additional measures are taken, they should be treated as public clients (as defined by Section 2.1 of [RFC6749]).

RFC 8628 §3.4 - Device Access Token Request:

client_id - REQUIRED if the client is not authenticating with the authorization server as described in Section 3.2.1. of [RFC6749].

RFC 6749 §2.1 - Client Types:

public - Clients incapable of maintaining the confidentiality of their credentials (e.g., clients executing on the device used by the resource owner, such as an installed native application or a web browser-based application)

Solution

• Move grant_type validation before credential check (needed to determine auth requirements)
• For device_code grant: only require client_id (public client mode per RFC 8628 §5.6)
• If client_secret is provided: still validate it (supports confidential clients that choose to authenticate)
• Other grant types (authorization_code, refresh_token): unchanged, still require client_id + client_secret

Changes

File	Change
src/sentry/web/frontend/oauth_token.py	Allow public client auth for device_code grant
tests/sentry/web/frontend/test_oauth_token.py	Added 5 new tests for public client support

New Tests

1. test_public_client_success - Public client can exchange approved device code
2. test_public_client_invalid_client_id - Invalid client_id rejected with 401
3. test_public_client_missing_client_id - Missing client_id rejected with 401
4. test_public_client_authorization_pending - Polling works for public clients
5. test_confidential_client_wrong_secret_rejected - Wrong secret still rejected when provided

Security Considerations

This change is RFC-compliant and does not reduce security:

1. Device code binding: The device_code is bound to the application at creation time, so a public client can only poll for tokens for its own application
2. User authorization: The user must still explicitly approve the request via the browser
3. Confidential clients still supported: If a client provides client_secret, we validate it
4. Rate limiting: Existing rate limiting on device code polling remains in place

Related

• Original device flow implementation: feat(oauth): Implement OAuth 2.0 Device Authorization Flow (RFC 8628) #105675
• RFC 8628: https://datatracker.ietf.org/doc/html/rfc8628