Adding new session requirement for propagating session information

[jmanico]

3.5.8	[ADDED] Verify that user session tokens, such as JWTs, are securely propagated between services as part of service-to-service communication, ensuring that session tokens are validated at each service layer.		✓	✓	306

This suggestion came from the conversation here #2072

[elarlang]

What problem it solves?

Why it needs to be validated on each layer? Maybe it is not even used on each layer, just forwarded to the next one.

I think we have similar discussion on #1312 (comment) to remove 13.1.4

13.1.4 Verify that authorization decisions are made at both the URI, enforced by programmatic or declarative security at the controller or router, and at the resource level, enforced by model-based permissions.

[jmanico]

It's usually more secure to actually verify the token at each layer than to just pass a userid after the initial step.

This prevents forgery, is more of an end-to-end security mechanism (ie: zero trust), it's more reliable for access control since we reliably need the userid, which is only reliable when it's from the session, and some tokens actually contain the access control permission policy for the user which are likely needed at each layer.

There are many more benefits to this pattern. It's solves a lot of security problems.

[jmanico]

Yes I think #1312 (comment) touched on this issue but I still think we need a new requirement.

Essentially I feel every API (and many big companies like google have this standard in their API secure coding docs) should have strong session management and strong access control, regardless of it being internal or external.

In the era of micro-services we no longer do access control in one place, we do access control at each individual micro-service. And to do that securely, we reliably need the userId. And to reliably get the userId we need an active session.

[elarlang]

Also personally I feel, that this is more V4 topic to check user permissions.

If it is about token validation, then it is covered by current "V3.5 Token-based Session Management" requirements. Many of them are under discussion, but for example 3.5.4:

3.5.4 [ADDED] Verify that stateless tokens are checked for expiration before processing them further.

It is valid for every service layer, where it is used. So kind of covering the point you propose?

[jmanico]

No, 3.5.4 is strictly about verifying expiration at one service layer.

My requirement focuses on API architecture, specifically around session management. When making a request that traverses several microservices, it's essential that the session token is passed all the way through the microservice structure. This ensures that each individual service receives the actual session artifact, which can then be verified and/or passed to the next service, rather than just passing a user ID. This is a critical difference.

I can see this in v2 (Session management) or v13 (API's) but it is not specific to tokens, it's for any session artifact (even tough todays its mostly JWT's).

[elarlang]

Are you actually talking about access tokens?

[jmanico]

No. This could be any session artifact.

[elarlang]

Assigned to @tghosth - maybe he can understand what security problem it solves. I can not.

[tghosth]

I believe we are duplicating the requirement I set out in the following comment, @jmanico

#2061 (comment)

[jmanico]

4.2.4 Is specifically about access control. I think the requirement I’m suggesting is more about overall session management architecture which has the potential to benefit: Access Control Better Statelessness (no need to verify a session in another service) Better integrity of the session artifact Decentralizing security policies End to end security, each service is enforcing its own policies There are a few downsides to this pattern as well, especially if you are using a bloated JWT with lots of extra unnecessary data. But overall “pass the JWT” patterns are inline with the zero-trust architecture movement which is why I’m suggesting it.

[elarlang]

You are saying (#2079 (comment), #2079 (comment)) that is for sure not about access control, but first thing that it solves/benefits, is access control?

[jmanico]

What I am saying it is not *only* about access control, it’s just one of the benefits of this pattern.

[elarlang]

I think it is just one way to build a "session handling eco-system" and it is just a way to send session artifact information between (micro)services. So far, I can not see material for the "it fits for everyone" requirement here. If there is a list of abstract benefits, it does not share the information required - what problem does it solve, or what attack vector it mitigates?

[jmanico]

I can not see material for the "it fits for everyone"

I think that’s a fair argument. This is more of a architectural design *suggestion* and there are other viable patterns like the gateway pattern that competes with it. I’m ok to drop this Elar. You make a fair point.

[elarlang]

As @tghosth descibed, most likely the security concerns from this issue are addressed by another issue:

I believe we are duplicating the requirement I set out in the following comment, @jmanico

#2061 (comment)

Closing this.