JWT

소밍·2023년 7월 28일
0
post-thumbnail

JWT(JSON Web Token)

  • 인증에 필요한 정보들을 암호화시킨 JSON 토큰
  • JWT 기반 인증은 JWT 토큰(Access Token)을 HTTP 헤더에 실어 서버가 클라이언트를 식별하는 방식

세션 인증 방식과 토큰 인증 방식

세션 방식 인증 - stateful

  • 비밀번호 등 클라이언트의 민감한 정보를 서버가 저장하고 관리하는 방식
  • 서버가 사용자 상태를 세션에 저장하기 때문에 사용자 수가 많다면 데이터베이스 성능에 영향을 미칠 수 있음

토큰 인증 방식 - stateless

  • 클라이언트가 서버로 부터 받은 인증 토큰을 인증 요청시 요청 헤더에 넣어 보내는 방식
  • 서버는 클라이언트에서 받은 토큰을 기존 토큰과 비교하는 검증 절차 진행
  • 서버는 사용자 상태를 저장해둘 필요 없이 인증 토큰 검증을 통해 사용자를 인증하고 권한을 부여

► "로그인 세션이 만료되었습니다"

사용자의 세션이 유효기간이 만료되어 인증 상태가 해제된 것을 의미 (세션 기반 인증)
이 경우 사용자는 다시 로그인하여 새로운 세션을 생성해야 인증 상태를 유지할 수 있음


JWT 구조

  • JWT 토큰의 payload에 중요한 데이터를 직접 포함시키지 않고,
    필요한 경우 식별자나 참조 정보를 사용하여 안전한 데이터 관리 방식을 사용하는 것이 보안적으로 좋은 접근 방법
  • header, payload를 조합하고 비밀키를 이용해서 만든 해쉬값 = signature
  • 서버는 기존 signature 와 요청 받은 signature를 비교하여 토큰을 검증 (만약 일치하지 않다면 조작된 데이터로 판단)

인증 과정

만약 토큰 기간이 만료되었다면
클라이언트는 refresh token을 이용해 새로운 access token을 발급받음.


JWT 장점

  • 데이터 무결성 보장
    • 서버가 가지고 있는 비밀키를 가지고 Signature를 생성하므로 데이터 위변조를 막을 수 있음.
  • Stateless 서버 - 서버 확장성 향상
    • 클라이언트 인증 정보를 저장하는 세션과 다르게, 인증 정보에 대한 별도의 저장소가 필요없기 때문에 서버 부담 줄어 듦.
  • 서비스간 권한 공유
    • 다른 로그인 시스템에 접근 및 권한 공유 가능. (쿠키는 도메인간 공유에 제약)
  • OAuth의 경우 Facebook, Google 등 소셜 계정을 이용하여 다른 웹서비스에 로그인 가능.

JWT 한계점

  • Payload 인코딩
    • header와 payload는 BASE64로 인코딩 된 것이기 때문에 payload에 중요 데이터를 넣지 않아야 함.
  • stateless
    • 토큰을 클라이언트측에서 관리하고 저장하기 때문에
      토큰을 탈취당할 경우 서버가 토큰을 강제로 만료시킬 수 없기 때문에 위험
    • JWT는 stateless 특징을 가지기 때문에
      토큰 발급 후 토큰의 내용을 변경하거나 만료시간을 조정하는 것이 불가능.
    • 서버가 토큰을 강제로 만료시킬 수 없으니 보안 측면에서 토큰 수명을 짧게 하는 것이 좋음
    • 세션처럼 stateful할 경우 서버가 사용자들의 상태를 알고 있기 때문에 '제어'할 수 있음
      • ex. 만약 여러 기기에서 접속할 수 없는 서비스라면 기존 기기가 아닌 다른 기기에서 로그인 요청이 올 경우 기존 기기의 세션을 종료할 수 있음.

보완책

► 토큰 유효기간 짧게 설정

토큰의 유효기간을 짧게 설정하고, refresh token 활용

► JWT + 대칭키 암호화 방식

대칭키 암호화 방식

  • 데이터를 암호화하고 복호화하기 위해 동일한 키를 사용하는 방식
  • 키를 알지 못하면 복호화를 하지 못해 데이터를 알 수 없음

개인정보를 모두 클라이언트가 보관하면 정보 유출 위험 있음.
클라이언트 단에서 대칭키 암호화 방식을 사용하여 토큰을 암호화하면
토큰 탈취 당하더라도 암호화 되어있기 때문에 정보 유출로 부터 안전해짐.
복호화할 수 없기 때문에 인증 수단으로 활용할 수도 없음.


헷갈렸던 점

로그인 요청 자체를 JWT로 하는 것인가? 했다. 하지만 JWT는 로그인 요청 자체를 처리하는 메커니즘이 아니다.
쇼핑몰 사이트를 예로 들자면, 유저는 로그인후 장바구니 담기, 찜하기, 결제하기 등과 같은 인증이 필요한 다양한 api요청을 보낼 수 있다. JWT는 로그인 후 발급되어 클라이언트의 인증 상태를 나타내는 토큰으로 사용된다.

또한 JWT와 access token 개념이 헷갈렸는데 access token은 클라이언트가 서버의 보호된 리소스에 접근할 수 있는 권한을 나타내는 토큰으로, JWT 인증 방식을 채택한 경우 JWT로 구현한 access token을 발급받는 것이다.


참고자료

jwt
참고블로그
참고블로그
RFC7519

profile
생각이 길면 용기는 사라진다.

0개의 댓글

관련 채용 정보