세션 vs JWT

[출처] - 얄팍한 코딩사전

https://youtu.be/1QiOXWEbqYQ

 

 

1. 인증, 인가 차이 (Authentication vs Authorization)

---

 - 인증(Authentication): 쉽게 말해서 로그인, 이 사이트에 가입된 회원임을 확인하는 것

 - 인가(Authorization): 한 번 "인증"을 받은 사용자가 서비스 여러 기능 사용 시 로그인 되어있음을 알아보고 허가를 해 주는 것

    ex) 페이스북에서 로그인으로 인증 후 내 친구목록을 확인하는 행위와 같이 내 계정으로'만' 할 수 있는 것을 보고 허가를 해 주는 것 즉, 로그인이 유지되는 상태에서 일어나는 일

 - 얄팍코딩에서는 'Authorization'을 기억하기 쉽게 로그인 된 사용자를 환영하는 '어서와'라고 부르기도 합니다 ....

 

 

 

 

 

2. 인가 방식 중 하나인 "세션"

---

- 어떤 사용자가 서버에 로그인 되어있음이 지속되는 상태를 '세션' 이라고 한다.

[동작방식]
 - 사용자가 로그인에 성공하면 서버는 일종의 '세션 표딱지'를 출력함 
 - '세션 표딱지'의 반쪽은 사용자 브라우저, 다른 반쪽은 인메모리에 올린다.
 - 사용자 브라우저가 요청 시 Session ID란 쿠키를 보내게 되고 서버는 이에 맞는 반쪽을 찾는 형태
 
[세션 표딱지의 위치]
 - 사용자 브라우저가 가진 '세션 표딱지'를 Session ID란 이름의 쿠키로 저장
 -  나머지 '세션 표딱지'의 절반은 서버가 인메모리에서 갖고 있는다.

[세션의 단점] 
 - 동시접속 사용자가 많아지면 메모리 고갈 우려 존재
 - 휘발성 메모리에 저장하기 때문에 재부팅 시 삭제될 수 있음
 - 서버마다 세션스토리지가 있기 때문에 다수의 서버를 운영하는 경우 로드밸런싱 시 문제가 된다.

[다수의 서버를 운영할 때 세션을 사용하는 법]
 - Redis 혹은 Memcached 같은 인메모리 DB를 사용한다. 

 

 

 

 

 

3. JWT 토큰

---

- JWT란 Json Web Token의 약자로써 Json 포맷을 이용하여 사용자 속성을 저장하는 Claim 기반의 웹 토큰입니다.

- 중간 점을 기준으로 [헤더.페이로드.서명] 으로 구성되어 있습니다.

 

 

[JWT 구성] - Header, Payload, Signature
 [1] Header : 디코딩하면 2개의 정보로 구성
    (1) type : 보통 "JWT"가 들어간다.
    (2) alg : 알고리즘, Header + Payload를 넣고 해당 알고리즘을 돌리면 Signature값이 나오게 된다. 
                  '서버의 비밀 키'와 함께 돌려서 계산된 결과값이 Signature과 일치하는지 확인
 [2] Payload : Base64로 인코딩되어 누구에게 발급했는지 언제까지 유효한 지 토큰 내용(유저권한, 유저ID)
                  등을 담고 있다. ( Claim 이라고 함 )  ==> 따라서 세션과 다르게 DB에서 찾아볼 필요가 없다.

 

 

 

 

4. 둘의 비교 (얄팍한 코딩사전)

---

 (1) 세션은 stateful, JWT는 stateless 하다. 세션은 한 기기에서만 사용하도록 통제가 가능하다.

 (2) JWT 토큰은 탈취당할 수 있는 문제가 있다. 이를 보완하기 위해 access Token의 수명을 짧게 하고

     로그인 시 access Token(보통 몇 분)과 refresh Token(보통 2주) 발급한다.

JWT 토큰 (access Token + refresh Token 같이 관리하는 경우)
    1. 로그인 시 access Token과 refresh Token을 발급해 준다.
    2. access Token을 발급받은 유저가 자유롭게 이용한다.
    3. 특정 api 인가 시 access Token의 수명이 만료되었다면 
    4. 유저는 refresh Token을 서버에게 전송한다.
    5. 서버는 Redis 혹은 DB에 저장된 refresh Token과 대조해 보고 맞다면 새 access Token을 발급해 준다. 

 (3) access Token 주기를 짧게 하고 refresh Token를 사용하면 보안성에 이점이 있겠지만

     마찬가지로 짧은 access Token 주기 동안 토큰을 탈취당한다면 결국 취약합니다.

 

실제 실무에서는 JWT만을 쓰는 경우는 적다고 합니다.

 

 

 

 

5. 결론 및 번외 (다른 분들의 의견 정리 - 무한루프 코딩)

---

 - 간단한 프로젝트, 예민하지 않은 데이터를 다루고 경제적인 면이 중요할 땐 ==> [JWT]

 - But 조금이라도 보안이 요구된다면 ==> [세션] 

 

 - API call이 많은 사이트일수록 JWT로 인한 Overhead가 있기 때문에 JWT를 안 쓴다고 합니다.

 - JWT도 대칭키가 아닌 비대칭키로 사용할 수 있다고 합니다. (키워드 : JWKS) 

 

 [확장]

 - 세션의 경우 서버 1대라면 인메모리로 구현이 가능하지만,

 - 만약 트래픽이 늘어 Scale Out하게 된다면 곤란해지는 문제점이 있습니다.

 - 이 경우 Redis로 세션 스토리지를 만들어서 여러 서버가 같은 Redis 세션 스토리지를 바라보게 하는 것도 있지만 

 - Redis에 과하게 트래픽이 몰릴 수 있으니 [api -> 로컬 캐시 -> Redis]로 캐싱하면 그나마 부하가 줄어들 수 있다고 합니다. 

  ==> 이 부분에 대해서 자세한 내용을 아신다면 댓글로 가르쳐주시면 감사하겠습니다 😂😂😂