Adobe Acrobat Sign OAuth 2.0 callback returns a modified state parameter

Description

We are integrating Adobe Acrobat Sign with our application using OAuth 2.0 authorization code flow.

Our application sends the state parameter as a URL-encoded, JSON-serialized string containing the context required to complete account creation. We understand that Adobe's documentation defines state as a string; we are not assuming that JSON is mandatory or that Adobe requires JSON-formatted values.

However, we have observed that the value returned to our callback appears to differ from the value sent in the authorization request.

Outgoing state (after URL decoding):
{"service":"Adobe","serviceId":"Adobe","securityType":"OAUTH_JWT",...}

Returned state (after URL decoding):
{"service":"Adobe",...}

The outgoing value is valid JSON. The returned value contains HTML entities (") instead of quotation marks, so it is no longer valid JSON as received by our application.

We verified that the outgoing value is correctly URL-encoded and that Adobe's initial authorization page receives the expected value. The modified value is present in the callback request after the user completes authentication. The issue persists when using the Adobe India-region authorization endpoint.

Our callback currently relies on parsing the original state string to recover the account context. Because the returned value differs, parsing fails and the OAuth account-creation process cannot complete, even though an authorization code is returned.

Clarification requested

Could you please clarify:

1. Does Adobe Acrobat Sign support a JSON-serialized string as the value of the OAuth state parameter, provided it is correctly URL-encoded?

2. Is the observed transformation of quotation marks into HTML entities expected behavior for any supported authorization endpoint or application configuration?

3. If JSON-serialized strings are supported, could you investigate why the returned state differs from the value received in the authorization request?

4. If Adobe imposes additional restrictions on the contents or encoding of state, could you point us to the relevant documentation and recommend the supported format?

We can provide sanitized outgoing authorization URLs, callback URLs, and redirect-response evidence to help investigate the discrepancy.

No client secrets, authorization codes, access tokens, session cookies, or other authentication credentials are included in this report.

Thank you for your assistance.