본문 바로가기

개발몰입과정 개념스터디/3차

JWT란?

JWT란?

Json Web Token의 약자로 인증에 필요한 정보들을 암호화시킨 토큰을 뜻한다.

 

token 구성요소

Encoded Header + "." + Encoded Payload + "." + Verify Signature

Header : 위 3가지 정보를 암호화할 방식(alg), 타입(type) 등이 들어갑니다.

Payload : 서버에서 보낼 데이터가 들어갑니다. 일반적으로 유저의 고유 ID값, 유효기간이 들어갑니다.

Verify Signature :  Base64 방식으로 인코딩한 Header, payload, SECRET KEY를 더한 후 서명된다.

 

[출처 : https://tansfil.tistory.com/58?category=475681]

  1. 사용자가 로그인을 한다.
  2. 서버에서는 계정정보를 읽어 사용자를 확인 후, 사용자의 고유한 ID값을 부여한 후, 기타 정보와 함께 Payload에 넣는다.
  3. JWT 토큰의 유효기간을 설정한다.
  4. 암호화할 SECRET KEY를 이용해 ACCESS TOKEN을 발급한다.
  5. 사용자는 Access Token을 받아 저장한 후, 인증이 필요한 요청마다 토큰을 헤더에 실어 보낸다.
  6. 서버에서는 해당 토큰의 Verify Signature를 SECRET KEY로 복호화한 후, 조작 여부, 유효기간을 확인한다.
  7. 검증이 완료된다면, Payload를 디코딩하여 사용자의 ID에 맞는 데이터를 가져온다.

세션/쿠키는 세션 저장소에 유저의 정보를 넣는 반면, JWT는 토큰 안에 유저의 정보들이 넣는다.

클라이언트 입장에서는 HTTP 헤더에 세션ID나 토큰을 실어서 보내준다는 점에서는 동일하나, 서버 측에서는 인증을 위해 암호화를 하냐, 별도의 저장소를 이용하냐는 차이가 발생한다.

  • 회원 인증: JWT 를 사용하는 가장 흔한 시나리오이다. 사용자가 로그인을 하면, 서버는 사용자의 정보를 기반으로한 토큰을 발급한 후, 사용자가 서버에 요청을 할 때 마다 JWT를 포함하여 전달한다. 서버는 클라이언트에서 요청을 받을때 마다, 해당 토큰이 유효하고 인증됐는지 검증을 하고, 사용자가 요청한 작업에 권한이 있는지 확인하여 작업을 처리한다.
  • 서버에서는 사용자에 대한 세션을 유지 할 필요가 없다. 즉 사용자가 로그인되어있는지 안되어있는지 신경 쓸 필요가 없고, 사용자가 요청을 했을때 토큰만 확인하면 되므로 세션 관리가 필요 없어서 서버 자원과 비용을 절감할 수 있다.
  • 정보 교류: JWT는 두 개체 사이에서 안정성있게 정보를 교환하기에 좋은 방법. 그 이유는, 정보가 서명이 되어있기 때문에 정보를 보낸이가 바뀌진 않았는지, 또 정보가 도중에 조작되지는 않았는지 검증할 수 있다.

 

장점

  • 세션/쿠키는 별도의 저장소의 관리가 필요. 그러나 JWT는 발급한 후 검증만 하면 되기 때문에 추가 저장소가 필요 없다.
    • Stateless : 어떠한 별도의 저장소도 사용하지 않는, 즉 상태를 저장하지 않는 것을 의미.
  • ⇒ Stateless 한 서버를 만드는 입장에서는 큰 강점이다. 이는 서버를 확장하거나 유지,보수하는데 유리하다.
  • 확장성이 뛰어나다.예를 들어 Facebook 로그인, Google 로그인 등은 모두 토큰을 기반으로 인증을 한다. 이에 선택적으로 이름이나 이메일 등을 받을 수 있는 권한도 받을 수 있다.
  • ⇒ 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능하다.

단점

  • 이미 발급된 JWT에 대해서는 돌이킬 수 없다.⇒ 악의적인 사용자는 유효기간이 지나기 전까지 신나게 정보들을 털어갈 수 있다.
  • 세션/쿠키의 경우 만일 쿠키가 악의적으로 이용된다면, 해당하는 세션을 지워버리면 되지만, JWT는 한 번 발급되면 유효기간이 완료될 때 까지는 계속 사용이 가능하다.

⇒ 해결책 : 기존의 Access Token의 유효기간을 짧게 하고 Refresh Token이라는 새로운 토큰을 발급,그렇게 되면 Access Token을 탈취당해도 상대적으로 피해를 줄일 수 있다.

  • Payload 정보가 제한적이다. Payload는 따로 암호화되지 않기 때문에 디코딩하면 누구나 정보를 확인할 수 있다. 세션/쿠키 방식에서는 유저의 정보가 전부 서버의 저장소에 안전하게 보관되지만 JWT는 아니기 때문에 유저의 중요한 정보들은 Payload에 넣을 수 없다.
  • JWT의 길이. 세션/쿠키 방식에 비해 JWT의 길이는 길다. 따라서 인증이 필요한 요청이 많아질 수록 서버의 자원낭비가 발생하게 된다.

 


[참고]

https://tansfil.tistory.com/58?category=475681

 

http://www.opennaru.com/opennaru-blog/jwt-json-web-token/

'개발몰입과정 개념스터디 > 3차' 카테고리의 다른 글

Class Component vs Functional Component  (0) 2022.02.05
React Virtual Dom란?  (0) 2022.02.05
CORS란?  (0) 2022.02.05
JavaScript의 비동기 기술  (0) 2022.02.05
TypeScripts란?  (0) 2022.02.05