🔐 JWT(Json Web Token): 강력하지만 조심해야 할 인증 방식

🤔 JWT가 뭐길래?

최근 Google CASA 인증을 받으면서 JWT를 해명(?)해야할 일이 많았습니다. 그러다 보니 '이거 한 번 제대로 정리해야겠다'라고 생각했습니다. 사실 JWT는 많은 개발자가 사용하고 있지만, 제대로 이해하지 못하면 보안적으로 큰 문제가 될 수도 있겠다는 생각이 들더군요. 그래서 오늘은 JWT가 어떻게 동작하는지, 왜 많이 사용되는지, 그리고 보안적으로 어떤 점을 주의해야 하는지 한 번에 정리해보겠습니다! 🚀

---

🔍 JWT의 기본 구조

JWT는 3가지 파트로 구성된 문자열입니다. 점(.)으로 구분되며, 각각 헤더(Header), 페이로드(Payload), 서명(Signature)으로 이루어져 있습니다.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvbiBEb2UiLCJpYXQiOjE1MTYyMzkwMjJ9
.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

1️⃣ 헤더(Header)

JWT의 헤더에는 토큰 타입과 사용된 암호화 알고리즘이 포함됩니다.

{
  "alg": "HS256",
  "typ": "JWT"
}

• alg: 사용할 암호화 알고리즘(예: HS256, RS256)
• typ: 토큰 타입 (JWT)

2️⃣ 페이로드(Payload)

JWT의 페이로드에는 사용자 정보와 토큰의 만료 시간 등이 포함됩니다.

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

• sub: 토큰의 주인 (Subject)
• name: 사용자 이름
• iat: 토큰이 발급된 시간 (Issued At)

📌 주의: JWT는 Base64로 인코딩되기 때문에, 누구든지 디코딩해서 내용을 볼 수 있습니다. 따라서 비밀번호 같은 민감한 정보를 절대 포함해서는 안 됩니다!

3️⃣ 서명(Signature)

서명(Signature)은 JWT의 무결성(Integrity)을 보장하기 위해 사용됩니다. 즉, 토큰이 중간에 조작되지 않았다는 것을 확인하는 역할을 합니다.

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

서명 부분이 유효하지 않으면, 토큰이 변조되었음을 의미하므로 인증이 거부됩니다.

---

🎯 JWT가 왜 이렇게 인기일까?

JWT가 인기 있는 이유는 간단합니다. 사용하기 편리하기 때문입니다.

1️⃣ 상태 관리가 필요 없음

JWT는 서버가 로그인 정보를 따로 저장할 필요가 없습니다. 예전 방식처럼 사용자의 로그인 세션을 서버에서 관리하려면, 트래픽이 많아질수록 서버 부담이 커지고, 부하 분산을 위해 세션 공유(Sticky Session) 같은 걸 해야 하는데 이게 꽤나 귀찮습니다... 하지만 JWT는 클라이언트가 자체적으로 인증 정보를 갖고 있기 때문에 서버에서는 이걸 확인만 하면 됩니다. 즉, 확장성(Scale-Out)에 강합니다.

2️⃣ 빠름

JWT는 클라이언트가 요청을 보낼 때마다 필요한 인증 정보를 포함해서 보내기 때문에, 서버가 별도의 DB 조회 없이도 사용자의 권한을 검증할 수 있습니다. 즉, 매번 DB에 접근해서 사용자의 인증 상태를 확인할 필요가 없으니 응답 속도가 빨라집니다!

3️⃣ 언어와 플랫폼에 관계없이 사용 가능

JWT는 JSON 포맷을 기반으로 하기 때문에 웹뿐만 아니라 모바일 앱, 마이크로서비스 아키텍처, 서버 간 인증 등 다양한 환경에서 쉽게 활용할 수 있습니다. Node.js, Python, Java, Go 등 대부분의 언어에서 지원하기 때문에 프론트엔드와 백엔드가 서로 다른 기술을 써도 문제없이 연동 가능합니다.

그럼에도 불구하고, 편하다고 마냥 좋은 건 아니니까! JWT를 쓸 때 조심해야 할 점도 많습니다.

✅ 1. 상태 유지 필요 없음 (Stateless Authentication)

JWT는 세션 정보를 서버에 저장할 필요가 없습니다.

• 기존 세션 기반 인증 방식에서는 사용자의 로그인 상태를 유지하기 위해 세션을 서버에 저장해야 합니다.
• 하지만 JWT는 토큰 안에 사용자 정보를 포함하고 있기 때문에, 별도의 세션 저장소가 필요하지 않습니다.

✅ 2. 확장성(Scalability) 향상

JWT는 서버 간 공유가 필요 없는 방식이기 때문에, 마이크로서비스 환경에서도 쉽게 사용할 수 있습니다.

• 서버 간 상태를 공유할 필요가 없으므로, 여러 개의 서버에서 JWT를 검증하기만 하면 됩니다.
• 세션을 저장하는 서버 부담이 줄어들어, 트래픽이 많아도 원활한 서비스가 가능합니다.

✅ 3. 다양한 플랫폼에서 사용 가능

JWT는 웹뿐만 아니라, 모바일 앱, 서버 간 인증, API 인증에도 활용됩니다.

• OAuth2, OpenID Connect 등에서 표준 인증 방식으로 사용되고 있습니다.

---

⚠️ JWT 사용할 때 조심해야 할 점

JWT가 편리한 만큼, 보안적으로 신경 써야 할 부분도 많습니다. 대충 사용하면 큰 문제가 생길 수 있으니 반드시 확인해야 합니다.

1️⃣ 토큰은 디코딩할 수 있다 (암호화 아님!)

JWT는 Base64로 인코딩되어 있을 뿐, 암호화된 게 아닙니다. 즉, 누구든지 토큰을 디코딩해서 내부 정보를 볼 수 있습니다. 예를 들어, eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 이런 문자열을 Base64 디코딩하면 바로 원본 JSON 데이터가 나옵니다. 그러니까 비밀번호 같은 민감한 정보를 절대 JWT에 담지 말아야 합니다.

2️⃣ 만료 시간을 반드시 설정하자

JWT는 기본적으로 서버에서 따로 세션을 관리하지 않기 때문에, 토큰이 유출되면 누구나 해당 토큰을 사용할 수 있습니다. 그래서 exp(만료 시간)를 설정해서 유효기간을 짧게 두는 것이 필수입니다! 예를 들어, 로그인 토큰은 30분~1시간 정도로 설정하고, Refresh Token을 별도로 발급해서 관리하는 방식이 일반적입니다.

3️⃣ 'none' 알고리즘을 허용하면 안 된다

JWT의 헤더 부분을 보면 alg(알고리즘) 값이 있다. 여기서 alg: "none"으로 설정하면, 서명을 검증하지 않고 그냥 통과시키는 문제가 발생할 수 있습니다. 만약 서버에서 이걸 허용하면, 공격자가 서명을 아예 제거한 토큰을 만들어서 서버를 속일 수 있습니다. 그러니까 반드시 none 알고리즘을 허용하지 않도록 설정해야 합니다.

4️⃣ 토큰 저장 방식 주의 (XSS, CSRF 공격 대비)

JWT를 클라이언트에서 저장할 때, 로컬 스토리지(localStorage)에 저장하면 XSS(Cross-Site Scripting) 공격에 취약할 수 있습니다. 대신, Secure, HttpOnly 쿠키를 사용하면 XSS 공격을 막을 수 있습니다. 하지만 이 경우 CSRF(Cross-Site Request Forgery) 공격에 대비해야 하므로, CSRF 토큰을 같이 사용하는 것이 좋습니다.

JWT는 강력한 인증 방식이지만, 잘못 사용하면 보안상 심각한 문제가 발생할 수 있습니다. 다음과 같은 사항을 반드시 주의해야 합니다.

❌ 1. 민감한 정보 포함 금지

JWT는 Base64 인코딩이기 때문에, 누구나 디코딩할 수 있습니다.

base64 -d eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvbiBEb2UiLCJpYXQiOjE1MTYyMzkwMjJ9

➡ 결론: 비밀번호, 카드 번호, 개인정보 같은 민감한 정보를 절대 포함하지 마세요!

❌ 2. 토큰 저장 위치 (XSS 공격 대비)

• JWT를 로컬 스토리지(localStorage)에 저장하면 XSS(Cross-Site Scripting) 공격에 노출될 위험이 큽니다.
• Secure HttpOnly Cookie를 사용하는 것이 더 안전한 방법입니다.

❌ 3. 적절한 만료 시간 설정

• JWT는 기본적으로 세션을 유지하지 않기 때문에, 토큰이 유출되면 심각한 보안 사고로 이어질 수 있습니다.
• 따라서 JWT의 exp(만료 시간)를 짧게 설정하고, 필요할 경우 Refresh Token을 활용하여 재발급하는 방식이 좋습니다.

❌ 4. 'none' 알고리즘 공격 주의

• 일부 JWT 라이브러리에서는 alg: "none" 설정을 허용하는 경우가 있습니다.
• 공격자가 서명 검증을 우회하기 위해 alg: "none"을 설정하여 서명 없이도 유효한 JWT로 인식될 수 있습니다.
• 반드시 none 알고리즘을 허용하지 않도록 서버 설정을 확인하세요!

---

🚀 정리: JWT, 이렇게 쓰면 안전하다!

JWT는 확실히 편리한 인증 방식이지만, 보안적으로 신경 써야 할 부분이 많습니다.

📌 안전하게 JWT를 사용하려면?

• 비밀번호 같은 민감한 정보는 절대 JWT에 담지 말 것!
• 만료 시간을 짧게 설정하고, Refresh Token을 활용할 것
• 서버에서 'none' 알고리즘을 허용하지 않도록 확인할 것
• JWT를 저장할 때 로컬 스토리지 대신 Secure HttpOnly 쿠키를 사용할 것

JWT는 강력하고 확장성이 뛰어난 인증 방식이지만, 보안적으로 취약할 수 있는 요소들이 있습니다. 이를 방지하기 위해 아래 원칙을 꼭 지켜주세요! ✅

✔ 민감한 정보는 절대 포함하지 말 것
✔ 토큰을 로컬 스토리지에 저장하지 않고, Secure HttpOnly Cookie를 사용할 것
✔ 적절한 만료 시간(exp)을 설정하고, Refresh Token을 활용할 것
✔ 서버에서 none 알고리즘을 허용하지 않도록 설정할 것
✔ 비밀 키(Secret Key)를 안전하게 관리할 것

이제 JWT에 대해 더 깊이 이해하고, 실무에서 올바르게 적용해 보세요! 🚀

다음에는 CASA Tier2를 받기 위한 인증 과정도 정리해서 올려보겠다. 오늘은 여기까지 정리합니다! 😉 다음에는 CASA Tier2 인증 과정도 정리해볼 예정이니 기대해 주세요!