보안 웹 서비스에도 액세스하는 iOS 앱에서 Facebook 인증을위한 디자인

목표 : 사용자가 Facebook을 사용하여 내가 실행중인 보호 된 웹 서비스에 액세스해야하는 iOS 응용 프로그램으로 인증 할 수 있도록합니다.

가정 : 로그인에 Facebook을 사용하지 않는 사용자를위한 기본 인증 (및 등록) 시스템이 있습니다.

세부:

• 시스템에 별도의 계정 / 자격 증명을 만들지 않고 사용자가 Facebook에 로그인 할 수있는 옵션을 제공한다고 가정합니다.
• 자체 고유 인증 메커니즘 (사용자 이름 및 비밀번호)을 지원하므로 고유 한 사용자 ID가 있으며 초기 신임 정보 유효성 검증 후 후속 상호 작용에 사용되는 인증 토큰을 발행합니다.

Facebook의 개발자 설명서에 Facebook에 대한 모범 사례가 없다는 것에 놀랐습니다. 기존의 모든 문서는 웹 사이트에 FB 인증을 구축한다고 가정하거나 인증이 필요한 서비스가없는 독립형 모바일 앱입니다.

이것이 어떻게 설계 될지에 대한 나의 초기 생각은 있지만 그것이 옳은지에 대한 검증을 원합니다.

1. 클라이언트가 Facebook iOS 로그인 팝업
2. UI 사용자가 Facebook 자격 증명으로 로그인하고 액세스 토큰을 얻습니다.
3. iOS 앱이 서버에 액세스 토큰을 전달합니다

4. 우리 서버는 (a) 토큰의 유효성을 검사하고 (b) 해당 액세스 토큰의 FB 사용자 ID를 얻기 위해 액세스 토큰을 사용하여 FB 그래프 API와 통신합니다.

   예 : Google 서버는 https://graph.facebook.com/me/?access_token=XYZ 를 호출 하여 JSON 객체에 프로필 정보를 반환합니다.

5. 서버가 유효하다고 가정하면 Google 서버는 JSON 객체에서 사용자 ID를 추출하여 사용자에게 이미 계정이 있는지 확인합니다. 그렇다면 해당 세션에 사용할 수 있도록 자체 인증 티켓을 고객에게 발급합니다. 사용자가 계정이없는 경우 Facebook 사용자 ID로 새 계정을 만들고 고유 한 UserID를 할당하고 인증 티켓을 발급합니다.

6. 그런 다음 클라이언트는 인증이 필요한 후속 상호 작용에서 인증 티켓을 다시 전달합니다.

이것은 나에게 올바른 접근 방법처럼 보이지만 내가 미친 듯이 기본적인 것을 놓치고 잘못된 (복잡한) 길을 가고 있는지 확실하지 않습니다.

방금이 문제를 직접 처리했으며 여기에 저를 물린 부분이 있습니다.

5 단계에서 ... 사용자가 자신의 Facebook ID와 완전히 별개의 계정을 등록 할 수 있습니까? 그리고 다른 시간에 그들은 페이스 북으로 로그인했습니다 .... 그리고 당신은 그들에게 두 번째 계정을 만들고 첫 번째 계정을 잃었습니다.

웹 서비스에 로그인 한 다음 페이스 북에 로그인하고 페이스 북 ID와 로컬 계정 간의 연결을 캡처 할 수있는 방법이 필요합니다.

그 외에도 당신의 계획은 확실하게 들립니다.

업데이트 : 페이스 북은 이러한 시나리오를 요약 한 문서에 추가했습니다 여기를

Facebook에 명시된대로 https를 사용하여 인증 토큰을 서버로 전송하십시오.

액세스 토큰 공유

당사의 데이터 정책은 귀하의 앱에 대한 액세스 토큰을 다른 앱과 공유하는 것을 명시 적으로 금지합니다. 그러나 HTTPS를 사용하여 전송하는 한 개발자는 동일한 구현 (예 : 동일한 응용 프로그램 ID 사용)의 기본 구현과 서버 구현간에 토큰을 공유 할 수 있습니다.

이 전략으로 볼 수있는 한 가지 문제는 누군가 다른 페이스 북 앱용으로 얻은 액세스 토큰을 제공 할 수 있다는 것입니다. 내가 아는 한, 액세스 토큰이 응용 프로그램에 대한 것인지 확인할 방법이 없으므로 계속 사용하십시오.

그러나 매우 해롭지는 않습니다. 일반적으로 사람 / 앱은 액세스 토큰을 공유하지 않고 보호하려고합니다.

이를 악용 할 수있는 방법 중 하나는 누군가 자신의 사이트 나 모바일 앱을 만들고 사용자의 액세스 토큰을 확보 한 후 API를 사용하여 인증하는 것입니다. 이것이 성공하면 (사용자가 사이트에 페이스 북 계정을 가지고있는 경우) 악의적 인 사이트가 사용자를 가장하는 API를 사용할 수 있습니다.

약간 긴 샷이지만 작동 할 수 있다고 생각합니다.

편집 : 결국 액세스 토큰의 유효성을 검사하는 방법이있는 것 같습니다. 질문에 대한 @Daaniel의 답변을 참조하십시오 사용자 액세스 토큰에서 응용 프로그램 ID 가져 오기 (또는 토큰의 소스 응용 프로그램 확인) .

귀하의 솔루션은 완전히 작동합니다.

어쩌면 대안이 될 수 있습니다. 초기 소셜 서비스 요청에서 고객에게 이메일을 보내고 웹 서비스로 보내십시오. 웹 서비스는 전자 메일과 social_provider도 저장할 수 있습니다. 귀하의 웹 서비스가 이메일의 출처를 확인할 수는 없지만 귀하의 웹 서비스와 클라이언트간에 신뢰도가 높은 관계는 아닙니까? 있다면 올바른 장소에서 오는 이메일에 의존하는 것 같습니다. 이메일 기반 접근 방식을 어리석게 만드는 누락 된 것이 무엇인지 알려주세요.