feat: support optional stateless association of token with session #72
Conversation
Added the getSessionIdentifier parameter to the csrf-csrf configuration. By providing the getSessionIdentifier callback, generated tokens will only be valid for the original session identifier they were generated for. For example: (req) => req.session.id The token will now be signed with the session id included, this means a generated CSRF token will only be valid for the session it was generated for. This also means that if you rotate your sessions (which you should) you will also need to generate a new CSRF token for the session after rotating it.
Any session. An anonymous session will still have a csrf token, and you can still tie that csrf token to that session by the session id. By session I just mean the id of the session, the session string. For people using JWT as a session identifier, then that would be considered their session id, and they would only need it when authenticated. So, creating a session and generating a csrf token, this will work. Once the user logs in, the session SHOULD be rotated, but this logic is often left to the developer, and most aren't well-versed or educated and they don't actually do this. In this case, the CSRF token generated when the session was created will continue to work. However, if the session is rotated (session id changed) when login occurs (privilege escalation) as it should, then those developers will also need to make sure a new CSRF token is generated on the session rotation. Similarly for rotating on logout. |
Natively support session <> CSRF token association so CSRF tokens are only valid for the session they are generated for.