인증 서버 구현

TODO

• 인증 로직 구현

인증 방식

JWT

• 빠른 기능 구현을 위해 가장 간단한 JWT 방식 채택
• 추후 다른 인증 방식으로 변경

이메일을 제한 없이 전송할 수 있다보니 악의적인 트래픽에 대항할 방법이 없습니다.
이를 막기 위해 처리율 제한장치를 개발하도록 결정했습니다.
가장 간단한 방법인 Token-Bucket 방식을 채택했습니다.

회원 서버 설계

대략적인 목표 기능

• 회원 가입
• 회원 가입시 인증 이메일 전송
• 회원 정보 검색

ERD 설계

• 연관관계가 당장 필요없기 때문에 user 테이블만 생성하면 될 것 같다.
• table name - user는 예약어랑 겹칠 가능성이 있기 때문에 users로 설정
• password - 암호화를 해서 저장
• status - DEACTIVATED, ACTIVATED, DELETED 를 표시
  • DEACTIVATED - 이메일 미인증 상태
  • ACTIVATED - 이메일 인증 상태
  • DELETED - 계정 삭제 상태

아키텍처 설계

Hexagonal Architecture

• 애플리케이션 영역을 순수하게 만들기 위해 설계한 아키텍처
• 외부(Adapter)과 애플리케이션 영역간의 통신은 추상화된 port가 담당
  • 의존방향에 따라 [IN, OUT] 포트로 나뉘게 된다.
• 이 구조를 통해 캡슐화가 되어 변화에 유연성을 가질 수 있다.

회원 서버 구현

TODO

• 회원 도메인 엔티티 구현
• DB Adapter 구현
  • Persistence
  • Redis
• 회원 가입 API 구현
  • Web Adapter 계층
    • input validator 구현
  • Port 계층
  • Service 계층 (Business logic)
    • 비밀번호 암호화
    • 인증 코드 이메일 전송 및 redis 저장
    • business validator 구현

정책

회원 상태 관리

회원 상태 관리는 총 세가지로 나뉩니다.

• DEACTIVATED - 이메일 미인증 상태
• ACTIVATED - 이메일 인증 상태
• DELETED - 계정 삭제 상태 (바로 DB에서 지우지 않고 1년동안 저장 후 배치를 사용해 삭제)

인증 정책

인증 정책은 다음과 같습니다.

• 회원가입 시 미인증 상태. 추후 인증을 해야 함.
• 인증 URI 전송
  • queryParam으로 username, email, authcode가 들어가있음.
  • authcode는 UUID를 사용해 전송.
  • 세 개의 정보를 사용해 redis 저장.
  • 해당 링크 접속 시 인증 완료.

Email 정책

• 회원가입 시 기본적으로 전송해주고 실패 가능성을 산정해 얼마든지 인증 이메일을 전송할 수 있도록 설정.
• 단, 악의적인 리소스 사용 방지를 위해 횟수 제한을 둘 예정. (하루 3회)
  • 간단하게 bucket 방식을 사용.
  • 단, 트래픽 자체를 제어하는 방식은 적용되지 않기 때문에 게이트웨이에 트래픽 제한 장치 배치를 고려하자.