Token 사용 이유 및 작동 방식

Token 사용 이유

• 서버 부담 경감: Token은 서버가 아닌 클라이언트에 저장되므로 서버 저장 공간 부담을 줄인다.
• 다양한 클라이언트 지원: Cookie와 달리 웹 브라우저 외 모바일 앱 등 다양한 환경에서 인증 처리가 가능하다.
• 높은 확장성 (Stateless 기반): 각 요청이 필요한 모든 정보를 포함하므로 서버는 이전 요청 상태를 기억할 필요가 없는 Stateless 방식으로, 서버 확장에 유리하다.
• 위조 방지: Token은 고유 서명을 포함하여 인증된 사용자인지, 요청이 위조되지 않았는지 확인할 수 있다.

Token 작동 순서

1. Token 생성 시 사용자 고유 정보를 포함한다.
2. 데이터베이스 접근 없이 Token 자체의 서명 및 만료 시간 검증을 통해 유효성을 판단한다.

Token의 단점

• 데이터 용량 증가: Cookie/Session 방식 대비 Token 자체의 데이터 용량이 커 요청 시 트래픽이 증가할 수 있다.
• Payload 보안 취약: Payload는 암호화되지 않고 Base64로 인코딩되므로 중요한 개인 정보 포함은 지양해야 한다.
• 탈취 시 대처 어려움: Token 탈취 시 즉각적인 무효화가 어려워 비교적 짧은 만료 시간(일반적으로 30분 내외)을 설정하여 위험을 줄인다.

JWT 구조

JWT(JSON Web Token)는 XXXXXX.YYYYYY.ZZZZZZ 형태를 가지며, 각 부분은 다음과 같다.

1. Header: 토큰 타입(JWT) 및 해싱 알고리즘(alg, 예: HMACSHA256)을 정의한다.
    

   {
     "alg": "HS256",
     "typ": "JWT"
   }
   

2. Payload (Claims): 인증 관련 데이터인 Claims를 포함한다. Claims 종류는 다음과 같다.

   • Registered Claims (등록된 클레임): JWT 표준에서 미리 정의된 클레임 (iss, exp, sub, iat, jti 등).
   • Public Claims (공개 클레임): 사용자가 자유롭게 정의 가능한 클레임으로, 공개 정보 전달 목적을 갖는다.
   • Private Claims (개인 클레임): 당사자 간 정보 공유를 위해 사용자가 정의한 클레임이다.

   {
     "iss": "example.com",
     "sub": "user123",
     "exp": 1678886400,
     "userId": "uniqueUserId"
   }
   

3. Signature (서명): Header와 Payload를 서버 Secret Key로 암호화한다. 암호화는 Header에 정의된 알고리즘(alg)을 사용하며, 이를 통해 서버는 토큰 변조 여부를 검증한다.

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret
)

상기한 바와 같이, JWT의 Payload는 Base64 URL 인코딩만 적용되어 내용 확인이 가능하다는 점을 유념해야 한다. 따라서 민감 정보 포함은 보안상 취약점을 야기할 수 있다.

Token 사용은 서버의 상태 유지 부담을 줄이고 다양한 클라이언트 환경을 지원하는 이점을 가지나, Token 자체의 크기 및 탈취 시 대처의 어려움과 같은 단점 또한 존재한다.

결론적으로, Token 인증 방식은 클라이언트에게 '인증 완료' 도장을 부여하고 서버는 해당 도장을 통해 신뢰성을 판단하는 것과 유사하다. 그러나 해당 도장이 위조될 경우의 감별 방안에 대한 심층적인 고려가 요구된다.