Cookie 와 Session 그리고 토큰

💡 HTTP 특징

HTTP는 무상태(Stateless) 프로토콜입니다.

• 각 요청이 독립적으로 처리되며 서버가 클라이언트의 이전 상태를 기억하지 않는다는 의미

이 때문에 로그인 상태와 같이 사용자의 연속적인 상태 정보를 유지하기 위해 쿠키와 세션 같은 기술이 필요합니다.

이런 Auth 기능을 구현할 때 쿠키, 세션, 토큰, JWT 등의 용어가 있는데 이를 예전에 학습을 했지만 다시 정리를 해보고자 합니다.

 

🍪 쿠키

쿠키를 이용하면 서버는 브라우저에 데이터를 넣을 수 있습니다.

 

브라우저에서 서버에 요청을 보내고 서버에서는 브라우저에게 응답을 보냅니다.

• 이때 이 응답에 브라우저에 저장하고자 하는 쿠키가 있을 수 있습니다.

 

💡 브라우저에 쿠키를 저장하면 웹사이트에 접속을 할 때마다 브라우저는 해당 쿠키도 요청과 함께 보내게 됩니다.

 

🧩 특징

1️⃣ 도메인 제한

• 특정 도메인에서 발급한 쿠키는 그 도메인에만 전송됩니다.
• 예: youtube.com 이 발급한 쿠키는 youtube.com 요청에만 포함됨.

 

2️⃣ 유효기간이 있습니다.

• 서버에서 쿠키의 만료 시간을 지정할 수 있습니다.
• 만료 기간이 지나면 브라우저가 자동으로 쿠키를 삭제합니다

 

3️⃣ 인증뿐만 아니라 여러가지 정보를 저장할 수 있습니다.

• ex) 웹사이트 언어 설정
  • 서버는 쿠키를 주고 선택한 언어를 저장
  • 브라우저가 다시 웹사이트에 방문할 경우 쿠키는 요청과 함께 서버로 보내져 쿠키가 저장하고 있는 언어 설정의 페이지를 제공

 

🏄‍♂️ 동작 과정

 

1. 브라우저 → 서버 요청
2. 서버 → 브라우저 응답 (+ Set-Cookie 헤더)
3. 브라우저가 쿠키를 로컬에 저장
4. 이후 같은 도메인에 요청 시 자동으로 쿠키를 포함하여 서버로 전송

 

🤖 쿠키 사용 예제

사용자의 편의를 위하고 가로채이거나 지워지더라도 큰 문제가 없을 정보를 브라우저에 저장

 

1️⃣ 로그인창의 아이디를 자동 완성

2️⃣ 웹 페이지의 공식 메시지 하루 안 보기 선택

3️⃣ 로그인하지 않은 상태로 장바구니에 물건을 담기

 

📌 세션

HTTP는 기본적으로 Stateless 방식으로 동작합니다.

• 요청이 끝나면 서버는 요청을 보낸 주체를 잊게 됩니다.
• 따라서 요청을 할 때마다 우리가 누군지 알려주어야 합니다.
• 이를 처리하는 방법중 하나가 세션!!

 

🏄‍♂️ 동작 과정

1. 사용자가 (이메일, 패스워드)를 통해 서버에 로그인 요청
2. 비밀번호가 맞다면 서버는 세션 DB에 해당 유저를 생성
3. 해당 세션에는 별도의 ID가 있어 해당 세션 ID는 쿠키를 통해 브라우저로 돌아와 저장
4. 브라우저는 세션 ID를 가지고 있는 쿠키를 서버에게 보냅니다
5. 서버는 쿠키를 보고 세션 ID를 가지고 세션 DB를 확인하여 유저의 정보를 가져옵니다.

 

🌠 유저 정보는 서버에 저장

• 브라우저는 단순히 세션 ID만 가지고 있음
• 실제 사용자 정보는 서버의 세션 저장소(DB, Redis 등)에 보관

 

쿠키는 단순히 세션 ID를 전달하기 위한 매개체일 뿐!

 

⚠️ 세션 한계

☑️ 세션은 현재 로그인한 유저들의 모든 세션 ID를 DB에 저장

• 모든 요청이 들어올때마다 서버는 쿠키를 받아 세션 ID를 보고 이를 통해 세션 ID와 일치하는 유저를 찾고 그 다음 요청을 처리합니다.
• 즉, 유저가 늘어남에 따라 DB의 리소스가 많이 필요

 

☑️ 서버가 여러대인 경우

• 특정 서버 메모리에만 세션을 저장하면 다른 서버에서 사용자 식별 불가
• Redis 같은 외부 세션 저장소 필요

 

🤖 세션 사용 예제

세션의 특징인 서버가 로그인 된 유저의 모든 정보를 저장하는 것을 이용하면 아래와 같이 사용할 수 있습니다.

 

1️⃣ 특정 유저를 강제로 로그아웃 시키고 싶을 때

• 그냥 해당 유저의 세션을 삭제

 

2️⃣ 인스타그램

• 현재 로그인된 모든 디바이스를 확인
• 원하지 않는 디바이스 로그아웃 처리

 

3️⃣ 넷플릭스 계정 공유 숫자 제한

• 현재 로그인한 유저의 수를 확인할 수 있고 이를 제한하는 기능을 처리

 

🔖 토큰 (Token)

토큰은 단순히 식별을 위한 긴 문자열입니다.

 

세션과 비슷하지만 브라우저에 쿠키 대신 토큰 자체를 저장하고 요청 시 헤더에 넣어 보냅니다.

Authorization: Bearer <token-value>

• 네이티브 앱(iOS, Android)은 쿠키 대신 토큰을 사용
• 브라우저 외의 환경에서도 동일한 인증 방식을 사용할 수 있음

 

🚀 JWT

JWT를 이용한다면 세션 DB를 사용할 필요도 없고 서버는 유저를 인증한다고 많은 처리를 할 필요도 없습니다.

 

🏄‍♂️ 동작 방식

1. 사용자가 (이메일, 패스워드)를 통해 서버에 로그인 요청
2. 비밀번호가 맞다면 서버는 유저의 ID(예시)를 가져다가 사인 알고리즘을 이용해 사인
3. 토큰(사인된 정보) 를 string 형태로 반환
4. 서버에 요청을 보낼 때 토큰를 서버에 보내줍니다.
5. 서버는 토큰을 받으면 사인이 유효한지 체크하고 유효하다면 서버는 우리를 유저로 인증합니다.

 

🧩 특징

1️⃣ 서버는 DB에 무언가를 저장하지 않습니다.

• 원하는 정보(예: userId)를 사인하고 전달하는 것이 전부

 

2️⃣ JWT는 세션 ID보다 훨씬 긴 문자열입니다.

• 쿠키는 길이에 제약이 있지만 JWT는 제약이 없어 엄청 길어도 가능!

 

3️⃣ 유저를 인증하기 위한 필요한 정보를 토큰에 저장

• 세션의 경우 세션 DB에 저장
• 따라서 JWT을 사용하면 서버는 DB를 거칠 필요 없이 토큰이 유효한지만 검증

 

🌠 JWT는 암호화되지 않았습니다.

🤔 만약 암호화가 되었다면?

• 아무도 읽을 수 없고 이해할 수 없게 됩니다.

 

JWT는 암호화가 되어 있지 않기 때문에 아무나 이 컨텐츠를 확인할 수 있습니다.

• 비밀번호같은 민감정보를 JWT안에 두면 안된다!! ❌

 

🤖 JWT 구조

JWT는 . 을 기준으로 세 파트로 나뉩니다.

 

Payload

📖 Claim

• 토큰에 담긴 사용자 정보등의 데이터
• ex) 토큰이 언제까지 유효한지?, 사용자의 닉네임, 관리자 여부 등

 

🤔 이런 정보에 접근하고 조작하면 어떻게 되지?!?

• 유효기간을 증가시키는 등의 작업

💡 이런 문제를 해결하기 위해 헤더와 서명 부분이 존재!!

 

Header

{
     "alg": "서명 시 사용하는 알고리즘",
  "typ": "JWT"
}

• type 값으로는 항상 JWT가 들어있습니다.

 

📖 alg (알고리즘)

• 서명값을 만들기 위한 알고리즘 방법이 지정
• HS256 등 여러 암호화 방식중 하나를 지정
• 헤더와 페이로드 그리고 서버에서 사용하는 secret key 이 3가지를 이용해 암호화 알고리즘에 넣고 처리하면 서명 값이 나오게 됩니다.

 

Signature

서버에서는 요청이 들어오면 토큰의 헤더, 페이로드, secret key 를 이용해서 계산된 결과 값이 Signature 값과 같은지 확인합니다.

서명 값이 계산된 값과 일치하고 유효기간도 지나지 않았다면 그 요청은 인가처리가 됩니다!

 

💡 따라서 토큰을 탈취해도 서버의 secret key 를 찾아낼 수 없고 페이로드의 값이 하나라도 변경되더라도 서명값이 달라지기 때문에 조작할 수 없습니다.

 

🤔 그럼 JWT가 짱 인건가?

세션과 비교했을 때 JWT의 큰 단점이 존재

• 세션은 stateful 하기 때문에 모든 사용자들의 상태를 기억하고 있기 때문에 구현하기 어렵고 관리하기 어렵지만 이런 상태를 언제든지 제어를 할 수 있습니다.

 

⚠️ 여러 사용자가 같은 아이디로 로그인(같은 토큰)

• JWT를 사용하는 서버에서는 항상 허용(토큰이 유효하기 때문)
• 이와 달리 세션의 경우는 여러 아이디로 접속을 할 경우 이를 막는 등의 작업을 할 수 있습니다.

 

⚠️ 강제 로그아웃 불가능

• 한번 발급된 토큰이 만료되기 전까지는 유효!
• 탈취가 되었을 때 토큰을 무효화할 방법이 없습니다.

 

🔄 Refresh Token 전략

JWT의 문제를 보완하는 방법

• 만료시간을 매우 짧게 설정하여 토큰의 수명을 짧게 하는 것!

 

만료시간을 짧게 하면 해당 만료시간이 끝나면 다시 로그인을 해주어야 합니다.

 

이런 번거로움을 줄이기 위해 로그인을 했을 때 access token 과 함께 refresh token 을 제공해줍니다.

access token	매번 인가를 받을 때 사용하는 토큰, 수명이 짧음
refresh token	엑세스 토큰을 재 발급받을 때 사용하는 토큰, 수명이 김

 

📌 사용 방법

1. 로그인시 access token 과 refresh token을 사용자에게 반환
2. refresh token은 데이터베이스에 저장
3. 클라이언트는 access token이 만료되었을 때 refresh token을 서버로 보내주고
4. 서버는 데이터베이스에 저장된 값과 비교해 맞다면 새로운 access token을 발급

 

☁️ 결과

💡 refresh token만 잘 관리해준다면 access token이 만료될 때마다 다시 로그인을 할 필요가 없이 새로 발급을 받을 수 있습니다.

 

따라서, 중간에 엑세스 토큰이 탈취당하더라도 refresh token을 데이터베이스에서 삭제해 오래 사용하지 못하도록 보완

 

🚨 남아있는 한계점

• Access Token이 살아있는 동안은 여전히 즉시 차단 불가
• Refresh Token 관리가 복잡해짐
  • 탈취당하지 않도록 보안 강화 필요

 

📚 Ref.

https://www.youtube.com/watch?v=tosLBcAX1vk

https://www.youtube.com/watch?v=gA1KsJ2ak10