'직접 회원가입 하고 로그인하기' 와 'SNS 로 로그인하기' 기능이 존재할 때 로그인을 어떻게 구현할까에 대해 작성한다.
요구사항과 정책에 따라 구현도 달라지기 때문에 다음과 같이 정해보도록 한다.
1. 직접 회원가입 후 로그인을 할 수 있다.
2. 직접 회원가입 한 다음 SNS 연동을 할 수 있다.
3. SNS 연동 시 email 을 기준으로 유저를 식별한다.
4. SNS 에서는 email 을 변경하지 못한다.
5. 7일 이상 접속하지 않을 시 로그아웃 시킨다.
6. SNS 는 구글, 애플, 페이스북, 네이버가 존재한다.
7. SNS 에서 가져오는 정보는 이메일과 초기 세팅할 정보인 이름만 존재한다.
8. SNS 연결을 끊어도 로그인이 된 상태는 유지 되어야 한다.
처음에 난 SNS 연동을 도입한다는 뜻은 '회원가입이나 유저 정보를 입력 또는 관리에 용이하게 하기 위함' 이라고 생각을 하고 있기에 SNS 연동 시에 주는 access token 과 refresh token 을 이용하여 로그인 관리를 하려고 했다. 그리고 수동 회원가입에 대해서는 따로 우리 서버만의 토큰을 발급해주는 식으로 말이다. 그러나 나중에는 이렇게 구현하는 것이 과연 좋은 방법일까에 대한 의문이 생기게 되었다.
1. third party 에서 발급해주는 토큰들에 대해 의존하게 된다.
2. 다른 third party 에 의존하기에 토큰 유효성에 대한 요구사항 변경이 생겼을 때 반영할 수 없다.
3. 로그인 관련 장애가 생겼을 때 서버에서 직접 만든 토큰이 아니기에 이를 파악하기 어려워진다.
4. SSO 구현 시에도 토큰 발급 주체가 third party 이기에 적절히 녹이기 힘들다.
5. 보안 문제로 인해 토큰이 탈취 당했을 때 우리 서비스만이 아닌 third party 에도 영향이 간다.
내가 생각했을 때 위의 문제점들이 존재할 것 같다. 물론 더 많을 것이다. third party 에서 준 토큰들은 말 그대로 유저의 정보를 접근하거나 활용할 수 있는 토큰이라고 생각이 된다. 그렇기에 본래 목적과 다르게 사용을 하면 안 될 것 같았다. 그래서 나는 수동 로그인을 했을 때만 서버에서 직접 발급하는 토큰을 사용하는 것이 아닌 SNS 로 로그인을 하던 수동으로 로그인을 하건 상관 없이 서버에서 직접 만든 토큰을 발급해야 한다는 결론에 도달하게 되었다.
토큰을 직접 발급해서 사용하게 됐을 때의 이점이 될 것으로 보이는 것이다.
1. 요구사항, 정책에 따라서 토큰 유효성을 변경하기 쉽다.
2. SNS 연동 후 SNS 에서 서비스 연결을 끊어버려도 우리 서비스를 이용 가능하게 할 수 있다.
3. 토큰이 탈취 당해도 third party 에는 영향이 없다.
4. third party 토큰은 처음 회원가입 당시에만 사용해서 유저 정보를 가져오는 형태로만 사용하면 된다.
만약 서비스에서 SNS 기능을 이용해야 한다면 어떻게 해야할까? 여러가지 구현 방법이 있을 것 같다.
1. 서버 내에서 직접 만든 jwt 내에 access token 과 refresh token 정보를 담아 매 요청마다 체크하는 식으로 한다.
2. redis 같은 미들웨어에 third party 에 대한 token 을 올린다.
우선 https 를 전제로 하고 있고 end point 에서 토큰이 탈취당하는 것을 배제하면 첫 번째 방법으로 구현을 할 수 있을 듯하다. 만약 털린다는 가정을 하면,,, 답이 없을 것이다. redis 를 사용하는 것은 굳이? 싶기도 하다. 상황에 따라서 두 가지 방법 중 하나를 선택해서 구현을 할 듯 싶다.