로그인 구현 방식 변경- Session vs JWT
팀에서 로그인 구현 방식을 기존의 JWT 대신 세션 방식으로 변경하기로 결정하였다. 주 이유는 서비스 특성을 고려하였을 때 세션 방식이 더 적합하다고 생각하였다.
JWT가 우리와 맞지 않다고 판단한 이유
1. jwt의 장점이 우리 서비스에도 장점인가?
answer: no
jwt가 가진 장점인 서버 확장성이 좋다는 장점은 우리 서비스의 규모를 생각해 봤을 때 크게 도움이 되진 않으리라 생각했다.
이유는 다음과 같다.
- 지스트는 학부가 한 학년에 200명인 소규모 학교고, 대학원, 교직원 인원까지 해도 인원이 그리 많지는 않은 학교이다.
- 청원사이트라는 서비스 특성상 단시간에 많은 트래픽이 몰릴 가능성이 적다.
따라서 하나의 서버로도 충분히 커버가 가능한 서비스이기 때문에 서버확장성이 좋다는 장점은 우리 서비스엔 큰 구미가 당기지 않는 부분이었다.
- 청원사이트라는 서비스 특성상 단시간에 많은 트래픽이 몰릴 가능성이 적다.
2. 필수가 되버린 DB 접근
우리의 기존 JWT 방식은 토큰으로 유저를 특정하기 위해서 토큰 안에 user의 이메일을 담아서 보냈다.
jwt payload 자체는 base64로 인코딩만 되어있을뿐 암호화가 되어있지 않기 때문에 private한 정보를 담지 않는 것이 좋기 때문에 이메일주소를 담았다.
하지만, 이메일주소만 가지고는 해당 유저가 가지고 있는 다른 정보들을 얻어낼 수 없기에 해당 유저의 다른 정보들(userRole 등)을 얻으려면 결국 userDB를 찔러서 해당 유저의 유저id를 얻어온 후, id를 이용해 다른 정보를 얻어내야 했다.
이를 세션으로 구현한다면?
이를 만약 세션 방식으로 구현한다면,
메모리에 생성해 둔 세션 저장소 안에 세션ID를 key로, 유저 객체를 value로 해서 담아두고 있다가, 세션ID에 해당하는 유저 객체를 찾는 요청이 오면 유저 객체를 반환하기만 하면 되므로, DB를 접근할 필요가 없어진다.
따라서 우리는 위와 같은 이유들로, jwt에서 세션 방식으로 변경하기로 하였다.
