🍪 쿠키란?

클라이언트 측에 저장되는 작은 데이터이다. 주로 텍스트 형식으로 저장되며, 만료 기간을 설정할 수 있다. 클라이언트, 즉 사용자가 가지고 있으므로 사용자가 언제든지 수정하거나 삭제할 수 있다. 따라서, 수정하면 안되는 중요한 정보를 담아놓는 것은 부적절하다. 중요한 정보는 세션이 더 적합하다.

이 쿠키를 이용해서 서버는 브라우저에 데이터를 넣을 수 있다. 브라우저에 쿠키가 저장되면 우리가 브라우저에 방문할 때마다 브라우저는 해당 쿠키도 함께 Request로 보낼 것이다.

쿠키는 인증 뿐만 아니라 여러가지 정보를 저장할 수 있다. 예를 들어, 브라우저가 언어 설정을 바꾸면 서버는 쿠키를 주고 바뀐 언어 설정을 저장한다. 따라서, 다음에 해당 사이트를 방문하면 쿠키는 Request와 함께 서버로 보내지고 서버는 쿠키가 기억해둔 언어 설정의 페이지를 제공할 수 있게 된다.

중요한 점은, 쿠키는 도메인에 따라 제한된다는 것이다. 즉, 유튜브가 준 쿠키는, 유튜브에게만 보내진다.

🤔 세션? 쿠키?

우리가 웹 사이트를 이용할 때 쓰는 프로토콜, HTTP는 stateless이다. 서버로 가는 모든 요청은 독립적으로 다루어진다는 뜻이다. 요청끼리 연결이 없고, 메모리가 없다! 요청이 끝나면 서버는 우리가 누구인지 기억하지 못하기 때문에, 요청할 때마다 우리가 누구인지 알려줘야 한다. 이 방법 중 하나가 바로 세션이다.

예를 들어, A라는 유저가 로그인을 했을 때 저장된 회원 정보와 일치한다면 서버는 세션 DB에 세션 ID(sid)와 함께 유저를 저장할 것이다. 이렇게 생성된 사용자별로 고유한 세션 ID는 클라이언트에 쿠키를 통해 브라우저로 돌아오고, 저장된다! 즉, 쿠키는 세션ID를 전달하기 위한 매개체라고 생각하면 된다. 🤗

따라서, 같은 웹사이트의 다른 페이지로 이동하면, 브라우저는 세션ID를 가지고 있는 쿠키를 서버에게 보낼 것이다. 서버는 들어오는 쿠키를 보고 세션ID를 알 수 있고, 해당 세션ID를 가지고 세션 DB를 확인할 것이고 거기서 해당 세션ID는 A유저라는 것을 알 수 있다! 해당 요청이 끝나고 다른 페이지로 이동하게 되면, 이 과정이 반복되게 된다!

정리를 해보자면,

브라우저는 오직 세션ID만 있는 쿠키를 가지고 있는 것이고, 유저의 중요한 정보는 모두 서버가 가지고 있다. ➡️ 인증에 대한 정보를 서버가 저장한다.

하지만, 세션을 이용하여 iOS, Android 앱을 만들 수 있어도 쿠키는 사용할 수 없다. 왜냐하면 쿠키🍪는 오직 브라우저에만 있으니까!!
이런 경우는 바로 토큰을 사용한다.(쿠키랑 비슷하다.) 해당 토큰을 서버에 보내고, 서버는 세션 DB에서 해당 토큰과 일치하는 유저를 찾는다.

세션에 대해서 기억해야 할 것은, 현재 로그인한 유저들의 모든 세션ID를 DB(메모리 or 디스크 등의 ‘저장소’)에 저장해야 한다는 것이다. 요청이 들어올 때 마다, 서버는 쿠키 속 세션ID와 일치하는 유저를 찾기 위해 세션DB를 모두 찾아야 한다! 유저가 늘어날수록 DB에도 저장해야 한다. 또한, 세션 DB를 실수로 모두 날려버린다면? 사용자들은 모두 로그인을 다시 해야한다는 번거로움이 생겨난다.

바로 이때, JWT가 등장한다. JWT는 토큰 형식이다. JWT로 유저 인증을 처리하면, 세션 DB를 가지고 있을 필요가 없고 서버가 유저 인증을 할 필요가 없다. 🫢 (잠깐, JWT가 만능은 아니다!)

🪙 JWT

로그인 예시를 통해 세션과 JWT의 차이를 알아보자.
만약 유저 A가 로그인을 하려면 아이디, 비밀번호를 서버에 보낼 것이다.(여기까지 세션과 다른 점이 없다.)
회원정보가 일치한다면, 서버는 DB에 유저 정보를 저장하지 않는다. 대신, 서버는 예를 들어 유저의 id를 가져가서 사인 알고리즘을 이용하여 사인을 한다. 그리고, 해당 사인된 정보를 String 형태로 본내다. JWT는 이런식으로 생겼다. 매우 길다. 쿠키는 공간 제약이 있기 때문에 이렇게 긴 형태는 불가하다. 하지만 JWT는 공간 제약이 없어서 엄청 길어도 된다!

정리를 해보자면,

JWT는 토큰의 한 종류이며, JSON 객체를 사용하여 정보를 전달한다.
➡️ 인증에 대한 정보를 사용자가 저장한다.

구조

출처 : https://jwt.io/

왼쪽을 보면 마침표 2개로 끊어져서 총 3부분(xxxxx.yyyyy.zzzzz)으로 나뉘어진 것을 볼 수 있다. 이 3부분은 오른쪽에 보이는 것처럼 header, payload, verify signature로 구분된다.

header

header를 Base64로 디코딩 2가지 정보가 있다. 이 정보는 Base64Url로 인코딩된다.

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

1. 토큰의 타입

   언제나 JWT가 들어간다.

2. alg

   알고리즘의 약자이다. verify signature를 만드는데 사용될 암호화 알고리즘(HS256 등)이 지정된다.

payload

payload를 Base64로 디코딩해보면 JSON 형식으로 여러 정보들이 들어있다. 이 정보도 Base64Url로 인코딩된다.

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

토큰에 담긴 이 정보를 claim이라고 하는데, 토큰을 누가 누구에게 발급했는지, 이 토큰이 언제까지 유효한지, 서비스가 사용자에게 이 토큰을 통해서 공개하기 원하는 내용(Ex) 사용자의 닉네임, 관리자 여부 등) 등 사용자의 정보가 들어있다. 클레임은 사용자 정보나 토큰 속성 등을 나타내는 key-value 쌍이다.

하지만 이 부분은 다른 정보로 바꾸거나 악용할 우려가 있다. 그래서 header와 verify signature가 있는 것이다.

verify signature

토큰의 무결성을 검증하기 위해 사용된다.

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

header안에 있는 암호화 알고리즘(인코딩된 header + 인코딩된 payload + 서버의 비밀키) = verify signature

서버는 위 과정을 따라서 verify signature를 만들고, 토큰과 일치하는지 확인한다. 이 따라서, 서버의 비밀키를 모르면 아무리 payload를 탈취해서 바꾸더라도 인가에 통과하지 못한다!

즉, 똑같이 로그인을 했지만 세션과 달리 JWT는 DB를 건드리는 대신 정보를 사인하고 전달한다.
이제 서버에 요청을 보내려면 세션ID와 비슷하게 (사인된 정보 or 토큰)을 서버에 보내야 한다. 서버는 토큰을 받으면 해당 사인이 유효한지 체크하고(토큰이 조작되었는지 체크), 토큰이 유효하다면 서버는 해당 요청을 유저로 인증할 것이다!

JWT에선 유저를 인증하는데 필요한 정보를 토큰에 저장한다. 그리고 페이지를 요청하면, DB를 뒤질 필요도 없이 해당 토큰이 유효한지만 검증하면 된다. 염두해야 할 것은 JWT는 암호화되지 않았다. 따라서 비밀 정보 같은 경우는 JWT안에 둬서는 안된다.

🤓 세션과 JWT의 장단점

세션

• 장점
  세션이 저장하고 있는 유저의 정보를 토대로 다양한 기능 개발 가능
  Ex) 세션 삭제를 통한 강제 유저 삭제, 계정 공유 숫자 제한
  - 토큰은 시간에 따라 변하지 않는다. 따라서, stateless하다!
• 단점
  • 유저가 늘어날수록 DB가 커지므로 비용이 많이 든다.

JWT

• 장점
  • 서버는 생성된 토큰을 추적하지 않고 유효한지만 검증하므로 DB를 살 필요 없다.
• 단점
  • 유저 정보를 알아야지만 할 수 있는 기능은 구현할 수 없다. 왜냐하면 토큰이 만료되기 전까지는 유효하니까! 따라서, 여러 기기에서 같은 아이디로 로그인해도 막을 수 없다. 왜냐하면 토큰은 유효한지만 검증하는 것이므로..! 그래서 실제 서비스에서는 JWT 토큰 하나로만! 인가를 구현하는 곳은 많지 않다.
  • 이러한 단점을 보완하기 위해 나온 것이 수명이 짧은 access Token + 수명이 2주 정도로 나름 긴 refresh Token을 같이 사용하는 방식이다. 서버는 refresh Token만 DB에 저장하고 access Token의 수명이 다하면 전달받은 refresh Token 확인하여 새로운 access Token을 발급해주는 것이다. Refresh Token을 사용하면 Refresh Token을 삭제하기만 하면 로그아웃 되므로 서버 측에서 토큰을 무효화하거나 관리하기가 더 쉽다. 하지만, 완벽한 해결책은 아니다! Refresh Token이 탈취될 위험은 당연히 존재한다. 따라서 이런 점이 JWT의 한계이다.

🤗 서비스가 작거나 유저 정보를 활용 or 관리할 필요가 없을때는 세션보단 JWT가 더 유용할 것 같다!

참고 자료

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

쿠키, 세션, 캐시가 뭔가요?

[10분 테코톡] 연로그의 쿠키 vs 세션 vs 토큰 vs 캐시

세션 VS. 토큰! JWT가 뭔가요?