JWT

박효상·2022년 4월 22일
0

BACKEND-TIL

목록 보기
8/21
post-thumbnail

JWT 란?

  • Json Web Token의 줄임말로서, Access Token 생성을 위해 가장 널리 사용되는 기술
  • JWT는 유저 정보를 담은 Json 데이터를 암호화 한 Token으로서, Token 자체를 정보로 사용하는 Self-Contained 방식으로 정보를 안전하게 전달

JWT가 생긴 배경

  • (1) 유저 인증/인가 처리를 위한 로그인, 회원가입시 클라이언트의 상태를 보존하지 않는 HTTP의 무상태성으로 인해 매번 새로 클라이언트가 서버로 요청해야 하는 문제 발생
  • (2) 이로 인해 쿠키와 세션(서버에서 메모리 또는 DB에 유저 정보를 저장하는 방식)을 통해 인증/인가 처리를 하는 방식이 사용되기 시작
  • 하지만 세션을 DB로 처리하면 성능이 떨어지고 메모리로 처리하면 저장공간이 적어 접속자가 많을 때 세션 유지가 어렵다는 점 그리고 자원 소모 예방을 위해 Stateless인 HTTP가 쿠키와 세션을 통해 Stateful로 된다는 점 등 여러 문제 발생
  • 서버에 부하가 덜 가면서, 동시에 새로 요청할 필요 없이 인증/인가를 처리할 수 있는 토큰 처리 방식이 도입

JWT 구조

  • Header : 토큰 로직
    • typ(토큰의 타입)과 alg(해싱 알고리즘)으로 구성
    • ex) { "typ": "JWT", "alg": "HS256" }
  • Payload : 토근 정보
    • 정보의 한 조각이라 불리며 key-value 쌍으로 구성된 여러 claim으로 구성
    • 클레임 구성요소
      • Registered claim : 토큰의 속성 정보들이며, 사용은 선택적
        • iss : 토큰 발급자
        • sub : 토큰 제목
        • aud : 토큰 대상자
        • exp : 토큰 만료 시간
        • nbf : 토큰 활성 날짜
        • iat : 토큰 발급 시간
        • jti : 토큰 고유 식별자
      • Public claim : 충돌이 방지된 이름을 담으며, URL 형식
      • Private claim : 서비스에 필요한 정보
        • 클라이언트와 서버의 협의 하에 사용되는 클레임 이름 정의 필요
        • Public claim과 달리 이름이 중복되어 충돌 가능
        • 해당 유저의 이름, ID, PW 등이 담기는 곳
  • Signature : Header, Payload, 그리고 서버의 Secret Key를 이용해 만든 암호화 코드
    • 악의적인 사용자가 토큰을 수정해도 서버가 애초에 발급한 Signature 안의 내용과 다르기에 토큰 조작 여부 확인 가능

JWT Method

  • jwt.sign : JWT Token 생성
  • jwt.verify : JWT Token 검증
    • 검증시 decoded된 객체 반환
    • 검증 실패시 null 반환
  • jwt.decode : 토큰 해석을 위한 용도지만 주로 사용 x

JWT 동작 원리

  • (1) 클라이언트가 유저 ID, Password 데이터를 담아 로그인을 서버에 요청
  • (2) 서버에서 유저 인증을 위해 전달받은 클라이언트 데이터를 Database에서 조회
  • (3) Database에서 인증 완료시, 서버는 JWT Token을 생성 및 클라이언트에게 전달
  • (4) Database에서 인증 실패시, 회원가입을 요청하며 회원가입 후 Database에 유저 정보를 추가하고 JWT Token 생성 및 클라이언트에게 전달
  • (5) 클라이언트는 전달받은 JWT Token을 쿠키 또는 로컬스토리지 또는 세션 스토리지에 저장
  • (6) 클라이언트가 인가가 필요한 페이지에 접속할 때마다 HTTP Header에 JWT Token이 담긴채로 서버로 전송
  • (7) 서버는 이 토큰을 디코딩해서 클라이언트 인가를 처리하고 요청한 데이터를 전송

JWT 특성

장점

  • JWT 자체에 인증/인가에 필요한 유저 정보가 담겨 있어, SessionDB 같은 별도의 인증 저장소가 필요 x
  • URL 파라미터/헤더로 사용 가능
  • 서버 부담 감소
  • 내부 만료 기간 존재
    단점
  • 토큰은 클라이언트 사이드에 저장되어, Database 내에서 유저 정보가 변경되도 토근에 적용 불가능
  • 클레임 추가시마다 토큰이 커짐

인증과 인가의 차이

  • 인증: 사용자의 정보가 해당 서비스의 Database에 존재하는지 확인하는 절차
    • ex) 로그인, 회원가입
  • 인가: 사용자가 해당 서비스에 특정 서비스 이용 권한이 있는지 확인하는 절차
    • ex) 권한이 필요한 페이지 접근 - 마이페이지, 상품 장바구니, 관리자 페이지
profile
집념의 백엔드 개발자

0개의 댓글