세션 VS JWT(토큰) .Feat 쿠키

사용자 인증이 필요할 때 (Authentication) 

서버와 DB 는 사용자에게 일종의 ID 구별자를 줘서 

해당 사용자님이 맞음을 인증 해줘야 한다. 

 

일단 HTTP 는 stateless 한 특성을 지닌다. 

사용자가 서버로 보내는 모든 요청들은 서로 독립적이고 (Indenpendent) 연결점이 없다. 

즉, 매 요청이 끝나면 서버는 기억상실에 걸려 

같은 사용자가 다음 요청을 보내면 

 

"근데 누구셨더라..?" 가 된다. 

 

이때, 서버한테 정신줄 꽉 잡고 기억좀 하라고 계속 사용자 정보를 알려주는게 바로 

 

Session 이다. 

 

처음 사용자가 서버에 요청을 보내면,

서버는 사용자 정보를 Session DB 에 보내고, 

Session DB는 별도의 Session ID 를 만들어 서버를 통해 사용자에게 돌려보내며 '낙인'을 찍는다.

 

그럼 사용자가 다음 요청을 보낼 때,

서버에 보내는 요청에는 이 '낙인' 정보가 함께 보내진다. (Sessoin ID) 

서버는 이 Session ID 를 DB에 전달해 주는 역할만을 수행한다. 

그럼 DB는 Session ID를 보고, 

 

"아 맞네 이분이다. 기억난다. 물건 내드려라" 

 

하고 인증이 완료되고 Response 응답이 수행된다. 

 

이때, 사용자의 요청, 서버의 응답 이 왔다갔다 할 때, 

응큼한 Cookie 라는 놈도 몰래 따라서 왔다갔다 하고 있다. 

이 Cookie는 사용자의 다양한 정보를 담는 '박스' 같은 역할을 하는데,

Session ID 또한 이 Cookie 박스에 담겨서 옮겨진다. 

 

 

이렇게, Session 과 Cookie 를 사용해서 사용자는 DB 로부터 인증을 받을 수 있게 된다. 

 

Session은 사용자 요청이 있을때마다,  매번 Session ID 를 DB에 저장하고, 사용자에게 Session낙인을 찍어줘야한다.

(기억상실 HTTP 를 위해서)

그러다보니, DB 리소스를 잡아먹는다는 단점도 있다. 

 

하지만, 그만큼 Session ID 하나하나로 관리가 되기 때문에, 

예를 들어, 특정 사용자를 추방시키고 싶으면 

Session ID 를 찾아서 Session 을 지워버리면 된다. 

즉, Session ID 를 이용한 관리가 용이하다. 

 

- 

 

반대로 이런 추방 시스템을 수행하지 못하는 낙인방법이 있는데 

그게 JWT, JSON Web Token. 바로 토큰이다 

 

Session 은 사용자에게 Session ID 를 낙인 찍었다면, (DB에서 받아와서) 

JWT      는 사용자에게     Token    을 던져 낙인 찍는다. 

 

가장 큰 차이점이라면 

JWT 가 던지는 토큰은 Session 처럼 DB에서 받아오는게 아니라는 점이다.

 

JWT 는 서버에서 스스로 낙인을 찍고, 사용자에게 토큰을 던진다.

 

JWT : "뭘 DB 씩이나 써 그거 도장좀 찍는데. 내가 알아서 해줄게" 

 

멋진 녀석이다. 

 

사용자가 id 등 유저정보를 지닌 COOKIE 를 서버에 보내면, 

JWT는 Sign 알고리즘을 통해 사용자정보를  => Signed Information  ( 낙인찍힌 정보 ) 로 정보화 해버린다. 

 

siajdfpsdnafisadjfp.asnqvjagaswef-asvasnabsklsjdnvlkdsjfkj  ( 대충 Token의 어질어질 모양새 ) 

 

서버는 이 낙인찍힌 Token 을 사용자에게 던진다. ( Cookie 에 담아서 )  

 

그럼 사용자가 다음 요청을 할때,

"서버"는 사용자에게 찍힌 Token 낙인 을 확인해서

인증이 완료되고 응답을 받을 수 있게된다. 

 

Session 에서는 서버는 단지 전달만 했을 뿐, 인증확인은 Session DB 가 했는데  

JWT 에서는   서버가 인증까지 해준다. ( Token 이 유효한지만 검증 ) 

 

결국 JWT 는 DB 없이 자기가 모든 일을 해낸다. 

그렇기 때문에, DB 리소스를 쓰지 않는다는 장점이 있다. 

 

하지만, DB 가 없다는건? 

- Session 처럼 DB 에서 Session ID를 관리해서 삭제 - 유저를 추방는등의 기능을 할 수 없다는 것이다. 

- JWT 는 암호화 되어있지않고 Open 되어있다. ( 비밀번호 같은 정보는 Token 에 담으면 안된다 ) 

 

하는 단점이 있다. 

 

그래서 보통 JWT 는 인스턴스식품같이(?) 약간 작은 서비스에 효율적으로 쓰일 수 있고,  - QR 코드! 

Session 은 사용자 관리가 철저히 필요하고, 유지해 나가야하는 큰 서비스에 필요하다.     - 넷플릭스! 

 

Session 과 JWT. 

필요에 따라서 적절하게 사용할 수 있도록 역량을 키워나가야 겠다. 

 

 

- 정리 - 

Cookie -  그냥 담는 박스. 

 

Session -  DB이용. Sesson ID 낙인, 요청마다 Session 생성 (HTTP 기억상실), 큰 서비스, 

 

JWT (Token) -  DB 안씀, 서버레벨에서 해결, Token 낙인. Signed information, 암호화X, 가벼운 서비스,