Migration Guide: Updating JWT SSO Callbacks from GET to POST

Overview

In our v13.1 build release, we’ve addressed a critical security vulnerability where sensitive user details could be exposed via URL query parameters when using the GET method for JWT SSO callback. To mitigate this, we've enforced the use of the POST method instead. This update ensures sensitive data is no longer transmitted in the browser’s address bar, helping safeguard user sessions from unintended exposure.

Purpose of the Change

• Prevent sensitive information leakage during JWT SSO callback.

• Comply with best practices for secure data transmission.

• Improve overall security posture by using HTTP POST, which transmits data in the request body rather than the URL.

Previously, our documentation recommended the GET method, which led to user credentials being passed in query strings — discoverable in browser history, logs, and potentially exposed via third-party scripts. 

Impact to Existing Users

Customers who have already configured the GET method for their JWT provider application will experience breaking changes upon upgrading to build 13.1. Any attempts to authenticate using the older configuration may fail.

What You Need to Do

1. Update Your Callback Endpoint

Update JWT provider applications to use the POST method when sending authentication tokens.

2. Parse JWT from the Request Body

Modify implementation logic to send the jwt, site_identifier and redirect_to values in the POST request body instead of query parameters.

Refer to the updated JWT configuration documentation for implementation guidance.

3. Update Client-Side or Identity Provider Configuration

If you're using a third-party identity provider (IdP), update the callback method in their configuration to use POST.

4. Test the Integration

• Simulate a full SSO login flow.
• Confirm that the JWT is received and processed correctly.
• Check for any errors or misconfigurations in logs.