팀 프로젝트를 진행할 때 팀원 간의 기술 스택 문제로 프로젝트를 여러개로 나누어 개발한 적이 있다.
이 때, 사용자가 로그인 할 경우 각 애플리케이션 간에 로그인 상태를 유지해야 했기 때문에 JWT를 도입했다.
결과적으로 구현에는 성공했으나 JWT에 대한 깊은 이해가 없는 상태로 적용했던 것 같아, 조금 정리해 보고자 한다.

JWT란

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object.

JWT 공식 사이트에서 가져온 내용이다.

대충 해석해 보면 "JWT란 두 당사자 간에 JSON 형태로 정보를 교환하는 표준이며, 가볍고(?), self-contained 하다."

self-contained 하다라는 말은 처음 들어 보았는데, 찾아 보니 "독립적으로 필요한 모든 것을 가지고 있는" 이라는 뜻이라고 한다.

즉, 스스로 모든 정보를 내장하고 있는 JSON 형태의 정보 교환 방식이라는 뜻으로 요약할 수 있을 것 같다.

JWT의 구성

먼저, JWT의 구성에 대해서 간단하게 알아 보자.

JWT는 점(.)으로 구분되는 Header, Payload, Signature 이렇게 3가지 요소로 구성되어 있다고 한다.

xxxxx.yyyyy.zzzzz 이런 형태를 갖는다.

1. Header

Header는 사실 크게 별 거 없다.

{
  "alg": "HS256",
  "typ": "JWT"
}

위와 같이 알고리즘과 타입 정도만 지정한다.

여기서 알고리즘은 Signature 부분에서 사용되는데 그 이유는 밑에서 설명하겠다.

2. Payload

Payload는 데이터를 담는 부분이라고 생각하면 된다.

토큰에 담고 싶은 정보들은 실질적으로 이 곳에 담기게 되는 것이다.

이 Payload에 담기는 주체(Entity)에 대한 정보나 부가적인 데이터들을 클레임(Claim)이라고 한다.

JWT에서는 이러한 클레임을 3가지로 나누어 표현하였는데, registered, public, private 클레임이다.

아마 개념적으로 표준을 정해 놓은 것이지, 꼭 저 형태에 맞춰서 해야 한다는 것은 아닌 것 같다. ( OSI 7Layer 같은 느낌..? )

1. Registerd 클레임
   • 필수적인 내용은 아니지만 포함하길 추천하는 내용들이며 표준으로 이름이 정해져 있음. [ 종류는 공식사이트에 나와 있음 ]

2. Public 클레임
   • 커스텀 클레임이지만, 다른 클레임들과 이름이 충돌나지 않도록 해야 한다. 보통 URI를 이용하거나 IANA에 등록하여 충돌을 방지하는 듯 한데, 왜 충돌을 방지해야 하는 지는 잘 모르겠다. ( 아무리 찾아도 이유가 안 나옴.. )

3. Private 클레임
   • 커스텀 클레임이다. 두 당사자 간에 합의하여 만들어지는 클레임으로 실질적으로 JWT를 만들어 데이터를 담으면 여기에 해당하게 된다. Registerd 클레임과 Public 클레임과 이름이 겹치지 않도록 조심해야 한다.

아마 개인적인 생각으로는 의도의 차이가 있지 않을까 싶다..
Pulbic 클레임은 고유성을 가지기 때문에 어떤 JWT에서 해당 클레임을 사용하든 역할이 명확하고 제 3자가 그 의도를 파악할 수 있지만 Private 클레임은 당사자들 간에만 합의된 클레임이기 때문에 제 3자가 봤을 때 그 의도와 형태를 완전히 이해할 수 없지 않을까 싶다.
JWT를 단순히 로그인에서만 사용한다는 고정관념(?)을 버리고 생각해 보면 이러한 Public 클레임은 JWT를 이용해 뭔가 만들고 Open하는 사람들에게 고유성을 부여해 줄 수 있지 않을까 싶다.. (잘 아는 사람은 댓글로 설명 좀)

3. Signature

Signature는 JWT가 중간에 위조되었는 지를 확인하기 위해 존재한다.

아까 위에서 본 Header의 알고리즘이 여기서 사용되는데,

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret
)

공식사이트에서 가져 온 Signature 생성 방식이다.

헤더(Header)와 페이로드(Payload)의 값을 각각 BASE64로 인코딩하고, 인코딩한 값을 서버의 비밀 키를 이용해 헤더에 정의한 알고리즘으로 해싱을 하고, 이 값을 다시 BASE64로 인코딩하여 생성한다.

위에 있는 생성 과정식을 보면 마지막에 다시 BASE64로 인코딩하는 과정은 있지 않는데, 이유는 모르겠다.

헤더의 알고리즘때문에 사람들이 JWT의 데이터가 암호화되어 전송되는 줄 알지만 실제로 Payload 부분은 암호화되지 않는다.

그렇기 때문에 JWT에는 민감한 데이터를 Payload에 담지 않는 게 중요하고, 꼭 담아야 한다면 자체적으로 암호화해서 담아야하지 않을까 싶다.

JWT 적용 방식

JWT에 대해서 알았으니 실제로 어떻게 적용해야 하는 지 알아 보도록 하자.

1. Access Token

1-1 발급

사용자가 인증에 성공했을 때, 서버에서 JWT 형식에 맞춰 Json을 만들어 보내 주면 된다.

직접 만들기가 어렵다면 라이브러리가 많이 있으니 적절하게 사용하면 된다.

이렇게 발급된 JWT는 Access Token이 된다.

1-2 저장

이렇게 완성된 Access Token을 클라이언트는 받아서 어디에 저장해야 할까??

보통 Local Storage나 Cookie에 저장한다.

Local Storage와 Cookie 모두 각각의 장단점이 존재한다.

Local Storage는 XSS 공격으로부터 방어가 쉽지 않다는 문제가 있지만 CSRF로부터는 안전하다는 특징이 있다.

Cookie는 Local Storage와 달리 Http Only 속성으로 XSS를 통한 쿠키 접근을 막을 수 있고 Same-site 속성을 통해 CSRF 공격 또한 어느정도 방어할 수 있다. 게다가 요청 시에 자동으로 함께 보내주기 때문에 보안 설정과 요청의 편리함 때문에 백앤드 개발자들이 JWT를 적용해 보기에는 Cookie가 더 선호되는 듯 하다.

다만 Cookie도 Http Only 속성을 통한 Cookie 직접 접근을 막는 것이지 XSS가 뚫리면, CSRF처럼 URL요청으로 쿠키가 자동으로 담기는 형태의 공격은 가능해진다. 또, Local Storage 보다 CSRF 방어에 취약하다. 그래서 필자는 어차피 XSS 공격은 두 가지 방식에서 모두 방어해야 한다면 개인적으로 Local Storage가 더 보안상 유리하지 않을까 하는 생각이 있다.

1-3 보안

그럼 Cookie를 사용한다고 가정하고, 어떻게 하면 보안 문제를 최대한 방지할 수 있을까?

• JWT에는 보안상 위험한 정보는 포함하지 않도록 한다.

• 클라이언트에서는 XSS를 서버에서는 기본적인 CORS와 CSRF 방어가 가능하도록 설정한다.

• Cookie를 사용할 경우 Http Only, Secure, Same-site 속성을 설정한다.

  1. Http Only 속성은 쿠키가 오로지 Http 통신에서만 쓰이도록 만들어 준다. 즉, 브라우저에서 스크립트를 통해 쿠키에 접근할 수 없게 만든다. ( XSS 예방 )
  2. Secure 속성은 쿠키가 오로지 Https 요청에서만 보내질 수 있도록 만든다.
     ( Https 프로토콜은 자체적으로 데이터가 암호화되기 때문에 탈취 당하더라도 비교적 안전함 )
     참고로 Secure 속성은 localhost에서는 먹히지 않는다. (편의 때문인듯) 로컬에서 테스트 하다가 쿠키가 넘어간다고 당황하지 말자
  3. Same-site 속성은 동일 사이트 컨텍스트에서 요청하는 경우에만 쿠키가 보내질 수 있도록 제한한다. ( CSRF 예방 -> 완벽하지 않음 )
     same-site 속성에는 None, Lax, Strict 세 가지가 있는데 해당 내용은 검색해 보면 금방 나오니 찾아 보도록 하자

     참고로 Servlet에서 사용하는 Cookie로는 same-site 속성을 줄 수가 없다. Spring에서 제공하는 Cookie를 사용하면 아래와 같이 적용 가능하다.

     ResponseCookie accessTokenCookie = ResponseCookie.from("accessToken", accessToken)
                  .httpOnly(true)
                  .secure(true)
                  .maxAge(6 * 60 * 60)
                  .path("/")
                  .sameSite("Strict")
                  .build();

위와 같은 방식으로 어느 정도 위험을 줄일 수 있다.

다만 토큰 탈취나 토큰을 이용한 외부 공격을 완전히 막는 방법은 존재하지 않는다고 생각한다.

예를 들어, Cookie의 Same-site 속성은 Sub Domain에 대한 방어를 할 수가 없다. Same-site라는 개념 자체를 이해하면 알 수 있는 내용이다.

해당 사이트를 참고해 보면 좋을 것 같다. https://jub0bs.com/posts/2021-01-29-great-samesite-confusion/

그리고 이러한 이유 때문에 Local Storage가 보안상 유리할 수도 있다고 한 것이다.
Local Storage의 접근은 same-site가 아니고 same-origin으로 묶여 있기 때문에, XSS 공격만 방어한다면 외부에서 Local Storage에 접근할 수 없기 때문이다.

결론은, 어떤 방식을 사용하든 JWT를 사용할 때에는 가능하다면 최대한 탈취를 방지하고, 탈취되더라도 문제가 없도록 하는 게 좋은 방법이지 않을까 싶다.

2. Refresh Token

위의 방법으로 Access Token을 발급했다면 JWT 사용하는 데에 성공한 것이다.

다만 위에서도 말했듯이 토큰 탈취에 대한 위험은 완전히 막을 수 없다.

그래서 Access Token의 생명 주기를 너무 길게 잡아 둔다면 토큰이 탈취되었을 때 해커가 자유롭게 사용할 수 있을 것이다.

그렇다고 Access Token의 생명 주기를 짧게 주자니 사용자 경험이 박살나 버린다. ( 하루 종일 로그인 해야 됨 )

개인적인 생각이지만 사용자 편의 보다 보안이 더 중요하다고 생각한다. ( 하지만 사람들은 불편한 걸 못 참는다. 막상 해킹 당해 봐야 눈물을 흘리겠지.. 사실 나도 그럼ㅋ)

위와 같은 문제점을 해결하고자(사실 해결 안 됨) Refresh Token을 도입했다.

사실 명확하게 Refresh Token을 어떻게 구현하면 되고 무엇이 가장 좋은 방법인지 설명하고 싶지만,
필자도 아직 초보이고, JWT를 구현하는 방식은 여러 가지가 있기 때문에 특정지어서 말하기가 어렵다. 간단하게 Refresh Token에 대한 개념과 나의 생각 정도만 적어 보겠다.

일반적으로 Refresh Token은 DB에 저장하는 형태를 취한다.

사용자가 로그인에 성공하면 Refresh Token을 DB에 부가적인 정보(검증할 정보?)와 함께 저장하고, Access Token과 Refresh Token을 사용자에게 뿌려 준다.

그리고 사용자의 Access Token이 만료되어 서버로부터 에러가 떨어지면, Refresh Token을 보내 검증 과정을 거치고 다시 Access Token을 발급받는 형태이다.

3. 뭔가 이상한데!?

예전에 Refresh Token을 공부하면서 느낀 것은

결과적으로는 Refresh Token도 탈취당할 위험이 있으니 같은 거 아닌가..?

이다..

실제로 프로젝트에서 JWT를 공부하고 도입할 때, 이러한 이유로 Refresh Token의 필요성을 크게 느끼지 못 했다.

Refresh Token을 도입해도 탈취에 대한 위험이 존재하는 건 사실이다.

하지만 단순히 Access Token의 생명 주기를 길게 주고 끝내는 것 보다 Refresh Token이라는 개념을 도입하면 Access Token의 유효기간을 짧게 가져갈 수 있어 Access Token이 탈취되었을 때 유효기간이 짧으니 보안상 유리하고, 또 Refresh Token은 탈취되더라도 서버에서 관리 가능한 상태가 되었기 때문에 탈취되었을 때에 대한 대처가 조금 가능하다. 사용자 입장에서는 로그인을 계속해서 하지 않아도 되니 사용자 편의도 어느정도 향상시킬 수 있다.

그럼 이 부분은 넘어가고 한 가지 더 궁금한 점이 생겼다.

기존의 Session 방식과 크게 차이가 나 보이지 않는다는 점이다.

Session vs Token

오늘 가장 정리하고 싶었던 내용은 이 부분이다.

과연 Session 방식과 Refresh Token을 도입한 JWT 방식에 어떤 차이가 있는 지 정리하고 싶었다.

하지만 이 주제에 대해 함부로 다루기는 무섭다. 워낙 얘기가 많은 주제이기도 하고, 어설프게 블로그에 정리했다가 두들겨 맞을 것 같다.

그래서 개인적인 의견과 가능성에 초점에 맞춰서 정리해 보고자 한다.

위에서

Session 방식과 크게 차이가 나지 않는다는 점이다.

이렇게 말했는데, 크게 차이가 나지 않는다는 점이라는 말은 차이가 있긴 있다는 것이다.

그리고 그 작은 차이가 JWT와 Session 방식 중에 무엇을 선택하는 게 좋을지 판가름 하는 기준이 아닐까 싶다.

JWT의 장단점

장점

1. Stateless하다(?)

보통 JWT를 떠올리면 Stateless 하다는 생각을 많이 한다.

그 전에, Stateless에 대한 정확한 정의 부터 내려야할 듯 하다.

컴퓨팅에서 무상태 프로토콜은 어떠한 이전 요청과도 무관한 각각의 요청을 독립적인 트랜잭션으로 취급하는 통신 프로토콜로, 통신이 독립적인 쌍의 요청과 응답을 이룰 수 있게 하는 방식이다. 무상태 프로토콜은 서버가 복수의 요청 시간대에 각각의 통신 파트너에 대한 세션 정보나 상태 보관을 요구하지 않는다. 반면, 서버의 내부 상태 유지를 요구하는 프로토콜은 상태 프로토콜(stateful protocol)로 부른다.

Stateless Protocol(무상태 프로토콜)은 서버의 내부 상태 유지를 요구하지 않는 프로토콜이라는 의미이다.

쉽게 말하면, 이전 요청에 대한 어떠한 상태 정보도 저장하지 않는다는 뜻이다.

예를 들어, 이전 요청에 대한 정보가 서버에 저장되어 있다가 다음 요청이 올 때에 해당 정보로 인해 응답이 달라진다면 Stateless하지 않은 것이다. 각 요청은 독립적이어야 한다.

결국 Stateless는, 통신에서 사용되는 특정 프로토콜의 특징을 표현하는 단어라고 할 수 있다.

Stateless에서 중요한 건 서버가 요청에 대한 정보를 저장 하느냐 안 하느냐이다.

그럼 Http는 원초적으로 무상태 프로토콜에 해당하는데, 왜 Session과 같이 서버에 상태를 저장해야 하는 상황이 발생한 걸까?

개인적으로 생각해 보면 아주아주 옛날 Http가 정말 별 거 아닌 문서 정도의 응답만 반환하던 시절로 돌아가 보면, 그 때에는 요청에 대해서 정적인 응답만을 제공하는 게 전부였기 때문에 Sate가 필요하지도 않아서 Stateless가 잘 유지되던 시절이었을 거라고 생각한다.

다만 점점 동적인 웹이 늘어나고 웹 상에서 여러 기능들을 추가하여 제공하다 보니 발생한 문제인 듯 하다.

"로그인"이라는 문제도 Http가 Connectionless한 프로토콜이 아니었다면 크게 문제될 게 없는 부분이 아닐까 싶다.

커넥션을 유지하면 어차피 어떤 클라이언트로부터 오는 요청인 지 서버가 알 수 있기 때문이다.

다만 Stateless하고 Connectionless한 Http 프로토콜을 사용하는 웹상에서 "로그인"이라는 개념을 구현하려다 보니 어쩔 수 없이 상태를 어딘가에는 저장해야 하는 상황이 온 것이다.

그리고 그 어딘가가 서버(Session)이냐, 클라이언트(JWT)이냐의 차이일 뿐이다.

JWT의 장점은 Stateless하다는 말은 조심해야 한다

위 내용을 보면 알았겠지만 Stateless 하다는 것은 원래 특정 통신 프로토콜의 특징이다.

그렇기 때문에 JWT가 Stateless하다고 말하는 건 조금 조심해야 한다. JWT 자체가 Stateless하다는 뜻처럼 들릴 수 있기 때문이다.

JWT가 Stateless하다는 말은 JWT를 사용하면 Http 통신을 Stateless하게 유지할 수 있다는 의미가 더 맞는 것 같다.

JWT를 사용하면서 Refresh Token을 도입하여 서버에 저장하는 것은 Stateless한가?

JWT를 사용하더라도 서버에 상태를 저장하는 형태를 띈다면 그건 Http가 Stateless한 특징을 잃고 Stateful해졌다고 볼 수 있다.

JWT는 구현하는 방식에 따라 서버에 상태를 저장하는 경우도 있고, 클라이언트에만 저장하는 경우도 있다.

서버에 상태를 저장하는 방식은 확실히 Stateful하다고 할 수 있다.

클라이언트에 저장하는 것도 결국 상태를 저장하긴 하는거잖아?

위에서 Statelss의 정의를 보면 "서버가 통신 파트너의 상태를 저장" 이라고 되어 있기 때문에 클라이언트는 서버가 아니니 개인적으로 Stateful이라고 보기엔 애매하다고 생각한다.

( Session도 Token을 사용하지만 서버에 상태를 저장하기 때문에 Statelful하다고 보통 표현한다. )

그러니 필자는 서버에 상태를 저장하지 않는 형태, 즉 클라이언트에만 상태를 저장하는 형태는 Stateless하다는 전제로 글을 작성할 것이다.

따라서 토큰은 사용 방법에 따라 Stateless할 수도( Http 통신을 Stateless 하게 유지할 수도 ) 그렇지 않을 수도 있다고 생각한다.

아래는 JWT를 Stateless하게 구현한다는 전제하에 딸려오는 장점들이다.

• 수평 확장(Scale-out)에 용이하다

  • JWT를 Stateless하게 사용하기만 한다면 서버를 확장해도 각 서버 간에 상태를 공유할 필요가 없기 때문에 수평 확장(Scale-out)에 용이하다고 할 수 있다. ( JWT를 Stateful하게 만들어도 클러스터링 기술을 사용하면 구현은 가능하다. )

• 서버 부담이 없다.

  • 서버에 상태를 저장하지 않기 때문에 서버가 가지는 메모리적 부하가 없다.

Refresh Token을 사용했더니..

Statelss하게 JWT만 구현할 수 있다면 위와 같은 장점을 누릴 수 있고 너무나도 큰 장점들이다. Refresh Token을 사용하는 경우, 위의 JWT를 Stateless 하게 구현했을 때의 장점이 줄어든다.

보통 JWT를 사용하면 Refresh Token을 함께 도입하는 경우가 많기 때문에 위와 같은 장점이 줄어든 건 크게 아쉽다고 볼 수 있다.

2. 데이터 베이스 질의어 감소

2-1 유저정보

JWT 자체에 사용자에 대한 정보가 어느 정도 담겨 있기 때문에, 불필요한 경우 유저 정보를 조회하는 과정을 생략할 수 있다.

일반적인 웹 서비스에서는 크게 체감되지 않을 수 있지만 엄청난 규모의 서비스라고 생각하면 한 번의 조회 생략이 모여 엄청난 횟수가 된다.

( 근데 이거 세션도 정보 좀 더 넣으면 안 되나..? -> 일반적으로 세션에는 많은 데이터를 담지 않는다고 하더라도.. )

2-2 Scale-out까지 고려한 경우

또한 수평 확장(Sacle-Out)을 고려해서 Session을 따로 DB로 관리하려 했다면 이러한 질의어 감소는 더더욱 빛을 발할 수 있을 것이다.

Session을 사용하면 매 요청마다 Session DB를 조회해야 하는데 Stateless한 JWT를 사용하면 조회 과정이 완전히 없어진다.

이러한 장점은 Stateful한 JWT 방식에서도 마찬가지로 적용된다. Refresh Token도 DB에 저장하기 떄문에 Session처럼 조회해야 하는 건 똑같지만, 그 빈도에 확실한 차이가 있다.

Refresh Token은 Access Token이 만료되었을 때에만 조회하기 때문에 Session 방식과 비교해서 조회 횟수가 현저히 줄어들게 된다.

예를 들어, Access Token의 유효 기간이 15분이라면 15분마다 한 번씩 DB를 조회해서 Access Token을 재발급해 주면 된다. Session은 15분 동안에 요청이 100번이 왔다면 100번의 DB 조회가 있었을 것이다.

3. 크로스 플랫폼

Cookie를 사용하는 JWT형식에는 해당하지 않는다.

모바일 환경에서는 쿠키라는 개념이 존재하지 않기 때문에 JWT와 같은 Token을 잘만 이용하면 인증 상태 유지가 가능하다.

즉, 조금 더 범용적인 특징이 있다고 할 수 있다.

물론 모바일에서도 여러 라이브러리를 사용하면 쿠키를 사용할 수 있긴 하지만, 이미 그 시점부터 크로스 플랫폼이 가능하다는 장점은 무색해진다.

또, 필자는 Java만 많이 써서 정확한 내용인 지는 모르겠지만, Session은 특정 언어에 종속적인 경우가 많아서 범용성이 조금 떨어진다는 얘기를 봤다.

단점

1. 토큰 탈취의 위험성이 있기 때문에 보안상 위험하다.

Session 또한 해당되는 내용이다. 다만 세션과 Refresh Token을 도입한 JWT의 경우에는 탈취되었을 때에 약간의 대응이 가능하다는 특징이 있다.

하지만 Refresh Token을 만료시켜도 Access Token이 살아 있는 동안은 위험하기 때문에 Session에 비해서는 비교적 더 위험하다.

2. 통신 비용이 상대적으로 증가한다.

아무래도 요청을 보낼 때 Token도 함께 보내야하기 때문에 보낼 데이터 양 자체가 많아진다.

세션도 토큰을 사용하긴 하지만 self-contained하지 않기 때문에 JWT에 비해 데이터 크기가 작다.

3. 로그아웃의 어려움.

사실 토큰의 탈취와도 조금 연관이 있는 내용이다. 토큰 자체가 인증 방식이기 때문에, 토큰을 탈취당하면 토큰이 만료되어 사라질 때까지는 로그아웃이 사실상 불가능하다.

예를 들어 해커가 사용자의 토큰을 빼앗은 상태이고, 후에 사용자가 로그아웃을 했다고 가정해 보자.

이 때, 토큰의 유효 기간은 아직 1시간이 남아 있다면, 해커는 한 시간 동안 유저 행세를 할 수 있는 것이다.

토큰 자체만 유효하다면 그게 로그아웃된 토큰인 지 아닌 지는 상태를 저장하지 않기 때문에 알 방법이 없다.

이는 블랙리스트 도입과 같은 방법으로 어느정도 해결은 가능하지만 그 순간부터 Stateful해진다.

Session의 장단점

사실상 JWT의 장단점과 반대되는 부분이 많으니 자세한 설명하니 생략하겠다.

장점

1. 상대적으로 보안에 뛰어나다.

유저의 상태 정보를 서버가 직접 관리하기 때문에, 보안상 문제가 발생했을 때 대응이 수월하다.

2. 통신 비용이 상대적으로 절약된다.

Token 자체에 여러 정보를 담고 있는 JWT 보다는 상대적으로 통신 비용이 적다.

단점

1. 서버를 수평 확장하는 경우 서버 간에 세션을 공유하기 어렵다.

서버가 늘어나는 경우 서버 간에 세션을 공유해야 하는데, 일반적인 방법으로는 안 된다.

세션 클러스터링과 같은 방식으로 해결 가능하다.

2. 서버에 부하가 있다.

서버에서 유저 정보를 유지하기 위해서는 메모리를 차지하고, 매 요청마다 유저의 상태를 조회해야 하기 때문이다.

뭐가 더 좋아?

Http 통신에서 JWT로 Stateless한 로그인 방식을 만들었다면 참 좋았겠지만, 보안이라는 현실의 벽에 부딪힌 우리는 어쩔 수 없이 Refresh Token, 블랙리스트를 도입하는 등 Stateful한 상황을 만드는 일을 피할 수 없었다. JWT를 점점 Session과 비슷한 방식으로 만들어 가기 시작했다.
( 완전한 Stateless는 요즘 같은 웹 환경에서는 그저 이상론이 되지 않을까.. )

그렇다고 해서 JWT가 완전히 Session과 같은 것은 아니다. 충분히 JWT만의 장점이 있다.

Stateless한 JWT와 Session의 중간 ( 살짝 Session 쪽으로 기울어진 ㅋ ) 느낌이라고 생각하면 될 것 같다.

그래서 JWT와 Session을 비교할 때에는, Stateless하게 JWT를 구현하는 경우와 Stateful하게 구현하는 경우, 그리고 Session 이렇게 세 가지로 구분하면 더 이해하기 쉽지 않을까 싶다.

JWT를 Stateless하게 간단하게만 사용한다면 구현이 쉽기 때문에 규모가 작고, 보안적으로 크게 고려할 서비스가 아니라면 가볍게 적용해 보기 좋다.

Stateful하게 사용한다면 비록 몇 가지 Stateless한 방식의 장점이 줄어들고 세션과 비슷한 점이 많아지지만, JWT 자체의 장점들이 몇 가지 남아 있다. ( 질의어 감소, 크로스 플랫폼 등 )
만약 이러한 장점 요소들이 크게 중요한 서비스이고 보안적인 부분을 조금 감안하거나, 보안에 자신이 있는 기술적 능력이 있다면 Session 방식 대신 적용해 보아도 좋을 것 같다.

JWT에 대한 이해가 부족하다면, 보안상 비교적 유리하고 편리하며 대중적인(?) 세션 방식을 사용해 보는 게 좋을 것 같다.
( 프로젝트에 꼭 필요한 상황이 아닌데, 단순히 기술을 사용해 보기 위해 어설프게 적용해 보려는 거라면 전혀 어필이 될 것 같지 않으니 그냥 세션 방식으로 프로젝트를 진행하는 것이 좋아 보인다..)

이처럼 JWT와 Session 방식에는 각자의 장단점이 있고 무엇이 더 좋고 안 좋고의 문제 보다 상황에 따라 유리한 방식을 선택하면 좋을 것 같다.

JWT에 대해 공부해 보았는데, 사실 실무 경험이 전무한 필자 입장에서는 경험과 지식에 한계가 있다. 그런 것 치곤 잘 쓴듯ㅋ

추후에 더 깊게 공부하도록 하자.