jwt 구조 및 인증 절차 내용 정리jwt 구조 및 인증 절차 내용 정리

- 인증 (= 로그인)
Authentication
“나.. 여기 가입된 유저야..”
쇼핑몰 상품 볼 때? X
쇼핑몰 장바구니 담을 때 O
쇼핑몰 상품 구매
마이 페이지 ..
- 인가
Authorization
: 예시) 같은 사이트 내에 관리자 / 고객 에 따라 접근할 수 있는 페이지가 다르다.
관리자든 고객이든 인증을 통해서 사이트에 가입된 사용자라는 걸 증명하는 것
인증 후에, 이 친구 혹시 이 페이지 접근 권한 있나?
✨ 쿠키
- 로그인 -> 서버가 쿠키를 구워줘요.
- 사용자 ↔ 서버가 쿠키를 핑퐁
장점 : 서버가 저장 X => 서버 저장 공간,
Stateless => RESTful
단점 : 보안 취약
✨ 세션
- 로그인 -> 서버가 금고를 만들어서, 정보 저장 그 금고 번호를 줘요.
- 사용자 ↔ 서버가 번호만 가지고 대화
장점 : 보안 비교적 좋다
단점 : 서버가 저장 O => 서버 저장 공간, Stateless X
JWT : Json Web Token
✔ 개념
JSON 형태의 데이터를 안전하게 전송하기 위한 (웹에서 사용하는) 토큰
= 토큰을 가진 사용자가 “증명”을 하기 위한 수단
cf. 토큰 : (인증용) 입장 가능한 유저야 / (인가용) 관리자 권한 & 일반 유저 권한
✔ 장점
- 보안에 강하다! <= “암호화”가 되어 있다
- HTTP 특징을 잘 따랐다 = Stateless하다 <= “서버가 상태를 저장하지 않습니다.”
- 서버 부담 줄여줄 수 있고
cf. 토큰을 발행하는 서버를 따로 만들어줄 수도 있음!
✔ 구조 (feat. jwt.io)
헤더 : 토큰을 암호화하는 데 사용한 알고리즘, 토큰의 형태(jwt)
페이로드 : 사용자 정보 (이름, 주소, 핸드폰, … 비밀번호 X)
서명 : 만약 페이로드 값이 바뀌면, 이 서명값 통째로 바뀌기 때문에 우리는 JWT를 믿고 쓸 수 있다.

로그인 세션 – 인증과 인가
로그인 기능의 핵심은 인증(Authentication) 과 인가(Authorization) 이다.
- 인증: 사용자가 누구인지 확인하는 과정
- 인가: 인증된 사용자가 어떤 자원에 접근할 수 있는지 판단하는 과정
전통적인 웹 서비스에서는 보통 세션(Session) 을 이용해 이 두 가지를 처리한다.
로그인에 성공하면 서버는 세션을 생성하고, 클라이언트는 이후 요청마다 이 세션을 기반으로 인증 상태를 유지한다.
쿠키 / 세션 차이
세션과 쿠키는 함께 사용되지만 역할은 다르다.
- 쿠키(Cookie)
- 클라이언트(브라우저)에 저장
- 자동으로 요청에 포함됨
- 사용자 식별 정보(세션 ID 등)를 저장
- 세션(Session)
- 서버에 저장
- 실제 로그인 상태와 사용자 정보 관리
- 쿠키에 저장된 세션 ID로 세션을 조회
즉, 쿠키는 열쇠, 세션은 금고라고 이해하면 쉽다.
JWT 개념, 특징
JWT(JSON Web Token)는 토큰 기반 인증 방식이다.
세션처럼 서버에 로그인 상태를 저장하지 않고, 토큰 자체에 인증 정보를 담는다는 점이 가장 큰 차이점이다.
JWT의 주요 특징
- 서버가 상태를 저장하지 않는 Stateless 구조
- 확장성에 유리 (MSA, 모바일 앱)
- 토큰만 있으면 인증 가능
- 유효기간(exp)을 명확히 설정 가능
이 때문에 요즘은 세션보다 JWT를 더 많이 사용하는 추세다.
JWT 구조 (feat. jwt.io)
JWT는 점(.)으로 구분된 세 부분으로 구성된다.
Header.Payload.Signature
- Header: 토큰 타입, 해싱 알고리즘 정보
- Payload: 사용자 정보, 권한, 만료시간 등
- Signature: 토큰 위변조 방지를 위한 서명
jwt.io 사이트에 토큰을 붙여넣으면 구조를 바로 확인할 수 있어 디버깅에 매우 유용하다.
JWT 인증·인가 절차
JWT 기반 인증 흐름은 다음과 같다.
- 사용자가 로그인 요청
- 서버가 사용자 정보 검증
- JWT 토큰 발급
- 클라이언트가 토큰 저장
- 이후 요청 시 Authorization 헤더에 토큰 포함
- 서버가 토큰 검증 후 접근 허용
서버는 토큰의 유효성만 검사하고, 별도의 세션 저장소를 사용하지 않는다.
JWT 구현해보기
JWT 구현의 핵심 단계는 다음과 같다.
- 로그인 시 토큰 생성
- 비밀키(secret) 설정
- 토큰 검증 미들웨어 작성
- 보호된 API에 미들웨어 적용
이 구조만 잡아두면 대부분의 인증 로직은 공통으로 재사용할 수 있다.
.env 환경 변수 설정
보안상 중요한 정보는 코드에 직접 작성하면 안 된다.
- JWT secret key
- DB 비밀번호
- API Key
이런 값들은 .env 파일에 분리해서 관리한다.
JWT_SECRET=your-secret-key
JWT_EXPIRES_IN=1h
.env 파일은 반드시 .gitignore에 포함시키는 것도 잊지 말자.
YouTube에 JWT 적용해보기
JWT 개념을 이해하기 위해 유튜버 조회 API에 JWT를 적용해봤다.
- 로그인 성공 시 JWT 발급
- 인증이 필요한 API는 토큰 없으면 접근 불가
- 토큰 검증 실패 시 401/403 응답
단순한 예제지만, 실제 서비스 구조를 이해하는 데 큰 도움이 됐다.
Cookie, 403 에러
JWT를 쿠키에 저장했을 때 종종 403 Forbidden 에러를 마주친다.
주요 원인은 다음과 같다.
- 쿠키 옵션 문제 (httpOnly, sameSite)
- CORS 설정 오류
- 인증 미들웨어에서 토큰 미전달
특히 쿠키 기반 JWT + CORS 조합은 설정을 꼼꼼히 봐야 한다.
Cookie 설정 변경
JWT를 쿠키에 저장할 경우 다음 옵션들이 중요하다.
- httpOnly: JS에서 접근 불가 (보안 강화)
- secure: HTTPS에서만 전송
- sameSite: CSRF 방어
환경(로컬 / 배포)에 따라 옵션을 다르게 설정하는 것이 포인트다.
JWT 유효기간 설정
JWT는 유효기간 관리가 매우 중요하다.
- 너무 길면 보안 위험
- 너무 짧으면 사용자 불편
보통은
- Access Token: 짧게
- Refresh Token: 길게
이런 구조로 나누어 사용한다.
이번 실습에서는 Access Token 기준으로 유효기간 설정을 적용했다.
마무리
세션부터 JWT까지 직접 구현해보면서 느낀 점은,
인증 방식은 서비스 구조에 따라 선택해야 한다는 것이다.
- 단순한 서버: 세션도 충분
- 확장성, 모바일, MSA: JWT가 유리
이 글이 인증 방식을 이해하고 직접 구현하는 데 도움이 되었으면 좋겠다
다음 글에서는 Refresh Token이나 OAuth도 정리해볼 예정이다.
'pgms' 카테고리의 다른 글
| [6주차] - [9기] 타입스크립트로 함께하는 웹 풀 사이클 개발(React, Node.js) 10회차 - 28 (0) | 2026.02.12 |
|---|---|
| [6주차] - [9기] 타입스크립트로 함께하는 웹 풀 사이클 개발(React, Node.js) 10회차 - 27 (0) | 2026.02.11 |
| [6주차] - [9기] 타입스크립트로 함께하는 웹 풀 사이클 개발(React, Node.js) 10회차 - 25 (0) | 2026.02.10 |
| [5주차] - [9기] 타입스크립트로 함께하는 웹 풀 사이클 개발(React, Node.js) 10회차 - 24 (0) | 2026.02.06 |
| [5주차] - [9기] 타입스크립트로 함께하는 웹 풀 사이클 개발(React, Node.js) 10회차 - 23 (0) | 2026.02.04 |