Web/spring-boot

JWT 와 RTR기법

부에나온다 2024. 3. 20. 12:15

1. JWT

  • jwt는 사용자가 로그인을 하면 서버는 해당 사용자가 인증(Autehntication)되었고, 기본적인 정보를 토큰으로 만들어 응답
  • 사용자는 이 토큰을 기반으로 인가(Authorization)를 필요로 하는 요청에는 Header에 토큰을 담아서 보내게된다.
  • Json 개체로 안전하게 전송하기 위한 컴팩트하고 독립적인 방식을 정의하는 개방형 표준
    • Header (헤더)
      • alg : 해싱 알고리즘을 지정한다. 해싱 알고리즘은 기본적으로 HS256을 사용한다.
      • typ : 토큰의 타입을 지정. JWT이기 때문에 typ는 JWT 고정
    • Payload (내용)
      • 토큰에 담을 정보를 담는곳
      • 정보 하나하나가 클레임(claim)이라고 부르고 Key : Value로 이루어져있다.
      • 민감한 정보는 넣지않는것이 좋다
      • 공개클레임 : 발급자(issuer), 제목(subject), 만료시간(expiration), 발급된시간(issued at)
      • 비공개클레임 : 사용자와 서버사이에 사용되는 클레임
{
    "iss": "seungyong20.tistory.com",                   // 등록된 클레임 (토큰 발급자)
    "exp": 1673741869628,                               // 등록된 클레임 (토큰의 만료시간)
    "<https://xxx.com/jwt_claims/is_admin>": true,      // 공개 클레임
    "userId": "00001",                                  // 비공개 클레임
    "username": "seungyong"                             // 비공개 클레임
}
    • Signature (서명)
      • Header인코딩값과 Payload인코딩값을 합친 후 주어진 Secret Key로 헤더에 지정된 알고리즘을 통해 해쉬를 하여 생성
      • 만들어진 해쉬값을 base64로 인코딩하여 나타낸다.

2. JWT 사용이유

  1. Cookie + Session
    • 인증 절차
      • 로그인 요청 시 사용자를 특정할 수 있는 유니크한 데이터로 세션 ID를 생성하여 사용자에 대한 정보를 세션 저장소에 저장
      • 클라이언트에서는 쿠키에 세션 ID를 저장하여 요청시에 넘겨주고, 서버에는 쿠키에 담긴 세션 ID를 통해 검증
    • 장점
      • 사용자에 대한 정보는 서버에 저장되어있고, 쿠키의 데이터로는 알수없기 때문에 보안상 안전
    • 단점
      • 사용자의 데이터를 서버의 메모리에 저장하기 때문에 메모리 용량에 대한 리스크 존재
      • 서버를 스케일 아웃할 경우 각 서버에 세션을 동기화해야하는 비용 발생 stateless 위배
  2. JWT
    • 인증절차
      • 로그인 요청 시 사용자에 대한 정보를 담은 토큰을 생성하여 클라이언트에 전달한다.
      • 클라이언트에서는 요청 시에 해당 토큰을 넘겨주고, 서버에서는 토큰에 대한 유효성을 검사하여 검증을 진행
    • 장점
      • 쿠키와 세션과 다르게 별도의 저장소를 필요로 하지 않기 때문에 stateless 하여 서버 확장성이 뛰어나다
      • Facebook, Google 소셜 로그인 등처럼 사용자에 대한 인증 방식의 확장이 가능하다.
    • 단점
      • 토큰을 한번 발급하면 해당 토큰이 만료되기 전까지는 사용을 막을 수 있는 방법이 없다.
      • 토큰의 크기가 커지면 네트워크에 부하를 줄 수 있고, Payload는 따로  암호화되지 않기 때문에 필요한 최소한의 정보만 담아야한다.

    => JWT는 위변조를 방지할 수 있으며, stateless 할 수 있다는 점에서 세션방식에 비해 가볍고 확장성이 좋다.

 

3. Access Token / Refresh Token

  1. Access Token
    • 사용자의 정보를 담고 있는 토큰으로써, 사용자 인증 / 인가를 위한 토큰
    • Access Token을 받으면 토큰의 정보를 사용하여 사용자 정보를 제공해주는 역할을 한다.
    • Access Token은 탈취를 당했을 때를 대비해 만료시간을 짧게 잡는다. 보통 30분
  2. Refresh Token
    • Access Token의 만료시간이 다 되면 새로운 토큰을 발급해주는 토큰
    • 제 3자를 통해서 Access Token을 탈취 당해도 만료시간이 지나면 새로운 토큰을 발급하기 때문에 보안성 강화
    • Refresh Token은 Access Token을 새로 발급하기 위한 수단으로 Access Token보다 만료시간을 길게 잡기 때문에 보통 14일 정도를 잡는다.

 

4. RTR (Refresh Token Rotation) 기법

  • Refresh Token을 단 한번만 사용하게 일회용 토큰으로 사용하는 기법

  1. Access Token 1과 Refresh Token 1을 얻는다.
  2. Refresh Token 1을 사용하여 Access Token 2와 Refresh Token 2를 얻는다.
  3. Refresh Token 2를 사용하여 Access Token 3와 Refresh Token 3을 얻는다.
  4. 이 과정을 계속 반복한다.

5. 또 다른 보안대책