Minor Changes
-
Optimize handshake payload delivery with nonce-based fetching (#5905) by @jacekradko
This change introduces a significant optimization to the handshake flow by replacing direct payload delivery with a nonce-based approach to overcome browser cookie size limitations.
Problem Solved
Previously, the handshake payload (an encoded JWT containing set-cookie headers) was sent directly in a cookie. Since browsers limit cookies to ~4KB, this severely restricted the practical size of session tokens, which are also JWTs stored in cookies but embedded within the handshake payload.
Solution
We now use a conditional approach based on payload size:
- Small payloads (≤2KB): Continue using the direct approach for optimal performance
- Large payloads (>2KB): Use nonce-based fetching to avoid cookie size limits
For large payloads, we:
- Generate a short nonce (ID) for each handshake instance
- Send only the nonce in the
__clerk_handshake_noncecookie - Use the nonce to fetch the actual handshake payload via a dedicated BAPI endpoint
New Handshake Flow (for payloads >2KB)
- User visits
example.com - Client app middleware triggers handshake →
307 FAPI/v1/client/handshake - FAPI handshake resolves →
307 example.comwith__clerk_handshake_noncecookie containing the nonce - Client app middleware makes
GET BAPI/v1/clients/handshake_payload?nonce=<nonce_value>request (BAPI) - BAPI returns array of set-cookie header values
- Client app middleware applies headers to the response
Traditional Flow (for payloads ≤2KB)
No changes. Continues to work as before with direct payload delivery in cookies for optimal performance.
Trade-offs
- Added: One additional BAPI call per handshake (only for payloads >2KB)
- Removed: Cookie size restrictions that previously limited session token size
Patch Changes
-
Ensure
__clerk_syncedis removed from cross-origin return-back urls (#6196) by @tmilewski -
Updated dependencies [
f1be1fe,bffb42a]:- @clerk/types@4.62.0
- @clerk/shared@3.10.0