쿠키 vs 세션 vs 토큰 vs JWT

프로젝트에 Spring Security를 적용하기에 앞서 jwt와 쿠키, 세션, 토큰 등에 대해서 한번 더 정리해보고자 합니다!

 

먼저 쿠키와 세션이 나타나게 된 이유를 살펴봐야 하는데

바로, HTTP 프로토콜의 특징 때문입니다.

 

HTTP 프로토콜은 두 가지의 특징을 갖습니다.

 

• 비연결지향 ( Connectionless )
  • 클라이언트가 요청을 서버에 보내고, 서버는 클라이언트에게 적절한 응답을 준 뒤, 연결(Connection)을 끊는 특성이 있습니다.
• 상태없음 ( Stateless )
  • 연결을 끊는 순간 클랑이언트와 서버의 통신이 끝나며 상태 정보를 유지하지 않는 특성이 있습니다.

 

비연결지향이라는 특성 덕분에 커넥션을 유지하지 않아 서버 리소스 낭비가 줄어든다는 장점이 있지만, 통신할 때 마다 새로운 커넥션을 만들기 때문에 클라이언트 측에서는 불편함이 있습니다. 쉽게 말하면 어떤 페이지에서 다른 페이지로 넘어갈 때마다 매번 인증을 해야한다는 것입니다.

잠시 상상만 해도 너무 번거롭고 귀찮습니다..

이런 단점들을 보완하기 위해서 쿠키와 세션을 사용하게 되었습니다!

 

 

---

 

1️⃣ 쿠키 Cookie

• 쿠키를 이용해 사용자의 브라우저에 데이터를 넣을 수 있습니다.
• 브라우저는 요청과 함께 해당 쿠키도 보내게 됩니다.
• 쿠키는 도메인에 따라 제한됩니다. ( ex 티스토리에서 준 쿠키는 티스토리에만 보내짐 )
• 유효시간이 존재합니다.
• 인증 뿐만 아니라 여러가지 정보를 담을 수 있습니다.
• 즉, 사용자에 의해 조작되어도 크게 문제되지 않을 정보를 브라우저에 저장합니다.

 

---

 

2️⃣ 세션 Session

https://velog.io/@gusdnr814/%EB%A1%9C%EA%B7%B8%EC%9D%B8-%EC%9D%B8%EC%A6%9D-4%EA%B0%80%EC%A7%80-%EB%B0%A9%EB%B2%95

• 과정
  • 로그인을 통해 유저ID와 PW로 서버에서 사용자 확인
  • 서버는 유저에 대한 회원 정보 세션을 생성해서 Session DB에 저장
  • Session DB에서는 연결된 세션ID를 발급하고, 쿠키 안에 세션ID를 담아 서버로 보냄
  • 서버에서는 브라우저로 세션ID가 담긴 쿠키를 보냄
  • 이후 클라이언트는 매 요청마다 header에 세션ID가 담긴 쿠키를 넣어 통신하는 방식으로 인증을 진행
• 특징
  • 중요한 유저 정보는 모두 서버에 있고, 유저가 갖고있는 것은 세션ID 뿐입니다.
  • 세션ID를 통해 서버에서 데이터를 조회하기 때문에 통신 속도에서 장점이 있습니다. ( 세션ID만 request header에 담으면 됨 )
  • 서버 측에서 데이터를 관리하기 때문에 쿠키보다는 보안이 좋습니다.
  • 단점은 서버에 추가적인 저장 공간이 필요합니다.
  • 계정 조작, 관리가 가능합니다.
• Stateless
  • 서버로 가는 모든 요청이 이전 리퀘스트와 독립적으로 다뤄진다는 뜻 입니다.
  • 요청끼리 연결하지않고, 메모리가 필요 없습니다.
  • 요청이 끝나면 서버는 우리가 누군지 잊어버리기 때문에 요청할 때 마다 우리가 누군지 알려주어야 합니다.
  • 이 작업을 하는 게 바로 session !

 

---

 

3️⃣ 토큰 Token

 

클라이언트에서 인증 정보를 보관하는 방법입니다.

세션 기반 인증은 매 요청마다 DB를 필요로하는데, 그 단점을 보완하기 위해 토큰 기반 인증 개념이 생겨났습니다.

토큰은 유저 정보를 암호화 한 상태로 담게 됩니다.

종류에는 access token, refresh token 두 가지가 있습니다.

 

🔍 Access Token & refresh token

https://velog.io/@gusdnr814/%EB%A1%9C%EA%B7%B8%EC%9D%B8-%EC%9D%B8%EC%A6%9D-4%EA%B0%80%EC%A7%80-%EB%B0%A9%EB%B2%95

 

클라이언트가 처음 인증을 받게 될 때 두 가지 토큰을 둘 다 받게 되지만 실제로 권한을 얻는데 사용하는 토큰은 access token 입니다.

access token의 유효 기간을 짧게 주고, access token 의 유효 기간이 만료되었을 경우 refresh token을 서버에 요청하여 새롭게 access token 을 발급받습니다. 이를 통해 해커가 access token  을 탈취하더라도 유효 기간이 짧아 사용 기간이 짧으며, refresh token 은 안전한 저장소에 저장되기 때문에 기존 방식보다 안전합니다.

 

과정

• 클라이언트가 서버에 ID, PW를 통해 로그인 요청
• 서버는 ID, PW 일치 여부를 확인하고, 암호화 된 토큰을 생성
• 해당 토큰을 클라이언트에게 보내주면 클라이언트는 토클르 저장
• 클라이언트가 HTTP Header에 해당 토큰을 담아 서버에 보냄
• 서버는 토큰을 해독하여 세션DB에서 해당 토큰과 일치하는 유저를 찾아 응답을 보내줌

 

---

 

 

4️⃣ JWT (JSON Web Token)

https://velog.io/@gusdnr814/%EB%A1%9C%EA%B7%B8%EC%9D%B8-%EC%9D%B8%EC%A6%9D-4%EA%B0%80%EC%A7%80-%EB%B0%A9%EB%B2%95

• JWT는 인증에 필요한 정보들이 암호화된 토큰 형식 입니다.
• JWT로 유저 인증을 처리하면, 세션DB를 갖을 필요가 없고, 서버는 유저 인증을 한다고 많은 일을 하지 않아도 됩니다.
• 예를 들어, DB를 건들이는 대신, 정보를 확인하고 사인하고 전달합니다.
• 서버에 요청을 보내려면 해당 '사인된 정보' OR '토큰'을 서버에 보냅니다.
• 서버는 토큰을 받으면, 해당 사인이 유효한지 체크하고, 유효하다면 유저로 인증해줍니다.
  => 페이지를 요청하면 서버는 DB를 거칠 필요 없이 해당 토큰이 유효한지만 검증하면 되는 것입니다.
• 암호화 되지 않기 때문에 비밀정보를 JWT 안에 두면 안됩니다.
• 추가 저장소 없이 간편하게 인증할 수 있는 장점이 있으나 토큰이 탈취되었을 시 토큰의 유효 기간이 만료되기 전까지 대처할 방법이 없다는 단점이 있습니다.
• 즉, 강제 로그아웃 등 관리가 불가능합니다.