Persistent HTTP 400 Bad Request on OAuth Authorization (before login)

We are encountering a persistent HTTP 400 Bad Request error when attempting to initiate the OAuth 2.0 authorization flow for our Constant Contact application. The error occurs immediately upon redirecting to the Constant Contact authorization URL, before the user is presented with the Constant Contact login or consent page.

Key Application Details:

• Client ID (API Key): 4d3d00f2-6a99-4a00-88a7-42ec9b000eff

• Registered Redirect URI: http://34.74.242.84:5000/cc_callback/

• Authorization URL being called: https://identity.constantcontact.com/oauth2/aus1lm3ry9mF7x2Ja0h8/v1/authorize?response_type=code&client_id=4d3d00f2-6a99-4a00-88a7-42ec9b000eff&redirect_uri=http://34.74.242.84:5000/cc_callback/&scope=contact_data&state={dynamic_state_value}

Observed Behavior:

• Upon redirect to the Authorization URL, the browser remains on the identity.constantcontact.com domain and displays a generic "HTTP Status 400 – Bad Request" HTML page.

• The HTTP response from your server (as observed in browser developer tools) is a generic HTML 400 page and does not contain any specific error message or JSON payload (error, error_description) detailing the reason for the bad request.

Troubleshooting Steps Performed:

We have thoroughly debugged this issue from our end, confirming the following:

1. Client ID and Redirect URI Verification: Confirmed exact, character-for-character match (including trailing slash) between our application code, our .env file, and the settings within our Constant Contact developer portal.

2. Authorization Base URL: Verified that our application is targeting the specific authorization endpoint https://identity.constantcontact.com/oauth2/aus1lm3ry9mF7x2Ja0h8/v1/authorize as indicated by previous redirects from your system.

3. Credential Regeneration: Generated and updated new Client ID and Client Secret in our .env file from the Constant Contact portal.

4. Redirect URI Re-entry: Deleted and manually re-added the Redirect URI in the Constant Contact portal to rule out hidden character issues.

5. Scope Simplification: Tested with a minimal scope (contact_data) to rule out scope-related issues.

6. URL Construction Validation: Verified via browser developer tools that the constructed Authorization URL (including all parameters) is syntactically correct and being sent as expected.

7. Clean Sessions: Tested repeatedly using incognito/private browser windows to rule out local caching or session issues.

Despite these extensive checks, the generic 400 error persists.

Request:

Given that the error occurs on your server's side before the login page and provides no specific details in the response, we request that your team examine your server-side logs associated with our Client ID (4d3d00f2-6a99-4a00-88a7-42ec9b000eff) and the provided Authorization URL to determine the precise reason for the 400 Bad Request.

Thank you for your assistance.