[Web] 세션 vs 쿠키 vs 토큰

TL;DR

---

💡 Authentication은 인증(서버의 유저인지), Authorization은 권한부여(특정한 행동 허용)

 

• 쿠키 : HTTP 프로토콜의 무상태성(Stateless)을 보완해주는 도구다. 쿠키 자체는 인증수단이 아니다.
• 세션 : 서버가(세션 DB) 인증정보를 가진다. 클라이언트는 서버가 쿠키에 담아 보내주는 세션 ID만 가진다.
• 토큰 : 클라이언트가 인증정보를 가진다. 서버는 토큰이 유효한지만 확인한다.
• Authentication과 Authorization 차이점
  • Authentication(인증 / 신원확인) : 현재 사용자가 누구인지 확인하는 과정. 회사 건물을 예로들면 1층 안내 데스크에서 방문자가 해당 건물에 출입할 수 있는지 여부를 확인하는 과정.
  • Authorization(허가 / 권한부여) : 사용자에게 접근을 허락하는 과정. 관리자는 건물의 다양한 공간에 접근할 수 있고, 방문자는 허용한 공간만 접근할 수 있는 것에 비유할 수 있다.

 

쿠키 Cookie

---

• 사용자 정보를 기억하기 위해 서버는 쿠키를 사용해 사용자 브라우저에 데이터를 넣을 수 있다
• 사이트에 방문하면, 브라우저는 서버에 요청을 보낸다
  • 서버는 이에 응답한다. 응답에는 사용자가 찾고 있는 페이지 정보가 있다. 이 응답에 쿠키를 보낼 수 있다
  • 사용자 브라우저에 쿠키가 저장되면, 웹사이트에 방문할 때마다 쿠키도 요청과 함께 보내진다.
• 쿠키는 도메인에 따라 제한된다. e.g. 유튜브가 준 쿠키는 유튜브에만 보낼 수 있다
• 쿠키는 유효기간이 있다. 하루 혹은 한달 등 서버가 정한 기간에 따라 유효하다
• 쿠키는 인증 뿐만 아니라 여러가지 정보를 저장할 수 있다
  • 사용자가 웹사이트에서 언어 설정을 바꾸면(서버에 요청)
  • 서버는 응답과 함께 쿠키를 보낸다(사용자가 선택한 언어를 저장하고 응답한다)
  • 사용자가 해당 웹사이트에 다시 방문했을 때 언어 설정이 담긴 쿠키를 요청과 함께 서버로 보내고
  • 서버는 쿠키가 기억해둔 언어 설정의 페이지를 제공한다(응답한다)
• 참고로 iOS 네이티브 앱의 쿠키는 웹브라우저를 통해 액세스 하는 쿠키와 다르게 관리된다
  • HTTP Cookie Storage 통해 쿠키 관리
  • 앱 간 쿠키 공유 불가

 

세션 Session

---

• HTTP 프로토콜은 Stateless(무상태성)다. 즉 서버로 가는 모든 요청은 이전 요청과 독립적으로 다뤄진다.
• 요청이 끝나면 서버는 요청을 보낸 곳의 정보를 저장하지 않는다
• 때문에 요청할 때마다, 요청을 보낸 곳이 누구인지 서버에게 알려줘야 한다
• 이때 사용하는 방법중 하나가 바로 Session
• Smith라는 유저가 있고 로그인하고 싶다면
  • 유저이름과 비밀번호를 서버에 보낸다
  • 정보가 맞다면 서버는 세션 DB에 Smith라는 유저를 생성한다
  • 해당 세션에는 별도의 ID를 가지고 있다
  • 이 세션 ID는 쿠키를 통해 브라우저로 돌아오고 저장된다
  • 그 후 같은 웹사이트의 다른 페이지로 이동하면 브라우저는 세션 ID가 담겨 있는 쿠키를 서버에 보낸다. — 브라우저가 서버에 요청할 때 쿠키도 자동으로 보내진다
  • 서버는 세션 ID가 담겨있는 쿠키를 확인하고 — 이때까지 서버는 요청을 보낸자가 누구인지 모른다
  • 이 세션 ID로 세션 DB를 확인한고 해당 ID는 유저명 Smith의 것이란걸 알게된다.
  • 이 요청이 끝나고 다른 페이지로 이동할 때마다 위 프로세스를 반복된다
• 중요한 유저 정보는 모두 서버에 있다. 유저가 갖고 있는건 세션 ID 밖에 없다.
• 이때 쿠키는 세션 ID를 전달하기 위한 매개체일 뿐이다
• 서버는 현재 로그인한 유저들의 모든 세션 ID를 DB에 저장해야 한다.
  • 요청이 들어올 때마다 서버는 쿠키를 받아서 세션 ID를 확인하고
  • 세션 ID와 일치하는 유저를 찾아야한다.
  • 즉 요청이 있을때마다 서버는 DB를 조회한다
  • 때문에 유저가 늘어날 수록 더 많은 DB 리소스가 필요하다
  • 이런 단점을 보완하기 위해 토큰 방식을 사용할 수 있다

 

토큰 Token

---

• 토큰은 간단히 말하면 요상하게 생긴 문자열.
• 요청할 때마다 토큰을 서버에 보내고, 서버는 세션 DB에서 토큰과 일치하는 유저(혹은 정보)를 찾는다
• JWT는 토큰 형식중 하나
• JWT로 유저 인증을 처리하면 세션 DB를 가질 필요 없고, 서버 리소스를 쓰지 않아도 된다.

 

로그인 예시로 보는 세션 vs JWT 차이점

JWT는 헤더(알고리즘/토큰 타입), 페이로드(정보), 서명(유효한 토큰인지 검증) 부분으로 구성된다.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IlNtaXRoIiwiaWF0IjoxNTE2MjM5MDIyfQ.odnizKpao0oX_Ky8TJyDqrX3U3llMYGybySsJQjgMpY

 

1. Smith라는 사용자가 유저명, 비밀번호를 서버에 보낸다. — 여기까진 세션과 JWT는 동일하다
2. 유저명, 비밀번호가 맞다면 서버는 유저 ID에 대해 사인 알고리즘을 이용해 '사인'을 한다 — 이때 서버는 DB에 뭔가를 생성하거나 하지 않는다
3. 서버는 '사인된 정보'를 string 형태로 응답한다 — 세션과 다르게 JWT는 DB를 건드리지 않고 정보를 사인하고 전달하기만 하면 된다.
4. 쿠키는 공간 제약이 있는 반면, JWT는 제약이 없어 매우 길어도 무방하다
5. 그 후 사용자가 서버에 요청을 보낼 때 세션 ID처럼 '사인된 정보' 혹은 토큰을 서버에 보낸다
6. 토큰을 받은 서버는 사인이 유효한지만 체크한 후 자신의 유저인 것을 인증한다

 

세션 인증에서 세션에 대한 모든 정보는 세션 DB에 저장된다. 브라우저에서 페이지를 요청하면 서버는 세션 ID를 DB에서 찾는다.

 

JWT에서 서버는 유저를 인증하는데 필요한 정보를 토큰에 저장한다. 그리고 그 토큰을 유저(브라우저)에게 보낸다. 페이지를 요청하면 서버는 DB를 거칠필요 없이 해당 토큰이 유효한지만 검증하면 된다.

 

JWT의 Payload 부분은 암호화 되지 않는다. 암호화하면 아무도 읽을 수 없기 때문이다(base64 값을 디코딩해서). JWT 토큰 내용을 확인할 수 있기 때문에 비밀번호 같은 민감한 정보는 JWT에 두면 안된다.

 

세션과 토큰의 장단점

💡 JWT, Session 언제 사용하는게 좋을까?

 

• JWT : 세션이나 DB 없이 유저를 인증할 때 적합
• Session : 서비스 규모가 커져서 유저 계정을 더 잘 관리하고 싶을 때 적합

 

Session

• 세션을 사용하면 로그인한 유저 정보를 세션 DB에 저장하므로 이를 이용해 새로운 기능을 추가할 수 있다.
  • 특정 유저를 쫓아내기(세션을 삭제하면 된다)
  • 로그인한 디바이스 목록을 보여주고, 특정 디바이스에서 강제 로그아웃(인스타그램 등)
  • 계정 공유 숫자 제한(넷플릭스 등)
• 하지만 이를 위해 DB를 구매 / 유지해야하고, 유저가 늘어날수록 DB도 커져야 하므로 그에따른 비용이 많이드는 단점이 있다(보통 저렴하고 빠른 Redis를 많이 사용한다)

 

JWT

• JWT를 사용하면 생성된 토큰을 추적하지 않는다.
  • 서버가 아는 것은 토큰이 유효한지 여부뿐이다.
  • JWT에선 DB를 따로 살 필요가 없다.
  • 하지만 토큰은 만료되기 전까지 계속 유효하기 때문에 강제 로그아웃 같은 기능을 구현할 수 없다.
• JWT는 DB 없이 ➊데이터를 사인하고 ➋유저에게 보내고 해당 데이터를 돌려받을 때 ➌유효성을 검증할 수 있는 장점이 있다.
  • 코로나 QR 체크인은 JWT가 들어간 QR 코드다.
  • 이처럼 JWT는 세션이나 DB 없이 유저를 인증하기 위해 많은 곳에서 쓰인다

 

레퍼런스

---

세션 vs 토큰 vs 쿠키? 기초개념 잡아드림. 10분 순삭! | 노마드코더    

 

---

글 수정사항은 노션 페이지에 가장 빠르게 반영됩니다. 링크를 참고해 주세요