---
title: Renewal & Caching
url: https://docs.kaltura.com/docs/getting-started/authentication/ks-renewal
---

## Renewal, Caching, and Fallback

* TTL you control: you set expiry when starting the session; store issued_at + expiry in your app and refresh as needed *before it lapses*.
* Client pattern: your frontend should get KS rendered from your backend — secrets stay on the server.
* Pass KS in POST bodies so the token stays out of proxy caches and URL logs.
* The Kaltura API validates the KS on every request automatically and returns an error if it is invalid or expired. Validation is implicit — use any API call to confirm a KS is valid.
* Store KS in memory only; set `Cache-Control: no-store` headers to keep tokens ephemeral.
* Pass KS in POST bodies or PlayKit provider config — these transport channels keep the token private from referrer headers, logs, and proxies.
* Revoke a session immediately with `session.end`:

```bash
curl -X POST "$KALTURA_SERVICE_URL/service/session/action/end" \
  -d "ks=$KALTURA_KS" \
  -d "format=1"
```

After `session.end`, the KS is immediately rejected by all subsequent API calls. Use this for logout flows, session revocation, and security incident response.