🔐 헷갈리는 인증 개념 (JWT · Bearer · Access Token · Session · Storage) 정리

이 문서에서는 웹 인증 과정에서 자주 등장해 헷갈리기 쉬운(제가 헷갈려요) JWT, Bearer, access_token, refresh_token,
쿠키·localStorage·메모리 저장 방식, Session 방식, 그리고 세션 토큰 개념을 명확히 정리해봤습니다.

---

1. 인증의 큰 흐름 이해하기

웹에서 로그인 관련 작업은 크게 두 단계로 나뉩니다.

1. Authentication (인증) — 👤 누구인지 확인하기: 사용자가 정말 그 사람인지 확인합니다.
2. Authorization & Session 유지 — 🔐 권한주고 유지하기: 인증된 사용자가 로그인 상태를 유지하고, 권한대로 행동할 수 있도록 관리합니다.

이 두 단계 과정에서 아래 개념들이 자연스럽게 등장합니다:

• 세션(session)
• 쿠키(cookie)
• JWT(JSON Web Token)
• access_token / refresh_token
• 저장 방식(localStorage, cookie, in-memory)
• Opaque Token
• id_token, API Key 등

---

2. JWT(JSON Web Token)

✔ 무엇인가?

JWT는 토큰의 모양(포맷) 입니다. 즉, “토큰이 어떤 구조로 생겼냐?”를 정의한 규격입니다. => "토큰이 어떤 모양인가"

xxxxx.yyyyy.zzzzz
Header.Payload.Signature

구조

• Header — 어떤 알고리즘으로 서명했는지
• Payload — 유저 정보, 권한, 만료 시간(exp) 등
• Signature — 위조 방지를 위한 서명값

✔ 어디에 쓰는가?

• access_token 용도로 가장 널리 사용됨
• 서버가 상태를 저장하지 않는 Stateless 인증에 적합

  Stateless = 서버가 아무 상태도 보관하지 않고, 요청마다 인증 정보를 다시 받아 확인하는 방식

✔ 어디에서 많이 쓰는가?

• access_token 구현 방식으로 가장 널리 사용됨
• 클라이언트가 API 서버에 인증할 때 (웹·모바일 공통)
• OAuth의 id_token
• 서버가 상태를 저장하지 않는 Stateless 환경

✔ 중요한 포인트

• JWT는 암호화된 것이 아니라 서명(Signature)된 것이다.
  → payload는 Base64 디코딩하면 누구나 볼 수 있음
• 민감한 정보 저장 금지
• JWT는 포맷일 뿐, 저장 방식은 쿠키/스토리지/메모리 중 아무거나 사용 가능

---

3. Bearer

✔ 무엇인가?

Bearer는 인증 토큰을 전송하는 방식(스킴) 입니다. => "전송 방식"

Authorization: Bearer <token>

• JWT, Opaque Token, access_token 등 모든 종류의 토큰 전달 가능
• 토큰을 헤더에 넣어 보내기 위한 가장 표준적인 방식
• API 인증에서 가장 흔하게 사용됨

✔ 어디에서 많이 쓰는가?

클라이언트가 서버 API에 인증 정보를 전달할 때 거의 표준처럼 사용됩니다.

• REST API
• GraphQL API
• OAuth 기반 access_token 인증

🔗 jwt와 Bearer의 관계

Bearer는 “전송 방식”이라 JWT가 아닌 토큰도 얼마든지 실어 보낼 수 있다.
JWT는 Bearer에서 쓰이는 여러 토큰 중 하나일 뿐이다.

---

4. 💾 Token "저장 방식" (쿠키 · localStorage · 메모리)

🍪 쿠키(Cookie)

• 서버가 Set-Cookie 로 내려주면 브라우저가 저장
• 요청 시 자동 전송
• httpOnly, secure, sameSite 옵션으로 보안 강화 가능

🔐 httpOnly란?
자바스크립트에서 쿠키를 읽지 못하도록 차단하는 옵션
→ refresh_token, session_id처럼 유출되면 위험한 값 보호에 필수

왜 refresh_token / session_id 는 반드시 httpOnly 쿠키에 저장할까?

이 두 값은 탈취되면 계정이 그대로 도난되는 ‘가장 위험한 토큰’이기 때문입니다.

항목	털렸을 때 위험도
access_token	짧게 살아서 피해 제한적
refresh_token	새 access_token 무한 재발급 → 계정 장악
session_id	서버 세션 그대로 탈취 → 완전 도난

즉, 절대 JavaScript에서 읽히면 안 되는 토큰들입니다.

• localStorage ❌
  → JS로 읽힘 → XSS 공격에 그대로 노출

• httpOnly 쿠키 ⭕
  → JS 접근 완전 차단
  → 브라우저가 자동 전송하므로 인증 흐름도 자연스러움
  일반 쿠키는 JS에서 읽히기 때문에 XSS 공격에 취약합니다.

XSS(Cross-Site Scripting)?

사용자가 방문한 정상 사이트 안에서
공격자가 만든 악성 JS 코드가 실행되도록 속이는 공격

Set-Cookie: refresh_token=abcd; HttpOnly;

주로 어디에 쓰는가?

• refresh_token 저장
• session_id 저장

---

✔ localStorage / sessionStorage

• JS에서 직접 접근 가능한 저장소
• 자동 전송 X → Bearer 헤더에 직접 넣어야 함
• 원래는 일반 데이터 저장용
• XSS 취약

주 사용처

• 일반 UI 설정값, Key-Value 데이터 저장 (예: 테마, 언어 설정, 필터 값 등)
• 인증 정보 중 보안 중요도가 낮은 값 저장 시 (예: access_token — 단, 안전성은 떨어짐)
• 간단한 SPA, 데모/프로토타입에서 임시 데이터 저장

---

🧠 메모리(In-Memory)

• 새로고침 시 사라지는 저장 방식
• XSS 위험을 줄이기 위해 access_token을 메모리에 저장하는 패턴 증가

인메모리란?

React state, Context, Redux store, Zustand, 전역 JS 변수 등
런타임 메모리에만 들고 있는 상태를 의미

주 사용처

• access_token 보관 (가장 권장되는 방식)

---

🤔 새로 고침하면 사라지는데 왜 사용할까?

일부러 사라지도록 설계한 것입니다.

이유: XSS 공격에서 안전

localStorage에 저장하면 스크립트로 쉽게 탈취됨:

localStorage.getItem("access_token")

그러나 메모리는 페이지 Reload 시 사라져 지속적인 공격이 불가능.

---

그렇다면 새로고침 후에는 어떻게 로그인 상태를 유지할까?

인메모리에 있던 access_token은 새로고침 시 사라지기 때문에,
아무 로직도 없으면 사실상 “로그아웃" 됩니다.

그래서 보통 앱에서 이런 흐름으로 구현합니다:

1. 앱이 처음 로드될 때(예: App 또는 Layout 마운트 시점에)
   /auth/refresh 같은 토큰 재발급 API를 자동으로 한 번 호출합니다.

2. 이때 브라우저가 알아서 refresh_token(httpOnly 쿠키)을 서버로 전송합니다.

3. 서버는 refresh_token을 검증하고 새 access_token을 응답으로 내려줍니다.

4. 프론트는 받은 access_token을 다시 메모리에 저장합니다.

이렇게 하면, 유저 입장에서는 새로고침을 해도 로그인이 유지된 것처럼 보입니다.

---

✔ 실제 권장 패턴

• refresh_token → httpOnly 쿠키
• access_token → 메모리 보관
• access_token 만료 시 → refresh_token으로 재발급

---

5. access_token / refresh_token

🔑 access_token

• 짧게 사는 인증 토큰 (5분~1시간)
• 보통 JWT
• Bearer로 API 인증

🔑 refresh_token

• access_token 재발급용
• 오래 살기 때문에 보안 중요
• 보통 랜덤 문자열(Opaque Token) + httpOnly 쿠키

비유

• access_token = 🚪 “문 앞에서 보여주는 출입증”
• refresh_token = 🎫 “출입증 재발급권”

---

6. Session 방식 (sessionStorage와 완전히 다름)

세션(Session) 방식은 서버가 로그인 상태를 직접 기억하는 방식입니다.

✔ 작동 흐름

1. 로그인 성공 → 서버가 세션 생성

   session_id → { userId: 1, role: 'admin' }

2. session_id를 쿠키로 내려줌

   Set-Cookie: session_id=xyz123; HttpOnly;

3. 브라우저가 요청마다 자동 전송

   Cookie: session_id=xyz123

4. 서버는 이 session_id로 유저 정보 조회

서버가 유저 상태를 저장하고,
브라우저는 session_id라는 열쇠만 들고 다니는 구조

✔ 장점

• 서버에서 강제 로그아웃 가능
• 민감 정보가 서버에 있어 안전

✔ 단점

• 서버가 상태를 저장해야 함 → 스케일링 비용

스케일링 비용이란?

사용자 증가에 맞춰 서버를 확장할 때 필요한 추가 부담

---

🚫 sessionStorage는 완전히 다른 개념입니다.

개념	저장 위치	목적	인증 여부
Session(서버 세션)	서버	로그인 상태 유지	✔
sessionStorage	브라우저	일반 데이터 임시 저장	❌

---

세션 방식은 어떻게 구현할까?

✔ 서버에서 하는 일

• 로그인 시 세션 저장
• session_id 쿠키 발급
• 요청마다 session_id로 유저 조회
• 로그아웃 시 세션 삭제

✔ 프론트에서 하는 일

fetch('/api/login', {
  method: 'POST',
  credentials: 'include'
});

• 쿠키 자동 전송 → 토큰 관리 불필요
• 로그아웃 API만 호출하면 끝

---

7. Opaque Token(불투명 토큰)

Opaque Token은 의미를 알 수 없는 랜덤 문자열 토큰입니다.

예:

4f8d1b28e92c4a6ca8948d91a3f8a0d7

✔ 특징

• 토큰 내부 정보를 알 수 없음
• 반드시 서버 DB에 저장해 매칭해야 함
• refresh_token에서 가장 많이 사용됨
• OAuth2 기본 access_token 형태

✔ 왜 쓰는가?

• JWT처럼 내부 정보가 노출되지 않아 안전
• refresh_token처럼 “매우 민감한 토큰”에 적합

✔ 누가 발급하나?

백엔드 인증 서버가 직접 생성해 클라이언트에게 전달합니다.

1. 서버가 Opaque Token을 만든다
2. 서버는 이 토큰을 DB/Redis 등 저장소에 저장한다
3. 클라이언트는 이 문자열을 들고 다닌다
4. 요청 올 때 서버는 DB에서 토큰을 찾아야 유저 확인 가능

예)

98de12ccf39a49dbb041a01bdac20345

서버 DB에는 이렇게 저장됨:

refresh_token -> userId 123

✔ JWT는 왜 DB가 필요 없을까?

토큰 종류	서버에서 DB 필요?	이유
JWT	❌ 필요 없음	토큰 안에 userId/exp/role 등이 다 들어있고 서명으로 검증 가능
Opaque Token	✔ 필요함	내부 정보 없음 → 서버가 저장한 정보와 매칭해야 함

→ 그래서 refresh_token을 쓰면

노출됐을 때 내부 정보가 없으므로 안전

서버 DB에서 해당 토큰만 지우면 즉시 무효화 가능 (로그아웃 가능)

JWT refresh_token보다 훨씬 컨트롤이 쉬움

---

8. JWT 말고도 존재하는 중요한 토큰들

✔ 세션 토큰(Session ID)

• 세션 방식에서 사용
• 쿠키에 저장
• 내부 정보는 서버에 있음

✔ Opaque Token

• 랜덤 문자열
• OAuth2 기본 토큰
• refresh_token에 주로 사용

✔ OAuth 토큰들

• access_token (opaque 또는 JWT)
• refresh_token (opaque)
• id_token (항상 JWT)

✔ API Key

• 외부 서비스 인증

✔ id_token

• OAuth 로그인에서 사용자 프로필을 담는 JWT

---

✅ 어떤 것을 어디에서 주로 쓸까?

개념	역할	주로 쓰는 곳
JWT	토큰 포맷(Stateless 인증에 적합)	API 인증, OAuth id_token
access_token	짧게 사는 인증 토큰	Bearer 헤더, 인메모리 저장
refresh_token	access_token 재발급	httpOnly 쿠키(서버 DB 검증)
Bearer	인증 전달 방식(헤더 스킴)	모든 API 인증 요청
쿠키(httpOnly)	민감 토큰 보관/자동 전송	refresh_token, session_id
localStorage / sessionStorage	JS 접근 가능 Key-Value 저장소	일반 UI 값, 낮은 보안 데이터
메모리(In-Memory)	JS 런타임 상태 저장	access_token 임시 보관
세션(SessionID)	서버가 상태 저장하는 인증 방식	SSR/전통 웹, 사내 시스템
Opaque Token	서버가 DB에 저장하는 랜덤 토큰	refresh_token, OAuth2 access_token
API Key	서비스/서버 간 인증	외부 API, 백엔드 통신
id_token	사용자 정보(JWT)	소셜 로그인(OAuth/OpenID Connect)

---

📝 전체 인증 흐름 요약

1. 사용자가 로그인 요청을 보냄
2. 서버는 다음 두 값을 생성함
   • access_token (JWT, 짧은 수명)
   • refresh_token (Opaque Token, 장기 수명)
3. 서버는 refresh_token을 httpOnly 쿠키로 내려 저장하게 함
4. 프론트는 access_token을 메모리(In-Memory) 등에 보관하여
   API 요청 시 Bearer 헤더로 전송
5. access_token이 만료되거나 새로고침으로 사라지면
   프론트는 /auth/refresh 요청을 보내고
   브라우저는 refresh_token 쿠키를 자동 전송
6. 서버는 refresh_token을 검증해 새로운 access_token을 재발급
7. 세션 기반 방식이라면, 서버는 session_id를 쿠키로 발급하고
   이후 요청마다 자동으로 전송되는 session_id로 로그인 상태를 유지

→ 결과적으로 사용자는 새로고침을 하거나 access_token이 만료되더라도
refresh_token(쿠키) 또는 session_id 덕분에 로그인 상태가 유지됨

---