JWT 이해 및 활용 방향에 대해

JWT 이해 및 활용 방향

---

[정의]

• JSON Web Token의 약자
• 선택적 서명 및 암호화를 사용하여 JSON 데이터를 보관하고 있는 인터넷 표준 웹 토큰입니다.

[사용이유]

• 사용자 인증 처리

[특징]

• 서버에 정보를 저장하지 않는다.
• Signature는 option값이지만, 사용한다면 Signature 값을 통해 Header와 Payload가 변형이 되었는지 안되었는지 확인이 가능하다
• 서버가 클라이언트 쪽에 만들어서 주는 값이다.

[구조]

• Header, Payload, Signature 3가지로 구성되어있음
  • Header
    • typ
      • Token 타입을 나타냄. ex) JWT
    • alg
      • Signature를 hashing 하기 위한 암호화 알고리즘.

      {
      	  "typ" : "JWT",
            "alg" : "HS256" // or RSA
      }
    

  • Payload
    • 사용자의 인증에 필요한 정보를 담는다.
    • 단, 절대 개인정보를 담아선 안된다.
      • JWT를 알고 있다면 JWT Decoder에 의해서, Header와 Payload를 누구나 확인가능하기 때문
    • Base64로만 인코딩 됨
    • 일반적으로 고유한 값인 id값, 그리고 해당 토큰의 만료시각 정도를 넣는다고 한다.
  • Signature
    • 헤더의 인코딩값(Base64)과, 정보의 인코딩(Base64)값을 합친후 서버가 가지고 있는 비밀키로 해쉬를 하여 생성

[현실상황]

1. JWT가 탈취당하면 어떻게 할 것 인가?
   • JWT(access_token)과 Refresh token으로 대응 한다.
     • 클라이언트는 Access Token이 만료되었다는 오류를 받으면
     • 따로 저장해두었던 RefreshToken을 이용하여 Access Token의 재발급을 요청한다.
     • 서버는 유효한 RefreshToken으로 요청이 들어오면 새로운 AccessToken을 발급하고,
     • 반대로 만료된 RefreshToken으로 요청이 들어오면 오류를 반환해, 사용자에게 로그인을 요구한다.
   • Refresh Token의 경우는 JWT와 달리 DB에 저장하며, 문제가 생길 경우, 강제로 만료시킬 수 있다.
   • Access Token과 Refresh Token을 모두 사용하여 인증하는 로직의 순서는 다음과 같다.
     • 최초 로그인 시에 AccessToken / RefreshToken을 모두 발급한다.
     • 이후 AccessToken을 가지고 요청한다.
     • AccessToken이 만료되었을 경우에, RefreshToken을 가지고 AccessToken을 재요청하여 발급받는다.
     • 만약 RefreshToken이 만료되었을 경우, 로그인을 요청하고 AccessToken/RefreshToken을 다시 발급시킨다.
2. Refresh Token은 어디다가 저장해야 하는가?
   1. Cookie에서 HttpOnly 옵션을 사용하여 어느정도 보안을 챙긴다
   2. HttpOnly 옵션을 동작시키면, 외부에서 Cookie에 접근을 할 수가 없다.
   3. 단, 브라우져가 HttpOnly 옵션을 지원안하면 의미가 없다..

[참고]

https://velog.io/@tlatldms/서버개발캠프-Refresh-JWT-구현