[API] admin 작업전 회원가입, 로그인 Admin 추가

Admin 로그인 로직(인증) 처리 방식

해당 Issue 와 PR 은 우선 건너뛰기로 합니다. 대신 api-admin에서 구현할 수 있는 방법들을 고민해보고 정리합니다.
api-user 모듈에서 JWT 인증을 통한 로그인 구현을 하였으므로 다른 API 혹은 시스템 설계에 시간을 투자하기 위함입니다.
관리자 페이지라는 특성상 보안에 신경써야하기 때문에 해당 관점에서 토큰, 세션등의 방식들을 생각해보았습니다.

1. JWT + Redis
토큰을 사용하게 된다면 토큰을 생성, 검증 하는 로직 뿐 아니라 무효화 시키는 로직을 구현하는 방법을 생각해 볼 수 있습니다.
예를 들어, 토큰이 생성되어 해당 사용자의 ID와 함께 Redis 에 저장한다고 했을 때, 해당 토큰을 저장소에서 지움으로써 인증을 무효화할 수 있습니다.
물론 무효화 로직 또한 인증 기반(확인)이 되어야 보안상 보다 안전 할 수 있습니다.

장점 : 중앙화된 토큰 관리가 가능하고 모든 서버에서 일관된 토큰 상태를 유지할 수 있습니다.

단점 : 추가적인 인프라가 요구되어집니다. (별개로 Redis 특성 상 대량의 토큰을 사용할 경우 상당한 메모리를 소비할 수 있는데, 관리자 특성상 토큰을 과연 대량으로 관리할지가 의문이라 이 부분은 단점에서 제외했습니다.)

JWT Token의 Stateless의 성질을 무시하게 됩니다. 이 성질을 무시하게 되면 위와 비슷한 방법으로 상태기반 JWT를 활용해볼 수 있다고 생각합니다. Token에 버전 혹은 상태 정보를 추가하여 서버 측에서 제어가 가능하게 하고 모든 토큰을 한 번에 무효화 시킬 수 있다는 특징을 가질 수 있습니다. 그러므로 인프라 환경, 상황등을 고려하여 이 방식의 적합성을 판단해야 한다고 생각합니다.

2. Session

세션은 서버측에서 사용자의 로그인 상태를 유지하는 방식이고, 사용자가 로그인을 하면 서버에서 세션을 생성하고, 클라이언트에게는 세션 ID 를 제공합니다.
서버에서 하루가 지나면 일괄적으로 세션을 없애 다음날 로그인을 강제할 수 있습니다.
다중화 서버 일 경우, 동기화 문제를 해결해야 하는데, 이때 Sticky Session, Session Clustring, Redis등을 활용해 해결 할 수 있습니다.

장점 : 서버 측에서 완전히 제어가 가능하고 즉각적인 세션 무효화가 가능하여 종료시킬 수 있습니다.

단점 : 다중 서버 환경에서 세션의 동기화가 필요할 수 있습니다.

민감한 정보는 암호화하여 세션에 저장하도록 해야하고, 필요하다면 세션저장소를 따로 구축하는 것도 가능합니다. Token 에서도 구현가능하지만, 관리자의 유형이 한가지 이상일 수 있기 때문에 권한수준을 두어 보다 쉽게 세션에 저장하고 관리할 수 있습니다. 또한 같은 권한 수준을 가진 관리자는 세션을 하나만 허용하게 할 수 있습니다.

3. 그 외..

위 방법 이외에 추가적으로 생각해본 것은 2 Factor 인증입니다. Jwt나 세션방식을 첫번째 인증단계로 놓고, 두번째 인증단계를 사내 메일을 통한 코드 전송으로 확인 하는 방법 또는 google authentication 과 같은 OTP 서비스 연동으로 인증하는 방법을 사용하는 것입니다.

추가 구현에 복잡함을 겪을 수 있지만 보안성이 크게 향상되므로 인해 충분히 고려해 볼 만 하다고 생각합니다.

이 외에 보안조치가 더 필요하다면 IP 기반 접근 제한을 둘 수 있고, 관리자의 활동로그를 남겨 모니터링 할 수 있는 방법도 있습니다.

f-lab-edu / retry-lee