🤷♂️ JWT란?
JWT는 Json Web Token의 줄임말이다.
모바일이나, 웹의 사용자 인증을 위해 사용하는 암호화 토큰으로
토큰에 있는 정보를 request에 담아서 사용자 관련 정보를 요청할 수 있다.
JWT 인증 방식은 이름에서 알 수 있듯이 토큰을 사용하는 토큰 기반 인증 방식이다.
JMT 아닙니다..
JWT를 사용하기 이전에는 세션을 통해서 사용자 인증을 진행하였다.
💁♂️ 토큰 기반 인증 시스템을 사용하는 이유
토큰 기반 인증 시스템을 사용하기 전에는,
클라이언트의 정보를 쿠키 라는 것을 사용하여 클라이언트 측에서 기억하고 있어야 했다.
Cookie?
- 클라이언트가 웹사이트에 접속할 때, 정보를 기록하게 되는 일련의 파일
이전에 접속했던 사이트의 대한 정보를 얻어올 수 있는 것도, 쿠키에 정보를 기록해 놓기 때문이다. 이전에는 이러한 쿠키 파일에 사용자의 ID, Password 까지 저장하여 사용했었다.
당연하게도, 쿠키에 민감 정보를 저장함으로써 보안 문제가 발생하게 되었다.
또한 웹 브라우저마다 쿠키 지원 형태가 달라 공유가 불가능하고 쿠키 사이즈가 제한되어 충분한 데이터를 저장할 수가 없었다.
쿠키의 보안 문제를 해결하기 위해 Session이 등장한다.
Session?
-
Session이란? 클라이언트의 요청에 따른 정보를 세션 아이디 파일을 만들어 서비스중인 서버의 (DB,메모리 등에) 저장하는 것
-
클라이언트가 서버한테 정보를 요청했을 때, 지속적인 메시지 교환을 위해서 통신을 마칠 때 까지 방문자 정보를 서버에 저장하는 논리적인 연결이다.
자물쇠로 치자면, 서버가 자물쇠가 되고 클라이언트가 가지는 식별 값이 ID가 되어, 서버에서 저장하고 있는 특정 인증 정보를 인증하게 되는 방식이다.
서버 기반 인증 시스템 흐름
하지만, 위 방식은 서버를 확장하는데 문제가 생긴다.
저장소 문제
세션을 메모리나, DB, 디스크에 저장하게 되면서 클라이언트의 수가 많아질 수록 서버의 램에 과부화가 걸린다거나, DB 성능에 문제가 생길 수 있다.
확장성
여러대의 서버로 확장하게 되었을 때, 유저가 처음 로그인 했던 서버로 요청을 보내지 않으면 인증이 되지 않기 때문에 확장성에 문제가 생긴다.
🤷♂️ 그래서 JWT가 뭔가요?
- 인증에 필요한 정보들을 Token에 담아 암호화 시켜서 사용한다.
- stateless - 토큰 자체가 인증된 정보이기 때문에 별도의 세션 저장소가 필요하지 않다.
JWT 구조
- HTTP의 헤더로 전달될 때 문자열의 형태로 인코딩하게 된다.
- .을 기준으로 Header, Payload, Signature을 구분하게 된다.
해당 토큰을 Json 형식으로 디코딩하면 다음과 같은 구조를 가진다.
Header
alg는 해싱 알고리즘, typ는 토큰 타입을 의미한다.
Payload
토큰의 담을 정보(클라이언트의 고유 ID값, 생성날짜 등) 를 지닌다.
Signature
String으로 인코딩 된 Header와 Payload를 더한 뒤 비밀키로 해싱한다. Header와 Payload는 노출 될수 있는 단순 String 값이지만, Signature은 서버에서 관리하는 비밀키로만 복호화 할 수 있기 때문에 토큰의 위변조 여부를 확인할 수 있다.
인증 과정
- 클라이언트의 고유 ID 등의 정보를 Payload에 담아 서버에 전달한다.
- 서버에서의 비밀키를 통해 암호화하여 JWT(Acess Token을 발급한다.
- 클라이언트는 발급받은 토큰을 가지고 요청할 때 마다 포함시켜 전달한다.
- 서버는 토큰의 Signature을 비밀키로 복호화하여 위변조 여부 및 유효기간을 확인하고, 유효하다면 응답한다.
이처럼 유저의 인증 정보를 세션에 담아두지 않기 때문에 stateless 하다고 말할 수 있다.
물론, 장점이 있는 만큼 단점도 존재한다.
단점
- JWT 토큰의 길이가 길어, 인증 요청이 많아지면 그만큼 네트워크 부하가 심해진다.
- Payload에 중요한 정보를 담을 수 없다.
- 토큰 탈취에 대처하기 어렵다.(한번 발급되면 유효기간 만료 전까지 사용이 가능하기 때문)
- 특정 사용자의 접속을 강제 만료하기 어렵다.
❌보안 전략
JWT 사용시 위와같은 단점들을 보완하기 위한 전략으로 다양한 방법을 채택할 수 있다.
짧은 만료 기한 설정
토큰의 만료 시간을 짧게 설정하여, 탈취 시 피해를 최소화 한다. 하지만 사용자가 자주 로그인해야 하는 단점이 있다.
Refresh Token
클라이언트가 로그인 요청을 보내면 Access Token 보다 긴 만료 기간을 가지는 Refresh Token을 발급하는 전략이다. 클라이언트는 Access Token이 만료되었을 때 Refresh Token을 사용하여 Access Token의 재발급을 요청하고, 서버가 이를 식별하여 만료된 경우 사용자 인증을 요구한다. 이를 통해 Access Token의 만료 기한을 짧게 설정할 수 있고, 서버가 강제로 Refresh Token을 만료시킬 수 있다.
그러나, Refresh Token을 서버의 저장소에 저장해야 하므로 추가적인 I/O 작업이 발생하여 빠른 인증을 자랑하는 JWT의 장점을 상쇄시킨다.
Sliding Session
지속적으로 서비스를 이용하는 클라이언트에게 자동으로 토큰 만료 기한을 늘려주는 방법이다.
ex) 글 작성 도중 토큰이 만료가 되는 경우, 작성한 글이 날아가는 상황을 해결할 수 있다.
참고 블로그
https://webcoding-start.tistory.com/50
https://tech.toktokhan.dev/2021/04/30/JWT/https://tecoble.techcourse.co.kr/post/2021-05-22-cookie-session-jwt/
https://tecoble.techcourse.co.kr/post/2021-05-22-cookie-session-jwt/
JMT 설명 글 잘 보고 갑니다~! 글이 존맛탱이네요~!~!