커뮤니티 이용 정책에 위배되는 게시물을 작성할 경우, 별도 안내 없이 게시물 삭제 또는 커뮤니티 이용이 제한될 수 있습니다.
뒤끝 이용과 관련한 문의사항은 카데고리를 변경하여 문의해주세요.
제목: 퍼블리셔 자체 SDK 로그인 연동 방식 문의
이번에 퍼블리셔 계약을 진행하게 되면서, 구글/페북 같은 일반 소셜 로그인이 아닌 퍼블리셔 자체 SDK의 로그인 시스템을 필수로 적용해야 하는 상황입니다.
이 과정에서 퍼블리셔 SDK의 스펙을 확인해 보니, 일반적인 OAuth 방식처럼 클라이언트에 검증용 Access Token을 매번 발급해 주는 것이 아니라, 로그인 성공 시 유저의 고유 UID(또는 OpenID)만 클라이언트에 넘겨주는 형태도 고려해야 하는 상황입니다.
이와 관련하여 뒤끝에서 어떤 식으로 아키텍처를 가져가야 할지 조언을 구하고자 질문을 올립니다.
- 퍼블리셔 SDK 로그인 연동 방식 (커스텀 로그인 외 대안 여부)
퍼블리셔 SDK 로그인 성공 후 넘겨받은 유저 고유 ID를 기반으로 뒤끝 서버에 유저를 가입/로그인 시켜야 합니다.
현재 제가 생각한 방식은 [뒤끝 커스텀 회원가입/로그인] 기능을 활용하여, 퍼블리셔의 UID를 뒤끝의 커스텀 ID(아이디/비밀번호 형태)로 매칭해 처리하는 방법입니다.
혹시 이 방법 외에 외부 퍼블리셔 연동을 위해 뒤끝에서 지원하는 별도의 기능이나, 더 권장되는 연동 아키텍처가 있을까요?
- 토큰 없이 'UID만 제공되는 경우’의 보안 취약점 해결 방안
만약 위에서 언급한 ‘커스텀 로그인’ 방식을 사용하면서, 퍼블리셔 SDK가 클라이언트에 토큰을 주지 않고 UID만 던져주는 구조라면 심각한 보안 우려가 생깁니다. 클라이언트 패킷을 변조하여 타인의 UID를 뒤끝 커스텀 로그인 API로 쏴버리면, 비밀번호 검증이 없는 구조 특성상 타인의 계정으로 우회 로그인이 가능해 보이기 때문입니다.
퍼블리셔 측에서 별도의 토큰 검증 API(Auth API)를 제공하지 않고 클라 단에서 UID만 전달해 줄 때, 이러한 클라이언트 변조 및 우회 로그인 어뷰징을 방지하기 위해 뒤끝 구조상에서 어떤 식의 방어책을 세워야 하는지 궁금합니다.