[JS] 쿠키/ 세션/ JWT / Access Token, Refresh Token 인증 방식

1) 쿠키 인증 방식

브라우저에 쿠키를 저장하고, 요청마다 그 쿠키를 서버로 자동 전송해서 인증하는 방식입니다.

1. 로그인 성공
2. 서버가 쿠키를 내려줌
3. 이후 요청마다 브라우저가 자동으로 쿠키를 포함
4. 서버가 쿠키 값을 기준으로 사용자 인증

• 브라우저가 자동 전송
• HttpOnly, Secure, SameSite로 보안 제어 가능
• CSRF 방어가 필요

👉 쿠키는 “전송 수단”이지 인증 로직 그 자체는 아님

 

---

2) 세션 인증 방식

사용자 인증 상태를 서버가 세션으로 저장하고 클라이언트는 세션 ID만 쿠키로 들고 있는 방식입니다.

1. 로그인 성공
2. 서버가 세션 생성
3. 세션 ID를 쿠키로 내려줌
4. 요청 시 쿠키의 세션 ID로 서버가 사용자 조회

• 인증 정보는 서버에만 존재
• 보안에 유리
• 서버 자원 사용 / 확장 시 세션 공유 필요

👉 “쿠키 + 세션”이 전통적인 인증 방식

---

3) JWT 인증 방식

사용자 정보와 만료 시간 등을 서명된 토큰 형태로 담은 인증 토큰입니다.

1. 로그인 성공 → 서버가 JWT 발급
2. 클라이언트가 JWT 저장
3. 요청 시 JWT를 전송
4. 서버는 토큰 서명/만료만 검증 (세션 조회 없음)

• 무상태(stateless) → 서버 확장에 유리
• 토큰 탈취 시 즉시 위험
• 토큰 저장 위치가 매우 중요

👉 JWT는 보통 Authorization 헤더 + Bearer 토큰으로 전송

---

4) Access Token / Refresh Token

1. 로그인 성공
   → Access Token + Refresh Token 발급

2. 클라이언트가 Access Token으로 API 요청

3. Access Token 만료
   → API 401 응답

4. Refresh Token으로 /refresh 요청
   → 새로운 Access Token 발급

5. 기존 요청 재시도

 

1️⃣ Access Token - 사용자가 인증되었음을 증명하고, API 요청 시 권한을 확인하는 토큰

특징

• 유효 기간이 짧음 (보통 수 분 ~ 1시간)
• 매 API 요청마다 Authorization: Bearer <token> 형태로 전달
• 탈취되면 위험 → 짧은 수명으로 피해 최소화

역할

• “이 요청은 로그인한 사용자 요청이 맞다”를 증명
• 서버는 토큰만 보고 권한 판단 (세션 조회 불필요)

 

2️⃣ Refresh Token - 만료된 Access Token을 다시 발급받기 위한 토큰

특징

• 유효 기간이 김 (보통 며칠 ~ 몇 주)
• API 요청에는 사용 ❌
• 보통 서버에 저장 (DB/Redis 등)

역할

• Access Token이 만료되면 Refresh Token으로 새 Access Token 발급

 

3️⃣ 왜 두 개를 나눠 쓰나?

❌  Access Token만 쓰면

• 유효 기간을 길게 잡아야 함
• 탈취 시 장시간 악용 가능

❌ Refresh Token만 쓰면

• 매 요청마다 서버 확인 필요
• 성능·확장성 떨어짐

✅ 둘을 나누면

• Access Token: 빠른 인증 + 짧은 수명
• Refresh Token: 보안 유지 + 재인증 역할