From bccb27fa426081ecfd2a4b0b2313cd84a07f22c7 Mon Sep 17 00:00:00 2001 From: Josh Grossman Date: Sun, 24 Nov 2024 17:49:17 +0200 Subject: [PATCH 1/2] Update 0x12-V3-Session-management.md --- 5.0/en/0x12-V3-Session-management.md | 1 - 1 file changed, 1 deletion(-) diff --git a/5.0/en/0x12-V3-Session-management.md b/5.0/en/0x12-V3-Session-management.md index dbd83e1eb1..78c2124aa0 100644 --- a/5.0/en/0x12-V3-Session-management.md +++ b/5.0/en/0x12-V3-Session-management.md @@ -82,7 +82,6 @@ Token-based session management includes JWT, OAuth, SAML, and API keys. Of these | **3.5.3** | [MODIFIED, LEVEL L2 > L1] Verify that cryptographically secured tokens are validated using their digital signature or MAC to protect against tampering before accepting the token's contents. | ✓ | ✓ | ✓ | 345 | | **3.5.4** | [ADDED] Verify that, if a validity time span is present in the token data, the token and its content are accepted only if the verification time is within this validity time span. For example, for JWTs the claims 'nbf' and 'exp' must be verified. | ✓ | ✓ | ✓ | 613 | | **3.5.5** | [ADDED] Verify that only algorithms on an allowlist can be used to create and verify cryptographically secured tokens, for a given context. The allowlist should include the permitted algorithms, ideally only either symmetric or asymmetric algorithms, and should not include the 'None' algorithm. If both symmetric and asymmetric are needed, additional controls should prevent key confusion. | ✓ | ✓ | ✓ | 757 | -| **3.5.6** | [ADDED] Verify that other, security-sensitive attributes of a stateless token are being verified. For example, in a JWT this may include issuer, subject, and audience. | ✓ | ✓ | ✓ | 287 | | **3.5.7** | [ADDED] Verify that key material that is used to validate cryptographically secured tokens is from trusted pre-configured sources for the token issuer, preventing attackers from specifying untrusted sources and keys. For JWTs and other JWS structures, headers such as 'jku', 'x5u', and 'jwk' must be validated against an allowlist of trusted sources. | ✓ | ✓ | ✓ | | | **3.5.8** | [ADDED] Verify that the service only accepts tokens which are intended for use with that service (audience). For JWTs, this can be achieved by validating the 'aud' claim against an allowlist defined in the service. | ✓ | ✓ | ✓ | | | **3.5.9** | [ADDED] Verify that the service receiving a token validates the token to be the correct type and is meant for the intended purpose before accepting the token's contents. For example, only access tokens can be accepted for authorization decisions and only ID tokens can be used for proving user authentication. | ✓ | ✓ | ✓ | | From 9023842671fb833765ea11d458c92982f86e0ddf Mon Sep 17 00:00:00 2001 From: Josh Grossman Date: Sun, 24 Nov 2024 17:54:52 +0200 Subject: [PATCH 2/2] Renumber --- 5.0/en/0x12-V3-Session-management.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/5.0/en/0x12-V3-Session-management.md b/5.0/en/0x12-V3-Session-management.md index 78c2124aa0..a3da9a4fb2 100644 --- a/5.0/en/0x12-V3-Session-management.md +++ b/5.0/en/0x12-V3-Session-management.md @@ -82,9 +82,9 @@ Token-based session management includes JWT, OAuth, SAML, and API keys. Of these | **3.5.3** | [MODIFIED, LEVEL L2 > L1] Verify that cryptographically secured tokens are validated using their digital signature or MAC to protect against tampering before accepting the token's contents. | ✓ | ✓ | ✓ | 345 | | **3.5.4** | [ADDED] Verify that, if a validity time span is present in the token data, the token and its content are accepted only if the verification time is within this validity time span. For example, for JWTs the claims 'nbf' and 'exp' must be verified. | ✓ | ✓ | ✓ | 613 | | **3.5.5** | [ADDED] Verify that only algorithms on an allowlist can be used to create and verify cryptographically secured tokens, for a given context. The allowlist should include the permitted algorithms, ideally only either symmetric or asymmetric algorithms, and should not include the 'None' algorithm. If both symmetric and asymmetric are needed, additional controls should prevent key confusion. | ✓ | ✓ | ✓ | 757 | +| **3.5.6** | [ADDED] Verify that the service receiving a token validates the token to be the correct type and is meant for the intended purpose before accepting the token's contents. For example, only access tokens can be accepted for authorization decisions and only ID tokens can be used for proving user authentication. | ✓ | ✓ | ✓ | | | **3.5.7** | [ADDED] Verify that key material that is used to validate cryptographically secured tokens is from trusted pre-configured sources for the token issuer, preventing attackers from specifying untrusted sources and keys. For JWTs and other JWS structures, headers such as 'jku', 'x5u', and 'jwk' must be validated against an allowlist of trusted sources. | ✓ | ✓ | ✓ | | | **3.5.8** | [ADDED] Verify that the service only accepts tokens which are intended for use with that service (audience). For JWTs, this can be achieved by validating the 'aud' claim against an allowlist defined in the service. | ✓ | ✓ | ✓ | | -| **3.5.9** | [ADDED] Verify that the service receiving a token validates the token to be the correct type and is meant for the intended purpose before accepting the token's contents. For example, only access tokens can be accepted for authorization decisions and only ID tokens can be used for proving user authentication. | ✓ | ✓ | ✓ | | ## V3.6 Federated Re-authentication