Response Signing

Verify that API responses come from your Authgate server and haven’t been tampered with.

Response signing adds cryptographic signatures to all responses from Authgate. This lets your application verify that the data it receives is authentic and hasn’t been modified by attackers.

Why Use Response Signing?

Response signing protects against two types of attacks:

1. Response Tampering: Nobody can modify the response data after it leaves your Authgate server
2. Man-in-the-Middle: Attackers can’t inject fake responses even if they intercept the connection

Response signing is especially useful when combined with Request Signing to create a fully secured two-way communication channel.

How It Works

When response signing is enabled, Authgate automatically:

1. Generates a signature for each response using your response_signing_key
2. Includes a timestamp showing when the response was created
3. Optionally binds the response to the original request (when request signing is also enabled)
4. Adds signature headers (x-signature and x-timestamp) to the response

Your API client (SDK) then verifies the signature before using the response data.

All of this happens automatically - the SDK handles verification for you!

Response-Request Binding

When both request and response signing are enabled together, Authgate creates a cryptographic binding between each request and its corresponding response. This prevents sophisticated attacks where attackers try to replay or swap responses.

How the binding works:

1. Your app sends a signed request with signature, timestamp, and nonce
2. Authgate processes the request and generates a response
3. When signing the response, Authgate includes the original request’s signature data (signature, timestamp, and nonce) in the response signature calculation
4. Your app verifies that the response signature matches the request it sent

This binding ensures:

• An attacker can’t replay an old valid response to a new request
• An attacker can’t swap responses between different requests
• Each response is cryptographically tied to exactly one request

Response Signature Format

Each signed response includes two headers:

• x-signature: The signature in format v1,hmac-sha256,<base64url>
• x-timestamp: UNIX timestamp (epoch seconds) when the response was signed

The signature covers:

• HTTP status code
• Response body (SHA256 hash)
• Timestamp
• Request signature data (if request signing is enabled)

Enabling/Disabling

Response signing can be enabled or disabled in your application settings in the Authgate dashboard.

• Enabled: All responses include cryptographic signatures
• Disabled: Responses are sent without signatures (less secure)

Important Notes

• Keep Your Key Secret: Your response_signing_key must be kept secret and secure in your app
• Works with Request Signing: When both request and response signing are enabled, responses are bound to specific requests for maximum security
• Time Sync: Make sure your app’s system clock is accurate to validate timestamps correctly
• Works With All Auth Methods: Response signing works alongside Token Auth, Legacy Auth, and anonymous access