[인증/보안] JWT(JSON Web Token)

1. JWT

토큰기반 인증이라고 하며 기존의 세션기반 인증은 서버나 데이터베이스에 유저 정보를 담는 방식이라 유저가 정보를 요청할 때 마다 세션의 정보값과 일치하는지 확인하는데 이러한 절차를 덜어내기 위해 고안된 인증방법이다.

여기서 토큰은 유저정보를 암호화한 상태로 담을 수 있고, 암호화를 했기 때문에 클라이언트에 담을 수 있다.

• 세션기반 자격 증명 / 토큰기반 자격 증명방식

---

2. JWT의 종류

• Access Token
  
  
• Refresh Token

클라이언트가 처음 인증을 받을 때,  두 가지의 토큰을 다 받고 실제로 권한을 얻는 데에 사용하는 토큰은 Access Token이다.

Refresh Token이 필요한 이유는?
Access Token이 탈튀 당했을 때 큰 문제가 발생할 수 있기 때문에 Access Token에는 짧은 유효기간을 주어 오랫동안 사용할 수 없게 하고 유효기간이 만료되었을 때 Refresh Token을 이용해 새로운 Access Token을 발급받아 사용하므로 Refresh Token이 필요하다.

여기서 Refreah Token까지 탈취를 당하면?
정보를 지키는 것이 더 중요한 웹 애플리케이션은 Refresh Token을 사용하지 않는 곳이 많다.

---

3. JWT의 구조

• Header : JSON포맷 형태로 정의한다.
   - 어떤 종류의 토큰인지?
   - 어떤 알고리즘으로 암호화 하는지?
• Payload : 암호화된 정보라도 민감한 정보는 되도록 보함하지 않는다.
   - 유저의 정보
   - 권한을 부여 받았는가?
   - 기타 필요한 정보
• Signature : base64로 인코딩된 값은 누구나 쉽게 디코딩 할 수 있지만 서버에서 사용하고 있는 비밀 키 값이 없으면 해독하는데 엄청난 시간이 걸린다.
   - Header, Payload를 base64인코딩한 값과 salt값의 조합으로 암호화된 값

---

4. JWT의 장점 / 단점

• 장점
  1. 상태를 유지하지 않고, 확장에 용이한 애플리케이션을 구현하기 쉽다.
      - 서버에서 클라이언트에 대한 정보를 저장할 필요가 없고 토큰이 정상적으로 검증되는지만 판단한다.
      - 클라이언트는 request를 전송할 때 마다 토큰을 헤더에 포함시키면 된다.
  2. 클라이언트가 request를 전송할 때 마다 자격 증명 정보를 전송할 필요가 없다.
      - HTTP Basic 같은 인증 방식은 requset를 전송할 때 마다 자격증명 정보를 포함해야하지만 JWT는 토큰이 만료되기 전까지는 한번의 인증만 거치면 된다.
  3. 인증을 담당하는 시스템을 다른 플렛폼으로 분리하는 것이 용이하다.
      - 사용자의 자격 증명 정보를 직접 관리하지 않고, Github, Google등의 다른 플랫폼의 자격 증명 정보로 인증하는 것이 가능하다.
      - 토큰 생성용 서버를 만들거나, 다른 회사에서 토큰 관련 작업을 맡기는 것 등이 가능하다.
  4. 권한 부여에 용이하다.
      - 토큰의 내용물(Payload)안에 해당 사용자의 권한 정보를 포함하는 것이 용이하다.
• 단점
  1. Payload는 디코딩이 쉽다.
      - Payload는 base64로 인코딩 되기 때문에 탈취하여 Payload를 디코딩하면 토큰 생성시 저장한 데이터는 확인할 수 있다.
  2. 토큰의 길이가 길어지면 네트워크에 부하를 줄 수 있다.
  3. 토큰은 자동으로 삭제되지 않는다.
      - 토큰 삭제를 위해 반드시 만료 시간을 추가해야 한다.
      - 토큰이 탈취당한 경우 토큰의 기한까지 탈취자가 사용할 수 있으므로 너무 길게 설정하면 안된다.

---