state parameter contains pipe characters (|), and I'm hoping the Zoho team can address this in a future update.
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>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.
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.
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 |
state parameter as an opaque value. This means:
| 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 Request4. User cannot authorize the connection |
1. Client sends: state=user|action|1232. 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) |
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.
// 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_SEP_) are non-standard and may conflict with actual data values%7C) in the state parameter, as required by RFC 6749. The state value must be treated as an opaque data blob.
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 |
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.
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?