[네트워크] JWT 토큰

JWT (JSON Web Token)

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

JWT 토큰 (Access Token)을 HTTP 헤더에 실어 서버가 클라이언트를 식별함

. 을 구분자로 나누어진 세개의 문자열의 조합

Header.Payload.Signature

Header

정보를 암호화할 해싱 알고리즘 및 토큰의 타입을 지정

Payload

토큰에 담을 정보 지정 (클라이언트의 고유 ID값, 유효기간 등이 포함)

key-value 형식

Signature

인코딩된 Header와 Payload를 더한 뒤 비밀키로 해싱하여 생성

토큰의 위변조 여부를 확인하는데 사용한다.

Header와 Payload는 단순히 인코딩된 값이기 때문에 제 3자가 복호화 밎 조작 가능하나,

Signature는 서버 측에서 관리하는 비밀키가 유출되지 않는 이상 복호화할 수 없다.

인증 과정

{
	Authorization: <type> <access-token>
}

1. 클라이언트 로그인 요청이 들어오면, 서버는 검증 후 클라이언트 고유 ID 등의 정보를 Payload에 담는다.
2. 암호화할 비밀키를 사용해 Access Token(JWT)을 발급한다.
3. 클라이언트는 전달받은 토큰을 저장해두고, 서버에 요청할 때 마다 토큰을 요청 헤더 Authorization에 포함시켜 함께 전달한다.
4. 서버는 토큰의 Signature를 비밀키로 복호화한 다음, 위변조 여부 및 유효 기간 등을 확인한다. //
5. 유효한 토큰이라면 요청에 응답한다.

장점

1. Header와 Payload를 가지고 Signature를 생성하므로 데이터 위변조를 막을 수 있다.
2. 인증 정보에 대한 별도의 저장소가 필요없다.
3. JWT는 토큰에 대한 기본 정보와 전달할 정보 및 토큰이 검증됐음을 증명하는 서명 등 필요한 모든 정보를 자체적으로 지니고 있다.
4. 클라이언트 인증 정보를 저장하는 세션과 다르게, 서버는 무상태가 된다. ?
5. 확장성이 좋다.
6. 토큰 기반으로 다른 로그인 시스템에 접근 및 권한 공유가 가능하다. ?
7. OAuth의 경우 Facebook, Google 등 소셜 계정을 이용하여 다른 웹서비스에서도 로그인을 할 수 있다.
8. 모바일 어플리케이션 환경에서도 잘 동작한다.

단점

1. 쿠키/세션과 다르게 JWT는 토큰의 길이가 길어, 인증 요청이 많아질수록 네트워크 부하가 심해진다.
2. Payload 자체는 암호화되지 않기 때문에 유저의 중요한 정보는 담을 수 없다.
3. 토큰을 탈취당하면 대처하기 어렵다. (토큰은 한 번 발급되면 유효기간이 만료될 때 까지 계속 사용이 가능하기 때문)
4. 특정 사용자의 접속을 강제로 만료하기 어렵지만, 쿠키/세션 기반 인증은 서버 쪽에서 쉽게 세션을 삭제할 수 있다. ?

보안 전략

JWT 사용시 위의 단점들을 극복하기 위해 다양한 방법을 사용할 수 있다. 각각의 전략은 장단점이 다르기 때문에, 서비스의 특성을 고려하여 보안 수준을 높일지 사용자의 편의성을 높일지 결정해야 한다.

1. 짧은 만료 기한 설정

토큰의 만료 시간을 짧게 설정한다. 그러면 토큰이 탈취되어도 빠르게 만료되기 때문에 피해를 최소화할 수 있습니다. 그러나 사용자가 자주 로그인해야 하는 불편함이 있다.

2. Sliding Session

글을 작성하는 도중 토큰이 만료가 된다면 Form Submit 요청을 보낼 때 작업이 정상적으로 처리되지 않고, 이전에 작성한 글이 날아가는 등의 불편함이 있다. Sliding Session은 서비스를 지속적으로 이용하는 클라이언트에게 자동으로 토큰 만료 기한을 늘려주는 방법이다. 글 작성 혹은 결제 등을 시작할 때 새로운 토큰을 발급해줄 수 있다. 이를 통해 사용자는 로그인을 자주 할 필요가 없어진다.

3. Refresh Token

클라이언트가 로그인 요청을 보내면 서버는 Access Token 및 그보다 긴 만료 기간을 가진 Refresh Token을 발급한다. 클라이언트는 Access Token이 만료되었을 때 Refresh Token을 사용하여 Access Token의 재발급을 요청한다. 서버는 DB에 저장된 Refresh Token과 비교하여 유효한 경우 새로운 Access Token을 발급하고, 만료된 경우 사용자에게 로그인을 요구한다.

해당 전략을 사용하면 Access Token의 만료 기한을 짧게 설정할 수 있으며, 사용자가 자주 로그인할 필요가 없다. 또한 서버가 강제로 Refresh Token을 만료시킬 수 있다.

그러나 검증을 위해 서버는 Refresh Token을 별도의 storage에 저장해야 합니다. 이는 추가적인 I/O 작업이 발생함을 의미하기 때문에 JWT의 장점(I/O 작업이 필요 없는 빠른 인증 처리)을 완벽하게 누릴 수 없다. 클라이언트도 탈취 방지를 위해 Refresh Token을 보안이 유지되는 공간에 저장해야 한다.

 

 

RFC7519 표준

인증 방식 : Cookie & Session vs JWT

JWT (JSON Web Token) 이해하기와 활용 방안 - Opennaru, Inc.