Support Authenticated Encrypted Sessions

[marcusdacoregio]

One alternative that we have to provide stateless support is to store the session data in an authenticated encrypted cookie.

The Rails Session Storage documentation gives a good insight into the pros and cons of that approach.

Related:

• Allow persistence of session in cookies(encrypted for sure) #186
• https://spring.io/blog/2014/01/20/exploiting-encrypted-cookies-for-fun-and-profit

[quaff]

Keeping secret key is a challenge.

[gourav]

With @marcusdacoregio & @quaff guidance, I would like to work on this issue.

[tarmolehtpuu]

Any progress on this one? Coming from Rails it's really weird there is no out of the box support for this in Spring Boot, I guess I will have to roll my own implementation

[marcusdacoregio]

Hi, @tarmolehtpuu. Thanks for reaching out. I plan to add it to 3.3, but most likely it will be included in the second milestone release. Please, subscribe to the issue to get notified about new updates.

[marcusdacoregio]

Hi, @tarmolehtpuu. Can you share a bit more how it works on Rail's side? Does Rail's use it for the authentication session cookie? How does it work when you have a few session attributes, are all attributes written to the cookie?

[MatthiasWinzeler]

@marcusdacoregio I can chime in here - Rails does indeed write additional attributes to the cookie (I learned that the hard way, since it's easy to exceed the 4k cookie size limit that way).

You can find Rails' implementation in https://github.com/rails/rails/blob/main/actionpack/lib/action_dispatch/middleware/session/cookie_store.rb

Also interesting to get some inspiration would be the implementation of ASP.NET Core: https://learn.microsoft.com/en-us/aspnet/core/security/authentication/cookie?view=aspnetcore-8.0

Be aware that these implementations do not seem to have protection in replay attacks that were raised in https://spring.io/blog/2014/01/20/exploiting-encrypted-cookies-for-fun-and-profit/.

[marcusdacoregio]

Thanks, @MatthiasWinzeler. I'm trying to identify if users really need the session attributes in the session cookie or what they are really looking for is a way to encrypt the SecurityContext in the session cookie. If it is latter that they are looking for, a new SecurityContextRepository implementation in Spring Security would be needed instead of any change in Spring Session.

[MatthiasWinzeler]

@marcusdacoregio I can't talk for others, but I was looking to store a JWT token in the session (since that became a recommended pattern in https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#name-cookie-based-session-manage) - not sure whether that's in the SecurityContext or session attributes in spring.

[marcusdacoregio]

This can be achieved using oauth2Login() in Spring Security. It is indeed as a session attribute but there is no relation with where the session is serialized. This goal of this issue is to encrypt and store all the session information in an authenticated encrypted cookie.

[MatthiasWinzeler]

@marcusdacoregio to make sure I understand you correctly: so this issue right here would enable us to store the JWT obtained by your link above (which is indeed what I'm wanting to achieve) and store it in the encrypted cookie?

if yes, then this issue here is exactly what I'd need for my use case.

[marcusdacoregio]

This support would enable us to store any session attribute in an (or more than one) encrypted cookie, if the JWT is in there, it doesn't matter from Spring Session perspective.

Currently, you can store the access token (as a session attribute) in the session, save that session somewhere, and then return to your client only the session id. There is no need for encryption since all session information is stored on the server side. If you are using Spring Cloud Gateway for your BFF, you can rely on the TokenRelayGatewayFilter to do the work of reading the access token from the session and passing it to downstream services.

[MatthiasWinzeler]

@marcusdacoregio thanks, cool, I didn't know that Spring Cloud Gateway supported this.

Having a different approach with the encrypted/signed cookie might be worthwhile nevertheless - for one, it's a recommended way to store access token in the BFF architecture which is recommended to build OAuth2 browser-based apps:

Server-side sessions only expose a session identifier and keep all data on the server. Doing so ensures a great level of control over active sessions, along with the possibility to revoke any session at will. The downside of this approach is the impact on scalability, requiring solutions such as "sticky sessions", or "session replication". Given these downsides, using server-side sessions with a BFF is only recommended in small-scale scenarios.

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#name-cookie-based-session-manage

[tarmolehtpuu]

Yes the entire session is serialized in the cookie, which has the nice property of making all the spring boot apps stateless (client will pass the session state via the encrypted cookie). Using that to store has the 4kb limitation, but upside is that the request can go to any instance.