Bug: OAuth 2.0 State Parameter fails with Pipe Delimiters (RFC 6749 Non-Compliance)

Bug: OAuth 2.0 State Parameter fails with Pipe Delimiters (RFC 6749 Non-Compliance)

I've discovered a bug in how Zoho's API Console handles the OAuth 2.0 authorization flow when the state parameter contains pipe characters (|), and I'm hoping the Zoho team can address this in a future update.
The Issue
Zoho's OAuth 2.0 implementation for server-based client applications uses the standard authorization endpoint: 
https://accounts.zoho.com/oauth/v2/auth?response_type=code
    &client_id=<client_id>
    &scope=<scope>
    &redirect_uri=<redirect_uri>
    &access_type=offline
    &state=<state_value>
While Zoho's documentation does not explicitly list the state parameter, it is a standard part of the OAuth 2.0 specification (RFC 6749 Section 4.1.1) and is widely used for CSRF protection and maintaining application state through the authorization flow.
However, when the state parameter contains pipe characters (|), Zoho's authorization server fails to process the request correctly, preventing users from authorizing the connection. This occurs whether the pipe characters are URL-encoded (%7C) or left unencoded.
The Problem
The pipe character is a standard delimiter in multi-part state values, particularly when passing a combination of a CSRF token and a return URL. This behavior—failing on both encoded and unencoded pipe characters—is often indicative of overly restrictive input validation or a "leaky" WAF/Proxy layer that decodes parameters before the application logic can handle them.
State Value As Sent in URL Result
abc123xyz state=abc123xyz ✓ Works correctly
session_12345 state=session_12345 ✓ Works correctly
user|action|timestamp state=user|action|timestamp
(unencoded pipes)		 ✗ Authorization fails
user|action|timestamp state=user%7Caction%7Ctimestamp
(URL-encoded pipes)		 ✗ Authorization fails
user:action:timestamp state=user%3Aaction%3Atimestamp ? Not tested
Note: Pipe characters cause failures whether URL-encoded or not. Other special characters/delimiters have not been tested and may or may not exhibit similar issues.
RFC 6749 Compliance Issue
Section 4.1.1 - Authorization Request:
"state: RECOMMENDED. An opaque value used by the client to maintain state between the request and callback."
Section 4.1.2 - Authorization Response:
"state: REQUIRED if the 'state' parameter was present in the client authorization request. The exact value received from the client."
The RFC explicitly defines the state parameter as an opaque value. This means:
  • The Authorization Server should not be looking "inside" or parsing the string at all
  • The state value must pass through the authorization process unchanged
  • Any URL-encoded characters should be handled transparently
  • The exact value received must be returned to the client in the redirect
Key Point: By definition, an "opaque" parameter means the authorization server must treat it as a data blob—accepting it, storing it, and returning it without any interpretation or transformation.
Current Behavior vs Expected Behavior
Current Behavior Expected Behavior (Per RFC 6749)
1. Client sends: state=user|action|123
(or state=user%7Caction%7C123)
2. Zoho fails to parse the state parameter
3. Authorization server returns HTTP 400 Bad Request
4. User cannot authorize the connection 		1. Client sends: state=user|action|123

2. Zoho treats state as opaque data blob
3. User authorizes the connection
4. Redirect includes the exact value received:
state=user|action|123
(or consistently encoded as sent)
The Current Workaround (Suboptimal)
Important: The workarounds below only apply if you have control over the client application generating the OAuth request. If you're integrating with a third-party application that sets the state parameter (e.g., integration platforms, SaaS tools, enterprise software), you have no ability to modify the state value and therefore no workaround is available. You are completely blocked from completing the OAuth flow.
For developers who do control the client application, you must avoid pipe characters entirely: 
// Instead of using pipes as delimiters:
state = csrf_token + "|" + user_id + "|" + redirect_path;
// ❌ This breaks Zoho's authorization flow

// Developers must use alternative approaches:
state = csrf_token + "_SEP_" + user_id + "_SEP_" + redirect_path;
// or
state = base64_encode(json_encode({"csrf": token, "user": id, "path": path}));
// or
state = csrf_token; // Store other data server-side keyed by CSRF token
Problems with these workarounds:
  • Requires refactoring existing codebases that use pipe delimiters
  • Base64 encoding increases state parameter length significantly, risking URL length limits (particularly in older browsers and some enterprise proxies which enforce ~2000 character limits)
  • Server-side storage approach adds complexity, database overhead, and potential race conditions
  • Inconsistent with how the same code works with other OAuth providers (Google, Microsoft, etc.)
  • Developers may not discover this issue until production deployment
  • Custom delimiters (like _SEP_) are non-standard and may conflict with actual data values
What Should Happen Instead
Proposed Solution:
Zoho's authorization server should properly handle URL-encoded pipe characters (%7C) in the state parameter, as required by RFC 6749. The state value must be treated as an opaque data blob.
Technical Requirement: Treat state as a Data Blob
1. Input Accept %7C (and other encoded characters) as valid parts of the query string without triggering validation errors or WAF rules
2. Persistence Store the string exactly as received during the user's login/consent session—do not decode, parse, or transform
3. Output Append the exact string back to the redirect_uri without additional transformations that might strip or corrupt the delimiters
This approach:
  • Complies with RFC 6749's requirement to return "the exact value received"
  • Follows the same behavior as other major OAuth providers
  • Requires no changes from client applications
  • Unblocks third-party integrations that cannot modify their state format
Real-World Impact
This limitation affects any integration where:
  • Third-party applications set the state parameter and cannot be modified (integration platforms, SaaS connectors, enterprise software)
  • Multi-tenant applications need to encode tenant ID and return URL in state
  • CSRF protection implementations combine security tokens with application state
  • Single Sign-On flows need to preserve original request context
  • Migration projects from other OAuth providers that used pipe delimiters

Critical Blocker: When the state parameter originates from a third-party system outside your control, there is no workaround available. The integration is completely impossible until this is fixed.

Security Note: The state parameter is critical for CSRF protection in OAuth flows. Forcing developers to change their state encoding approach may inadvertently introduce security vulnerabilities if not handled carefully.

Request to Zoho Team

Can this be addressed in a future update?

This is a standards compliance issue that impacts developers integrating with Zoho's API. For those who control their client application, the current implementation forces unnecessary workarounds. For those integrating third-party applications, the situation is worse:

1. Custom development
Refactor code to avoid pipe characters, creating Zoho-specific OAuth handling 		2. Third-party integrations
No workaround possible - integration is completely blocked

Users should not be blocked from integrating with Zoho due to non-standard OAuth implementation.

Community Input Requested: Has anyone else encountered this issue? Are there other special characters that cause similar problems with Zoho's OAuth implementation?