구현 목적

• 입력된 이메일이 정확한 지 확인할 수 있다.
• 사용자의 정보 변경 시, 본인 인증의 방법이 될 수 있다.

설계

고민

• 기존 시스템은 이메일을 이용해 회원가입하지만, 추후 OAuth2.0 으로 소셜 로그인 기능을 추가할 예정인데 그렇다면 이메일 인증이 아닌 소셜 플랫폼 인증을 이용하는게 좋지 않을까?
• 우리 서비스를 이용하는 유저가 소셜로그인이 아닌 이메일을 이용한 회원가입과 로그인을 원할 수 있으므로 두 방법을 모두 제공하기로 한다.
• 앞서 말한 소셜 플랫폼 인증 이라는 용어가 정의가 확실하지 않다. 소셜 로그인에도 인증번호를 입력해야 되는게 있고 아닌게 있으므로 둘 중 어떤 것을 의미할 지 정확하게 정해야 한다.

인증 방식

• 1. 인증번호 클라이언트 검증

1. 인증번호 서버 검증

   • 흐름

     • 서버에서 시간제한이 있는 랜덤한 인증번호를 생성해 유저의 이메일로 보내준다.
     • 유저가 이메일에서 인증번호를 확인하고 클라이언트에서 입력한다.
     • 클라이언트가 입력된 인증번호를 회원가입 요청과 함께 서버로 보내준다.
     • 서버에서 인증번호가 검증되면 정상적으로 회원가입이 완료되고, 검증이 되지 않으면 실패했음을 응답한다.

   • 서버 로직

     redis 를 이용해 <이메일, 인증번호> 를 시간제한을 두고 저장한다. 회원가입 요청시 1차적으로 인증번호 검증을 한다. 이 단계에서 검증을 성공해야만 다음 단계로 진행한다. 즉, 인증번호 검증이라는 관문을 최초에 먼저 두는 방식이다.

     다른 방식으로는 회원 엔티티에 인증번호 필드를 두고 인증된 회원, 인증되지 않은 회원으로 상태를 두는 방법도 있었는데 우리 서비스는 "인증되지 않은 상태의 회원"은 필요하지 않아서 제외했다.

→ 회의 거쳐 2번 방법으로 결정!