코딩/sparta TIL

TIL 31 - 2 : Token, JWT, Filter

americanoallday 2025. 3. 31. 19:43

Token

Web Application이나 API에서 인증(Authentication)과 인가(Authorization) 과정에서 사용되며 사용자 또는 시스템의 신원과 권한을 증명하고 요청의 유효성을 검증하는 데 사용되는 디지털 문자열이다.

 

Token을 사용하는 이유

  1. Token은 서버가 아닌 클라이언트에 저장되어 서버의 부담을 덜 수 있다.
  2. Cookie는 웹 브라우저에만 존재하여 모바일 앱 등의 다양한 클라이언트에서 인증을 처리할 수 없다.
  3. Token 방식은 Stateless를 기반으로 하여 확장성이 뛰어나다.
  4. 인증된 사용자임을 확인하기 위한 고유한 서명을 포함하여 위조된 요청인지 확인할 수 있다.

 

Token 동작순서

  • Token 생성 시 사용자의 고유한 정보를 포함한다.
  • 데이터베이스에 접근하지 않고 Token의 유효성만 검증한다.

Token의 단점

  1. Cookie/Session 방식보다 Token 자체의 데이터 용량이 많다.
    • 요청이 많아지면 그만큼 트래픽이 증가한다.
  2. Payload(전송되는 데이터)는 암호화되지 않아서 중요한 데이터를 담을 수 없다.
  3. Token을 탈취당하면 대처하기 어려워 만료 시간(30분)을 설정한다.

JWT(JSON Web Token)

인증에 필요한 정보들을 암호화시킨 JSON 형태의 Token을 의미한다. JSON 데이터 포맷을 사용하여 정보를 효율적으로 저장하고 암호화로 서버의 보안성을 높였다.

 

JWT Encoding / Decoding

https://jwt.io/

 

JSON Web Tokens - jwt.io

JSON Web Token (JWT) is a compact URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is digitally signed using JSON Web Signature (JWS).

jwt.io

 

JWT 구조

XXXXXX.YYYYYY.ZZZZZZ
(Header).(Payload).(Signature)

Header

  • 토큰의 타입과 해싱 알고리즘을 정의한다.

Payload

  • 실제로 인증과 관련된 데이터(Claims)를 담고 있다.
  • Claims의 종류
    • Registered Claims : 미리 정의된 Claims
      • iss(issuer) : 발행자
      • exp(expiration time) : 만료시간
      • sub(subject) : 제목
      • iat(issued At) : 발행 시간
      • jti(JWT ID) : 토큰의 고유 식별자
    • Public Claims : 사용자가 정의할 수 있는 클레임, 공개용 정보 전달 목적
    • Private Claims : 사용자 지정 클레임, 당사자들 간에 정보를 공유하기 위한 목적

Signature

  • Header와 Payload를 서버의 Secret Key로 서명하여 암호화 한다.
  • 암호화는 Header에서 정의한 알고리즘(alg)을 활용한다.
  • 서명을 통해 서버는 Token이 변조되지 않았음을 확인할 수 있다.
HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret
)
base64UrlEncode는 값을 URL에서 사용할 수 있도록 +, /를 각각 -, _로 표기한다.
Header와 Payload는 Encoding된 값이기 때문에 복호화 혹은 값을 수정할 수 있지만 Signature는 서버에서 관리하는 값이기 때문에 Secret Key가 유출되지 않는 이상 복호화 할 수 없다.

 

JWT 인증

JWT는 Base64로 인코딩되어 쉽게 복호화 할 수 있다. Payload가 그대로 노출되기 때문에 비밀번호나 민감한 정보를 저장하지 않는다.

 

JWT 인증 과정

더보기
  1. 클라이언트의 로그인 요청
  2. 로그인에 성공했다면 Header, Payload에 Secret Key를 사용하여 Signature를 만든다.
    • 이후 Base64로 Encoding 한다.
    • 일반적으로 Cookie에 담아 클라이언트에게 JWT를 발급한다.
  3. 발급받은 JWT를 저장 후 서버에 요청할 때 Authorization Header에 JWT를 담아 보낸다.
  4. 서버에서 JWT의 유효성 검사를 통해 통과한다면 인증에 성공하여 요청을 처리해준다.
    • JWT 만료, 위변조 여부를 검사한다.

JWT의 유효성 검사

더보기
  1. A의 JWT를 B가 탈취
  2. B가 탈취한 JWT를 임의로 수정
  3. B가 수정한 JWT로 Server에 요청
  4. 서버는 Signature를 사용하여 유효성 검사(Signature 불일치)
    • Header, Payload를 서버의 Secret Key값을 이용해 Signature를 다시 만들어 비교한다.
    • 임의로 조작된 데이터를 판별할 수 있다.
JSON Web Token의 목적은 정보 보호가 아닌, 위조 방지에 있다.

 

JWT 장단점

더보기
  • JWT 장점
    1. Signature로 서버의 보안성이 증가한다.
    2. Token 자체가 필요한 정보(유저 및 검증 정보)들을 모두 가지고 있다.
    3. 서버는 인증 정보와 관련된 별도의 저장소를 사용하지 않는다.
    4. 서버의 수평 확장성(Scale Out)이 높아진다.
    5. Cookie가 없는 다른 환경에서도 인증/인가를 적용할 수 있다.
    6. DB를 조회하지 않아도 된다.
Mobile의 경우 App을 자주 닫거나 백그라운드로 전환하여 Session 방식을 사용하지 않는다.

 

  • JWT 단점
    1. Payload는 암호화 된 것이 아니라 민감한 정보를 다루지 못한다.
    2. Token의 길이가 길어서 트래픽이 증가하면 네트워크에 부하가 증가한다.
    3. 클라이언트 측에서 Token을 관리하기 때문에 탈취당하면 대처하기 어렵다.

Access Token, Refresh Token

Token은 클라이언트에서 관리하여 탈취당할 위험성이 높기 때문에 만료 시간 설정이 필요하다. 이 때 발생하는 단점을 극복하기 위해 Access Token과 Refresh Token을 사용한다.

 

Access Token

  • 사용자 인증 후 서버가 발급하는 유저 정보가 담긴 토큰이다.
  • 유효 기간 동안 API나 리소스에 접근할 때 사용한다.

Refresh Token

  • Access Token은 보안을 위해 짧은 수명을 가진다.
  • Access Token이 만료된 경우 재발급 받기위해 사용한다.
  • 주로 데이터베이스에 유저 정보와 같이 저장한다.

Access Token, Refresh Token 인증

더보기
  1. 클라이언트의 로그인 요청
  2. 로그인에 성공했다면 Header, Payload에 Secret Key를 사용하여 Signature를 만든다.
  3. 발급받은 JWT를 저장 후 서버에 요청할 때 Authorization Header에 JWT(Access Token)를 담아 보낸다.
  4. 서버에서 JWT의 유효성 검사를 통해 통과한다면 인증에 성공하여 요청을 처리해준다.
  5. Access Token이 만료 되었다면 Refresh Token 으로 토큰 재발급을 요청한다.
  6. 서버로부터 Access Token을 재발급 받는다.
JWT를 Access Token만을 사용하여 인증한다면 탈취되어 보안에 취약할 수 있다. 유효 시간을 부여하여 문제를 해결하지만 유효 시간이 짧다면 로그인을 자주 해야하기 때문에 Refresh Token을 적용한다.

 

참고 영상 : https://www.youtube.com/watch?v=XXseiON9CV0

공통 관심 사항(cross-cutting concerns)

더보기

같은 말로 횡단 관심사 라고 하며 여러 위치에서 공통적으로 사용되는 부가 기능이고 Filter가 나오게된 이유는 공통 관심사(Cross Cutting Concern)의 처리 때문이다.

Servlet Filter

Servlet Filter는 보안, 로깅, 인코딩, 인증/인가 등 다양한 작업을 처리하기 위해 사용된다.
더보기

Servlet Filter 특징

  1. 공통 관심사 로직 처리
    • 공통된 로직을 중앙 집중적으로 구현하여 재사용성이 높고 유지보수가 쉽다.
    • 모든 요청이 하나의 입구를 통해 처리되어 일관성을 유지한다.
  2. HTTP 요청 및 응답 필터링
  3. Filter Chain
    • 여러 개의 필터가 순차적으로 적용될 수 있다.
    • filterChain.doFilter(request, response); 다음 필터로 제어를 전달한다.
  4. doFilter()
    • 실제 필터링 작업을 수행하는 주요 메소드로 필터가 처리할 작업을 정의한다.
    • 다음 필터로 제어를 넘길지 여부를 결정한다.

Servlet Filter 적용

  • Filter를 적용하면 Servlet(디스패쳐서블릿)이 호출되기 이전에 Filter를 항상 거치게된다.
  • 공통 관심사를 필터에만 적용하면 모든 요청 or 응답에 적용된다 .
  • Filter는 특정 URL Pattern에 적용할 수 있다.
  • Spring을 사용하는 경우 Servlet은 **Dispatcher Servlet**이다.

인증/인가 필터 동작

로그인 성공 : 정상적으로 Controller를 호출한다.

 

로그인 실패 : Filter에서 적절하지 않은 요청이면 Controller를 호출하지 않는다.

 

Filter Chain

  • Filter는 Chain 형식으로 구성된다.
  • Filter는 개발자가 자유롭게 추가할 수 있다.
  • Filter는 순서를 지정하여 추가할 수 있다.

 

Filter Interface

Java Servlet에서 HTTP 요청과 응답을 가로채고, 이를 기반으로 다양한 처리 작업을 수행하는 데 사용되는 Interface이다.

Filter Interface를 Implements하여 구현하고 Bean으로 등록하여 사용한다.
Servlet Container가 Filter를 Singleton 객체로 생성 및 관리한다.
더보기

주요 메서드

  1. init()
    • Filter를 초기화하는 메서드이다.
    • Servlet Container가 생성될 때 호출된다.
    • default method이기 때문에 implements 후 구현하지 않아도 된다.
  2. doFilter()
    • Client에서 요청이 올 때 마다 doFilter() 메서드가 호출된다.
      • doFilter() 내부에 필터 로직(공통 관심사 로직)을 구현하면 된다.
    • WAS에서 doFilter() 를 호출해주고 하나의 필터의 doFilter()가 통과된다면
    • Filter Chain에 따라서 순서대로 doFilter() 를 호출한다.
    • 더이상 doFilter() 를 호출할 Filter가 없으면 Servlet이 호출된다.
  3. destroy()
    • 필터를 종료하는 메서드이다.
    • Servlet Container가 종료될 때 호출된다.
    • default method이기 때문에 implements 후 구현하지 않아도 된다.

Filter가 많아질수록 성능적으로 문제가 발생하지는 않나요?

Filter 몇 개는 있어도 괜찮아요! Spring MVC 구조를 보면 요청이 한번 들어올 때 수백, 수천 가지의 메서드가 호출되는 것을 확인할 수 있듯이 Filter로 발생하는 부하는 사소한 부분이에요.

 

Spring Security에서 Filter를 어떻게 사용하고 있는지 가볍게 알아보자.

https://docs.spring.io/spring-security/reference/servlet/architecture.html