[데브코스] 인증/인가 시스템 이해: 쿠키, 세션, JWT와 보안 포인트

웹 어플리케이션을 구축하다보면, 사용자 인증과 권한 인가에 대한 개념을 반드시 마주하게 되고, 이를 실제로 구현하기 위해서 쿠키, 세션, JWT와 같은 기술을 활용하게 된다.

이번 강의에서는 인증 인가의 개념과 쿠키, 세션, JWT 각각의 방식이 어떻게 작동하는지, 어떤 장단점을 가지는지 전체적으로 알아보았다.

---

🔐인증/인가

인증

Authentication, 사용자가 "누구인지" 확인하는 과정

인증은 시스템에 이미 가입된 사용자인지를 판별하는 절차이다. 흔히 로그인 과정을 통해 수행되며, 사용자가 제공하는 자격증명(아이디, 비밀번호, 인증 토큰, OTP 등)을 기반으로 해당 사용자가 등록된 사용자임을 확인한다.

 

예시:

• 사용자가 이메일과 비밀번호를 입력해 로그인
• OAuth를 통해 구글 계정으로 로그인
• API 요청에 포함된 JWT 토큰을 파싱하여 유효한 사용자임을 검증

인증은 본인 확인 절차이며, 주로 로그인 또는 API 호출 시 Access Token 등으로 수행된다. 인증에 성공하면, 사용자에 대한 식별 정보(사용자 ID, 역할 등)을 시스템이 인식하게 된다.

 

인가

Authorization, 인증된 사용자가 특정 자원에 접근할 수 있는 권한이 있는지를 판별하는 과정

인가는 인증이 완료된 사용자가 요청한 자원에 접근할 권한이 있는지를 판단한다. 예를 들어, 일반 사용자와 관리자가 접근할 수 있는 자원이 다른 경우, 인가는 이 권한 구분을 제어하는 역할을 한다.

예시:

• 관리자인 경우에만 유저 목록 API 호출 가능
• 사용자가 본인의 게시글만 수정할 수 있음
• 특정 기능(결제, 삭제 등)은 특정 역할을 가진 사용자만 접근 가능

인가는 권한 제어 절차이며, 인증 이후에 수행된다. 일반적으로 Role, Permission, Access Control List(ACL) 등을 기준으로 판단한다.

인증 실패 -> 요청 자체 거절(401 Unauthorized)
인가 실패 -> 접근 거절(403 Forbidden)

---

🍪쿠키

웹 서버가 클라이언트(브라우저)에게 저장하라고 전달하는 작은 데이터 조각

브라우저는 쿠키를 저장해두고, 동일 도메인에 다시 요청을 보낼 때 자동으로 해당 쿠키를 함께 전송한다.

 

쿠키의 동작 흐름

1. 서버->클라이언트 (Set-Cookie 헤더)
로그인 성공 시, 서버가 HTTP 응답 헤더에 Set-Cookie를 포함하여 쿠키를 설정한다.

HTTP/1.1 200 OK
Set-Cookie: sessionId=abc123; HttpOnly; Secure; Path=/; Max-Age=3600

 

2. 클라이언트 저장 및 자동 전송
브라우저가 쿠키를 저장하고, 이후 같은 도메인 요청 시 Cookie 헤더에 해당 쿠키를 자동으로 포함한다.

GET /profile HTTP/1.1
Host: example.com
Cookie: sessionId=abc123

 

3. 서버는 쿠키 정보를 읽어 요청 처리
서버는 Cookie 헤더를 통해 클라이언트를 식별하거나 인증 상태를 판단한다.

 

쿠키의 장단점

✅장점

• 클라이언트에 저장되어 서버 부하가 적음 (Stateless)
• HTTP 요청마다 자동 전송되어 인증 정보 전송 편리
• 도메인별로 저장되어 보안 정책 적용 가능

❌단점

• 쿠키 자체는 클라이언트 저장 -> 탈취 위험이 있다(XSS, MITM 공격)
• 저장 용량이 적다(4KB 내외)
• 민감 정보 저장 불가(암호화 필요)
• CSRF 공격 취약(추가 대책 필요)

⭐쿠키는 클라이언트 저장 특성상, 보안 취약점 보완을 위해 반드시 HttpOnly, Secure, SameSite 옵션을 적절히 설정해야 한다.

---

📦세션

서버 측에서 사용자 상태를 저장하는 방식

클라이언트는 오직 고유 세션 ID만 쿠키로 저장하고, 서버는 세션 ID를 키로 사용자 정보를 저장한다.

 

세션 동작 흐름

1. 클라이언트가 로그인 요청 전송
2. 서버가 로그인 성공 시 고유한 세션 ID 생성(UUID 등)
3. 서버는 세션 스토리지(메모리, Redis, DB 등)에 사용자 정보를 저장

{ sessionId: { userId: 123, roles: ['admin'] } }

4. 서버는 클라이언트에 Set-Cookie: sessinId=xyz 헤더 전송
5. 클라이언트는 쿠키에 sessionId 저장
6. 이후 모든 요청에 Cookie: sessionId=xyz 헤더 포함
7. 서버는 세션 ID로 저장된 사용자 상태를 조회 후 인증 및 인가 처리

 

세션의 장단점

✅장점

• 사용자 정보를 서버에 저장 -> 중요 데이터 노출 위험 적음
• 세션 관리 시 권한 변경, 로그아웃 처리 용이
• HttpOnly, Secure 쿠키 옵션으로 보안 강화 가능

❌단점

• 서버 메모리, 저장소 부담(대규모 사용자에 부적합)
• 서버가 상태를 유지해야 하므로, 완전 Stateless가 아님
• 부하 분산 환경에서 세션 동기화(세션 클러스터링 필요)

---

🪙JWT

Json Web Token, JSON 객체를 Base64URL로 인코딩하고, 비밀키로 서명하여 클라이언트에 전달하는 토큰

서버는 별도의 세션 저장 없이 토큰 검증만으로, 인증을 수행할 수 있다. JWT는 Stateless 인증 구현에 최적화된 방식으로, SPA, 모바일 API, 마이크로서비스에서 폭넓게 사용된다.

 

JWT 구조 및 암호화 알고리즘 종류

JWT는 Header, Payload, Verify Signature 3부분으로 나뉜다.

구분	설명	예시 (Base64URL 인코딩)
Header	토큰 타입과 서명 알고리즘 명시	{ "alg": "HS256", "typ": "JWT" }
Payload	실제 인증 정보(클레임) 포함	{ "userId": 123, "admin": true, "iat": 1234567890 }
Signature	Header + Payload를 비밀키로 서명한 값 (변조 방지)	HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

 

JWT의 서명 검증은 JWT가 중간에 탈취되거나 조작되었을때의 방어 메커니즘을 이해하는 데 필수적이다. 페이로드가 탈취되거나 변조되었더라도, JWT의 서명 검증 과정에서 보안이 작동한다. JWT는 발급 시, 서버가 헤더와 페이로드를 이어 붙인 문자열에 비밀 키를 사용해 서명을 생성한다. 이 서명은 클라이언트가 조작할 수 없으며, 토큰 자체에 포함되어 전달된다.

 

서버는 클라이언트로부터 전달받은 JWT를 검증할 때, 헤더와 페이로드를 똑같이 이어 붙여 서버에 저장된 비밀 키로 다시 서명을 생성한다. 그 후 새로 생성한 서명과 클라이언트가 보낸 JWT의 서명을 비교한다. 만약 페이로드가 조작되었다면, 새로운 서명과 기존 서명이 일치하지 않기 때문에 서버는 이 토큰을 유효하지 않은 것으로 판단하고 요청을 거부한다.

 

즉, JWT는 페이로드가 외부에 노출되더라도 서명 검증을 통해 중간에서 위.변조된 토큰을 식별하고 차단할 수 있다.

 

주요 서명 알고리즘 종류

알고리즘	설명	특징
HS256	HMAC with SHA-256	대칭키 서명, 키 관리가 간단하지만 키 노출시 위험
RS256	RSA with SHA-256	비대칭키 서명, 공개키/개인키 쌍 사용, 보안 우수
ES256	ECDSA with P-256 curve and SHA-256	비대칭키 서명, 키 길이 짧고 효율적

HS256은 대다수 간단한 API에서 사용하지만, 보안 요구가 높은 경우 RS256같은 비대칭키 알고리즘 사용을 권장한다.

 

JWT 인증 흐름 상세

JWT를 사용할 때는 보통 Access Token과 Refresh Token 두 가지 토큰을 함께 운용한다.

토큰 종류	역할	유효 기간 예시	저장 위치	보안 고려사항
Access Token	API 요청 시 인증 정보로 사용, 짧은 유효 기간 (ex: 15분 ~ 1시간)	15분 ~ 1시간	클라이언트 메모리 또는 쿠키	탈취 시 위험, 짧은 수명으로 피해 제한
Refresh Token	Access Token 재발급 요청에 사용, 긴 유효 기간 (ex: 7일 ~ 30일)	며칠 ~ 몇 주	HttpOnly, Secure 쿠키 권장	서버에서 저장(권장), 탈취 시 위험 큼

 

1. 로그인 성공->토큰 발급

• 서버는 사용자 인증 후, Access Token과 Refresh Token을 모두 생성한다.
• Access Token은 API 접근을 위해 클라이언트에 바로 전달된다.
• Refresh Token은 보안 상 HttpOnly 쿠키 등 클라이언트 스크립트 접근이 제한된 저장소에 저장하는 것이 좋다.

2. API 요청 시 Access Token 사용

• 클라이언트는 매 API 요청에 Authorization: Bearer <Access Token> 헤더를 포함해 보낸다.
• 서버는 Access Token 서명 및 만료 시간(exp)을 검사해 유효하면 요청을 처리한다.

3. Access Token 만료->Refresh Token으로 재발급 요청

• Access Token이 만료되면 클라이언트는 Refresh Token을 사용해 서버에 새로운 Access Token 발급 요청을 한다.
• 서버는 Refresh Token을 검증하고, 유효하다면 새 Access Token을 발급해 클라이언트에 전달한다.
• 만약 Refresh Token도 만료되었거나 유효하지 않으면 클라이언트는 다시 로그인을 요구받는다.

4. 로그아웃 처리

• 클라이언트는 Access Token과 Refresh Token을 모두 삭제한다.
• 서버에서는 (Refresh Token을 저장하는 경우) 해당 토큰을 무효화 처리한다.
• Access Token은 짧은 유효 기간으로 자연 만료되므로 별도 서버 저장/삭제가 없을 수 있다.

 

JWT 토큰 유효 기간 관리 팁

• Access Token은 매우 짧게(10~60분) 설정 해 탈취 시 피해를 최소화한다.
• Refresh Token은 상대적으로 길게(일주일~한달) 설정하되, 재발급 로직과 탈취 감지가 필요하다.
• Refresh Token은 서버에 저장하거나 블랙리스트를 운영해 유효성 관리를 권장한다.
• 재발급 시 Refresh Token 자체도 갱신하는 전략(rolling tokens)으로 보안 강화가 가능하다.

JWT 토큰 예시 Payload

{
  "userId": 123,
  "roles": ["user"],
  "iat": 1650123456,            // 발급 시각 (Issued At)
  "exp": 1650127056             // 만료 시각 (Expiration Time) - 1시간 후
}

 

토큰 저장 위치별 보안 모범 사례

토큰,,,어디에 저장하는게 제일 좋을까 궁금하여 찾아보았다.

저장 위치	설명	장점	단점 / 위험요소	보안 권장 사항
LocalStorage	브라우저의 localStorage에 저장	- 간편하고 사용하기 쉬움 - SPA에서 자주 사용됨	- XSS 공격에 취약 (스크립트로 탈취 가능)	- 민감한 토큰 저장 지양 - XSS 방어 강화 (CSP, 입력 검증 등)
SessionStorage	브라우저의 sessionStorage에 저장	- 탭 별 분리 가능 - 브라우저 종료 시 삭제됨	- XSS 공격에 취약	- XSS 방어 강화 필요 - 민감 정보 저장 최소화
HttpOnly 쿠키	서버가 Set-Cookie 헤더로 발행하는 HttpOnly 쿠키	- JavaScript 접근 불가 → XSS 공격 방어 가능 - 자동으로 요청에 포함	- CSRF 공격에 취약 (자동 전송 특성)	- CSRF 토큰 사용 또는 SameSite 속성 설정 - Secure, SameSite=strict 권장
메모리 (JS 변수)	JavaScript 실행 중 메모리에만 임시 저장	- 탈취 위험 적음 - 브라우저 닫으면 소멸	- 새로고침 시 소실 - SPA에서 상태 유지 어려움	- 짧은 유효기간 Access Token에 적합 - 리프레시 시 별도 저장소 필요

Access Token을 localStorage나 sessionStorage에 저장하면, 자바스크립트를 통해 접근이 가능하다. 이 경우 사이트에 XSS 취약점이 존재하면 악성 스크립트가 토큰을 탈취할 수 있다.

• 토큰을 자바스크립트로 접근 가능한 저장소에 저장하지 않는 것이 좋다.
• Access Token은 메모리에만 임시로 저장하고, 페이지 리로드 시 사라지도록 관리한다.

// 로그인 성공 후 Access Token 저장
let accessToken: string | null = null;

function login() {
  api.post('/login', { email, password }).then(res => {
    accessToken = res.data.accessToken; // 메모리에만 저장
  });
}

 

Refesh Token은 민감한 정보를 담고 잇으며, 유효 시간이 길기 때문에 탈취 시 피해가 크다. 특히 브라우저의 localStorage나 sessionStorage에 저장하면 XSS로 탈취될 수 있다. 반대로, 쿠키에 저장하면 자동으로 요청과 함께 전송되므로 CSRF에 노출될 수 있다. 따라서 Refresh Token은 다음 옵션을 사용하여 쿠키에 저장하는 것이 보안 모범 사례이다.

• HttpOnly: 자바스크립트에서 접근 불가능-XSS 방어
• Secure: HTTPS에서만 전송-중간자 공격 방어
• SameSite=Strict 또는 Lax: 다른 출처의 요청에 자동 전송되지 않도록 제한-CSRF 방어

Set-Cookie: refreshToken=abc.def.ghi; 
             HttpOnly; 
             Secure; 
             SameSite=Strict;
             Path=/refresh;
             Max-Age=604800;

 

보안 취약점 정리

종류	설명	Access Token 영향	Refresh Token 영향
XSS	악성 스크립트를 통해 브라우저 자원 탈취	localStorage 저장 시 위험	쿠키에 HttpOnly 없으면 위험
CSRF	사용자의 인증 상태를 악용한 요청 위조	거의 없음 (헤더 수동 설정 필요)	자동 쿠키 전송 시 위험 (SameSite로 방지 가능)

 

 

저장 위치 선택 기준 요약

종류	저장 위치	이유/목적
Access Token	메모리(RAM)	XSS 공격 방지. 새로고침 시 자동 초기화.
Refresh Token	HttpOnly 쿠키	XSS 방지 + Secure, SameSite로 CSRF 방지 가능

💡Access Token은 언제든 재발급 가능한 소모품이므로, 보안보다는 민첩성과 임시성 중심으로 다루고, Refresh Token은 재발급의 핵심 열쇠이므로 최우선 보안 대상으로 다룬다!

 

JWT 실습 예제

JWT 실습을 위해서 먼저 jsonwebtoken 패키지를 설치해준다.

var jwt = require("jsonwebtoken"); //jwt 모듈 소환

//서명=토큰 발행
var token = jwt.sign({ foo: "bar" }, "shhhhhh");

//token 생성 시, jwt 서명을 했다! (페이로드, 나만의 암호키) + SHA256
console.log(token);

//검증
//만약에 검증에 성공하면, 페이로드 값 확인
var decoded = jwt.verify(token, "shhhhhh");
console.log(decoded);

 

---

🗝️환경 변수 관리: .env 파일 개념 및 활용

환경 변수는 중요한 비밀 정보를 코드와 분리해 안전하게 관리하기 위한 방법

• .env 파일에 민감 정보를 저장한다(DB 접속, JWT 비밀 키 등)
• 일반적으로, 프로젝트 루트에 위치한다.

PORT=3000
DB_HOST=localhost
DB_USER=admin
DB_PASS=secret
JWT_SECRET=superSecretKey123!

• .gitignore에 추가하여 Git 노출을 방지해야 한다.
• dotenv 패키지로 로드한다.

require('dotenv').config();

const jwtSecret = process.env.JWT_SECRET;

---

Access Token이랑 Refresh Token은 프로젝트 하면서 몇 번 써봤지만, 사실 “보안적으로 이게 맞나?” 고민해본 적은 거의 없었다. JWT도 그냥 다들 쓰니까 나도 따라 쓰는 느낌이었고..

 

근데 이번에 공부하면서 쿠키 vs 세션, JWT 구조, 서명의 역할 같은 걸 확실히 알게 되었고, 이제는 단순히 “돌아만 가면 됐다”가 아니라 “이게 진짜 안전한 방식인가?”를 고민하게 되는 것 같다. 토큰을 어디에 저장하느냐에 따라 어떤 공격을 막을 수 있고, 어떤 위험이 생길 수 있는지를 알고 나니까 이전엔 어떤 방식으로 구현을 했었나, 잠시 돌아보고 반성하게 된 것 같다.

 

앞으로는 인증/인가 구현할 때도 그냥 익숙한 방식 말고, 상황에 맞는 방식이 뭔지, 보안적으로도 납득이 가는 구조인지 먼저 생각해봐야겠다.