이메일 인증 처리에 대한 여러가지 방법

남·여 매칭 서비스에 이메일 인증 기능을 도입하면서 인증 처리를 어떻게 하는 것이 좋은지에 대한 고민이 있었다. 
먼저 이메일 인증 기능의 흐름은 다음과 같다.

인증을 위한 발송 과정과 인증 처리

위 흐름을 거쳐 사용자는 자신의 메일함에 도착한 메일에서 인증 코드를 확인하고 서비스에 돌아와 인증코드를 입력하게 된다.
이 때 인증 처리를 하는 방법이 다양하게 존재했고 이 중에서 가장 타당한 방법을 선택하고자 했다.

 

1. Cient 에서 인증 처리

첫 번째 방법은 HTTP 응답의 body에 인증코드를 담아서 client에게 보내는 것이다. 이 방법을 사용하면 서버에서 따로 인증 처리를 하지 않아도 되서 인증 처리에 대한 API 요청을 줄일 수 있는 장점이 있다. 반면 HTTP 응답을 가로챈다면 누구나 이메일을 가지고 가입을 할 수 있게 되는 보안 문제가 생기게 된다. 남·여 매칭 서비스는 비즈니스상 사용자가 신뢰할 수 있는 사람인지가 중요한 요소이기 때문에 보안에 특히 중점을 두어야 했다. 따라서 Client에서 인증 처리하는 방법을 선택할 수 없었다.

 

 

2. Server 에서 인증 처리

2-1. mySQL 을 활용해서 인증 처리

두 번째 방법은 서버에서 인증 처리를 하되 인증 코드를 mySQL 에 저장해 두고 인증 처리 요청이 올때 mySQL에 이메일에 대응하는 인증코드가 있는지 확인하는 방법이다. 이메일을 발송할 때 mySQL에 (email, code, expirationTime)의 형태로 저장하고 인증 처리 요청이 올 때 primaryKey인 email에 code가 일치하고 expirationTime이 지나지 않았는지만 확인하면 된다. 하지만 인증 코드는 회원 가입시 인증 이후에는 필요가 없는 데이터이기 때문에 mySQL에 데이터를 영속화시킬 필요성을 느끼지 못했다. 또한 데이터를 생성하고 조회 및 제거하는 DB로의 요청이 1명의 회원가입에 최소 3번 발생하기 때문에 네트워크 비용이 높다는 문제가 있었다. 따라서 Server에서 인증 처리는 하되 인증 코드를 저장할 다른 저장소가 필요했다.

 

2-2. 애플리케이션 내부 메모리 캐시 사용(Spring-Cache)

세 번째 방법은 Ehcache 또는 Caffeine 캐시 구현체를 사용하면 애플리케이션 내부의 메모리를 인증 코드 저장소로 사용하는 것이다.

이 방법은 mySQL에 비해 네트워크 비용이 감소하기 때문에 빠르게 저장하고 조회할 수 있는 장점이 있다. 하지만 내부 메모리 저장소를 사용하기 때문에 서버가 확장되었을 때 각 서버들끼리 인증 코드를 공유하지 못하는 문제가 생긴다. 따라서 서비스가 확장되었을 때를 고려한다면 외부 메모리 저장소가 필요했다. 

 

2-3 Redis 를 활용해서 인증처리

마지막 방법은 Redis를 인증 코드 저장소로 사용하는 것이다. Redis는 외부 메모리 저장소이기 때문에 서버가 Scale-out 된 상황에서도 모든 서버들이 하나의 저장소를 공유할 수 있는 장점이 있다. 또한 Redis는 TTL기능이 있기 때문에 이메일 인증 처리 기능으로 가장 적합하였다. (시간이 지나면 자동으로 Redis 저장소에서 데이터가 사라짐) 
또한 로그인에서 세션 방식의 인증 기능을 활용할 것이기 때문에 통합 세션 저장소로 Redis를 활용할 것이기 때문에 이 방법을 선택하게 되었다. (세션 방식의 인증 기능을 사용하는 이유는 사용자간의 신뢰도가 중요한 서비스이기 때문에 보안성이 낮은 토큰 방식보다는 보안성이 높고 중앙에서 관리할 수 있는 세션 방식이 필요했다.)