Ming's develop story

Chapter1 - 미니프로젝트 review JWT 본문

스파르타코딩클럽 - 항해99/항해99 Chapter1 - 미니 프로젝트 (SarangBang)

Chapter1 - 미니프로젝트 review JWT

Ming 2021. 11. 9. 00:30

JWT란?

  • Json Web Token 약자로 모바일이나 웹에서 사용자 인증을 위해서 사용하는 암호화 토큰을 말합니다.
  • Json 포맷을 이용하여 사용자에 대한 속성을 저장합니다.

 

  "내가 이해한 보편적인 JWT란 사용자에게 2개의 토큰을 발급하는데 1개의 토큰은 접근권한을 단기간동안 허용해 주는것이고 또 다른 1개의 토큰은 좀 더 긴 기간동안의 토큰을 발급하는데 전자의 토큰은 user가 그 첫번째 토큰이 존재하는 시간내에 활동할때에 접근권한을 허용해주고 그 시간이 지난뒤에는 그 토큰이 만료가 되는데 user가 다시 로그인을 할 시에 두번째 토큰이 정해진 기간동안 그 user의 정보를 기억해 두었다가 다시 접속하였을때 첫번째 토큰을 다시 발급해주는 역할을 한다." 이다. 

 

JWT 토큰의 구성

3부분으로 나누어 진다. 각 파트는 점으로 구분하게 된다.

순서대로 header, payload, signature로 구성된다.

header : 토큰의 타입, 해시 암호화 알고리즘

payload : 정보를 담는 공간, 정보는 name : value 한 쌍으로 이루어져 있다. 이렇게 payload에 있는 속성들을 Claim Set이라고 부른다. 클라이언트와 서버 간의 주고받는 값들로 구성된다.

signature : 점을 구분자로 하여 header와 payload를 합친 문자열을 서명한 값, header에 정의된 알고리즘 방식으로SECRET_KEY를 이용하여 Base64 URL-Safe로 인코딩한다.

header, payload 값은 인코딩 될 뿐이지 따로 암호화 되지 않기 때문에 중요한 정보는 들어가면 쉽게 노출될 수 있다. 하지만 signature의 경우 SECRET_KEY를 알지 못하면 복호화 할 수 없다.

해쉬 암호화 방식을 사용하기 때문에 암호문을 평문으로 바꿀 수 없다. 또한 해쉬 암호화를 진행하게 되면 단 한 글자만 바꿔도 암호문이 완전히 달라진다. 따라서 만약 payload의 정보를 의도적으로 변경하여 요청을 한다 해도 검증과정에서 들통나게 되어있다.

검증 방식은 받은 토큰의 header와 payload를 합친 문자열을 SECRET_KEY를 이용하여 암호화 한 값이랑 받은 토큰의 signature값이 같지 않으면 payload나 header의 정보가 바뀐것이므로 서버는 인가해주지 않는다.

 

 

JWT 인증 원리

1. 사용자가 로그인을 하게 되면 서버로 로그인 정보( ID, PW )를 전송한다.

2. 서버는 회원 정보가 담긴 DB를 조회하여 해당 User가 존재하는지 확인한다.

3. 서버는 가입된 User임이 확인되면 "토큰"을 발급해준다.

4. 사용자(클라이언트) 측에서는 받은 토큰을 저장해둔다.

5. 데이터 요청 시, 서버한테 발급 받았던 토큰을 함께 보낸다.

6. 토큰의 정보가 올바른지 검증을 시행한다.

7. 검증이 잘 완료되면, 요청한 데이터를 보내준다.

 

그림으로 보면 쉽게 이해를 할 수 있다. 이렇게 간단한 방식으로 세션/쿠키 방식처럼 별도의 저장소가 필요없다!!

 

 

JWT 장단점

장점

  • 별도의 저장소가 필요 없기 때문에 서버의 확장, 유지 보수가 용이하고 비용이 덜 든다.
  • 확장성이 뛰어나다. 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능하다. 토큰만 가지고 있다면 어떤 서버로 요청이 들어가던지 검증만 되면 된다! FaceBook이나 Google의 로그인은 모두 토큰을 기반으로 인증한다고 한다. 

 

단점

  • 한 번 발급하여 클라이언트에게 준 JWT에 대해서 돌이킬 수 없다. 서버 측에서 따로 저장해두지 않기 때문에 한 번 발급한 토큰은 유효 기간이 완료될 때 까지는 계속 사용 가능하다. 따라서 Access Token이 탈취당할 경우 보안에 취약하다.

    -> 해결책으로 나온 방식은 기존의 Access Token의 유효기간을 매우 짧게 설정하고, 유효기간이 조금 긴 Refresh Token을 새로 발급한다. 따라서 Refresh Token은 Access Token의 유효기간이 만료됬을 때 새로 또 발급해주는 열쇠가 된다!
  • Payload의 정보가 제한적이다. payload는 따로 암호화 되지 않기 때문에 중요한 정보들을 넣을 수는 없다.
  • JWT 길이가 길다. 따라서 인증이 필요한 요청이 많아질수록 서버의 자원 낭비가 발생한다.

 

Comments