JWT(Json Web Token)

JWT란?

인증에 필요한 정보를 암호화시킨 토큰

다른 토큰 중 JWT는 전자 서명을 한다는 점이 다릅니다.

또한 JWT 를 사용하면 이점이 있습니다.

• 전자 서명(Digital Signature) 된 토큰을 이용해 스케일 문제를 해결할 수 있다.

오늘은 JWT의 구조, 장점, 단점 등을 알아보겠습니다.

구조

헤더(Header),페이로드(payload),서명(signature) 세 파트를 . 으로 구분하는 구조이다.

JWT를 검증하는데 필요한 정보를 가진 JSON 객체는 Base64로 인코딩된 문자열이다.
인코딩된 토큰을 Base64로 디코딩하면 아래와 같다.

Header
헤더는 jwt를 어떻게 검증(verify)하는가에 대한 내용을 담고있다. alg는 서명시 사용하는 알고리즘이고, typ은 Type을 줄인 말로 토큰의 타입을 의미한다.

Payload
JWT의 내용. 페이로드에 있는 속성들을 클레임 셋(Claim Set)이라고 부른다. 클레임 셋은 jwt에 대한 내용(토큰 생성자의 정보, 생성일시,,,)이나 클라이언트와 서버 간 주고받기로 한 데이터들로 구성된다.

Signature
점(.)을 구분자로 해서 헤더와 페이로드를 합진 문자열을 서명한 값. 서명은 헤더의 alg에 정의된 알고리즘과 비밀 키를 이용해 생성하고 Base64로 인코딩 한다. 토큰의 유효성 검사에 사용된다.

서명시 사용하는 알고리즘

1. HMAC(시크릿키를 포함한)-SHA256(해쉬 : 256bit로 구성)

• 단방향 암호화 = 복호화 불가능
• hash 함수의 일종

2. RSA

• 양방향 암호화 = 복호화 가능
• 공개키, 개인키가 있음
• 개인키: header와 payload를 암호화해서 signature를 만든다.
• 공개키: 검증시에 공개키로 signature를 열어본다.

JWT로그인(인증) 과정

1. 서버는 사용자의 아이디와 비밀번호를 서버에 저장된 아이디와 비밀번호에 비교한다.
2. 만약 인증된 사용자인 경우 사용자의 정보를 이용해 {헤더}.{페이로드} 부분을 작성하고 자신의 시크릿키로 {헤더}.{페이로드} 부분을 전자 서명한다.
3. 전자 서명의 결과로 나온 값을 {헤더}.{페이로드}.{서명}으로 이어붙이고 Base64로 인코딩한 후 반환한다.

인가 과정

1. 누군가 이 토큰으로 리소스 접근을 요청한다.
2. 서버는 이 토큰을 Base64로 디코딩 후 얻은 JSON을 {헤더}.{페이로드}와 {서명} 부분으로 나눈다.
3. 서버는 {헤더}.{페이로드}와 자신이 갖고 있는 Secret 으로 전자 서명을 만든 후 방금 만든 전자 서명과 요청으로 들어온 {서명}부분을 비교해 유효성을 검사한다.

장점

1. header와 payload 를 가지고 signaure를 생성하므로 데이터 위변조를 막을 수 있다.
2. 인증 정보에 대한 별도의 저장소가 필요없다. (서버 부하 ↓)
3. JWT는 토큰에 대한 기본 정보과 전달할 정보 및 토큰이 검증 되었다는 서명 등 필요한 모든 정보를 자체적으로 지니고 있다.
4. 토큰은 한 번 발급되면 유효기간이 만료될 때까지 계속 사용이 가능하다.

단점

1. 쿠키나 세션과 다르게 JWT는 토큰의 길이가 길어 인증 요청이 많아질수록 네트워크 부하가 심해진다.
2. payload 자제는 암호화되지 않기 땨문에 유저의 중요한 정보를 담으면 안된다.
3. 토큰을 탈취당하면 대처하기 어렵다.
4. 특정 사용자의 접속을 강제로 만료하기 어렵지만, 쿠키/세션 기반 인증은 서버 쪽에서 쉽게 세션을 삭제 할 수 있다.

🔑 보안 전략

1. 짧은 만료 기한 설정
   토큰의 만료 시간이 짧으면 탈취되더라도 금방 만료되기 때문에 피해를 최소화 할 수 있다. 하지만 사용자가 자주 로그인 해야하는 불편함이 있다.

2. Sliding Session
   예를들어 로그인하고 글을 작성하는 도중 토큰이 만료 된다면 저장 작업이 정상적으로 작동하지않고 작성한 글이 날아가는 일이 생기는 등 불편함이 존재한다. Sliding Session은 서비스를 지속적으로 이용하는 클라이언트에게 자동으로 토큰 만료 기한을 늘려주는 방법이다. 1번의 자주 로그인해야하는 단점을 보완시켜준다.

3. Refresh Token
   클라이언트가 로그인 요청을 보내면 서버는 Access Token과 그보다 만료기간이 긴 Refresh Token을 함께 내려준다. 클라이언트는 Access Token이 만료되었을 때, Refresh Token을 사용하여 Acess Token의 재발급을 요청한다. 서버는 DB에 저장된 Refresh Token과 비교하여 유요한 경우 새로운 Access Token을 발급하고, 만료된 경우 다시 로그인 시킨다.
   검증을 위해서는 서버에 Refresh Token을 별도로 저장시켜야한다.

기존에 발급한 jwt 만료시키는법

RefreshToken은 서버에서 따로 저장을 하고 있기 때문에 강제로 토큰을 만료시키는 것이 가능합니다. -> RefreshToken 만료

모든 사용자 jwt 탈취되었을때 모두 만료시키는법