From a663fb1ab2ffa9f13286f9c0567289cffccafa23 Mon Sep 17 00:00:00 2001 From: "Allaf, Kamil" Date: Mon, 17 Aug 2026 15:33:18 +0200 Subject: [PATCH 1/2] OLIVE-598 Clarify JWT validation behavior when JWT security is disabled and per-request scope of expiry checks --- theolive/distribution/security/token-based-security.mdx | 8 +++++--- theolive/troubleshooting.mdx | 6 +++--- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/theolive/distribution/security/token-based-security.mdx b/theolive/distribution/security/token-based-security.mdx index c31b3cde971c..fa5d8f57e434 100644 --- a/theolive/distribution/security/token-based-security.mdx +++ b/theolive/distribution/security/token-based-security.mdx @@ -29,7 +29,7 @@ The token can be provided in one of two ways: The token payload must include: -- **`exp`** — expiration time in epoch format. The token is rejected after this time. +- **`exp`** — expiration time in epoch format. Requests carrying the token are rejected after this time; note that playback already in progress may continue past the token's expiry. - **`nbf`** _(optional)_ — "not before" time in epoch format. The token is rejected before this time. Additionally, the following standard optional claims are supported: @@ -41,8 +41,10 @@ Additionally, the following standard optional claims are supported: Requests without a valid token are rejected with an HTTP `403` response. -::::caution Tokens are validated even when token security is disabled -Disabling token security makes the token optional, but it does not make the CDN ignore it. Any JWT still included in a request — via the `Authorization` header or the `token` query parameter — is validated for well-formedness and expiry. In particular, an **expired** token is rejected with an HTTP `403`, even though the same request without a token would have been allowed. After disabling token security, make sure your players stop attaching (potentially stale) tokens. +::::caution A token you send is still checked even when token security is disabled +Disabling token security makes the token optional — it does not make the CDN ignore a token you do send. Any request that carries a JWT, via the `Authorization` header or the `token` query parameter, is checked: if the token is malformed or **expired**, that request is rejected with an HTTP `403`, even though the same request without a token would have been allowed. After disabling token security, make sure your players stop attaching (potentially stale) tokens. + +Each request that carries a token is checked on its own. On a channel without token-based security there is no key to verify who issued the token, so this is not a way to control access or to limit how long someone can watch — enable token-based security if you need that. :::: ## Custom claims diff --git a/theolive/troubleshooting.mdx b/theolive/troubleshooting.mdx index 3a0de94594d0..e4c8c04076b1 100644 --- a/theolive/troubleshooting.mdx +++ b/theolive/troubleshooting.mdx @@ -24,6 +24,6 @@ Some known issues and advisable configuration items: ## Playback -| Topic | Description | -| ------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Why do I get HTTP `403` responses while token-based security is disabled? | Even when [token-based security](./distribution/security/token-based-security.mdx) is disabled, any JWT included in a request (via the `Authorization` header or the `token` query parameter) is still validated for well-formedness and expiry. An **expired** or malformed token results in an HTTP `403`, even though the same request without a token would succeed. Make sure your player stops attaching stale tokens. | +| Topic | Description | +| ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Why do I get HTTP `403` responses while token-based security is disabled? | Even when [token-based security](./distribution/security/token-based-security.mdx) is disabled, any JWT included in a request (via the `Authorization` header or the `token` query parameter) is still checked for well-formedness and expiry. An **expired** or malformed token results in an HTTP `403` for that request, even though the same request without a token would succeed. Make sure your player stops attaching stale tokens. | From 0c7eff49c95d15882cbd6a8bf2efbbf9a5492c93 Mon Sep 17 00:00:00 2001 From: "Allaf, Kamil" Date: Tue, 18 Aug 2026 13:34:14 +0200 Subject: [PATCH 2/2] Address code review comments --- theolive/distribution/security/token-based-security.mdx | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/theolive/distribution/security/token-based-security.mdx b/theolive/distribution/security/token-based-security.mdx index fa5d8f57e434..835f7b488c4d 100644 --- a/theolive/distribution/security/token-based-security.mdx +++ b/theolive/distribution/security/token-based-security.mdx @@ -29,7 +29,7 @@ The token can be provided in one of two ways: The token payload must include: -- **`exp`** — expiration time in epoch format. Requests carrying the token are rejected after this time; note that playback already in progress may continue past the token's expiry. +- **`exp`** — expiration time in epoch format. Requests carrying the token are rejected after this time. Note that playback already in progress may continue past the token's expiry. - **`nbf`** _(optional)_ — "not before" time in epoch format. The token is rejected before this time. Additionally, the following standard optional claims are supported: @@ -44,7 +44,6 @@ Requests without a valid token are rejected with an HTTP `403` response. ::::caution A token you send is still checked even when token security is disabled Disabling token security makes the token optional — it does not make the CDN ignore a token you do send. Any request that carries a JWT, via the `Authorization` header or the `token` query parameter, is checked: if the token is malformed or **expired**, that request is rejected with an HTTP `403`, even though the same request without a token would have been allowed. After disabling token security, make sure your players stop attaching (potentially stale) tokens. -Each request that carries a token is checked on its own. On a channel without token-based security there is no key to verify who issued the token, so this is not a way to control access or to limit how long someone can watch — enable token-based security if you need that. :::: ## Custom claims