3 ms·

A lot of your auth and session architecture depends on if you are doing a multi-page application or a SPA. If you are doing an SPA, I would just use a JWT and k

by kls 6y ago

A lot of your auth and session architecture depends on if you are doing a multi-page application or a SPA. If you are doing an SPA, I would just use a JWT and keep it in memory, don't put it in a cookie. If you are doing a MPA, I would only use a session cookie and set the secure only flag as well as the same origin flag for the cookie. Obviously any auth and session management should be done via TLS (and only allow the last few latest and greatest, don't let the client downgrade you to something that can be exploited), if they compromise TLS we all have bigger problems than the fact that they got your cookie and a user session. If the client is owned by a hack there is not much you can do, as they already have the client, you just have to protect your endpoints from that client exploiting your server for more than that users information or privileged escalation attacks. But honestly the best thing to do, is not roll your own. Use an existing auth solution. Httpd is pretty hardened and they are plenty of auth solutions for it, if you are using it.

m33k44 6y ago
> If you are doing a MPA, I would only use a session cookie and set the secure only flag as well as the same origin flag for the cookie. I am doing an MPA. I am setting a session cookie, the secure only flag and the origin flag. But I am using JWT to store the ephemeral session id which is then compared on the server-side to the session cookie as a cross-check. A new JWT with new id is created for each request. That way the server remains stateless and the client gets new token back for each request; this token is then used in the next request. The only question I have is what are the disadvantages of doing this i.e. making each request independent of the other requests and then cross-checking the validity of incoming request by comparing id stored in the JWT with the one stored separately in another cookie. > Httpd is pretty hardened and they are plenty of auth solutions for it, if you are using it. I am not using httpd.

by kls 6y ago

m33k44 6y ago

> If you are doing a MPA, I would only use a session cookie and set the secure only flag as well as the same origin flag for the cookie. I am doing an MPA. I am setting a session cookie, the secure only flag and the origin flag. But I am using JWT to store the ephemeral session id which is then compared on the server-side to the session cookie as a cross-check. A new JWT with new id is created for each request. That way the server remains stateless and the client gets new token back for each request; this token is then used in the next request. The only question I have is what are the disadvantages of doing this i.e. making each request independent of the other requests and then cross-checking the validity of incoming request by comparing id stored in the JWT with the one stored separately in another cookie. > Httpd is pretty hardened and they are plenty of auth solutions for it, if you are using it. I am not using httpd.