Day 49 of #100DaysOfCode: Review session-based authentication and token-based authentication (same origin)
Tags: 100daysofcode, session, jwt, javascript
Published: 2020-11-20 13:34:08

## Session-based authentication (sessions + cookies)  

### Procedures
1. The browser send the request with the user name and the password
2. The server verifies the credential with the database
3. The server generates the session for the user
4. The server set the cookie with the session ID
5. The browser send the request with the session ID
6. The server verifies the session with the database
7. The server destroy the session and clear the cookie when the user log outs

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/h5kdtldi8kpzcm1z6bt5.jpg)

### Features
* Used for: SSR web apps, frameworks (Spring, Rails), scripting langs (PHP)
* Stateful in the server-side: session is stored server-side and linked by session ID

### Pros
* session IDs are no meaningful data

### Cons
* server must store each user session in memory
* horizontal scaling is challenging: need [sticky sessions](https://www.itread01.com/articles/1475241626.html) with load balancing

## Token-based login (stateful JWT: JWT + cookies)
I think that it's safer to use JWT by [Double tokens policy: HttpOnly Cookie + CSRF token](https://medium.com/a-layman/where-should-we-store-the-jwt-for-spa-memory-cookie-or-localstorage-2491912d8e79) which is called stateful JWT. It can keep several 
advantages for storing JWT in cookies.
1. HttpOnly: avoid being manipulated by JavaScript (XSS)
2. Secure: cookie can only be sent to the server by HTTPS

### Procedures
1. The browser send the request with the user name and the password
2. The server verifies the credential with the database
3. The server generates the JWT for the user
4. The server set the cookie(HttpOnly, Secure) with the JWT
5. The browser send the request with the JWT
6. The server verifies the JWT

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/490iqhvxplwemroizu21.jpg)

### Features
* Used for: SPA (CSR), web APIs, mobile maps
* Stateless: session is not stored server-side
* Self-contained: carries all required user data in the payload. Reduces databases lookup

### Pros
* FE and BE architecture is decoupled, can be used with mobile apps

### Cons
* The server still has to maintain a blacklist of revoked tokens
* When scaling, the secret must be shared between servers

That's it!

## Articles
There are some of my articles and released projects. Feel free to check if you like! 
* [My blog-posts for software developing](https://medium.com/a-layman)
* [Facebook page](https://www.facebook.com/imalayman)
* [My web resume](https://jenhsuan.github.io/ALayman/cover.html)
* [Twitter bot](https://twitter.com/ALayman84368087)
* [Side project - Daily Learning](https://daily-learning.herokuapp.com/)

## References
* [Stop using JWT for sessions](http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/)
* [（译）别再使用 JWT 作为 Session 系统！问题重重且很危险。](https://learnku.com/articles/22616)
* [在Http Only 的網站 傳送 JWT Token 至後端API](https://ithelp.ithome.com.tw/questions/10196475)
* [負載均衡常見問題之會話保持-粘滯會話(Sticky Sessions)](https://www.itread01.com/articles/1475241626.html)
* [Authentication on the Web (Sessions, Cookies, JWT, localStorage, and more)](https://www.youtube.com/watch?v=2PPSXonhIck)