[Product] OAuth 계정 연동에서 발생하는 아이디 누락에 대한 논의

[psychology50]

현재 Pennyway 서비스에서는 2가지 회원가입 시나리오가 존재합니다.

1. 소셜 로그인 내역이 없는 유저가 일반 회원가입을 시도한다.
   a. 전화번호 인증
   b. 유저 정보(아이디, 비밀번호, 이름 등) 입력
   c. 회원가입 성공

2. 일반 회원가입 내역이 없는 유저가 소셜 로그인을 시도한다.
   a. 전화번호 인증
   b. 회원가입 성공

두 가지 시나리오에는 중요한 차이가 있는데, (2)의 방법으로 접근 시 사용자는 (현재 기획안에선) 아이디와 비밀번호를 가지고 있지 않습니다.
이 경우 두 가지 문제가 발생합니다.

1. 사용자 프로필에서 보여줄 아이디가 존재하지 않음
   • 아예 보여주지 않을 것인가?
   • 일반 회원가입을 권유할 것인가?
2. 추후 피드나 채팅방 기능에서 사용자 검색 시, 아이디가 없으므로 유저를 구분할 수 없다. (프로필 이미지 없는 동명이인)

따라서 아이디는 필수값이어야 합니다.
그렇다면 다음과 같은 대안을 생각해볼 수 있을 겁니다.

💡 소셜 로그인으로 회원가입을 하는 유저는 전화번호 인증 후, 아이디를 추가로 입력해야 한다.

다만, 이 시나리오로 가게 되면 다른 문제를 고민해봐야 합니다.

• 소셜 로그인 -> 회원가입을 통해 입력된 사용자의 아이디는 일반 로그인에 사용할 수 없다.
• 다른 유저가 해당 아이디로 계정을 생성하려 할 때 중복 검사에 걸린다. (그 아이디가 일반 회원가입 절차로 생긴 게 아님에도 불구하고)

그렇다면 또 다른 대안으로는 아이디는 필수적으로 입력받고, 이메일을 받는 방법이 있을 수도 있습니다.
하지만 이 방법은 사용자가 회원가입 시 밟아야 하는 스텝이 길어지므로 사용자 경험을 떨어트리게 됩니다.
또한 이메일을 받게 되면 추가 검증 단계가 필요하게 되므로, 전화번호 + 이메일 인증이라는 불필요한 중복 검증 절차를 밟게 됩니다.

따라서, 이 문제에 대한 해결책을 함께 의논해보고자 합니다.

[jinlee1703]

저는 재서님이 작성하신 의견 중 💡 소셜 로그인으로 회원가입을 하는 유저는 전화번호 인증 후, 아이디를 추가로 입력해야 한다.가 가장 나은 것 같아요.

• 소셜 로그인 -> 회원가입을 통해 입력된 사용자의 아이디는 일반 로그인에 사용할 수 없다.
• 다른 유저가 해당 아이디로 계정을 생성하려 할 때 중복 검사에 걸린다. (그 아이디가 일반 회원가입 절차로 생긴 게 아님에도 불구하고)

말씀해주신 대로 위와 같은 문제가 있음에도 불구하고, 저 방식을 사용하는 것이 쓸데없는 인증이나 데이터 저장 없이 구현할 수 있는 최선의 방법인 것 같습니다.

[psychology50]

사실 이 부분에 대해서 몇 가지 문제점들이 더 떠올랐었는데, 커맨트 남기다보니 딱히 문제 없는 거 같기도 하네요.
일단 다른 분들 의견도 마저 들어볼게요.
의견 남겨주셔서 감사드립니다. :)

[BangDori]

저는 사용자 인증에 있어, 전화번호 인증이 아닌 이메일 인증을 통해 회원가입을 진행하는 방법에 대해 초점을 맞추고 생각해보았는데, 이 방법에 대해 장단점과 고민해야할 점이 있어서 끄적여봅니다. 아래에 사용된 이미지는 모두의 집 회원가입 이미지 중 일부입니다.

장점

• 소셜 로그인을 통한 회원가입시 사용자가 이메일을 직접 입력하지 않더라도 이메일을 받아올 수 있습니다.
• 사용자 이메일을 바로 받아오기 때문에, 이메일 인증 과정을 생략하고 바로 아이디를 입력하고 넘어갈 수 있습니다.

단점

• 로컬에서 회원가입시, 사용자가 이메일을 입력하고 인증 번호를 받기 위해서 google 혹은 naver 메일을 확인해야 하는 과정을 거쳐야만 합니다.
• 만약 백엔드에서 도메인 설계나 로직 설계가 모두 완료되었다면, 휴대폰 인증에서 이메일 인증으로 변경하는 부분이 조금 귀찮을지도...?

고민

일반 로그인을 이용하는 사람보다 소셜 로그인을 사용하는 사람이 더 많다고 생각합니다. 그래서 "소셜로그인 과정에서 인증을 한 단계 더 줄여줄 수 있다면 그것이 최고의 방법이지 않을까?" 라는 생각을 했습니다. 카카오톡 외에 다른 OAuth 서비스에 대해 확인해본 바는 없지만, 카카오 OAuth에서는 이메일을 필수로 받아오기 위해서는 비즈앱 전환이 필요했습니다.

비즈앱

자사 앱이나 웹에서 카카오의 API를 사용하기 위해 카카오 디벨로퍼스에 개설하는 애플리케이션을 의미합니다. 카카오 디벨로퍼스에서 앱을 등록하신 후 사업자 정보를 등록하면 비즈 앱으로 전환됩니다. 앱의 오너만 사업자 정보를 등록할 수 있습니다.

처음에 사업자번호가 있어야지만 비즈앱 변환이 가능한 줄 알았는데, 사업자 번호가 없는 경우에도 비즈 앱을 설정하는 방법이 있길래 휴대폰 인증 방식이 아닌 이메일 인증 방식으로 변경하는 것도 괜찮지 않을까~~ 하는 의견을 남겨 봅니다.

Kakao - 사업자 번호가 없는 경우 비즈 앱 설정하는 방법

[BangDori]

현재 재서님이 말하고 있는 논점을 흐린거같기는 한데, 요약하자면 휴대폰 인증 방법이 아닌 이메일 인증 방법으로 진행을 하게 되면 아이디 입력만으로 소셜 로그인을 위한 회원가입을 진행할 수 있어서 다음과 같은 플로우로 진행될 수 있을 것 같습니다.

1. 소셜 로그인 내역이 없는 유저가 일반 회원가입을 시도한다.
   a. 이메일 인증
   b. 유저 정보(아이디, 비밀번호, 이름 등) 입력
   c. 회원가입 성공

2. 일반 회원가입 내역이 없는 유저가 소셜 로그인을 시도한다.
   a. 아이디 입력
   b. 회원가입 성공

[psychology50]

저도 이메일을 사용하는 방법을 고민을 많이 했는데, 다음과 같은 이유로 제약이 생깁니다.

• 카카오는 확실히 이메일을 받아올 수 있습니다.
• 구글은 아마도 가능했던 것 같습니다.
• 애플이 이메일을 못 받아옵니다.

네이버의 경우에도 OAuth 정책 명세서를 살펴보면 사용자 이메일이 아니라, 사용자가 지정한 이메일을 반환하게 되어 있습니다.
즉, 네이버 계정으로 로그인 했어도 반환되는 이메일은 다를 수 있으며, 사용자가 변경할 때마다 변경 사항을 추적해야 합니다.

여튼 핵심은 애플이 이메일 정보를 주지 않기 때문에, 고민할 겨를도 없이 제외한 부분이기도 합니다.
같이 고민해주셔서 감사드립니다. :)

[BangDori]

애플이 이메일을 받아오지 못하는 것 까지는 제가 확인을 못했네요.

좋은 논의 만들어주셔서 감사합니다 👍

[heejinnn]

답변드리자면 애플에서 이메일 받아올 수 있습니다.
하지만 애플은 최초 로그인시에만 이메일을 제공받을 수 있습니다. 두 번째 인증부터는 보안 문제로 사용자 정보가 공유되지 않아 동일한 계정으로 로그인 시, 사용자 ID만 반환하게 됩니다. 여기서 ID는 사용자 식별하는데 사용하는 값입니다.

애플이 카카오, 구글과의 차이는 최초 로그인할 때만 사용자 정보를 받아오고, 그 이후의 로그인 시에는 사용자 ID값만 받아온다는 것입니다.
그래서 최초 로그인했을 때 그 정보를 잘 캐시하고 있어야 한다는 점,,,,,

[psychology50]

정정 답변 감사드립니다. :)

[yanni13]

저도 소셜 로그인으로 회원가입을 할 때 전화번호 인증 후, 아이디를 추가적으로 입력받는 의견이 제일 좋다고 생각합니다.

제가 이해한 바로는 2번 회원가입 내역이 없는 유저가 소셜로그인을 시도할 때 아이디가 필수로 필요하다면, 전화번호 인증 후 별도 아이디를 추가적으로 입력받는 대신 랜덤(고유한 값)으로 아이디를 할당해서 나중에 사용자가 아이디를 수정하는 방식으로 진행할 수 있지 않을까라는 생각이 들어서 코멘트 남겨봅니다.

• 현재 스포티파이에서 구글 소셜로그인을 진행하면 성별, 생년월일, 이름값만 받아오고 해당 앱에서 지원하는 고유한 값(=사용자 이름)을 랜덤하게 사용자에게 지정해 주더라구요.
• 스포티파이 앱에서는 사용자 이름은 수정할 수 없게 고정되어 있습니다.
• 위와 같은 방법에서 고유 값(사용자를 식별하기 위해 사용하는 값)을 수정할 수 있을지는 모르겠지만, 만약 불가능하다고 가정하였을 때 랜덤으로 값을 사용자에게 지정하고 그 아이디를 사용해 로그인을 진행해야 한다는 단점이 있습니다 -..

[asn6878]

작성하고 나서 보니 얀님이랑 제 의견이 결이 비슷하네요.

[psychology50]

서비스에서 초기 아이디를 랜덤으로 생성해주자는 생각도 하긴 했습니다.
예를 들어, user + pk 조합으로 임의의 값을 생성할 수 있을 겁니다. 물론 해당 방법은 이미 존재하는 닉네임일 경우 문제가 발생하므로 user + 난수값이 될 수도 있을 거구요.

이 방법의 문제점은 사용자가 의도하지 않은 아이디가 생긴다는 점입니다.
그래서 아이디가 있음에도 일반 로그인은 안 되고, 막상 일반 회원가입을 하려고 하니 해당 아이디가 존재하니 연동하겠다고 하면 혼란을 줄 수도 있을 것 같습니다.
하지만 사용자에게 입력받도록 스텝을 한 단계 더 밟는 것보단 나을 거 같은데, 어떤 랜덤값을 생성해줄지도 고민이 필요한 부분입니다.

너무 복잡한 문자열이면 수정할 때도 번거로울 거 같거든요.

[asn6878]

저는 이 부분을 생각하며 여러가지 서비스를 모니터링 해본 후 아래와 같은 방법은 어떨까 라는 생각이 들었어요.

• 사용자는 소셜로그인을 진행한다.
• 서버는 소셜로그인을 진행한 사용자의 아이디 필드에 임시아이디 값을 부여한다.

임시아이디는 서버에서 특정한 형태로 발급합니다.
예) user14234, user14235, user12xxx.... 

• 사용자는 임시아이디를 통해 일반 회원과 동일한 서비스를 이용 가능하다.
• 마이페이지에서 아이디를 변경할 수 있기때문에 임시아이디가 거슬리는 회원은 변경 처리를 진행한다. (중복체크 필요)

---

이 생각을 할때 참고했던 서비스인 컴퓨터 하드웨어 커뮤니티 퀘이사존을 예시로 보여드리고 싶습니다.

소셜 로그인 진행 페이지

구글 로그인 진행시

소셜 서비스 정보제공 동의 후 아래와 같은 Alert가 발생합니다

그 후 회원설정 화면(마이페이지)으로 리디렉션되며, 퀘이사존 서비스에서 필요한 정보를 입력받기를 유도합니다.

인증된 사용자와, 인증되지 않은 사용자는 서비스 이용 권한이 분기됩니다. (PennyWay는 현재 문제가 되고있는 닉네임필드만 해결되면 서비스 이용에 어려움이 있어보이진 않기에, 이부분은 굳이 구현할 필요는 없을 것 같습니다.)

결론

위에서 언급한 임시 아이디를 사용하는 방법이 저희 서비스에 가장 최적화 된 방법을 사용할 수 있을 것이라 생각했습니다. 제가 놓친부분이 있으면 확인해주시면 감사하겠습니다 :)

[psychology50]

임시 아이디 값에 대한 이야기가 많네요. 나쁘지 않을 거 같긴 합니다.
이렇게 하면 일반 회원가입 -> 전화번호 인증 -> 기존 계정 탐색 과정에서 연동될 계정의 아이디를 사용자에게 보여주는 UI가 추가적으로 필요하게 되고, 비밀번호만 입력받도록 할 수도 있을 거 같긴 해요.

OAuth 로그인 시 사용자가 입력받는 스텝을 건너뛰면서, 프로필에서 수정할 수 있게 해주면 큰 문제가 되진 않을 거 같습니다.
다만 랜덤값을 어떤 기준으로 할 지가 좀 골치 아파지겠네요.

[heejinnn]

✋ 의견

소셜 로그인을 통해 회원가입 하는 경우, 사용자에게 필요한 데이터는 비밀번호를 제외한 이름과 아이디입니다. 사용자가 전화번호 인증 후 이름과 아이디를 입력해야 하는 불편함이 있긴 하죠.

랜덤값으로 하는 건 사용자가 소셜 로그인으로 회원가입할 때 인증 절차에 대한 번거로움을 조금 덜어줄 수는 있지만, 회원가입 후 서비스를 사용하려고 할 때 설정에서 다시 고쳐줘야 하는 번거로움도 생긴다고 생각해요.

- 아이디와 이름이 랜덤값이어도 상관없는 사용자 => 편하군
- 아이디와 이름이 랜덤값인게 불편한 사용자 => 다시 설정에서 고쳐줘야 하는 번거로움

이 두가지 케이스의 사용자를 생각해볼 수 있는데 저는 후자의 편을 들어주는 게 맞다고 생각해요.
물론 아이디와 이름이 크게 중요하지 않은 서비스라면 저도 랜덤값을 주는데 동의하지만 저희 서비스는 검색, 채팅이나 피드와 같은 기능에서 자주 아이디와 이름이 사용됩니다.

이런 경우에는 랜덤값으로 사용해도 괜찮은 사용자가 많지 않을 것이라고 생각해요. 제 개인적인 생각이지만,,,

📍 문제

• 소셜 로그인 -> 회원가입을 통해 입력된 사용자의 아이디는 일반 로그인에 사용할 수 없다.
  => 일반 로그인에 사용할 수는 없지만 서비스 내에서 사용자 검색과 같이 사용자를 식별하는 데 사용되므로 감안할 수 있는 문제라고 판단됩니다.

• 다른 유저가 해당 아이디로 계정을 생성하려 할 때 중복 검사에 걸린다. (그 아이디가 일반 회원가입 절차로 생긴 게 아님에도 불구하고)
  => 이 문제도 위와 같은 맥락으로 말할 수 있겠네요.

결론

결론적으로 랜덤값 없이 💡 소셜 로그인으로 회원가입을 하는 유저는 전화번호 인증 후, 아이디를 추가로 입력해야 한다.가 가장 최선의 방법이라고 생각합니다.

[psychology50]

희진님의 말씀은 제가 생각한 방식을 채택하고 있는 것으로 보입니다.
현재 해당 방식으로 진행하기로 결정이 난 상태여서 찬성표로 받아들이도록 하겠습니다.

추가적으로로 지금 말씀하신 부분은 문제 핵심에 맞닿아 있다고 생각합니다.
사용자 관점에서 신중히 고려하여 의견 제시해주셔서 감사드립니다.