🔐회원 인증 기능 : 세션 VS 토큰

✏️ 이번 학기에 서버시스템구축실습이라는 과목에서
웹서비스를 “기획+설계+구현”까지 한 학기 안에 모두 해보는 아주 어마무시한 팀프로젝트를 진행하고 있는데,
(덕분에 머리와 몸이 정말 열개여도 모자란 요즘이다…^_ㅠ 수업도 따라가랴 팀플도 하랴🥲)
이 팀플에서 내가 맡은 기능은… 웹서비스라면 반드시반드시반드시 꼬옥 구현되어야하는…
로그인 기능과 회원 인증 기능..!!😂

그래서 이와 관련한 공부는 필수적이라고 생각되어,,
요즘 나름 열심히 공부 중이다😇🔥
아래는 내가 공부한 내용을 간단히 정리해본 것! (물론 앞으로 더 공부할 예정이다😉)
이 기능들..어떤 방식으로든 꼭꼭 구현해내고 말거다..👩🏻‍💻

🔑[ 회원 인증 기능의 구현 방식 ] :

세션(session) VS 토큰(token)
→ 둘 중 하나 이용하면 구현 가능! 둘의 동작 방식은 유사함
: 유저가 로그인 → 서버가 입장권 발급 → 이후 회원 전용 기능을 이용하고 싶으면 유저는 입장권만 서버에 제출하면, 서버가 확인하고 승인

‼️ [ 둘의 차이점 ]

→ 세션(session) : 입장권에 little 정보(발급번호 정도만)
< 회원이 입장권을 서버에 제시하면, 서버가 메모리나 DB에 따로 만들어둔 입장권 발급 목록(세션 스토어)에서 조회한 뒤 승인 >
⇒ 단점! 회원이 매우 많아지면, 그 많은 회원들이 동시접속할때, 그 수많은 회원들을 인증 할때마다 목록을 확인해야하므로 서버에 부담 증가

VS

→ 토큰(token) (aka JWT) : 입장권에 many 정보(회원명, 이메일, 발급일, 유효기간, etc …)
< 회원이 입장권을 서버에 제시하면, 서버는 그 입장권을 검사할때 입장권 자체 하나만 보고, 유효기간 확인 뒤 승인 >
⇒ 장점! stateless하다 (회원이 매우 많아질수록 서버에 부담 X. 입장권 자체만 확인하면 되니까~)

BUT.. 토큰 방식에는 허점들도 있다..
1. secret key 대충 만들면 brute force 공격에 쉽게 뚫림(-해결책 : 길게 만들고 공유금지! / 더 엄격한 해결책 : 생성용 키&검증용 키(private 키&public 키) 이용!)
2. alg:none 공격 대비(-해결책 : 최신 라이브러리 이용)
3. 디코딩이 쉬움(base64) (-해결책 : 최소한의 정보만 토큰에 넣기)
4. 탈취 가능
(-해결책 : (1)훔치기 어려운 저장소에 보관(HttpOnly cookie), (2)입장권 블랙리스트(근데 이건 세션 방식이랑 차이X), (3)JWT 유효기간을 짧게! → 입장권 재발급을 위한 *refresh token 필요)

*근데 refresh token도 탈취당할 수 있음 → refresh token rotation 이라는 방법 이용(refresh token을 재발급/재사용하는 걸 발견하면 입장권 재발급 X == 즉, refresh token은 언제나 1회용(구현이 복잡하므로 라이브러리 잘 찾기..^^)

(+) passport-jwt 라이브러리는 토큰 생성 검증만 하므로, refresh token같은 기능을 제대로 쓰고 싶으면 따로 개발해야…^_ㅠ

💫 [ 결론 ] :

대부분의 서비스들은 역사와 전통이 깊은 세션 방식으로 회원을 인증함! 근데 만약 회원이 너무 많거나, 마이크로 서비스가 많으면 JWT가 더 나을 수도 있다~
(보안에 더 신경쓰고 싶으면, JWT+다른 보안장치 or 세션 방식 or 타사 인증방식(카카오 로그인)..!)



👩🏻‍🏫학습 내용 출처 : https://youtu.be/XXseiON9CV0