Feat/hmac token signing

[psibean]

The eventual intention before the next major release is to completely revamp the documentation and the testing suite as well, as well as provide more and better detailed examples. For testing, instead of repeating the same suite for all of the different configurations, I'd like to start splitting out the tests and only run the minimal amount needed, as well as generate a test coverage report to actually capture what has and hasn't been tested.

These changes are implicitly dependent on #60

The documentation and test changes aren't the best and there are some new edge cases not covered in the tests, such as one session trying to make a request with a CSRF token generated for another session. However, I plan on overhauling both the documentation and the tests before the next release, hopefully generating some sort of documentation from TSDoc, and also including a test coverage report.

[davidgonmar]

lgtm.
I am assuming if one does not want to use session identifiers they can just do getSessionIdentifier = () => "", right?
Is it the best option to use express session as the default though?

[psibean]

lgtm. I am assuming if one does not want to use session identifiers they can just do getSessionIdentifier = () => "", right?

I think the direction I'd like to go is to not explicitly support cases where the session id is not tied to the token. The recommended practice is that generated tokens should only be valid for the session that requested it, and this acheives that in a stateless way. In the case where getSessionIdentifier returns "", yeah that would work, but it will also be recommended that you otherwise tie the token to the session by some other means.

Is it the best option to use express session as the default though?

Not sure, are you suggesting we don't provide a default, thus removing the dev dependency on express-session?
And users have to provide this method? I wouldn't want to put a return of "" as a default, so no default would be the next best thing and would alleviate the implicit express-session introduced here. Could update doc to making it a required config option.

[davidgonmar]

lgtm. I am assuming if one does not want to use session identifiers they can just do getSessionIdentifier = () => "", right?

I think the direction I'd like to go is to not explicitly support cases where the session id is not tied to the token. The recommended practice is that generated tokens should only be valid for the session that requested it, and this acheives that in a stateless way. In the case where getSessionIdentifier returns "", yeah that would work, but it will also be recommended that you otherwise tie the token to the session by some other means.

Is it the best option to use express session as the default though?

Not sure, are you suggesting we don't provide a default, thus removing the dev dependency on express-session? And users have to provide this method? I wouldn't want to put a return of "" as a default, so no default would be the next best thing and would alleviate the implicit express-session introduced here. Could update doc to making it a required config option.

Hmmm isn't express-session stateful actually (afaik it stores them in memory by default)? I get the appeal, but the main point of double submit pattern is for it to be completely stateless, right?

Hmmm isn't express-session stateful actually (afaik it stores them in memory by default)? I get the appeal, but the main point of double submit pattern is for it to be completely stateless, right?

Also, I can't really think of a stateless way of maintaining a session in that sense.

[psibean]

Also, I can't really think of a stateless way of maintaining a session in that sense.

Right, but in a case where, let's say, a user is using JWT is a httpOnly cookie, then getSessionIdentifier here would just return the JWT from the cookie value. Or whatever httpOnly cookie value they're using for their authenticationauthorization identification.

If they aren't using a httpOnly cookie, then they aren't susceptible to CSRF, regardless of stateless or not.

I understand that the double submit pattern can be used from only the client side, without the backend being involved in the token generation at all - but all of the best practices recommend a backend using a secret so that you can guarantee where the token was generated from, and additionally, it's also recommended to include some piece of information when hashing that ties the token directly to the person who requested it.

Maybe I should rename it to getUniqueIdentifier as it isn't necessarily a session, it could also be the users id. The problem with using the user id, it doesn't exist before authenticating. But for people using JWT as a cookie, they don't typically need the authentication routes protected because there's no httpOnly cookie involved at that point for them.

Edit: I think I accidentally deleted a message, no idea how.

For express-session using memory by default, yes, it does, but express-session also says NOT to use the default in production and has a list of recommended DB or cache based stores. But yeah, it's stateful. Though providing it as a default doesn't require express-session if you're overriding it. Nor does the default even require express-session, it just requires a session object with an id to exist on the request, regardless of where it came from.

[davidgonmar]

Also, I can't really think of a stateless way of maintaining a session in that sense.

Right, but in a case where, let's say, a user is using JWT is a httpOnly cookie, then getSessionIdentifier here would just return the JWT from the cookie value. Or whatever httpOnly cookie value they're using for their authenticationauthorization identification.

If they aren't using a httpOnly cookie, then they aren't susceptible to CSRF, regardless of stateless or not.

I understand that the double submit pattern can be used from only the client side, without the backend being involved in the token generation at all - but all of the best practices recommend a backend using a secret so that you can guarantee where the token was generated from, and additionally, it's also recommended to include some piece of information when hashing that ties the token directly to the person who requested it.

Maybe I should rename it to getUniqueIdentifier as it isn't necessarily a session, it could also be the users id. The problem with using the user id, it doesn't exist before authenticating. But for people using JWT as a cookie, they don't typically need the authentication routes protected because there's no httpOnly cookie involved at that point for them.

Edit: I think I accidentally deleted a message, no idea how.

For express-session using memory by default, yes, it does, but express-session also says NOT to use the default in production and has a list of recommended DB or cache based stores. But yeah, it's stateful. Though providing it as a default doesn't require express-session if you're overriding it. Nor does the default even require express-session, it just requires a session object with an id to exist on the request, regardless of where it came from.

I think that's fine yeah. I saw the 'session' in the name and did not think of that haha