세션 기반 인증과 토큰 기반 인증

📌 무상태 프로토콜, HTTP

---

HTTP 프로토콜은 기본적으로 무상태를 지향한다.
서버에서 클라이언트의 상태를 저장하지 않는 특성을 무상태성이라고 하는데,

이러한 특성으로 인해, 클라이언트와 서버의 결합도가 매우 낮아 확장에 용이하다는 이점을 가진다.

💡 간단한 예시를 들자면 이렇다.

클라이언트가 서버에게 “저녁에 치킨 먹자”고 말했고 서버가 “그래”라고 답했다.
저녁이 되어 클라이언트는 서버에게 “먹으러 가자”고 말했고 서버는 대답했다. “뭘?”

📌 세션 기반 인증과 토큰 기반 인증

---

위에서 언급했듯, HTTP는 무상태 프로토콜이기 때문에 서버는 클라이언트의 상태를 저장하지 않는다.

그런데 우리가 평소 사용하는 로그인이 필요한 서비스들을 떠올려보자.
매 요청마다 로그인을 했었는가? 그렇지 않을 것이다.

그러나 우리는 매 요청마다 다시 로그인을 해야 하는 문제를 겪고 있지 않다.
어떻게 가능한 것일까?

이에 답이 되는 가장 대표적인 방법으로는 세션 기반 인증과 JWT 기반 인증이 있다.

✅ 세션 기반 인증

• 인증 정보를 서버의 세션 저장소에 저장하는 방식

  • 클라이언트에서 로그인을 요청하면 인증 정보가 유효한 지 확인한다.

  • 인증 정보가 유효하다면, 세션 식별자를 발급한다.

  • 세션 식별자를 키로, 인증 정보를 값으로 설정하여 세션 저장소에 저장한다.

  • 서버는 Set-Cookie 헤더에 세션 식별자를 담아 클라이언트로 응답을 전송한다.

  • 클라이언트는 전달 받은 세션 식별자를 쿠키에 저장하고,
    모든 요청의 Cookie 헤더에 세션 식별자를 담아 서버로 전송한다.

✅ 세션 기반 인증의 단점

세션 기반 인증은 로그인 된 상태를 서버에 저장하므로 HTTP 프로토콜의 무상태성을 해친다.

세션 생성 전, 인증이 유효한지 확인하기 위해 비교할 목적으로 인증 정보를 저장하는 것이 상태를 저장하는 것이라고 볼 수 없다.

그러나, 인증 정보가 유효하다는 것이 확인된 후,
세션 저장소에 저장되는 인증 정보는 해당 인증 정보를 가진 사용자가 로그인 된 상태 임을 유지하는 것을 목적으로 한다.

즉, 세션 기반 인증에서는 서버에서 클라이언트를 상태를 저장하기 때문에 서버의 부하가 증가하고,
클라이언트와 서버의 결합도가 높아져 확장성이 감소한다.

✅ JWT 기반 인증

• JWT : 인증에 필요한 정보들을 암호화 한 JSON 토큰

• 인증 정보를 암호화 한 토큰을 클라이언트에 저장하는 방식

  • 클라이언트에서 로그인을 요청하면 인증 정보가 유효한 지 확인한다.

  • 인증 정보가 유효하다면, 토큰을 발급하여 응답으로 전송한다.

  • 클라이언트는 전달 받은 토큰을 쿠키나 로컬 스토리지에 저장하고,
    모든 요청의 Authorization 헤더에 토큰을 담아 서버로 전송한다.

✅ JWT 기반 인증의 단점

JWT 기반 인증은 서버에서 클라이언트의 상태를 저장하지 않기 때문에 서버의 부하가 감소하고, 확장에 용이하지만

• Cookie 헤더에 세션 식별자만을 담아 요청을 전송하는 세션 기반 인증에 비해,
  Authorization 헤더에 토큰을 담아 요청을 전송하는 JWT 기반 인증은 네트워크 부하를 증가 시킨다.
  (토큰은 인증 정보와 토큰 정보를 포함하여 데이터의 크기가 크다.)

• 토큰의 Payload 자체는 암호화 되지 않기 때문에 보안이 필요한 인증 정보는 담을 수 없다.

• 서버에 토큰을 저장하지 않기 때문에, 토큰이 탈취되더라도 무효화 할 방법이 없다.

  • Access Token과 Refresh Token 2가지 토큰을 사용하는 방법이 고안되었다
  • 세션 기반 인증의 경우, 세션 식별자가 탈취되면 세션을 무효화 방법으로 제어할 수 있다.

✅ JWT 기반 인증의 단점을 보완하기 위한 2가지 방법

---

서버에 토큰을 저장하지 않기 때문에, 토큰이 탈취되더라도 무효화 할 방법이 없다는
JWT 기반 인증의 단점을 보완하기 위해 다음 두가지 방안이 고안되었다.

📍 토큰의 유효 기간을 짧게 설정

토큰의 유효 기간을 짧게 설정하면, 토큰이 탈취되었을 때 토큰을 무효화하지는 못하더라도,
피해 시간을 줄일 수 있다.

하지만, 토큰이 금방 만료되므로, 사용자는 로그인을 자주 해야 한다는 단점도 있다.

📍 Refresh Token 사용

• Access Token
  : 인증을 위한 토큰으로 유효 기간이 짧다.

• Refresh Token
  : Access Token을 재발급 하기 위한 토큰으로, 유효 기간이 Access Token에 비해 길며
  데이터베이스에 저장되는 토큰이다.

이 방법은 Access Token의 유효 기간은 짧게 설정하되, Refresh Token으로 Access Token을 재발급할 수 있게 하여
Access Token이 만료되더라도 사용자로 하여금 다시 재 로그인 주기를 줄일 수 있게 하는 방법이다.

Refresh Token의 유효 기간이 Access Token에 비해 길긴 하지만, Refresh Token 역시 만료되면
Access Token을 재발급할 수 없으므로 이 경우, 사용자는 다시 로그인을 해야 한다.

(로그인 시, 새로운 Access Token과 Refresh Token이 발급 된다.)

📌 결론

---

JWT 자체의 구조는 공식 문서 (JWT 공식 문서 - JWT 구조) 에 자세히 설명되어 있기 때문에 따로 정리하지 않았다.

본 포스팅에서는 토큰 기반 인증의 한계와 이를 보완하고자 고안된 2가지 방법에 대해서만 소개했는데, 이 2가지 방법에 관해서 여전히 아쉬움을 느꼈다.

본 포스팅에서 소개한 2가지 방법에 같은 아쉬움을 느껴 더 알아보고 싶다면, 새로운 대안을 소개한 아래 포스팅을 참고해보는 것도 좋을 것 같다. 😎

JWT의 단점을 보완하기 위한 새로운 방법