JWT (JSON Web Token)

SSL/TLS가 "통신 통로"를 안전하게 만드는 기술이었다면, 이제 그 통로를 통해 들어온 사용자가 누구인지 계속 기억해주는 "신분증" 이야기가 나올 차례입니다.

그중에서도 요즘 현대적인 서비스(앱, 웹)에서 가장 사랑받는 JWT를 아주 깊게 파헤쳐 드릴게요.

---

1. JWT가 뭐야? (JSON Web Token)

JWT는 정보를 JSON 객체 형태로 안전하게 주고받기 위한 "디지털 신분증"입니다.

• 특징: 신분증 안에 필요한 정보(내 이름, 권한, 유효기간 등)가 다 들어있어서, 서버가 일일이 DB를 뒤져보지 않아도 이 신분증만 보고 "아, XX님 맞네!"라고 바로 알 수 있습니다.

---

2. JWT의 생김새 (3단 구조)

JWT는 점(.)으로 구분된 세 부분으로 나뉩니다. 이게 제일 중요해요!

① Header (헤더)

• 내용: "이 토큰은 어떤 종류인지(JWT)", "어떤 알고리즘으로 암호화(서명)했는지(예: HS256)"를 적어둡니다.

② Payload (페이로드)

• 내용: 실제 담고 싶은 정보가 들어있습니다. (사용자 ID, 이름, 권한 등)
• 주의: 여기는 누구나 열어볼 수 있는 '공개된 정보'입니다. 비밀번호 같은 민감한 정보는 절대 넣으면 안 됩니다!

③ Signature (서명)

• 내용: JWT의 핵심 보안 장치입니다. 헤더 + 페이로드 + 서버만 아는 비밀키를 조합해서 만든 암호화 값입니다.
• 역할: 누군가 페이로드의 내용을 슬쩍 고치면(위조), 이 서명 값이 달라지기 때문에 서버가 "어? 이거 위조된 신분증인데?"라고 즉시 알아차립니다.

---

3. JWT는 어떻게 동작하나? (흐름)

1. 로그인: XX님이 ID/PW로 로그인을 합니다.
2. 발급: 서버가 정보를 확인하고, 비밀키를 이용해 슥슥 서명해서 JWT를 만들어 XX님께 줍니다.
3. 저장: XX님의 브라우저(또는 앱)가 이 토큰을 보관합니다.
4. 제시: 이후 XX님이 "내 프로필 보여줘"라고 요청할 때마다, HTTP 헤더에 이 토큰을 실어서 보냅니다.
5. 검증: 서버는 DB를 뒤지지 않고, 본인이 가진 비밀키로 토큰의 서명이 유효한지만 확인한 뒤 바로 서비스를 제공합니다.

---

4. 왜 JWT를 쓸까? (장점)

• 서버가 편하다 (Stateless): 서버는 로그인한 사람을 일일이 기억(Session)할 필요가 없습니다. 토큰만 검사하면 되니까요. 덕분에 서버를 여러 대 늘려도 관리가 아주 쉽습니다. (확장성 최고!)
• 모바일 앱에 최적: 세션 방식은 웹 브라우저가 아니면 관리가 까다로운데, 토큰은 어디서든 쉽게 주고받을 수 있습니다.

---

⚠️ JWT의 치명적인 단점 (아키텍트의 고민)

• 한번 발급하면 멈출 수 없다: 토큰은 서버가 통제권을 가진 게 아니라 사용자가 들고 있는 겁니다. 그래서 토큰을 도둑맞아도 유효기간이 끝날 때까지는 해커가 XX님 행세를 할 수 있습니다.
• 해결책: 그래서 유효기간을 아주 짧게(예: 30분) 잡고, 토큰을 새로 고쳐주는 Refresh Token이라는 보조 열쇠를 하나 더 씁니다.

---

🔗 다음 공부의 연결고리

JWT 설명을 듣다 보니 이런 의문이 들지 않으세요?

"아니, 옛날에는 토큰 없이도 로그인 잘만 됐는데? 굳이 왜 이렇게 복잡하게 해?"

그게 바로 전통적인 방식인 [Session]과 [Cookie] 이야기로 이어집니다. JWT와 무엇이 다른지 비교해보면 보안의 흐름이 완성되거든요.

JWT의 3단 구조와 '서명'의 원리가 이해되셨나요? 이해되셨다면 이제 전통의 강자 [Session / Cookie]와 JWT를 본격적으로 비교하러 가볼까요?