# Communication Security

In addition to using HTTPS to ensure transport security, digital signature verification is required to authenticate the identity of both communicating parties and verify the integrity of message content. Digital signatures are generated using SHA256withRSA.

## Exchange Public Keys

Before exchanging keys, both parties must generate their own RSA key pairs. Both communicating parties (the client integrating with the open platform, and the open platform itself) exchange their public keys in a trusted manner and store them in their respective systems.

## Digital Signatures

### Request Signatures

The client must use their own private key to perform SHA256withRSA signing on a combination of the API request path, message body, and other key data. The request signature information is passed through the HTTP `Authorization` header. See [Signature Generation and Verification](/collection/apis/intro/signature) for details. Requests without a signature or with a signature that fails verification will not be executed and will return 401 Unauthorized.

### Response Signatures

For requests with successful signature verification, the open platform will sign the response using its own private key. The signature information is included in the HTTP headers. See [Signature Generation and Verification](/collection/apis/intro/signature) for details.

### Callback Notifications and Signatures

The client provides an HTTPS endpoint address to the open platform for receiving callback notifications. When calling the client's endpoint, the open platform uses its private key to sign the callback request. The signing method is consistent with response signing. The client must use the open platform's public key to verify the callback signature. Notifications must have their signatures verified to prevent malicious attacks.