들어가면서
아래의 글은 대략적인 설계 방식 그리고 필요한 기술에 대해서 간략하게 설명하고 넘어갑니다. 만약 자세한 기술은 추가적으로 찾아보셔야합니다.
어떻게 제공할까?
사이트의 서비스를 이용하기 위해서는 회원가입이 필수이다. 물론 아닌 경우도 있지만, 회원가입과 로그인을 통해 어떤 사용자인지 특정하고 그에 맞는 서비스를 제공할 수 있다.
과거의 회원가입과 로그인은 직접 사용자로부터 회원가입에 필요한 정보(이메일, 비밀번호, 이름) 등등 을 받아야했다. 그러다 보니 유저 입장에서는 매번 사이트를 이용할 때 마다 그에 맞는 이메일과 비밀번호를 매번 입력해야하는 불편함이 존재한다.
유저입장에서만 불편할까? 유저의 정보를 매번 받아서 관리해야하는 기업 입장에서도 여간 불편한 일이 아니다. 가령 기업은 사용자의 이메일을 추가적으로 받지 않고 회원가입의 아이디로서 이메일을 사용하려고 한다. 그리고 이메일을 활용해 필요한 광고메일을 보내려고 한다. 그러기 위해서는 반드시 기업은 해당 이메일에 대한 인증여부는 필수로 받아야한다. 이메일 형식만 갖춘 이메일(실제로 존재하지 않음)은 아무런 소용이 없기 때문이다.
이렇듯 사용자로부터 직접 데이터를 받아 회원가입 정보, 특히 그것을 이용해서 의미있는 정보로 활용하기 위해서는 검증이 필수이다. 그렇다고 매번 검증하는 것도 귀찮은 일이다.
그렇다면 이러한 일을 대신해줄 수 없을 까? 바로 우리가 익히 잘 알고 있는 소셜로그인을 활용하면 된다.
소셜 로그인
Facebook , Twitter 또는 Google 과 같은 소셜 네트워킹 서비스 의 기존 정보를 사용하여 제3자 웹사이트에 로그인하는 SSO( Single Sign-On) 형태이다.
핵심은 간단하다. Facebook, Twitter 같은 소셜 네트워킹 서비스로 부터 받은 회원정보를 활용하는 것이다.
하지만 기업이 마음대로 위와 같은 서비스에서 회원정보를 가져오는 것은 아니다. 우리는 사용자로부터 허가를 받아야한다.
"사용자" : google 계정을 이용해 소셜 로그인(회원가입) 시도
"Google" : A 기업이 google 계정으로 부터 너의 "프로필 사진", "이메일" 정보를 사용하려는 데 괜찮아? (동의)
"사용자" : 응응 사용해도 괜챃아 -> 로그인 성공
"A 기업" : 로그인 성공 했을 때 Google 로 부터 받은 사용자의 "프로필 사진", "이메일" 정보를 활용한다.
물론 많은 과정이 생략되었지만, 대략적인 과정은 이러하다.
실제로는 로그인이 성공된 이후에는 바로 유저로 부터 위와 같은 데이터를 받는 것이 아니라, 토큰이라는 것을 발행후 이 토큰을 이용해서 실제 로그인 했던 소셜프로바이더에게 요청하여 필요한 정보(프로필 사진, 이메일 정보)를 받아오는 것이다.
이 토큰은 정확하게 "프로필 사진", "이메일 정보" 에 대해서만 허가가 된 토큰이기 때문에 사용자의 다른 정보를 가지고 오고 싶다면 사용자로부터 다시 추가적인 정보 제공에 대해 허락 받고 토큰을 새롭게 발급받아야한다.
소셜 로그인 주의할 점
-
소셜 로그인에서 제공하는 정보가 통일되지 않은 경우
소셜 로그인은 저마다 제공하는 사용자 정보가 다르다. 만약 우리는 이메일을 필수로 받아야하는 데 특정 소셜 로그인의 경우 이메일을 제공하지 않거나(만약 제공한다고 해도 그 이메일의 검증여부가 불확실한 경우) -
배보다 배꼽이 큰 경우
만약 이메일을 사용하지도 않고 어떠한 정보도 활용하지 않은데 소셜로그인을 생각한다? 굳이 그럴필요가 없어 보인다. 소셜 로그인을 했음에도 불구하고 원하는 정보를 제공하지 않아서 추가적인 정보를 무조건 받아야하는 경우, 아니 소셜로그인으로 하면 됬지 왜 또 정보를 입력하는 거지? 회원입장에서는 짜증날 수 밖에 없다.(물론 소셜 로그인을 통해 받지 못하는 정보는 받아야할 필요가 있다) -
사용자가 여러 소셜 로그인을 사용하려고 하는 경우에 대한 대처 마련
요즘에는 한명의 사용자가 트위터, 페이스북, 라인 등등의 계정을 가지고 있는 경우가 많다.
만약 어떤 소셜 로그인으로 가입한 지 모르고 다른 소셜 로그인으로 가입하려고 한다고 가정하자.
(라인으로 이미 로그인 계정을 가지고 있는 상태이고 추가로 구글로 로그인을 하려고 하는 상황이다.)
그런데 서버쪽에서는 잘못 설계하여 회원의 이메일은 중복되지 않게 설계되었다고 한다면? 아래와 같은 경우에는 충돌이 나기 때문에 위 회원은 구글로 로그인 할 수 없는 상황이다.라인 -> a@naver.com
구글 -> a@naver.com
이 경우에는 회원을 구분할 수 있는 다른 무언가가 있어야할 것이다. 소셜 회원가입 시 추가로 회원을 구분할 수 있는 용도로 전화번호를 받는 것도 하나의 방법이 될 수 있을 것이다.
이렇게 위와 같은 상황에 대해서 어떻게 할 것인가 역시 서버측에서는 고려를 해야한다. 서버 입장에서는 A 라는 사용자가 같은 유저인지? 다른 유저인지? 같은 유저로 판단할 수 있는 정보가 있다면 통합하는 과정을 거칠 것인지? 등등에 대해서도 미리 생각해야한다.
그렇기 때문에 아예 하나의 소셜로그인만 제공하는 방법도 하나의 방법이다. 이는 서비스 정책에 따라 다르다.
가비아의 경우 이렇게 예전에 어떤 서비스로 가입했는 지 미리 알려주기도 한다.
즉 소셜로그인을 최대한 많이 제공하면 좋아보일 수 있지만, 그 만큼 각 소셜 로그인 리소스 서버가 제공하는 사용자 정보가 무엇인지, 무엇을 제공할 수 있는 지 꼼꼼히 따져봐야한다.
