Stateless 아키텍처와 JWT( Json Web Token )

* session 기반 인증

서버 개발자들이 session id row들을 가지고 timeout까지 관리해야하니

client로 토큰 관리를 넘겨버림

- http 프로토콜은 무상태 프로토콜이다

=> 이전 요청을 알 수 없다

- 요청에 대해 식별해야 한다 : 인증이 필요하다

로그인을 하면 session이 만들어지고 응답하면서 cookie 헤더에 실어보낸다

이후 요청할 때마다 쿠키를 실어 보낸다.

 

* 모든 서버들 사이에서 session이 공유되지 않는 경우 문제될 수 있다.

따라서 별도 DB를 두거나 Session Cluser라는 기법을 활용한다

session은 메모리상에서 관리되게끔 한다

RDB보다 key-value DB를 사용하게 한다

session기반 : 서버 안에서 파일을 호스팅해서 처리를 많이 한다

앱서버에서 웹서버를 같이 묶어 배포한다?

 

* session이 없는 방식 : sessionless

무상태 : stateless - JWT 기반

 

session 정보가 서버에 없다

로그인하면 서버가 토큰을 준다.

토큰을 브라우저가 관리한다. 자바스크립트 객체처럼 만들어서 보관한다.

토큰화시켜서 string으로 쭉 만든다??

요청할 때마다 이 토큰을 보내는데 서버에서는 DB를 뒤지는게 아니라 내가 발급한 토큰이 맞는지만 검증한다.

어떤 유저의 요청이라는 것을 식별할 수 있다

- secret을 서버가 관리한다

- 브라우저가 토큰 주면 서버는 secret을 이용해서 verify만 하면 된다

토큰을 깠는데 expired date 지나면 요청 안 받는다

- secret키를 알아야만 토큰이 만들어지므로 토큰은 서버만 만들 수 있다

- 인증된 사용자 정보를 저장하는 session은 없어짐

- secret을 이용해서 encode, decode하는데 서버만 관리한다

서버가 payload 만들어준다

header에 매 요청마다 실어서 보낸다

 

* session : 서버쪽에서 보관

sessionless : 서버가 보관X, 대신 client가 관리

 

* JWT : 로컬 스토리지에 저장, 혹은 쿠키에 저장

쿠키는 서버에서 해줘야 한다

로컬스토리지는 XSS(Cross Sitet Scriping) 공격에 취약하다

쿠키 : httpOnly로 해주고 https로 해줘야 보안적으로 좋다

- 다른 사이트에서 로그인을 하게 해서, 쿠키가 자동 전송되는것 받아

- 매번 요청할 때마다 random 값 붙여야 - salt값

 

Note : CSRF = Cross Site Request Forgery

user logs into his bank

-> the bank gives the user a session token

-> Hacker tricks user into clicking on fake link pointing to the bank

 

* thunk에서 login 호출 후 토큰 decode

token을 decode해서 username을 알아내서 쓸 수 있다

토큰이 커지면 요청할 때마다 payload가 커지므로 토큰은 간소한 것이 좋다