Token] JWT (JSON Web Token)

인증토큰의 대표인 JWT에 대해 공부하려고 합니다.

(다른 토큰이 있는지 모르겠지만...)

 

JWT(JSON Web Token)는 인증에 필요한 정보를 암호화시킨 JSON형태의 서명된 토큰입니다.

저번 글에서 배웠던 토큰인증을 할 때 사용되는 방식?입니다.

 

https://jwt.io/

 

 

---

 

 

특징

• JWT토큰은 발급하면 별도로 삭제가 불가능하며 유효시간을 통해 관리하게 됩니다.
• JWT토큰을 사용하면 DB조회를 하지 않고, 인증을 확인할 수 있습니다.
• 데이터의 변조를 막을 수 있습니다.
• 서버 측에서 별도의 저장소가 필요 없습니다. (클라이언트에서 주로 쿠키나 웹스토리지에 저장해서 관리)
• 유효기간으로 Auth를 관리하기 때문에 기간을 짧게 하면 자주 로그인 해야 되고, 길게 하면 보안에 취약하게 됩니다.
• 토큰의 길이가 길어질 경우, 네트워크에 부하를 줄 수 있습니다.

 

 

---

 

 

구조

Header.Payload.Signature

총 3개의 문자열이 합쳐진 것을 JWT라고 합니다.

• Header : JWT에서 사용할 타입과 해시 알고리즘의 종류
• Payload : 사용자 권한 정보와 데이터
• Signature : Header, Payload를 해시함수를 적용시킨 뒤, 전자서명

 

 

Header

JWT에서 사용할 타입과 해시 알고리즘의 종류를 담아줍니다.

• alg : 서명 암호화 알고리즘
• typ : 토큰 유형

(다른 것들도 있을 거 같기는 한데... 찾아보는 거 마자 HS256과 JWT밖에 안 보인다.)

 

 

---

 

 

Payload

토큰에서 사용될 정보들이 담겨 있습니다.

Key-Value형식으로 이루어져 있고, 정보 한 묶음을 Claim이라고 지칭한다고 합니다.

Registered claims, Public claims, Private claim 총 3가지로 나뉜다고 한다.

 

• Registered claims : 미리 정의한 클레임
  • sub : 제목
  • iss : 발행자
  • lat : 발행 시간
  • exp : 만료 시간
• Public claims : 사용자가 정의할 수 있는 공개용 정보 클레임. 충돌 방지를 위해 URL 포맷을 이용
  • 위 예시에서 https://wanga... 이 부분이 해당된다.
• Private claims : 서버와 클라이언트 간에 정보를 공유하기 위해 만들어진 클레임.
  
  • 위 예시에서 username: wanga 이 부분이 해당됩니다.

 

 

---

 

 

Signature

Header에서 정의한 알고리즘 방식(alg) 값을 활용하게 됩니다.

Header와 Payload와 서버가  가지고 있는 유일한 key값을 합치면 됩니다.

 

 

전체적으로 취합해서 토큰을 만들게 되면 아래와 같습니다.

https://jwt.io/

 

 

728x90

 

 

Refresh Token

기본적으로 서버에서 JWT토큰을 발행할 때는 2개의 종류(AccessToken, RefreshToken)로 토큰을 발행합니다.

토큰의 값은 같지만 유효시간만 다른 토큰입니다.

Refresh Token도 Access Token과 마찬가지로 쿠키나 웹스토리지에 저장됩니다.

 

Refresh Token을 추가로 발행하는 이유는

Access Token이 탈취당할 위험이 높기 때문인데, 탈취한 Access Token을 통해서 서버에 접근이 가능하기 때문입니다.

이런 문제를 Access Token은 가지고 있기 때문에 Refresh Token이라는 또 하나의 토큰을 유효기간을 길게 발행하여 Access Token이 만료 됐을 때, 새로 발급해 주는 토큰을 발행하게 됩니다.

(클라이언트에서 Access Token이 만료된 것을 Payload를 통해 알 수 있으니, 애초에 재발급을 요청할 수도 있습니다.)

 

Access Token이 기간이 만료된 상태에서 서버로 보내지게 되면,

서버는 만료됐다는 응답을 보내게 되고,

그때  Access Token과 Refeash Token을 같이 보내면서 새로운 Access Token을 발급하게 되고

클라이언트에서도 Access Token이 업데이트 되게 됩니다.

 

로그아웃 하게 되면 두 개의 토큰은 삭제되게 됩니다.

 

주로 Refresh Token은 2주, Access Token은 1~2시간의 유효기간을 갖게 발급합니다.

Refresh Token도 탈취될 가능성이 있기 때문에 너무 길면 안 되고, 토큰 탈취의 위험이 완전히 해결된 것은 아닙니다.

 

 

---

 

 

동작 순서

1. 사용자가 로그인을 시도하여 서버에 요청을 보냅니다.
2. 클라이언트로부터 요청을 받은 서버는 DB조회하여 사용자 로그인정보를 확인한 뒤,
   JWT토큰을 Header.PayLoad.Signature로 만들고 암호화하여 토큰을 생성합니다.
3. 생성된 토큰을 쿠키에 담아 클라이언트에 전달하게 됩니다.
4. 서버로부터 응답을 받은 클라이언트는 쿠키에 담긴 토큰 값을 쿠키, 로컬스토리지 등에 저장하게 됩니다.
5. 클라이언트는 이제 API를 요청할 때, Authorization header값에 토큰값을 담아서 보내게 됩니다.
6. 서버는 이제 클라이언트로부터 요청받을 때마다 토큰 값을 확인하면 됩니다.
7. 만약 클라이언트로부터 요청을 받았는데 토큰 값이 만료되었을 경우,
   클라이언트는 Refresh Token을 통해 Access Token을 재발급받게 됩니다.

 

 

---

 

 

Cookie, Session에 이어 Token, JWT까지 해서 공부했습니다.
자세히 신경 안 쓰고 개발만 했었는데, 개념 잡고 생각하면서 개발을 할 수 있을 듯싶습니다.
Auth 쪽은 결국 안 쓰이는 곳이 없으니...

Cookie Session JWT 3개를 비교해 가면서 서로 쓰이는 것을 확인하면 좋을 듯싶습니다.