http 통신시 중복 로그인을 방지하는 방법 고찰.

 

기본적인 중복 로그인 방지 방법

1. 사용자의 마지막 로그인 정보 저장
   사용자가 로그인할 때마다 마지막 로그인 시간 및 기기 정보를 저장
   새로운 로그인 요청이 오면 기존 세션을 만료
2. 기존 세션 강제 종료
   동일한 계정으로 로그인할 경우 기존 세션을 삭제
   새 로그인만 허용하고 이전 세션을 무효화
3. Redis 또는 In-Memory 캐시 사용
   로그인된 사용자의 세션을 Redis에 저장하고 관리
   중복 로그인 요청이 오면 이전 세션을 삭제

서버에서 세션을 만료,삭제,무효화 시키면, 해당 세션을 사용하는 클라이언트는 로그아웃 된것으로 간주됨.

 

로그인 시점에 서버에서 관리되는 세션을 핸들링 해주는것이 핵심.

 

브라우저에서 Cookie를 사용하여, 세션 처리되는 방식처럼,

API에서도 비슷한 구현이 필요한 상황이다.

 

구현 시나리오 1 - 기본에 충실

1. 로그인시 Session 생성 및 redis에 저장 (삭제 처리도 귀찮으니 넉넉히 적당한 expire 적용).

2. Session id값을 클라에게 전달.

3. 클라로부터 Session id값을 매 통신시 받아, 세션이 존재하고, Valid한지 확인 후 로직 처리, 실패시, 에러 발생.

4. 중복 로그인 발생시, 기존 Session은 제거 및 신규 Session 생성.

 

장점

  - redis를 사용하여, 빠르고, 분산시스템에 적용이 가능함.

  - 세션에 추가 데이터를 활용할 수 있음.

단점

  - session storage (redis) 가 필요함. db사용은 성능상 비추.

  - 서버에서 세션 관리 필요. (만료시간 및 연장 등)

 

구현 시나리오 2 - 세션없이 인증 token 만 비교 (token인증방식만 가능)

1. 매번 로그인시 새로운 token을 발급하고, user db에 저장

2. 통신시 클라에게 받은 token값으로 인증 처리시, db의 token값을 비교하여, 동일하지 않으면, 에러 발생.

3. 중복 로그인 발생시, 기존 token은 새로운 token으로 대체되면, 사용불가 처리됨.

 

장점

  - 서버에서 따로 세션을 관리할 필요가 없음. (session storage 불필요)

  - 세션 만료 및 연장 고려할 필요없음

단점

  - db를 사용하여, 속도가 느림. (캐싱하여 개선가능)

  - 세션을 활용한 추가 데이터 처리 불가능.

 

 

시나리오 1에 비해 2가 구현도 간단하고, 사용도 간단하다.

세션 데이터를 활용할게 아니라면 굳이..