JWT를 공부하며 여러 블로그 글들을 공부하다보니 내용적으로 훌륭한 글들이 너무 많아
"이렇게 얇게 알고 정리하는게 어떤 의미가 있을까" 싶었지만
내 나름의 이해를 정리해보고자 한다.
JWT는 사용자의 인증과 권한을 포함하는 일종의 키라고 할 수 있다.
JWT가 왜 필요한지를 알아보려면 먼저 이전에 사용하던
Session/Cookie 방식과 비교하여 장단이 무엇인지를 이해하는 것이 좋을 것 같다.
이미지 출처 : https://interconnection.tistory.com/74
참고글 : https://jihyun03.tistory.com/52
(Session/Cookie 방식에 대해 잘 정리된 글들로 추천!)
먼저 Session/Cookie 방식과 JWT를 비교해보자면 2가지가 가장 큰 차이라 생각한다.
- Server Memory에 사용자 접속 정보를 담고 있는가?
Session/Cookie 방식에서는 사용자가 Server에 접속하게 되면
Session ID라는 값을 생성하여
Cookie에 담아 사용자에게 돌려주고
Server Memory에도 Session ID를 저장한다.
그리고 이후 사용자가 다시 Server에 접속하면서
Header에 Cookie를 실어서 요청을 보내고
Server에 있는 Session ID와 Cookie의 Session ID를 비교하여 일치하면 사용자를 인증한다.
문제는 사용자가 늘어나면 Server에 저장해야 하는 Session ID가 계속해서 늘어나고
"Server Memory - (Session ID X 사용자수)" 가 되어 Memory에 부담이 된다는 것이다.
열쇠에 비유하자면 위와 같이 계속해서 열쇠 구멍(Session ID)이
문(Server Memory)에 추가되어야 하는것이다.
(정확히 말하면 같은 지를 비교하는 것이니 열쇠와 열쇠 구멍과는 좀 다르다.)
JWT는 이에 비해 도어락의 카드키라고 생각 할 수 있다.
문(Server) 도어락에 비밀번호(Secret Key)와 Logic을 가지고 있고
카드키(JWT)에 비밀번호(변형된 Secret Key + 사용자 정보)를 담고
추후 검증만 하면 된다.(일치하는지 비교와는 다름)
https://docs.aws.amazon.com/ko_kr/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-verifying-a-jwt.html (검증 방법)
- Server 개수를 늘리게 될때(Scale Out)
사용자가 늘어 Server를 증설해야 할 경우 위의 예로 이해하자면
Session/Cookie 방식의 경우 새 Server에 기존 Server가 가지고 있던
Session ID를 모두 전해줘야 하고 전해주기 전까지
기존 사용자는 새 Server에 접속하지 못하도록 막기까지 해야 한다.
그에 반해 JWT는 그냥 새 Server에 기존 Server의
비밀번호(Secret Key)와 Logic만 그대로 전해주면 끝이다.
또한 사용자 수에 따라 가변적인 Session ID에 비해
비밀번호(Secret Key)와 Logic는 고정이다.
물론 JWT라고 해서 장점만 있는 것은 아니다.
Session/Cookie 방식에 비해 JWT의 단점은 크게 3가지가 있다.
(출처 : https://tansfil.tistory.com/58)
- 이미 발급된 JWT에 대해서는 돌이킬 수 없음.
Session/Cookie 방식의 경우 만일 쿠키가 악의적으로 이용된다면
해당 세션을 지워버리면 된다.
하지만 JWT는 한 번 발급되면 유효기간이 완료될 때 까지는 계속 사용이 가능하다.
(특정 열쇠가 악의적이면 해당하는 열쇠 구멍을 막아버리면 되지만,
특정 카드키가 악의적이라고 하나뿐인 도어락을 떼어버릴 수는 없다.)
-> 해결책
기존의 Access Token의 유효기간을 짧게 하고
Refresh Token이라는 새로운 토큰을 발급.
그렇게 되면 Access Token을 탈취당해도 상대적으로 피해를 줄일 수 있음.
- Payload 정보 활용이 제한적(다음편 JWT 구조에서 Payload 설명)
Payload는 따로 암호화되지 않기 때문에 Decoding하면 누구나 정보 확인이 가능.
(Session/Cookie 방식에서는 노출되는 것은 생성된 Session ID 뿐)
따라서 유저의 중요한 정보들은 Payload에 넣을 수 없음.
- JWT의 길이는 상대적으로 길다.
Session/Cookie 방식에 비해 JWT의 길이는 길다.
따라서 인증이 필요한 요청이 많아 질수록 서버의 자원낭비가 발생.
Session ID를 Server에서 생성/저장하지 않고
Cookie에 사용자 정보(ID, PW, 권한)를 있는 그대로 담아 사용한다면
Cookie와 JWT가 유사하지 않을까 생각했지만
보안상 민감정보가 통신을 통해 그대로 전송되는 것은 위험하여 사용되지 않는 것 같다.
(자동 로그인 사용 여부 정도는 괜찮을듯?)
글 하나로 끝내려 했는데 생각보다 길어져서
JWT의 구조와 실제 구현은 다음 편에서 정리해야겠다!
<참고글>
https://velog.io/@ayoung0073/springboot-JWT
https://velopert.com/2350
https://tansfil.tistory.com/58
