이번학기 서버시스템구축실습과정에서
“기획+디자인+구현”부터 웹 서비스까지 한 학기에 다 하는 아주 무서운 팀 프로젝트를 진행하고 있습니다.(요즘은 덕분에 머리와 몸이 열 개도 모자라…^_ㅠ 수업 따라갈까, 팀플레이할까)
이 팀에서 구현해야 할 기능들.. 웹서비스라면 구현해야 할텐데…
로그인 기능수업 회원 인증 기능..!!
따라서 공부는 필수라고 생각합니다.
요즘 열심히 공부중
아래는 제가 배운 내용을 간략하게 요약한 것입니다!
이 기능들.. 꼭 구현하겠습니다..
(회원 인증 기능 구현 방법):
세션 VS 토큰
→ 둘 중 하나를 사용하여 구현 가능! 둘의 행동은 비슷하다.
: 사용자 로그인 → 서버에서 티켓 발권 → 이후에 회원 전용 기능을 사용하려면 사용자가 서버에 티켓만 제출하면 서버에서 확인 및 승인
(둘의 차이점)
→ 세션 : 승차권에 대한 정보가 거의 없음(발권번호에 대한 정보만 있음)
< When a member presents a ticket to the server, the server searches and approves the ticket issuance list (session store) created separately in memory or DB >
⇒ 불리! 구성원이 너무 많으면 많은 구성원이 동시에 로그인하거나 그만큼의 구성원으로 인증할 때마다 목록을 확인해야 하므로 서버의 부담이 가중된다.
VS
→ 토큰 (일명 JWT): 티켓에 대한 많은 정보(회원 이름, 이메일, 발행일, 만료일 등…)
< When a member presents a ticket to the server, the server only looks at the ticket itself when inspecting the ticket, checks the validity period, and approves it >
⇒ 장점! Stateless (멤버가 많을수록 서버 X의 부담이 커집니다. 티켓 자체만 확인하면 됩니다.)
하지만.. 토큰방식은 허점도 있습니다…
1. 비밀키를 함부로 생성하면 무차별 대입 공격에 쉽게 뚫린다. )
2. alg:none 공격에 대비(-솔루션: 최신 라이브러리 사용)
3. 해독하기 쉬움(base64) (-솔루션: 최소한의 정보를 토큰에 담음)
4. 탈취 가능
(-솔루션: (1) 훔치기 어려운 저장소(HttpOnly 쿠키)에 저장, (2) 티켓 블랙리스트(단, 세션 방법 X와 다름), (3) 더 짧은 JWT 유효 기간! → *티켓에 대한 새로 고침 토큰 재발급 필요)
*단, 리프레시 토큰도 도난당할 수 있음 → 리프레시 토큰 로테이션(리프레시 토큰 재발급/재사용 확인 시 재발권 티켓 재발급)이라는 방법을 이용하세요 ^^)
(+) passport-jwt 라이브러리는 토큰 생성만을 검증하므로 Refresh Token과 같은 기능을 제대로 사용하려면 별도로 개발해야 합니다… ^_ㅠ
(결론):
대부분의 서비스는 역사와 전통이 깊은 세션 방식으로 회원을 인증합니다! 그러나 구성원이 너무 많거나 마이크로 서비스가 너무 많은 경우 JWT가 더 나을 수 있습니다.
(보안에 좀 더 신경쓰고 싶다면 JWT + 다른 보안기기나 세션 방식이나 타사 인증 방식(카카오 로그인)..!)
학습 콘텐츠 출처: https://youtu.be/XXseiON9CV0