[#3][다시, 처음부터 #5]JWT(Json Web Token) 기반 인증

지금까지 1~4일차는 API 기본 → HTTP 구조 → 요청/응답 흐름 → 서버 상태 관리(쿠키/세션/토큰)까지 왔다.

 

---

1. 개념 설명 (Concept)

 

JWT 란?

• JSON Web Token:  JSON 형식으로 정보를 담은 토큰을 헤더(Header), 페이로드(Payload), 서명(Signature) 3부분으로 나눈 인증 방식.
• 서버가 클라이언트에게 토큰을 발급하고, 이후 요청 시 토큰을 포함해 보내면 서버가 DB 조회 없이 인증할 수 있음.

 

동작 흐름

JWT = Header . Payload . Signature

1. 로그인 요청
   1. 클라이언트 → 아이디/비밀번호 전송
   2. 서버 → 인증 성공 시 JWT 생성 후 클라이언트에게 반환
2. JWT 구조
   1. Header: 어떤 알고리즘으로 서명했는지 (alg) + 타입(typ=JWT)
   2. Payload: 유저 정보, 권한, 만료시간(exp) 등 → 암호화 안됨(누구나 볼 수 있음)
   3. Signature: (Header + Payload)를 서버의 Secret Key로 서명 → 위변조 여부 검증 가능
3. 인증 요청
   1. 클라이언트 → HTTP 요청의 Header(Authorization)에 JWT 넣어 보냄
      예: Authorization: Bearer <토큰>
   2. 서버 → Secret Key로 Signature 검증 → 통과하면 Payload 정보로 유저 인증

 

---

2. 올바른 용어 (Terminology)

• JWT (JSON Web Token): JSON 형식의 인증 토큰
• Header (헤더): 토큰의 메타 정보(알고리즘, 타입)
• Payload (페이로드): 유저 데이터(공개 정보, Claims라고도 부름)
• Signature (서명): 위변조 방지를 위한 서명 부분
• Secret Key (비밀 키): 서버에만 저장, Signature 검증에 사용
• Stateless Authentication (무상태 인증): 서버가 세션을 저장하지 않고 토큰 자체로 인증

 

---

3. 잘못 쓰기 쉬운 표현 + 실제 맥락 (Misuse & Context)

 

❌ “Payload가 암호화되어 있어서 안전하다” → 잘못된 말
✅ “Payload는 단순 인코딩(Base64Url)일 뿐, 누구나 볼 수 있다. 보안은 Signature로 보장된다”

❌ “서버가 토큰을 매번 DB에서 확인한다”
✅ JWT의 장점은 DB 조회 없이 검증 가능하다는 점. 단, 보안상 이유로 Refresh Token이나 블랙리스트 관리 시 DB를 쓸 수 있음.

 

---

4. 면접 예시 (Interview Q&A)

 

Q1. JWT와 세션 기반 인증의 차이점은 무엇인가요?

• A: 세션 기반은 서버 메모리/DB에 상태를 저장하는 반면, JWT는 클라이언트가 토큰을 보관하고, 서버는 서명만 검증해 무상태로 인증합니다.

Q2. JWT Payload에 민감한 정보를 넣으면 왜 위험한가요?

• A: Payload는 Base64Url 인코딩이라 누구나 쉽게 디코딩할 수 있기 때문에, 비밀번호나 주민번호 같은 정보는 절대 넣으면 안 됩니다.

---

5일차 확인 퀴즈

 

 

1. JWT의 3가지 구성 요소를 올바른 순서대로 나열하세요.
① Payload, Header, Signature
② Header, Payload, Signature
③ Signature, Header, Payload

정답:
② Header → Payload → Signature

---

2. JWT의 Payload(페이로드)에 들어가는 정보에 대한 설명으로 옳지 않은 것은?
① 사용자 ID, 권한 같은 Claim 정보를 담을 수 있다.
② Base64Url로 인코딩되어 누구나 디코딩할 수 있다.
③ 암호화되어 있어서 보안상 안전하다.
④ 만료 시간(exp) 같은 값도 담을 수 있다.

Payload는 단순 **인코딩(Base64Url)**일 뿐, **암호화(encryption)**가 아님.

“암호화되어 안전하다”는 설명이 틀림.

정답: ③ 암호화되어 있어서 보안상 안전하다

---

3. 서버가 JWT를 검증할 때 사용하는 것은 무엇인가요?
① 클라이언트가 보낸 비밀번호
② 서버에 저장된 세션 ID
③ 서버의 Secret Key
④ 클라이언트의 로컬 스토리지

서버는 클라이언트가 보낸 토큰의 Signature를 자신이 가진 Secret Key로 검증함.

정답: ③ 서버의 Secret Key

---

4. JWT의 장점에 해당하지 않는 것은?
① 서버가 상태(Session)를 저장하지 않아도 된다.
② DB 조회 없이 Signature 검증으로 인증 가능하다.
③ Payload에 중요한 개인정보를 안전하게 보관할 수 있다.
④ 분산 서버(멀티 서버) 환경에서 확장성이 좋다.

Payload는 누구나 볼 수 있어서 개인정보 보관에 안전하지 않음.

정답: ③ Payload에 개인정보 안전 보관 가능하다

---

5. JWT를 사용할 때 반드시 고려해야 할 보안 대책이 아닌 것은?
① HTTPS를 사용해 전송 중 탈취를 막는다.
② Access Token을 짧게 발급하고 Refresh Token을 병행한다.
③ Payload에 비밀번호 같은 민감 정보를 그대로 넣는다.
④ 토큰 만료(exp)와 블랙리스트를 관리한다.

비밀번호 같은 민감 정보를 Payload에 넣으면 안 됨 → 보안 대책이 아님.

정답: ③ Payload에 비밀번호 넣는다