This Blog post will try and answer some of the common questions on how Play 2.6 deals with session data:
- How is session data transferred and stored?
- How is session data encrypted?
- How is session data integrity maintained?
How is session data transferred and stored?
Play 2.6 does not store session level data on the server at all. All of the data is stored on the client side as is sent with every subsequent request as part of the Cookies header.
This approach to handling session data means that Server will not have to store any of the session data, so the Servers memory footprint the will be smaller, this also allows for sessions to stay maintained even if the Server has to reboot. The memory overhead of session data is moved from the server's storage into every request that comes from the client. All changes to the session data are flushed down to the client when the response from the server is generated and they are sent as part of the Set-Cookies header.
Data in Play session is stored within a JSON Web Token (JWT). JWT is a String made out of 3 parts separated by a '.' char, the 3 parts are header, payload, and signature.
How is session data encrypted?
Play 2.6 session data is NOT encrypted, it is base64 encoded but can be decoded and changed easily.
Here is an example of a Play session:
The payload part of this session is:
When we base64 decode this text we get:
Play session data is not encrypted, to lower the chance of someone getting sensitive data from the session or someone performing session hijacking to your users you should encrypt your client-server interactions by running your backend with HTTPS with an SSL certificate.
How is session data integrity maintained?
Because Play 2.6 is using JWT's to represent the session data integrity is maintained by using the last (signature) part of the JWT.
Before Play 2.6 sends session data (payload part of the JWT) to the client it uses a private key to generate the signature part of the JWT. The signature can only be generated with the private key that the server has. When a request is received payload part is used used to generate the signature again with the same key and if it does not match the signature, that the client has sent, the session is considered invalid (tempered with).
The private key that Play is using is defined in application.conf under "play.http.secret.key".
Play 2.6 has a great session management mechanism that does not let session data eat up all of the memory of your server.
As long as the App is running with an SSL certificate the data will be encrypted and because of Plays use of JWT the integrity of the data will be maintained.
My email is firstname.lastname@example.org, let me know if you have any questions or suggestions.