Session vs JWT

1. Authentication/Authonization
2. cookie
3. session
4. jwt

로그인을 했다고 치자. 우리는 이 "로그인 됨"을 같은 도메인의 메일,블로그,카페 등 여러 서비스에서 사용할 것이다. 당연한 얘기지만 각 서비스를 이용할 때마다 로그인을 해야한다면 여간 번거로운 일이 아닐 것이다. 즉 "인증"을 여기저기 "인가"하여 사용하고 싶다. 즉, 인가는 인증된 사용자의 자원에 대한 접근을 확인하는 절차이다. 이 보안 방법은 크게 "세션" 과 "JWT"라는 토큰 방식으로 나뉜다. 둘을 얘기하기에 앞서 가장 기본이 되는 쿠키에 대해 먼저 얘기하겠다.

1. 쿠키(Cookie)

쿠키만 두고 보자면 server 에서 발행한 정보를 클라이언트 측에서 보관하는 방법 정도로 생각할 수 있다. 서버에서 쿠키의 이름, 값, 만료 날짜/시간(쿠키 저장기간), 경로 정보를 지정하여 HTTP response Header 에 key,value 형태로 값을 저장하게 되고, 클라이언트는 상태정보를 로컬에 저장하여, 요청시 request 헤더에 넣어서 보내게 된다. 서버의 stateless 함을 극복하고자한 방법이다.

본론으로 돌아와 인가에 대해서 적어보겠다. 인가의 과제는 결국 내가 인증되었음을 빠르게 증명할 수 있으면 된다. 이는 크게 "서버에서 기억하기" 와 "증명 배지 발급하기" 로 나뉜다.

2. 세션(Session)

"서버에서 기억하기" 이다. 세션에서 현재 사용자가 이미 인증되었음을 기억하고자 한다. 방법은 사용자의 정보를 기반으로 세션 id 를 발급하여 쿠키에 담아 클라이언트에게 응답을 보낸다. 클라이언트 측은 다른 서비스를 이용할 때 마다 매번 세션 id 를 보여주어 자원을 이용할 수 있게 허락받는다.

1. 사용자가 로그인

2. 인증정보를 서버에 저장 및 session ID 발급(식별자)

3. 쿠키 형태로 저장하여 클라이언트 측에 보냄. 실제 인증정보는 서버에 저장

   위와 같은 과정으로 진행이 된다. 이 방법은 서버에 사용자 정보가 저장되어 있기 때문에 보안상 유리하다.(세션 아이디가 탈취되었다 판단되면 인증정보를 무효처리하면 된다) 그러나 서버의 상태에 상당히 의존적이고, 서버의 규모가 커서 수평 확장된 형태로 돌아가는 서버에 대해서는 인증정보를 공용 데이터베이스에서 관리를 해야하므로 인가 속도가 굉장히 느리게 작동할 것이고, 사용자가 많을 수록 서버에서 사용되는 메모리가 늘어나게 된다.

3. JWT(Json Web Token)

"증명 배치 발급하기" 이다. 정확히 말하면 "토큰"이란걸 발행하여 문제를 해결한다. 이 방식은 유저의 정보를 서버에 저장하지 않는다. 서버는 토큰을 "발급"하여 매 접근시 토큰을 "검증"함으로써 클라이언트의 인증을 증명한다.
JWT 는 세부분으로 구성된다.
Header, Payload, Signature

• Header
  토큰의 유형과 암호화 알고리즘 정보
• Payload
  사용자의 정보 혹은 데이터 속성 등을 나타내는 클레임이라는 정보 단위로 구성된다.
  1) iss 토큰 발급자
  2) sub 토큰 제목
  3) autd 토큰 대상자
  4) exp 토큰 만료시각
  5) nbf 토큰의 활성 시각
  6) iat 토큰이 발급된 시각
  7) jti JWT ID
• Signature
  특정 암호화 알고리즘을 사용하여 헤더, 페이로드, 비밀키를 암호화한다. 이 값을 통해 서버는 보안을 유지하고 무결성을 검증한다.