# Client and server interaction flow

## 

Journeys are typically initiated by the client; however, most of the workflow is executed server-side. The journey processes each server-side step sequentially until a client-side interaction is needed.

Practically, when a client interaction step is encountered, the current state of the journey is stored, and the client —using the SDK— takes over until the required input is provided. Once the input is received, control returns to the server, and the journey continues according to the defined flow.

The SDKs for handling client-side interactions are available for [web](/guides/orchestration/getting-started/quick_start_web), [iOS](/guides/orchestration/getting-started/quick_start_ios), and [Android](/guides/orchestration/getting-started/quick_start_android), ensuring smooth communication between the client and server throughout the journey.

Throughout the client-server interaction, multiple layers of security are applied:

- **Data protection**: All communication between client and server is protected to prevent replay attacks, session hijacking, and other common threats. If needed, you can enable **double encryption** to add an additional encryption layer in addition to SSL. This layer guarantees point-to-point encryption from the client to the orchestration service, and is not affected by network topology and SSL termination point.
- **Cryptographic binding**: Device cryptographic binding uses PKI (Public Key Infrastructure) and challenge signing with private keys securely stored on the device. This process ensures that only authorized devices can interact with the server.
- **Risk signals**: Collected through the Mosaic SDK, client-side data is used to detect anomalies. The Mosaic risk engine responds with allow, challenge, or deny actions based on this data.


## Data exchange

At each client-facing step, the server sends an `IdoServiceResponse` containing instructions and any data the client needs to render the appropriate UI. Once the user completes the interaction, the client submits the collected input back to the server using the SDK's `submitClientResponse()` method. The server then processes the received data and continues executing the journey flow.

The data submitted back to the server typically includes form inputs, authentication results, or other step-specific values. Each journey step defines its own expected response schema — for steps like [Login Form](/guides/orchestration/journeys/login_form) and [Collect information](/guides/orchestration/journeys/get_info_from_client), this schema is configured by the journey author.

Payload size limits
The recommended maximum payload size is **100 KB**. In exceptional cases, payloads up to **512 KB** are accepted, but exceeding this hard limit may cause the request to be rejected. Keep payloads lean by only including the data required by the journey step.

![](/assets/interaction.054175028e52c7c72f37d1cc1f581fee080353c1069a644c9f6077b1484dd87b.4459c3bd.png)

style
section article ul li {
        margin-top: 5px !important;
    }