We split your tokens
When a user authenticates, Handled Cloud splits the token set in two. The halves combine again at the edge on every request.
- A complete token is never stored in the browser
- Refresh happens at the edge
Identity security is a specialist job. We've already done it.
Session handling, token exchange, and cookie security take engineering time to build, and more to maintain. Handled Cloud abstracts that work away, so your team spends that time on the product.
Sign up (opens in new tab)The token handler pattern.
The token handler pattern keeps tokens out of the browser entirely: a component on the API side acts as the OAuth client against your identity provider and holds the token set, so your front ends never handle one. Handled Cloud runs that component at the edge in your account, and splits every token set in two — one half stored at the edge near the user, one half in the httpOnly session cookie. Neither half alone reconstructs a token, so a compromised cookie or edge node cannot impersonate the user on its own. And an attacker who steals the cookie can use the session while it lives — they cannot extract a refresh token and act offline for days.
Your front ends are never OAuth clients: login, refresh, and token exchange happen at the edge, against your identity provider. When a route needs a token, the same edge node that validated the session forwards a standard JWT to the origin. The session cookie carries the __Host- prefix and is set withSameSite=strict, so the browser only sends it on same-site requests. That closes the Cross-Site Request Forgery (CSRF) route: a request forged from another site arrives without the cookie, and without the cookie it is just an unauthenticated request.
How we handle it
One mechanism of identity
One place handles identity for every app and environment you run, so implementations cannot drift apart.
- The same session across micro-frontends and API gateways
- Every environment enforces the same security model
- Application code never touches a cookie or an OAuth flow
Configuration you manage
Security is configured in the dashboard, per environment, with no code changes.
- Per-environment OAuth and cookie settings
- Route protection declared per route
- Changes apply at the edge without a redeploy
Federated SSO is configured in the dashboard.
Federated SSO is a control-plane feature you configure in the dashboard, separate from the token-store integration that forwards tokens to your origins. The architecture page shows where the control plane and its SSO identity provider sit in the deployment.
You choose where your tokens live.
The token store runs in the region you choose. The choice is set once per customer at onboarding, and it is immutable afterwards without an operator-managed migration.
The control plane that Handled Cloud operates runs in the European Union.
- European Union
- Tokens stored and processed in EU data centers.
- United States
- Tokens stored and processed in US data centers.
- FedRAMP-compliant US
- Tokens stored in FedRAMP-compliant US data centers.
Access is declared per route.
Route protection is declared per origin, per path, and per HTTP method. Tokens are forwarded only where one is actually used, so you are not spreading JWTs to every service just in case; every declaration limits who can hold your tokens.
- public
- Anyone can access the route; no session or token is required.
- login required
- The visitor must authenticate. Unauthenticated requests redirect to login, and no token reaches the origin.
- login with token forwarded
- The visitor must authenticate. Unauthenticated requests redirect to login, and the access token is forwarded to the origin.
- direct API-token check
- A valid access token is required up front. A request without one gets a 401, and the token is forwarded once verified.
Ready to let Handled Cloud handle identity security?