Problem
The authorization endpoint accepts but does not require the `state` parameter. Per RFC 6749 Section 4.1.1, `state` is "RECOMMENDED" for CSRF protection on the client side. The server correctly passes it through to the redirect, but does not reject requests that omit it.
Why it matters
Since PKCE is already mandatory (a stricter-than-spec requirement), omitting `state` enforcement is inconsistent with the security posture. While `state` is technically a client-side concern (the client validates that the returned state matches what it sent), requiring it at the server level:
- Prevents careless client implementations from skipping CSRF protection
- Is consistent with the "require PKCE" philosophy of enforcing security best practices
- Helps client developers catch integration bugs early
Suggested approach
- In `HandleOauthAuthorize`, return an error if `state` is empty
- This is a one-line check similar to the existing PKCE validation
This is a minor hardening measure. Some legitimate use cases (CLI tools, testing) may not send `state`, so consider whether to enforce it strictly or just warn.
Problem
The authorization endpoint accepts but does not require the `state` parameter. Per RFC 6749 Section 4.1.1, `state` is "RECOMMENDED" for CSRF protection on the client side. The server correctly passes it through to the redirect, but does not reject requests that omit it.
Why it matters
Since PKCE is already mandatory (a stricter-than-spec requirement), omitting `state` enforcement is inconsistent with the security posture. While `state` is technically a client-side concern (the client validates that the returned state matches what it sent), requiring it at the server level:
Suggested approach
This is a minor hardening measure. Some legitimate use cases (CLI tools, testing) may not send `state`, so consider whether to enforce it strictly or just warn.