Projektowanie uwierzytelniania Facebook w aplikacji na iOS, która ma również dostęp do zabezpieczonej usługi internetowej

Cel: Zezwalaj użytkownikowi na uwierzytelnianie za pomocą Facebook w aplikacji iOS, która wymaga dostępu do chronionej usługi internetowej, którą uruchamiam.

Założenia: Istnieje natywny System Uwierzytelniania (i rejestracji) dla tych użytkowników, którzy nie chcą używać Facebook do logowania.

Szczegóły:

  • Załóżmy, że chcemy zaoferować użytkownikowi opcję logowania się przez Facebook bez tworzenia osobnego konta / poświadczenia dla naszego system.
  • ponieważ obsługujemy własny natywny mechanizm auth (nazwa użytkownika i hasło), mamy własne identyfikatory użytkowników i wydajemy token uwierzytelniania, który jest używany do kolejnych interakcji po wstępnej walidacji poświadczeń.

Dziwię się, że Facebook nie ma najlepszych praktyk w tym zakresie w dokumentacji deweloperskiej. Cała istniejąca dokumentacja zakłada, że budujesz FB auth na stronie internetowej lub samodzielną aplikację mobilną bez usługi, która wymaga uwierzytelnianie.

Oto moje pierwsze przemyślenia na temat tego, jak to będzie zaprojektowane, ale chcę sprawdzić, czy jest poprawne.

  1. Klient wyskakuje Login Facebook iOS
    2. Użytkownik loguje się za pomocą danych uwierzytelniających Facebook i otrzymuje token dostępu.]}
  2. aplikacja iOS przekazuje token dostępu do naszego serwera

  3. Nasz serwer rozmawia z FB graph API za pomocą tokena dostępu, Aby (a) zweryfikować token i (b) uzyskać identyfikator użytkownika FB dla tego tokena dostępu.

    Np. nasz serwer będzie call https://graph.facebook.com/me/?access_token=XYZ który zwróci informacje o profilu w obiekcie JSON

  4. Zakładając, że jest poprawne, nasz serwer pobiera identyfikator użytkownika z obiektu JSON i sprawdza, czy użytkownik ma już konto. Jeśli tak, wystawiamy klientowi własny bilet auth, aby mógł go wykorzystać w tej sesji. Jeśli użytkownik nie ma konta, tworzymy nowe z Facebook User ID, przypisujemy własny unikalny UserID i wystawiamy nasz bilet auth.

  5. Klient następnie przekazuje auth ticket z powrotem w kolejnych interakcjach, które wymagają uwierzytelnienia.

Wydaje mi się to właściwe podejście, ale nie jestem pewien, czy brakuje mi czegoś szalenie podstawowego i idę złą (skomplikowaną) ścieżką.

Author: TMC, 2011-01-07
Source

4 answers

Sam sobie z tym poradziłem, a oto część, która mnie ugryzła:

W kroku 5... Użytkownik może zarejestrować konto u Ciebie całkowicie niezależne od swojego identyfikatora Facebook, prawda? Potem innym razem logują się na Facebook.... Założyłeś im drugie konto i straciłeś pierwsze.

Facebook facebook ID to aplikacja mobilna, która umożliwia zalogowanie się na Facebooku i zarejestrowanie powiązania pomiędzy facebook ID A lokalnym konto.

Poza tym, twój plan brzmi solidnie.

Update : Facebook dodał dokument opisujący taki scenariusz tutaj

 72
Author: Dan Ray,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-07-17 17:16:00

Użyj https, aby przesłać Token auth na serwer, jak twierdzi Facebook

Udostępnianie tokenów dostępu

Nasze zasady dotyczące danych wyraźnie zabraniają udostępniania Tokena dostępu dla Twojej aplikacji z dowolną inną aplikacją. Jednak pozwalamy programistom na udostępnianie tokenów między implementacją natywną a serwerem implementacja tej samej aplikacji (tj. używając tego samego ID aplikacji) tak długo, jak transfer odbywa się przy użyciu HTTPS.

 27
Author: zoomcrypt,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-03-11 03:53:12

Jeden problem widzę z tej strategii, jest to, że ktoś może dać ci token dostępu uzyskane dla innej aplikacji facebook. Z tego, co wiem, nie ma sposobu, aby zweryfikować, czy token dostępu jest dla Twojej aplikacji, więc po prostu go używaj.

To nie brzmi zbyt szkodliwie. Generalnie ludzie / aplikacje starają się chronić tokeny dostępu, zamiast je udostępniać.

Jednym z możliwych exploitów byłoby, aby ktoś stworzył własną stronę lub aplikację mobilną, uzyskać uzyskaj dostęp do tokenów dla swoich użytkowników i spróbuj je uwierzytelnić za pomocą interfejsu API. Jeśli to się powiedzie (użytkownik ma konto facebook w Twojej witrynie), złośliwa witryna będzie mogła użyć Twojego API podszywając się pod użytkownika.

To trochę ryzykowne, ale myślę, że może się udać.

Edit: wygląda na to, że istnieje sposób, aby zweryfikować token dostępu. Zobacz odpowiedź @Daaniel na pytanie Get application id from user access token (or verify the source application for a token) .

 12
Author: ivant,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 11:47:23

Twoje rozwiązanie całkowicie działa.

Może alternatywa: dlaczego po prostu nie dostać e-mail o kliencie z pierwotnego wniosku o usługę społecznościową i wysłać do serwisu internetowego? Serwis internetowy może po prostu przechowywać e-mail, a może również social_provider. Rozumiem, że Twój serwis internetowy nie będzie w stanie potwierdzić, skąd pochodzi e-mail, ale czy nie ma relacji wysokiego zaufania między Twoim serwisem internetowym a twoim klientem? Jeśli tak, wydaje się, że możesz polegać na nadchodzącym e-mailu z właściwego miejsca. Niech ktoś da mi znać, czego mi brakuje, co sprawia, że podejście oparte na e-mailu jest głupie...

 3
Author: hamsterdam,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-03-04 05:07:56