[Server] 세션, 쿠키, 토큰 정리

앱 개발을 하다보니, 서버에 대해서도 공부를 해야겠다는 생각이 들었다.
로그인과 회원가입을 구현하기 위해 세션, 쿠키, 토큰에 대해 간략하게 정리해봤다.

먼저 HTTP 통신은 요청(Request) -> 응답(Response) 이 종료되면 stateless(상태가 유지되지 않은) 한 특징 때문에 연결을 끊는 처리 방식이다. 
* Stateless : 서버에 가는 모든 요청이 이전 request와 독립적으로 다뤄짐. 요청이 끝나면 접속을 끊어서 이전 데이터를 유지하지 않는다.

 → 여기서 클라이언트의 상태를 기억하기 위해 쿠키, 세션, 토큰을 사용하게 된다. 

 

*  Cookie 

쿠키를 이용해서, 서버가 브라우저에 데이터를 넣을 수 있음. 
웹에 방문하게 되면 브라우저에서 서버로 필요한 정보를 request, 서버에서 브라우저로 response하는 과정을 거친다.
브라우저가 서버와 연결이 될 때, 브라우저에 저장하고자 하는 쿠키를 생성하고, response 할 때 브라우저로 넘겨준다.
그럼 이제 브라우저가 특정 서버(해당 웹사이트)에 연결할 때마다 저장된 쿠키를 함께 보내게 된다.
자동로그인 인증이나 나라, 언어 설정 등의 정보를 담아둔다. 

• key-value 쌍의 데이터 파일로 클라이언트 로컬 브라우저에 저장된다.
• 쿠키이름, 쿠키값, 만료 시간, 도메인, 경로 정보로 구성된다

 

*  Session

쿠키의 경우, 브라우저에 그대로 데이터가 저장되기 때문에 보안의 문제가 있을 수 있음. 세션은 인증 정보를 브라우저에 저장하지 않고, 

로그인을 하게 될 경우, 아이디, 비밀번호를 서버에 보내 인증된 유저라면 서버에서는 세션 db에 유저를 생성한다. (로그아웃/종료를 하면, 세션 db에서 삭제됨)
이 세션 ID는 쿠키를 통해 브라우저로 response된다. 유저가 웹에서 활동을 하면, 세션 ID를 가진 쿠키를 전송하고, 서버에서는 다시 세션 ID를 가지고 세션 DB에 해당하는 유저 정보를 파악한다.
즉, 브라우저(클라이언트)에서는 세션 ID 값을 가진 쿠키만 갖게 되고, 서버에서 세션ID를 사용하여 유저의 정보를 저장하게 된다. 

세션은 서버에 저장이 되고, 서버 내에서 처리하기 때문에, 유저가 늘어날 경우 많은 리소스가 필요하고, 서버에 과부하가 일어나게 된다. 

 

* Token(JWT)

쿠키나 세션의 경우, 브라우저에서만 사용 가능하다. 앱의 경우에는 token을 활용함.

세션의 경우에는 현재 로그인 되어있는 유저의 모든 세션 ID를 DB에 저장해야함. 요청이 들어올 때마다 세션 ID와 일치하는 유저를 찾아 작업을 수행한다. 여기서 많은 리소스가 소요됨. 
JWT는 이러한 작업 없이 로그인된 유저에 signed value(token)를 함께 전달한다. 서버에 request를 하게 될 때, 세션ID처럼 token을 서버에 보낸다. 서버가 토큰을 받으면 해당 값이 유효한지 체크하고, 토큰이 유효하면 유저로 인증된다. 
즉, 새로운 DB생성 없이 해당 토큰이 유효한지만 검증하는 것. 

유저가 로그인을 할 때, 서버에서는 유저를 확인한 후, 고유한 ID값과 함께 유효기간을 설정해 암호화한 JWT를 발급한다.
유저는 JWT를 저장한 후, 인증이 필요할 때마다 토큰을 같이 서버에 보낸다.
서버는 토큰 값을 복호화해서 조작 여부, 유효기간 확인하고 검증이 되었다면 유저ID에 맞는 데이터를 가져온다.

• Header, payload, signature로 구성되어 xxx.yyy.zzz같은 형태로 생성된다. 
• token을 복호화하면 json 형태로 토큰 타입, 토큰에 대한 정보, 서명(이건 서버가 가지고 있는 개인키로만 암호화를 풀 수 있음)이 담겨있다.