JWT 기반 인증 구현하기 완벽 가이드

웹 애플리케이션에서 가장 널리 사용되는 JWT 인증 방식을 초급 개발자도 쉽게 이해할 수 있도록 설명합니다. 토큰의 구조부터 보안 베스트 프랙티스까지 실무에 바로 적용할 수 있는 내용을 담았습니다.

---

목차

1. JWT_구조
2. JWT_생성과_검증_과정
3. Access_Token과_Refresh_Token
4. 토큰_저장_위치
5. 토큰_갱신_전략
6. JWT_보안_베스트_프랙티스

---

1. JWT_구조

입사 첫 주, 김개발 씨는 로그인 API 코드를 살펴보다가 이상한 문자열을 발견했습니다. 점으로 구분된 길고 복잡한 문자열이 응답으로 내려오고 있었습니다.

"이게 대체 뭐지?" 선배에게 물어보니 돌아온 답은 "JWT야, 모르면 큰일 나"였습니다.

**JWT(JSON Web Token)**는 사용자 인증 정보를 안전하게 전달하기 위한 토큰 형식입니다. 마치 신분증처럼 "나는 누구이고, 어떤 권한이 있다"는 정보를 담고 있습니다.

세 부분으로 나뉘어 있으며, 각각 Header, Payload, Signature라고 부릅니다.

다음 코드를 살펴봅시다.

// JWT의 세 가지 구성 요소
const header = {
  "alg": "HS256",    // 서명에 사용할 알고리즘
  "typ": "JWT"       // 토큰 타입
};

const payload = {
  "sub": "user123",  // 사용자 식별자
  "name": "김개발",   // 사용자 정보
  "iat": 1699900000, // 토큰 발급 시간
  "exp": 1699903600  // 토큰 만료 시간
};

// 최종 JWT: base64(header).base64(payload).signature
// eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyMTIzIn0.서명값

김개발 씨는 입사 첫 주차 주니어 개발자입니다. 회사에서 맡은 첫 업무는 기존 로그인 시스템을 파악하는 것이었습니다.

코드를 열어보니 로그인 성공 시 이상한 문자열이 클라이언트로 전달되고 있었습니다. "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U" 도대체 이 암호 같은 문자열은 무엇일까요?

선배 개발자 박시니어 씨가 다가와 설명을 시작했습니다. "이건 JWT라고 해.

JSON Web Token의 약자야. 쉽게 말해서 디지털 신분증이라고 생각하면 돼." JWT를 이해하려면 먼저 그 구조를 알아야 합니다.

JWT는 세 부분으로 나뉘어 있고, 각 부분은 점(.)으로 구분됩니다. 마치 주민등록증이 앞면, 뒷면, 홀로그램 세 부분으로 이루어진 것과 비슷합니다.

첫 번째 부분은 Header입니다. 헤더는 이 토큰이 어떤 방식으로 만들어졌는지 알려줍니다.

주로 서명 알고리즘(alg)과 토큰 타입(typ) 정보가 들어갑니다. 가장 많이 사용하는 알고리즘은 HS256입니다.

두 번째 부분은 Payload입니다. 페이로드는 실제로 전달하고 싶은 정보가 담기는 곳입니다.

사용자 ID, 이름, 권한 등 필요한 데이터를 넣을 수 있습니다. 여기서 중요한 점은 페이로드에 민감한 정보를 넣으면 안 된다는 것입니다.

왜냐하면 이 부분은 암호화가 아닌 단순 인코딩이기 때문입니다. 세 번째 부분은 Signature입니다.

서명은 앞의 두 부분이 위변조되지 않았음을 증명합니다. 서버만 알고 있는 비밀 키로 만들어지기 때문에, 누군가 페이로드를 조작하면 서명 검증에서 바로 들통납니다.

박시니어 씨가 덧붙였습니다. "주의할 점이 있어.

JWT는 암호화된 게 아니야. Base64로 인코딩된 것뿐이라 누구나 내용을 볼 수 있어.

그래서 비밀번호 같은 민감한 정보는 절대 넣으면 안 돼." 김개발 씨는 고개를 끄덕였습니다. "아, 그래서 서명이 중요한 거군요.

내용은 볼 수 있지만, 위조는 못 하게 막는 거네요." 실제 현업에서 JWT의 페이로드에는 주로 사용자 식별자(sub), 토큰 발급 시간(iat), 만료 시간(exp) 등의 표준 클레임을 넣습니다. 필요에 따라 사용자 역할이나 권한 정보를 추가하기도 합니다.

실전 팁

💡 - 페이로드에는 민감한 정보를 절대 넣지 마세요

• jwt.io 사이트에서 JWT 구조를 직접 확인해볼 수 있습니다

---

2. JWT_생성과_검증_과정

다음 날, 김개발 씨는 직접 JWT를 만들어보기로 했습니다. 하지만 막상 코드를 작성하려니 어디서부터 시작해야 할지 막막했습니다.

"토큰을 어떻게 만들고, 또 어떻게 확인하는 거지?"

JWT 생성은 사용자 정보를 담아 서명하는 과정이고, 검증은 받은 토큰이 유효한지 확인하는 과정입니다. 마치 도장을 찍어 문서를 발급하고, 나중에 그 도장이 진짜인지 확인하는 것과 같습니다.

서버는 비밀 키를 사용해 토큰을 만들고, 같은 키로 검증합니다.

다음 코드를 살펴봅시다.

const jwt = require('jsonwebtoken');

// 비밀 키 (환경 변수로 관리해야 함)
const SECRET_KEY = process.env.JWT_SECRET;

// JWT 생성 함수
function generateToken(user) {
  const payload = {
    sub: user.id,
    name: user.name,
    role: user.role
  };
  // 1시간 후 만료되는 토큰 생성
  return jwt.sign(payload, SECRET_KEY, { expiresIn: '1h' });
}

// JWT 검증 함수
function verifyToken(token) {
  try {
    const decoded = jwt.verify(token, SECRET_KEY);
    return { valid: true, data: decoded };
  } catch (error) {
    return { valid: false, error: error.message };
  }
}

김개발 씨는 JWT의 구조를 이해했지만, 실제로 어떻게 만들고 검증하는지는 아직 모호했습니다. 박시니어 씨가 화이트보드에 그림을 그리며 설명을 시작했습니다.

"JWT 생성과 검증은 마치 공증 사무소와 같아. 공증 사무소에서 도장을 찍어 문서를 발급하면, 나중에 그 도장이 진짜인지 확인할 수 있잖아?" JWT 생성 과정은 세 단계로 이루어집니다.

먼저 Header와 Payload를 각각 Base64로 인코딩합니다. 그다음 인코딩된 두 문자열을 점으로 연결합니다.

마지막으로 이 문자열을 비밀 키로 서명하여 Signature를 만듭니다. Node.js에서는 jsonwebtoken 라이브러리를 사용하면 이 모든 과정을 한 줄로 처리할 수 있습니다.

jwt.sign() 메서드에 페이로드와 비밀 키, 옵션을 전달하면 완성된 JWT가 반환됩니다. 검증 과정은 생성의 역순입니다.

받은 토큰을 점으로 분리하고, Header와 Payload를 다시 서명합니다. 새로 만든 서명과 토큰에 포함된 서명이 일치하면 유효한 토큰입니다.

jwt.verify() 메서드는 서명 검증과 함께 만료 시간도 확인합니다. 만약 토큰이 만료되었거나 서명이 일치하지 않으면 에러를 던집니다.

그래서 try-catch로 감싸서 사용하는 것이 좋습니다. "여기서 정말 중요한 게 있어." 박시니어 씨가 강조했습니다.

"비밀 키는 절대로 코드에 하드코딩하면 안 돼. 환경 변수로 관리해야 해.

키가 노출되면 누구나 유효한 토큰을 만들 수 있거든." 실무에서는 보통 로그인 API에서 JWT를 생성하고, 인증이 필요한 모든 API에서 미들웨어를 통해 검증합니다. Express.js라면 미들웨어 함수를 만들어 라우터 앞에 배치하는 방식을 많이 사용합니다.

김개발 씨가 질문했습니다. "그러면 매 요청마다 토큰을 검증하는 건가요?

성능에 문제가 없을까요?" 박시니어 씨가 웃으며 답했습니다. "JWT의 장점이 바로 그거야.

검증에 데이터베이스 조회가 필요 없어. 비밀 키만 있으면 서버 메모리에서 바로 검증할 수 있거든.

그래서 세션 방식보다 확장성이 좋아."

실전 팁

💡 - 비밀 키는 반드시 환경 변수로 관리하세요

• 검증 실패 시 구체적인 에러 메시지를 클라이언트에 노출하지 마세요

---

3. Access_Token과_Refresh_Token

일주일 후, 김개발 씨는 이상한 버그 리포트를 받았습니다. "로그인했는데 1시간 지나면 자동으로 로그아웃돼요." 사용자 불만이었습니다.

토큰 만료 시간을 늘리면 될 것 같은데, 박시니어 씨는 고개를 저었습니다. "그건 보안상 위험해."

Access Token은 실제 인증에 사용하는 짧은 수명의 토큰이고, Refresh Token은 Access Token을 재발급받기 위한 긴 수명의 토큰입니다. 마치 출입증과 재발급 카드의 관계와 같습니다.

출입증이 만료되면 재발급 카드로 새 출입증을 받는 것처럼, 두 토큰을 함께 사용하면 보안과 편의성을 모두 잡을 수 있습니다.

다음 코드를 살펴봅시다.

// Access Token: 짧은 수명 (15분)
function generateAccessToken(user) {
  return jwt.sign(
    { sub: user.id, type: 'access' },
    process.env.ACCESS_SECRET,
    { expiresIn: '15m' }
  );
}

// Refresh Token: 긴 수명 (7일)
function generateRefreshToken(user) {
  return jwt.sign(
    { sub: user.id, type: 'refresh' },
    process.env.REFRESH_SECRET,
    { expiresIn: '7d' }
  );
}

// 로그인 시 두 토큰 모두 발급
function login(user) {
  return {
    accessToken: generateAccessToken(user),
    refreshToken: generateRefreshToken(user)
  };
}

김개발 씨는 고민에 빠졌습니다. 토큰 만료 시간이 짧으면 사용자가 불편하고, 길면 보안에 취약합니다.

어떻게 해야 두 마리 토끼를 잡을 수 있을까요? 박시니어 씨가 해결책을 제시했습니다.

"Access Token과 Refresh Token, 두 종류의 토큰을 사용하는 거야." 이 개념을 이해하려면 회사 출입 시스템을 생각해보면 됩니다. 회사에는 매일 사용하는 출입증이 있습니다.

보안을 위해 이 출입증은 한 달마다 갱신해야 합니다. 하지만 매번 보안팀에 가서 신청서를 작성하기는 번거롭습니다.

그래서 "재발급 카드"를 따로 줍니다. 재발급 카드만 있으면 보안팀 방문 없이 자동 발급기에서 새 출입증을 받을 수 있습니다.

Access Token은 바로 이 출입증입니다. 짧은 수명(보통 15분에서 1시간)을 가지며, 실제 API 요청에 사용됩니다.

수명이 짧기 때문에 탈취되더라도 피해를 최소화할 수 있습니다. Refresh Token은 재발급 카드입니다.

긴 수명(보통 7일에서 30일)을 가지며, Access Token이 만료되었을 때 새로운 Access Token을 발급받는 데만 사용됩니다. 이 토큰은 더 안전한 곳에 보관해야 합니다.

두 토큰은 서로 다른 비밀 키로 서명하는 것이 좋습니다. 만약 Access Token의 비밀 키가 노출되더라도, Refresh Token은 영향받지 않기 때문입니다.

김개발 씨가 질문했습니다. "그러면 Refresh Token이 탈취되면 어떡하죠?

그건 수명이 긴데요." 좋은 질문입니다. Refresh Token이 탈취되면 공격자가 계속 새로운 Access Token을 발급받을 수 있습니다.

이를 방지하기 위해 몇 가지 추가 보안 조치를 취합니다. 첫째, Refresh Token을 데이터베이스에 저장하고 관리합니다.

이렇게 하면 특정 토큰을 무효화할 수 있습니다. 둘째, Refresh Token 사용 시 새로운 Refresh Token도 함께 발급합니다.

이를 Refresh Token Rotation이라고 합니다. 셋째, 비정상적인 사용 패턴(다른 IP, 다른 기기)이 감지되면 모든 토큰을 무효화합니다.

박시니어 씨가 마무리했습니다. "실무에서는 이 두 토큰 체계가 거의 표준이야.

처음엔 복잡해 보이지만, 한번 구현해두면 보안과 사용자 경험 모두를 잡을 수 있어."

실전 팁

💡 - Access Token과 Refresh Token은 서로 다른 비밀 키를 사용하세요

• Refresh Token은 데이터베이스에서 관리하여 필요시 무효화할 수 있게 하세요

---

4. 토큰_저장_위치

다음 과제는 클라이언트에서 토큰을 어디에 저장할지 결정하는 것이었습니다. 김개발 씨가 구글링해보니 localStorage, sessionStorage, Cookie 세 가지 선택지가 있었습니다.

그런데 각각 장단점이 달라서 어떤 걸 선택해야 할지 도무지 감이 잡히지 않았습니다.

토큰 저장 위치는 크게 localStorage와 Cookie 두 가지로 나뉩니다. localStorage는 JavaScript로 접근하기 쉽지만 XSS 공격에 취약합니다.

Cookie는 HttpOnly 옵션으로 JavaScript 접근을 차단할 수 있지만 CSRF 공격에 주의해야 합니다. 각각의 특성을 이해하고 서비스에 맞는 방식을 선택해야 합니다.

다음 코드를 살펴봅시다.

// 방법 1: localStorage 사용 (XSS에 취약)
localStorage.setItem('accessToken', token);
const token = localStorage.getItem('accessToken');

// 방법 2: HttpOnly Cookie 사용 (서버에서 설정)
// Express.js 서버 코드
res.cookie('accessToken', token, {
  httpOnly: true,     // JavaScript 접근 불가
  secure: true,       // HTTPS에서만 전송
  sameSite: 'strict', // CSRF 방지
  maxAge: 15 * 60 * 1000 // 15분
});

// 방법 3: 메모리 + HttpOnly Cookie 조합 (권장)
// Access Token: 메모리(변수)에 저장
// Refresh Token: HttpOnly Cookie에 저장

김개발 씨는 프론트엔드 개발자 이프론트 씨와 함께 토큰 저장 방식을 논의하고 있었습니다. 이프론트 씨가 먼저 의견을 냈습니다.

"localStorage가 편하지 않아요? 그냥 저장하고 꺼내 쓰면 되잖아요." 박시니어 씨가 끼어들었습니다.

"편하긴 한데, 보안 관점에서 생각해봐야 해." localStorage는 브라우저에서 데이터를 저장하는 가장 간단한 방법입니다. 키-값 형태로 저장하고, 언제든 JavaScript로 읽을 수 있습니다.

탭을 닫아도 데이터가 유지되어 편리합니다. 하지만 여기에 큰 문제가 있습니다.

JavaScript로 접근할 수 있다는 것은, XSS(Cross-Site Scripting) 공격에 취약하다는 의미입니다. 악성 스크립트가 페이지에 주입되면, 그 스크립트가 localStorage의 토큰을 훔쳐갈 수 있습니다.

그렇다면 Cookie는 어떨까요? Cookie는 HttpOnly 옵션을 설정하면 JavaScript에서 접근할 수 없습니다.

오직 브라우저가 HTTP 요청을 보낼 때만 자동으로 포함됩니다. XSS 공격으로부터 토큰을 보호할 수 있습니다.

하지만 Cookie도 완벽하지 않습니다. CSRF(Cross-Site Request Forgery) 공격에 주의해야 합니다.

악성 사이트에서 우리 서버로 요청을 보내면, 브라우저가 자동으로 Cookie를 포함시킵니다. 이를 방지하려면 SameSite 옵션을 설정하고, CSRF 토큰을 추가로 사용해야 합니다.

"그러면 뭘 써야 하는 거예요?" 김개발 씨가 물었습니다. 박시니어 씨가 추천 방식을 설명했습니다.

"요즘 많이 쓰는 방법은 조합이야. Access Token은 메모리(JavaScript 변수)에 저장하고, Refresh Token은 HttpOnly Cookie에 저장하는 거지." 이 방식의 장점은 명확합니다.

Access Token이 메모리에만 있으므로 XSS로 탈취하기 어렵습니다. 새로고침하면 사라지지만, Refresh Token으로 다시 발급받으면 됩니다.

Refresh Token은 HttpOnly Cookie에 있어 JavaScript로 접근 불가능합니다. 물론 이 방식도 완벽하지는 않습니다.

새로고침할 때마다 Refresh Token으로 Access Token을 다시 발급받아야 합니다. 하지만 보안과 사용자 경험 사이의 좋은 균형점입니다.

이프론트 씨가 고개를 끄덕였습니다. "복잡하긴 한데, 보안을 생각하면 그 정도 수고는 감수해야겠네요."

실전 팁

💡 - 보안이 중요한 서비스라면 HttpOnly Cookie를 사용하세요

• localStorage를 사용할 경우 XSS 방어에 더욱 신경 써야 합니다

---

5. 토큰_갱신_전략

며칠 후, QA팀에서 또 다른 이슈가 올라왔습니다. "작업 중에 갑자기 로그인이 풀려요." 원인을 분석해보니 Access Token이 만료되는 시점에 요청이 실패하고 있었습니다.

사용자가 열심히 글을 쓰다가 저장 버튼을 누르면 로그아웃되는 최악의 경험이었습니다.

토큰 갱신 전략은 Access Token 만료 시 사용자 경험을 해치지 않으면서 새 토큰을 발급받는 방법입니다. 크게 사전 갱신 방식과 실패 후 재시도 방식이 있습니다.

마치 휴대폰 배터리를 20%에서 미리 충전하느냐, 방전된 후 충전하느냐의 차이와 같습니다. 대부분의 서비스는 두 방식을 조합하여 사용합니다.

다음 코드를 살펴봅시다.

// Axios 인터셉터를 활용한 토큰 갱신
let isRefreshing = false;
let failedQueue = [];

axios.interceptors.response.use(
  response => response,
  async error => {
    const originalRequest = error.config;

    // 401 에러이고 재시도하지 않은 요청인 경우
    if (error.response?.status === 401 && !originalRequest._retry) {
      originalRequest._retry = true;

      try {
        // Refresh Token으로 새 Access Token 발급
        const { data } = await axios.post('/api/auth/refresh');
        const newToken = data.accessToken;

        // 새 토큰으로 원래 요청 재시도
        originalRequest.headers.Authorization = `Bearer ${newToken}`;
        return axios(originalRequest);
      } catch (refreshError) {
        // 갱신 실패 시 로그아웃 처리
        window.location.href = '/login';
      }
    }
    return Promise.reject(error);
  }
);

김개발 씨는 사용자 경험 문제를 해결해야 했습니다. Access Token이 만료되는 순간에도 사용자가 불편함을 느끼지 않도록 해야 합니다.

박시니어 씨가 화이트보드에 두 가지 전략을 그렸습니다. 첫 번째는 사전 갱신 방식입니다.

토큰 만료 시간이 얼마 남지 않았을 때 미리 새 토큰을 발급받습니다. 예를 들어 토큰이 15분짜리인데, 2분 남았을 때 갱신하는 것입니다.

휴대폰 배터리가 20% 남았을 때 미리 충전하는 것과 같습니다. 이 방식의 장점은 요청이 실패하는 일이 거의 없다는 것입니다.

하지만 타이머를 관리해야 하고, 사용자가 페이지를 떠났다가 돌아오면 타이머가 초기화되는 문제가 있습니다. 두 번째는 실패 후 재시도 방식입니다.

요청이 401 에러(인증 실패)로 실패하면, 그때 토큰을 갱신하고 원래 요청을 다시 보냅니다. 배터리가 방전된 후 충전하는 것과 같습니다.

이 방식은 구현이 단순합니다. Axios 인터셉터 하나만 설정하면 됩니다.

하지만 첫 번째 요청은 실패하기 때문에, 사용자가 잠깐 지연을 느낄 수 있습니다. "실무에서는 어떤 걸 많이 써요?" 김개발 씨가 물었습니다.

박시니어 씨가 답했습니다. "보통 두 가지를 조합해.

기본적으로 실패 후 재시도 방식을 쓰되, 중요한 작업 전에는 토큰 상태를 미리 확인하는 거야." 코드를 살펴보면, Axios의 response 인터셉터를 사용합니다. 모든 응답을 가로채서, 401 에러인 경우에만 토큰 갱신 로직을 실행합니다.

여기서 중요한 것은 동시 요청 처리입니다. 만약 여러 요청이 동시에 401을 받으면, 각각 토큰 갱신을 시도합니다.

이를 방지하기 위해 isRefreshing 플래그와 failedQueue를 사용합니다. 첫 번째 요청만 갱신을 시도하고, 나머지는 대기열에서 기다립니다.

갱신에 실패하면 사용자를 로그인 페이지로 보냅니다. Refresh Token마저 만료되었거나 무효화된 경우입니다.

이때 사용자에게 친절한 메시지를 보여주는 것이 좋습니다. 김개발 씨는 이 패턴을 적용했고, 더 이상 "갑자기 로그아웃됐어요" 같은 불만은 올라오지 않았습니다.

실전 팁

💡 - 동시에 여러 요청이 실패할 경우를 대비해 갱신 요청을 큐로 관리하세요

• 갱신 실패 시 사용자에게 명확한 안내 메시지를 보여주세요

---

6. JWT_보안_베스트_프랙티스

프로젝트 막바지, 보안팀에서 코드 리뷰를 요청해왔습니다. 보안 담당자가 김개발 씨의 인증 코드를 보더니 몇 가지를 지적했습니다.

"기본적인 것들은 잘 되어 있는데, 몇 가지 보완하면 더 안전해질 거예요."

JWT 보안은 단순히 토큰을 사용하는 것을 넘어, 여러 계층의 보안 조치를 적용해야 합니다. 비밀 키 관리, 토큰 만료 시간 설정, 페이로드 최소화, HTTPS 필수 사용, 토큰 블랙리스트 등 다양한 베스트 프랙티스가 있습니다.

이러한 조치들을 조합하면 안전한 인증 시스템을 구축할 수 있습니다.

다음 코드를 살펴봅시다.

// 1. 강력한 비밀 키 사용 (최소 256비트)
const SECRET_KEY = process.env.JWT_SECRET; // 환경 변수로 관리

// 2. 토큰 블랙리스트 (로그아웃 처리)
const tokenBlacklist = new Set();

async function logout(token) {
  const decoded = jwt.decode(token);
  // 토큰 만료 시간까지 블랙리스트에 보관
  tokenBlacklist.add(token);
  await saveToRedis(token, decoded.exp);
}

// 3. 검증 시 블랙리스트 확인
function verifyToken(token) {
  if (tokenBlacklist.has(token)) {
    throw new Error('Token has been revoked');
  }
  return jwt.verify(token, SECRET_KEY, {
    algorithms: ['HS256'], // 알고리즘 명시적 지정
    issuer: 'my-app',      // 발급자 검증
    audience: 'my-users'   // 대상자 검증
  });
}

// 4. 페이로드 최소화
const payload = {
  sub: user.id,  // 최소한의 정보만 포함
  // 비밀번호, 주민번호 등 민감정보 절대 포함 금지
};

보안 담당자 최보안 씨가 화면을 가리키며 설명을 시작했습니다. "JWT는 편리하지만, 제대로 사용하지 않으면 보안 구멍이 생겨요." 첫 번째로 짚은 것은 비밀 키 관리였습니다.

비밀 키는 최소 256비트(32바이트) 이상의 무작위 문자열이어야 합니다. "password123" 같은 약한 키는 절대 안 됩니다.

또한 코드에 직접 작성하지 말고, 환경 변수로 관리해야 합니다. 키가 노출되면 공격자가 유효한 토큰을 무한정 만들 수 있습니다.

두 번째는 알고리즘 명시입니다. 과거에 "none" 알고리즘 취약점이 있었습니다.

검증 시 알고리즘을 명시하지 않으면, 공격자가 "alg": "none"으로 설정한 토큰을 보내 인증을 우회할 수 있었습니다. 반드시 허용할 알고리즘을 명시적으로 지정해야 합니다.

세 번째는 토큰 블랙리스트입니다. JWT는 상태가 없어서 한번 발급하면 만료 전까지 유효합니다.

하지만 사용자가 로그아웃하거나 비밀번호를 변경했을 때 기존 토큰을 무효화해야 합니다. 이를 위해 Redis 같은 인메모리 저장소에 블랙리스트를 관리합니다.

네 번째는 페이로드 최소화입니다. 토큰에는 꼭 필요한 정보만 담아야 합니다.

사용자 ID 정도면 충분합니다. 이름, 이메일, 권한 등은 필요할 때 데이터베이스에서 조회하세요.

페이로드가 크면 네트워크 비용도 늘어납니다. 다섯 번째는 HTTPS 필수입니다.

HTTP로 통신하면 토큰이 네트워크에서 탈취될 수 있습니다. 프로덕션 환경에서는 반드시 HTTPS를 사용해야 합니다.

Cookie를 사용한다면 secure 옵션도 함께 설정하세요. 여섯 번째는 issuer와 audience 검증입니다.

토큰을 검증할 때 발급자(iss)와 대상자(aud)를 확인하면, 다른 서비스에서 발급한 토큰이 우리 서비스에서 사용되는 것을 방지할 수 있습니다. 최보안 씨가 마무리했습니다.

"보안은 한 가지만 잘한다고 되는 게 아니에요. 여러 겹의 방어막을 쌓아야 해요.

마치 양파 껍질처럼요." 김개발 씨는 지적받은 내용을 모두 반영했습니다. 비밀 키를 환경 변수로 옮기고, 알고리즘을 명시하고, Redis 기반 블랙리스트를 구현했습니다.

이제 인증 시스템이 한층 더 견고해졌습니다. 박시니어 씨가 다가와 어깨를 두드렸습니다.

"수고했어. 이제 JWT 인증은 완벽하게 이해한 것 같네." 김개발 씨는 뿌듯한 미소를 지었습니다.

입사 첫 주에 암호 같던 문자열이 이제는 친숙한 친구가 되었습니다.

실전 팁

💡 - 비밀 키는 최소 256비트 이상의 무작위 문자열을 사용하세요

• 프로덕션에서는 반드시 HTTPS를 사용하고, 토큰 블랙리스트를 구현하세요
• 정기적으로 비밀 키를 교체하는 키 로테이션 정책을 수립하세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!