JWT
JWT는 . 을 구분자로 3가지의 문자열로 구성된다. 헤더(header), 내용(payload), 서명(signature)로 구성
header
alg 와 typ 으로 구성
typ값은 jwt로 고정alg는 3번째 verify signature 값을 만드는데 사용될 알고리즘이 지정된다. 대표적으로 HMAC, SHA256, RSA 알고리즘이 있음.
payload
토큰에 담을 정보들이 들어있음. 각 정보들을 '클레임' 이라고도 함.
- sub: 토큰의 제목
- iss: 토큰 발급자
- aud: 토큰 대상자
- exp: 토큰의 만료시간. 시간은 NumericDate 형식으로 되어있어야 하며 언제나 현재 시간보다 이후로 설정되어 있어야 한다.
- iat: 토큰이 발급된 시간.
- jti: JWT 의 고유 식별자.
signature
-
1번 header, 2번 payload 을 합쳐 인코딩한 후, "서버에 감춰놓은 비밀 값" 으로 해싱해 생성한 고유값이다. header 의 알고리즘을 이용해 해싱한다. -> 이렇게 해싱한 값은 Base64 형태를 띄고 있다.
-
따라서 이 서버에서만 알고있는 비밀값을 모른다면 JWT 를 탈취해 Base64 디코딩 해봐도 정보를 알 수 없어 변조가 불가능하다.
-
JWT는 사용자의 상태를 따로 저장해둘 필요 없이 요청 들어올 때마다 JWT 디코딩해 인가하는 'stateless' 한 인증방식이다. 반대로 session 이용하는 인증방법은 'stateful' 한 인증방법이다.
JWT의 한계
-
JWT의 단점으로는 'stateless' 하다보니 JWT를 탈취할 경우 서버에서 제어가 불가능하는 점이 있다.
-> 이를 보완하기 위해 유효기간이 짧은 accessToken 과 유효기간이 상대적으로 긴 RefreshToken을 발급해 RefreshToken 정보를 서버에서 가지고 있는 방식을 사용한다. (결국 Refresh Token 을 사용해 서버에서 토큰정보를 갖고 있게되면 'stateful' 한 인증방식이 된다) -
RefreshToken 만 안전하게 관리된다면 accessToken 을 탈취당하더라도 악용에 의한 피해를 최소화할 수 있다. 하지만 accessToken 유효기간 내에서 악용되는 점을 막을 수 없어 JWT 인가 방식은 불완전한 방식이다. 따라서 실 서비스에서 JWT 만으로 인가를 구현하는 경우는 거의 없다.
인증/인가 Stateless vs Stateful
stateless
- 확장성: 각 요청이 독립적이므로, 시스템이나 애플리케이션의 확장성이 향상된다. 새로운 인스턴스를 추가하는 것이 비교적 간단하고, 서버 간의 동기화가 필요없다.
- 리소스 효율성: 서버가 사용자 상태를 추적하거나 저장할 필요가 없으므로, 메모리와 같은 서버 리소스를 보다 효율적으로 사용할 수 있다.
stateful
- 보안: 서버가 사용자의 상태를 추적하므로, 특정 세션을 무효화하거나 동시 세션을 제한하는 등의 추가 보안 조치를 취할 수 있습니다.
- 사용자 맥락 정보: 서버가 사용자의 이전 상태를 알고 있으므로, 이를 이용해 사용자 경험을 개선하거나 기능을 더욱 확장할 수 있습니다.
방식 선택
-
서버를 여러대 사용하며, 서비스 확장성이 중요한 대규모 서비스의 경우, 보안보다 성능이 중요한 경우, 중요한 개인정보가 필요 없거나 사용자 저장값이 적은 경우 stateless 방식을 선택하는 것이 유리하다.
-
보안 요구사항이 높은 경우, '한 기기에서만 로그인 할 수 있도록 하는 서비스' 등 사용자의 상태를 언제든 제어할 수 있어야 되는 경우, 사용자의 이전 상태를 알고 있어 '사용자 경험'이 중요한 경우 stateful 방식을 선택하는 것이 유리하다.
한 기기만 로그인 할 수 있도록 하는 서비스를 구현하는 방식은 다양하다. 그 중 Refresh Token 사용하는 방법을 설명하면, 일반적으로 로그인 할 때마다 Refresh Token 을 새롭게 발급하고, 이전의 Refresh Token을 무효화 해 이전 기기에서는 새롭게 로그인 해야 하는 방식으로 한 기기로만 로그인 하기 기능을 구현할 수 있다.
