세션 기반 인증과 토큰 기반 인증

왜 인증 방식이 필요한가

HTTP는 상태가 없다(stateless). 요청마다 "이 사람이 아까 로그인한 그 사람"이라는 증거를 다시 보내야 한다. 그 증거를 어디에 저장하고 무엇으로 검증하느냐에 따라 세션 방식과 토큰 방식이 갈린다.

쿠키 자체의 동작(속성, 수명, 퍼스트·서드파티)은 쿠키와 세션에 있다. 이 노트는 서버 쪽에서 두 방식을 고르는 기준을 다룬다.

신원 관리 방식의 계보

로그인은 세 단계로 나뉜다. 식별(identification) 은 "나는 누구다"라고 밝히는 것, 인증(authentication) 은 그 주장이 맞는지 확인하는 것, 인가(authorization) 는 확인된 사용자에게 권한을 주는 것이다. 아래 방식들은 대부분 앞의 둘을 다루고, OAuth 2.0만 인가 위임을 다룬다. 단순한 것부터 차례로 쌓였다.

세션 기반 인증

sequenceDiagram
  participant B as 브라우저
  participant S as 서버
  participant R as 세션 저장소
  B->>S: 1. POST /login (아이디·비밀번호)
  S->>R: 2. 검증 성공 → { sessionId: userId, 만료 } 저장
  S-->>B: 3. Set-Cookie: sid=abc123#59; HttpOnly#59; Secure#59; SameSite=Lax
  B->>S: 4. 이후 요청: Cookie: sid=abc123 (브라우저가 자동 첨부)
  S->>R: 5. 저장소에서 sid 조회
  Note over S: 사용자 확인
  S-->>B: 응답

세션은 HTTP의 무상태성과 모순되지 않는다. 무상태는 HTTP 프로토콜이 요청 사이를 기억하지 않는다는 뜻이고, 세션은 그 위의 응용이 상태를 따로 저장하는 것이다. 요청은 여전히 세션 ID라는 필요한 정보를 매번 담고 오며, 서버는 그 ID로 저장소를 찾아 처리한다. 대가는 무상태가 주던 장점 일부를 다시 내주는 것이다. 웹 서버 자체는 무상태로 두고 상태를 공용 세션 저장소 한 곳에 모으면, 서버를 늘리는 자유는 지키고 저장소의 가용성만 따로 책임지면 된다. 토큰 방식은 상태를 클라이언트 쪽 토큰에 넣어 저장소마저 없앤 것이지만, 즉시 무효화를 위해 결국 일부 상태(차단 목록, 리프레시 토큰)를 다시 둔다.

• 세션 ID는 무작위 문자열이라 유출돼도 개인정보는 드러나지 않는다. 다만 탈취하면 그 사용자로 위장할 수 있다(세션 하이재킹).
• 로그인 직후 세션 ID를 새로 발급해 세션 고정(session fixation) 공격을 막는다.
• 사용자마다 저장소 항목이 생기므로 동시 접속자가 많으면 저장소가 부담이 된다.
• 세션 ID 대신 아이디·비밀번호를 쿠키에 담아 매번 보내는 방식은 쓰지 않는다. 저장소가 필요 없고 확장도 쉽지만, 요청마다 자격 증명이 오가므로 쿠키 하나만 새도 계정이 넘어간다. 세션은 이 문제를 「의미 없는 식별자」로 바꾼 것이다.

서버가 여러 대일 때

세션 저장소가 서버 메모리에 있으면(예: 톰캣의 기본 세션 관리자), 로드밸런서가 요청을 다른 서버로 보내는 순간 세션을 찾지 못한다.

토큰 기반 인증 (JWT)

JWT(JSON Web Token)는 header.payload.signature 세 부분을 .으로 이은 문자열이다.

Header와 Payload는 인코딩일 뿐이라 누구나 디코딩해 읽을 수 있다(jwt.io). 위변조를 막는 것은 Signature뿐이다. NestJS에서 Passport로 구현하는 방법은 NestJS JWT 인증과 Passport에 있다.

sequenceDiagram
  participant C as 클라이언트
  participant S as 서버
  C->>S: 1. POST /login
  Note over S: 2. 검증 성공 → Payload { sub: userId, exp } 에 비밀키로 서명
  S-->>C: Access Token 발급
  Note over C: 3. 토큰 보관
  C->>S: 4. 이후 요청: Authorization: Bearer #lt;token#gt;
  Note over S: 5. 서명 검증(HS256은 같은 비밀키, RS256·ES256은 공개키) + exp 확인
  S-->>C: 응답

서명은 Header와 Payload를 각각 Base64URL로 인코딩해 .으로 이은 문자열에 서명 알고리즘을 적용하고, 그 결과를 다시 Base64URL로 인코딩해 만든다.

signingInput = base64url(header) + "." + base64url(payload)
HS256:  signature = base64url( HMAC-SHA256(signingInput, 비밀키) )
RS256:  signature = base64url( RSA-PKCS1-v1_5-Sign(SHA-256(signingInput), 개인키) )
ES256:  signature = base64url( ECDSA-P256-Sign(SHA-256(signingInput), 개인키) )
JWT = signingInput + "." + signature

• 서명은 복호화하는 것이 아니라 검증하는 것이다. 서버는 받은 Header·Payload로 서명을 다시 계산해 일치하는지 본다. 비밀키가 없으면 Payload를 고친 뒤 맞는 서명을 만들 수 없다.
• Payload는 암호화되지 않는다. 비밀번호, 개인정보는 넣지 않는다.
• 서버가 상태를 갖지 않으므로 확장이 쉽고, 여러 서비스가 같은 공개키로 토큰을 검증할 수 있다.

클레임의 종류

검증하는 쪽은 서명뿐 아니라 exp·nbf·iss·aud까지 확인한다. 특히 aud를 보지 않으면 다른 서비스용으로 발급된 토큰이 내 서비스에서 통한다.

서명 방식: 대칭과 비대칭

검증할 알고리즘은 서버가 정해 둔다. 토큰 Header의 alg를 그대로 믿으면 alg: none(서명 없음)이나, RS256 공개키를 HS256 비밀키로 착각하게 만드는 알고리즘 혼동(algorithm confusion) 공격에 뚫린다. 라이브러리에 허용 알고리즘 목록을 명시한다.

PASETO: 설정 실수를 줄인 대안

PASETO(Platform-Agnostic Security Tokens) 는 JWT의 이런 함정을 없애려고 만든 토큰 형식이다. 알고리즘을 Header에서 고르게 하지 않고 버전(v4)과 용도(local·public)가 암호 방식을 고정한다.

토큰을 자체 시스템 안에서만 주고받는다면 PASETO가 실수 여지를 줄인다. OIDC처럼 외부 표준과 맞물리는 곳에서는 JWT를 쓰되 허용 알고리즘을 고정한다.

토큰 방식의 약점과 대책

토큰은 발급하면 만료될 때까지 유효하다. 탈취당하면 서버가 막을 방법이 없다는 것이 가장 큰 약점이다. 그래서 실무에서는 아래 대책을 조합한다.

리프레시 토큰을 서버에 두는 순간 "완전한 무상태"라는 JWT의 장점은 일부 사라진다. 대신 원할 때 강제로 로그아웃시킬 수 있다. 대부분의 서비스는 이 거래를 받아들인다.

탈취된 토큰의 종류에 따라 대응 순서가 다르다.

공통으로, 이상 징후(다른 국가·기기에서의 재발급, 짧은 시간의 대량 호출)를 감지해 재인증을 요구하는 장치가 탈취를 알아채는 계기가 된다.

토큰을 어디에 보관하나 (브라우저)

흔한 조합은 Access Token은 메모리, Refresh Token은 HttpOnly 쿠키다. 브라우저 전용 웹 앱이라면 처음부터 세션 쿠키를 쓰는 편이 단순하고 안전한 경우도 많다.

실제로 어디에 무엇이 저장됐는지(쿠키의 HttpOnly·Secure·SameSite, localStorage의 토큰)는 Chrome DevTools의 Application 패널에서 확인한다 → DevTools Application 패널.

정리

• 세션은 상태를 서버에, 토큰은 상태를 토큰 안에 둔다. 차이는 즉시 무효화와 확장성 사이의 거래다.
• 세션 ID는 의미 없는 열쇠라 유출돼도 정보는 안전하지만, 열쇠 자체를 훔치면 위장할 수 있다.
• JWT의 Payload는 누구나 읽는다. 서명은 위변조 검증용이지 암호화가 아니다.
• 검증 쪽은 허용 알고리즘을 고정하고 exp·iss·aud까지 확인한다. 설정 실수를 구조적으로 막고 싶으면 PASETO를 검토한다.
• 토큰을 쓰면 짧은 Access Token과 회전하는 Refresh Token을 함께 쓰고, 브라우저에서는 HttpOnly 쿠키를 우선 고려한다.
• 같은 도메인의 웹 앱만 있다면 세션, 모바일·다중 서비스 API라면 토큰이 기본 선택이다.

관련 노트: 쿠키와 세션, NestJS JWT 인증과 Passport, OAuth 2.0, 웹 보안: CSRF와 XSS, API 보안 체크리스트, Django User와 인증, 인증·인가 로직은 어디에 두나: 필터, 인터셉터, API 게이트웨이