우리에게 가장 기본적인 기능이며 우리가 평상시에 뗄 수 없는 존재에요.
가볍게 로그인 방식과 취약점에 대해서 알아보고 구현 방식을 하나씩 이해 해보려 해요.
로그인 방식
로그인 방식은 기본적으로 JWT 토큰 방식과 Session 방식이 있어요.
Session
Stateful 구조로 상태는 서버에서 저장하며 몇 가지 세션 방식과 해당 방식에 문제점과 보완점을 예를 들어볼게요.
아래는 Session 방식을 통한 인증 방식 사례예요.
Stickty Session
가장 간단한 방식으로 세션 공유 저장소 없이도 다중 서버를 운영이 가능하나 해당 서버가 죽으면 세션이 유실되는 구조에요.
즉, 임시 방편이라고 생각하시면 돼요.
세션 클러스터링
클라이언트의 세션을 다중서버에 동기화 하는 방식이에요. 하나의 서버가 죽어도 하나의 서버 내에서 세션이 유지되기 때문에 서버 별로 세션을 동일하게 가져갈 수 있는 구조에요. 하지만 서버가 많아 질 경우 해당 서버 별로 동기화 해야 된다는 단점이 있죠.
외부 세션 저장소
외부 세션 저장소를 두고 여러 서버가 해당 서버에서 세션을 검색하는 형태에요. 서버 별로 동기화 할 필요가 없이 외부 세션 저장소를 바라보기 때문에 확장에 용이하며 설정 또한 간단해요. 하지만 특정 외부 세션 저장소에 의존적이라는 단점이 있어요.
이처럼 단점에 비해 리소스와 고가용성 측면에선 외부 세션 저장소가 너무나도 매력적인 방식이 있지만, 학습 목적이 아닌 비즈니스 전반적 구조 설계 시 해당 리소스에 맞게 설계하는 것이 무엇보다 중요해요.
JWT
Stateless 구조이며 서버가 토큰을 발급하고 해당 토큰을 클라이언트가 관리하게 되며 서명검증과 만료를 서버에서 검증해요.
✅ JWT는 세 가지 문자열을 조합해요.
헤더(Header)의 경우 타입과 각종 알고리즘 정보를 담아요.
페이로드(Payload)의 경우 요청 데이터를 담아요.
시그니처(Signature)는 헤더와 페이로드를 합친 것을 Key 값을 이용해 암호화해요.
Header와 Payload 를 각각 Base64로 인코딩하고 Signature의 경우 Header와 Payload를 합친 데이터를 비밀키로 서명하게 되죠. 이렇게 되면 위변조 검증이 가능해지며 비밀키 없이는 생성이 불가해져요.
그러므로 Payload에 민감 정보를 넣으면 안돼요.
Access Token Only
로그인 할 때 Access Token발급 받아 만료 시 재로그인하게 만들어요.
Stateless구조를 유지하면서 보안적 요구사항이 낮고 단기 세션으로 주지만 만료마다 재로그인 해야한다는 단점이 있죠.
JWT 블랙리스트(Token Revocation List)
JWT의 경우 강제 로그아웃 자체가 불가능해요 하지만 이 방식을 사용하게 되면 즉시 무효화가 가능하게 되죠. 하지만, 세션과 동일하게 요청마다 저장소를 조회하여 stateless하지 않게 되죠.
Refresh Token
보통은 Access Token을 짧게 주고 리프레쉬 토큰을 긴 라이프타임을 갖게 하는 전략으로 Access Token와 Refresh Token을 적절하게 섞어 진행하게 돼요. 보통 쿠키(HttpOnly, Secure) 로 전달 되며 단점으론 Refresh Token이 탈취되면 장기 세션 탈취 위험이 있어요.
‘프로젝트 기획에 따라 다르다’고 생각하지만 여러 사례를 찾아보아 쿠키에 저장하는게 상대적으로 균형 잡힌 선택이라고 생각해요. 단, 전제조건은 HttpOnly와 serure 설정이 잘되어 있어야 해요. HttpOnly와 secure 알고가면 좋아요.
HttpOnly를 설정하게 되면 클라이언트 측 스크립트가 쿠키에 접근하는 것을 차단하게 되죠. 이렇게 되면 XSS(Cross site Scripting)을 방지할 수 있게 돼요.
secure를 설정하게 되면 외부 요청 시 브라우저가 쿠키를 자동으로 전송하는 것을 제어하여 CSRF(Cross-Site Request Forgery) 공격을 방지할 수 있게 돼요.
참조자료
https://www.youtube.com/watch?v=EsqBuwOuXB0
💬 댓글 0
불러오는 중...