1. 세션기반 인증 (Session-based Authentication)
1) 로그인
로그인 조건
1. 서버는 사용자가 인증에 성공했음을 알고 있어야 합니다
2. 클라이언트는 인증 성공을 증명할 수단을 갖고 있어야 합니다
- 서버는 Client에 유일하고 암호화된 ID를 부여 (중요 데이터는 서버에서 관리)
- 암호화된 ID : 각 세션을 구분할 수 있는 Session Id로 클라이언트에서 세션 성공을 증명할 수단이 됩니다
* 사이트에서 로그인을 유지하기 위한 수단으로 쿠키를 사용,
쿠키에는 서버에서 발급한 Session Id가 저장됩니다 (session id가 담긴 쿠키는 클라이언트에 저장)
- 상대적으로 보안에 취약한 쿠키는 경우에 따라 자바스크립트로 접근이 가능하기에 Session Id는 암호화 과정이 필요합니다
- 쿠키를 통해 유효한 세션 아이디가 서버에 전달되고, 세션 스토어에 해당 세션이 존재한다면 서버는 해당 요청에 접근 가능하다고 판단됩니다
- 쿠키에 세션 아이디 정보가 없는 경우, 서버는 해당 요청이 인증되지 않았음을 알려줍니다
2) 로그아웃
로그아웃 조건
1. 서버의 세션 정보를 삭제해야 합니다
2. 클라이언트의 쿠키를 갱신해야 합니다
- 서버가 클라이언트의 쿠키를 임의로 삭제할 수는 없습니다
- set-cookie로 세션 아이디의 키값을 무효한 값으로 갱신해야 합니다
2. 문제점
1. 서버의 메모리에 Session 정보를 저장하고 있기 때문에 이용자가 많아질 경우 가용 메모리의 양이 줄어 서버 성능 저하
2. 기존 쿠키 인증 방식을 완전히 대체한 것이 아니기 때문에 XSS 공격으로 인해 세션 쿠키가 탈취될 수 있습니다 (탈취될 경우 서버는 해당 요청이 인증된 사용자의 요청이라고 판단)
* 쿠키의 단점을 여전히 가지고 있습니다
3. express-session
express-session : 세션을 위한 미들웨어로 Express에서 세션을 다룰 수 있는 공간을 보다 쉽게 만들어 줍니다
* 세션을 대신 관리해주는 모듈
필요한 경우 세션 아이디를 쿠키에 저장하고, 해당 세션 아이디에 종속되는 고유한 세션 객체를 서버 메모리에 저장합니다
* 세션 객체는 서로 독립적인 객체이므로 각각 다른 데이터를 저장할 수 있습니다
req.session이 바로 세션 객체이며 req.session은 세션 객체에 세션 데이터를 저장하거나 불러오기 위해 사용합니다
Cookie VS Session
1. Cookie
- 접속 상태 저장 경로: 클라이언트
- 장점 : 서버에 부담을 덜어줍니다
- 단점 : 쿠키 그 자체는 인증이 아닙니다
- 쿠키는 그저 http의 stateless한 것을 보완해주는 도구입니다
2. Session
- 접속 상태 저장 경로 : 서버
- 장점 : 신뢰할 수 있는 유저인지 서버에서 추가로 확인이 가능합니다 (보안에 유리)
- 단점 : 하나의 서버에서만 접속 상태를 가지므로 분산에 불리합니다
- 접속 상태를 서버가 가지며(stateful), 접속 상태와 권한 부여를 위해 세션 아이디를 쿠키를 전송합니다
반응형
