Co musisz wiedzieć o OAuth2 i logowaniu za pomocą Facebooka

Jeśli zastanawiasz się, czym jest OAuth2, jest to protokół, który umożliwia każdemu zalogowanie się za pomocą swojego konta na Facebooku. Obsługuje przycisk „Zaloguj się przez Facebooka” w aplikacjach i witrynach internetowych na całym świecie.

Ten artykuł pokazuje, jak działa „Zaloguj się przez Facebooka” i wyjaśnia protokół, który za tym wszystkim stoi. Dowiesz się, dlaczego chcesz logować się za pomocą Facebooka, Google, Microsoftu lub jednej z wielu innych firm obsługujących OAuth2.

Ten artykuł pokazuje, jak działa „Zaloguj się przez Facebooka” i wyjaśnia protokół, który za tym wszystkim stoi. Dowiesz się, dlaczego chcesz logować się za pomocą Facebooka, Google, Microsoftu lub jednej z wielu innych firm obsługujących OAuth2.

Przyjrzymy się dwóm przykładom: dlaczego Spotify używa Facebooka, aby umożliwić Ci zalogowanie się do aplikacji mobilnej Spotify oraz dlaczego Quora używa Google i Facebooka, aby umożliwić Ci zalogowanie się na swojej stronie internetowej.

Dalsze czytanie na SmashingMag:

• Cztery sposoby na zbudowanie aplikacji mobilnej
• Jak zbudować uczciwy interfejs użytkownika i pomóc użytkownikom w podejmowaniu lepszych decyzji
• Utrzymywanie popularności aplikacji na Androida po uruchomieniu
• Playlisty Spotify, które napędzają Twoje sesje kodowania i projektowania
  

Przed OAuth2

OAuth2 wygrał bitwę o standardy kilka lat temu. Jest to jedyny protokół uwierzytelniania obsługiwany przez głównych dostawców. Google zaleca OAuth2 dla wszystkich swoich interfejsów API, a interfejs API Graph Facebooka obsługuje tylko OAuth2.

Najlepszym sposobem na zrozumienie OAuth2 jest przyjrzenie się temu, co było przed nim i dlaczego potrzebowaliśmy czegoś innego. Wszystko zaczęło się od Basic Auth.

Uwierzytelnianie podstawowe

Schematy uwierzytelniania skupiają się na dwóch kluczowych pytaniach: Kim jesteś? I czy możesz to udowodnić?

Najczęstszym sposobem zadawania tych dwóch pytań jest podanie nazwy użytkownika i hasła. Nazwa użytkownika mówi kim jesteś, a hasło to potwierdza.

Uwierzytelnianie podstawowe było pierwszym schematem uwierzytelniania internetowego. Brzmi śmiesznie, ale w specyfikacji opublikowanej po raz pierwszy w 1999 r. nosiła nazwę „Podstawowe uwierzytelnianie”.

Uwierzytelnianie podstawowe umożliwia serwerom sieciowym proszenie o podanie tych poświadczeń w sposób zrozumiały dla przeglądarek. Serwer zwraca kod odpowiedzi HTTP 401 (co oznacza, że ​​wymagane jest uwierzytelnienie) i dodaje do odpowiedzi specjalny nagłówek o nazwie WWW-Authenticate ze specjalną wartością Basic .

Gdy przeglądarka widzi ten kod odpowiedzi i ten nagłówek, wyświetla wyskakujące okno dialogowe logowania:

Największą zaletą Basic Auth jest jego prostota. Nie musisz pisać ekranu logowania. Przeglądarka obsługuje to wszystko i po prostu wysyła nazwę użytkownika i hasło na serwer. Daje to również przeglądarce szansę na specjalną obsługę hasła, czy to poprzez zapamiętanie go dla użytkownika, pobranie go z wtyczki innej firmy, czy pobranie danych uwierzytelniających użytkownika z jego systemu operacyjnego.

Minusem jest to, że nie masz żadnej kontroli nad wyglądem ekranu logowania. Oznacza to, że nie możesz go wystylizować ani dodać nowych funkcji, takich jak „Zapomniałeś hasła?” link lub możliwość utworzenia nowego konta. Jeśli chcesz więcej personalizacji, musisz napisać niestandardowy formularz logowania.

Niestandardowe formularze logowania

Niestandardowe formularze logowania zapewniają pełną kontrolę, jakiej możesz chcieć. Piszesz formularz HTML i pytasz o poświadczenia. Następnie przesyłasz formularz i obsługujesz logowanie w dowolny sposób. Masz pełną kontrolę: możesz go nadać stylizacji, poprosić o więcej szczegółów lub dodać więcej linków.

Niektóre strony internetowe, takie jak WordPress, używają prostego formularza na ekranie logowania:

LinkedIn pozwala użytkownikom zalogować się lub utworzyć konto na tej samej stronie, bez konieczności przechodzenia do innej części serwisu:

Logowanie za pomocą formularzy jest bardzo popularne, ale wiąże się z głównym podstawowym problemem: użytkownicy muszą podać stronie swoje hasło.

Utrzymywanie tajemnic w tajemnicy

W kręgach bezpieczeństwa nazywamy hasło tajemnicą. To informacja, którą tylko Ty posiadasz i udowadnia, że ​​jesteś sobą. Sekret może być również czymś więcej niż tylko hasłem; porozmawiamy o tym nieco później.

Strona internetowa może podjąć wszystkie środki bezpieczeństwa na świecie, ale jeśli użytkownik udostępni swoje hasło, to bezpieczeństwo zniknie. Hakerzy włamali się do witryny Gawker w 2010 roku, ujawniając hasła wielu użytkowników. Chociaż stanowiło to problem dla Gawkera, problem na tym się nie skończył. Większość ludzi ponownie używa haseł, więc hakerzy zabrali dane, które wyciekły z Gawkera, i próbowali zalogować się na bardziej krytyczne strony internetowe, takie jak Gmail, Facebook i eBay. Każdy, kto używał hasła Gawkera do ważniejszych rzeczy, stracił znacznie więcej niż ostatnie plotki o seks taśmie Hulka Hogana.

Upewnienie się, że Twoi użytkownicy nie używają ponownie hasła do wielu kont, to pierwsza połowa problemu — a jest to niemożliwe. Dopóki ludzie będą musieli tworzyć różne konta w całym Internecie, będą ponownie używać swoich haseł.

Druga połowa problemu to bezpieczne przechowywanie haseł.

Gdy ktoś loguje się do Twojej aplikacji, musisz zweryfikować jego hasło, a to oznacza, że ​​potrzebujesz kopii, aby to zweryfikować. Możesz przechowywać wszystkie nazwy użytkowników i hasła gdzieś w bazie danych, ale teraz ryzykujesz utratę tych haseł lub zhakowanie. Najlepszą praktyką jest użycie funkcji skrótu, takiej jak jedna z funkcji SHA-2. Ta funkcja szyfruje dane w taki sposób, że nigdy nie można ich odzyskać, ale możesz odtworzyć szyfrowanie: „moje hasło” za każdym razem zostanie zaszyfrowane do czegoś takiego jak bb14292d91c6d0920a5536bb41f3a50f66351b7b9d94c804dfce8a96ca1051f2 .

A teraz jesteśmy w wysokiej trawie: opowiem wam, jak wdrożyć protokoły kryptograficzne. Następnie wyjaśnię, jak dodać soli do twoich danych i które podręczniki przeczytać o atakach typu man-in-the-middle. Wszystko, co chciałeś zrobić, to napisać aplikację, a teraz musisz zostać ekspertem ds. Bezpieczeństwa. Musimy się cofnąć.

OAuth2

Prawdopodobnie nie jesteś ekspertem od bezpieczeństwa. Nawet jeśli tak, to i tak nie powierzyłbym Ci mojego hasła. OAuth2 zapewnia lepszy sposób.

Jako przykład używam Spotify na moim iPadzie. Płacę firmie 10 dolarów miesięcznie za słuchanie muzyki. Spotify daje mi dostęp tylko na trzech urządzeniach, więc potrzebuję hasła, aby mieć pewność, że nikt inny nie użyje mojego konta. Moje konto Spotify nie stanowi dużego problemu w zakresie bezpieczeństwa. Zhakowanie to nie koniec świata, ale firma ma moją kartę kredytową, więc chcę się upewnić, że jestem bezpieczny.

Rzadko się loguję do Spotify, więc nie chcę zakładać kolejnego konta i muszę pamiętać kolejne hasło. Spotify daje mi lepszą opcję:

Mogę zalogować się za pomocą mojego konta na Facebooku. Kiedy klikam ten przycisk, Spotify wysyła mnie do facebook.com i tam się loguję. To może wydawać się drobnym szczegółem, ale jest to najważniejszy etap całego procesu.

Programiści Spotify mogli sami napisać formularz logowania, a następnie wysłać moją nazwę użytkownika i hasło do Facebooka za pomocą interfejsu API zaplecza, ale są dwa ważne powody, dla których nie chcę, aby to robili:

• Nie ufam Spotify, jeśli chodzi o moje hasło do Facebooka. Używam Facebooka do łączenia się ze znajomymi i nie chcę zostać zhakowany. Nie ufam, że Spotify poprawnie obsłuży hasło. Nie wierzę też, że uniknie pokusy zrobienia z nim czegoś zabawnego. Może spróbuje go przechowywać, aby później mógł z niego korzystać. Może ma błąd, który zapisuje go gdzieś w pliku przed wysłaniem go na Facebooka, aby haker mógł go złapać. Przepraszam, Spotify; Po prostu nie jestem typem ufnym.
• Nie chcę, żeby Spotify robił wszystko. Chcę, aby Spotify odtwarzał muzykę. Nie chcę, żeby to było publikowane na ścianach moich znajomych, kiedy słucham Spice Girls. Nie chcę też, aby pobierał moją listę znajomych i podsłuchiwał ich, aby dołączyli do Spotify. Gdybym podawał Spotify moje hasło do Facebooka, mógłby zalogować się jako ja na Facebooku; mógł zrobić wszystko, co mogłem zrobić.

Istnieją również dwa ważne powody, dla których Spotify nie chce tego robić:

• Facebook ma dla mnie wiele opcji logowania . Mogę się zalogować za pomocą mojej nazwy użytkownika i hasła lub mogę zalogować się za pomocą aplikacji Facebook. Mogę też odzyskać moje hasło z Facebooka lub uzyskać pomoc, której Spotify nie może mi udzielić. Gdybym po prostu podawał Spotify moje hasło, nie otrzymałbym żadnej z tych opcji.
• Mój sekret może nie być hasłem. . Hasło jest wystarczającym zabezpieczeniem dla mojego konta Spotify za 10 USD miesięcznie, ale może nie wystarczyć dla mojego banku lub czegoś jeszcze ważniejszego. Mogę podać wiele innych sekretów: mogę mieć kartę inteligentną lub mieszkać w filmie Mission Impossible i korzystać ze skanera siatkówki.

Nie jestem w filmie Mission Impossible, ale w prawdziwym świecie wiele firm używa uwierzytelniania dwuskładnikowego, takiego jak hasło i coś innego. Najpopularniejszą metodą jest użycie telefonu. Gdy chcesz się zalogować, firma wysyła Ci SMS-a ze specjalnym kodem, który trwa kilka minut; następnie wpisz kod lub użyj aplikacji, aby go wprowadzić.

Teraz firma ma pewność, że nikt nie może zalogować się na Twoje konto bez Twojego telefonu. Jeśli ktoś wykradnie Twoje hasło, nadal nie będzie mógł się zalogować. Dopóki nie zgubisz telefonu, wszystko jest bezpieczne.

Facebook nie jest jedynym dostawcą OAuth2. Kiedy loguję się do Quora za pomocą mojego konta Google, Google mówi mi, co Quora chce zrobić, i pyta, czy to jest w porządku:

Mogę być w porządku, zezwalając Quorze na wyświetlanie mojego adresu e-mail i podstawowych danych profilu, ale nie chcę, aby zarządzała ona moimi kontaktami. OAuth2 pokazuje mi cały dostęp, którego chce Quora, pozwalając mi wybrać, do czego przyznam dostęp.

Oto zalety OAuth2. Zobaczmy, jak to działa.

Jak działa OAuth2

Facebook, Google i większość innych dostawców OAuth2 traktuje klientów natywnych inaczej niż klientów internetowych. Klienci natywni są uważani za bardziej bezpiecznych i otrzymują tokeny oraz tokeny odświeżania, które mogą trwać miesiącami. Klienci sieci Web otrzymują znacznie krótsze tokeny, które zazwyczaj wygasają, gdy użytkownik zamyka przeglądarkę lub nie klika witryny przez jakiś czas.

W obu przypadkach proces logowania jest taki sam. Różnica polega na tym, jak często użytkownik musi przez to przechodzić.

Logowanie OAuth2 odbywa się zgodnie z następującymi ogólnymi krokami:

1. Użytkownik próbuje zrobić coś, co wymaga uwierzytelnienia. Może to być tak proste, jak otwarcie aplikacji lub kliknięcie przycisku „Zaloguj się”.
2. Aplikacja lub strona internetowa ustala, że ​​użytkownik jeszcze się nie zalogował i rozpoczyna proces logowania. Robi to, otwierając stronę internetową i wysyłając ją na specjalny adres URL na Facebooku, Google lub jakiejkolwiek innej witrynie udostępniającej OAuth2.

Otwarcie nowego okna przeglądarki dla dostawcy OAuth2 to kluczowy krok. To umożliwia dostawcom pokazywanie własnych formularzy logowania i proszenie każdego użytkownika o wszelkie potrzebne informacje do logowania. Większość aplikacji robi to za pomocą wbudowanego widoku internetowego.

Wraz z adresem URL logowania dostawcy musisz przesłać kilka parametrów adresu URL, które informują dostawcę, kim jesteś i co chcesz zrobić:

• client_id Informuje dostawcę OAuth2 o Twojej aplikacji. Aby uzyskać identyfikator klienta, musisz wcześniej zarejestrować swoją aplikację.
• redirect_uri Informuje dostawcę, dokąd chcesz się udać, kiedy skończysz. W przypadku witryny internetowej może to być powrót do strony głównej; aplikacja natywna może przejść do strony, która zamyka widok internetowy.
• response_type Informuje dostawcę, co chcesz odzyskać. Zwykle ta wartość to token , aby wskazać, że potrzebujesz tokena dostępu, lub code , aby wskazać, że potrzebujesz kodu dostępu. Dostawcy mogą również rozszerzyć tę wartość, aby zapewnić inne rodzaje danych.
• scope Informuje dostawcę, do czego aplikacja chce uzyskać dostęp. W ten sposób Google wie, że Quora prosi o dostęp do zarządzania kontaktami. Każdy dostawca ma inny zestaw zakresów.

Istnieją dodatkowe pola, które mogą zwiększyć bezpieczeństwo lub pomóc w buforowaniu. Niektórzy dostawcy mogą również dodawać więcej pól, ale te cztery są najważniejsze.

Gdy Twoja aplikacja otworzy widok internetowy, dostawca przejmuje kontrolę. Mogą po prostu poprosić o prostą nazwę użytkownika i hasło lub mogą wyświetlić wiele ekranów z prośbą o wszystko, od imienia ulubionego nauczyciela po nazwisko panieńskie matki. To wszystko zależy od nich. Ważną częścią jest to, że gdy dostawca skończy, przekieruje z powrotem do Ciebie i przekaże Ci token.

Chodzi o tokeny

Po zakończeniu procesu dostawca poda token i typ tokena. Istnieją dwa rodzaje tokenów: tokeny dostępu i tokeny odświeżania. Typ klienta, którego masz, określi, o jakie typy tokenów możesz poprosić.

Kiedy loguję się do mojej aplikacji Spotify, mogę pozostać zalogowany przez wiele miesięcy, ponieważ z założenia mój telefon jest używany tylko przeze mnie. Facebook ufa aplikacji Spotify do zarządzania tokenami, a ja ufam, że aplikacja Spotify nie zgubi tokenów.

Gdy token dostępu wygaśnie (zwykle w ciągu jednej do dwóch godzin), Spotify może użyć tokena odświeżania, aby uzyskać nowy.

Odśwież token działa przez miesiące. W ten sposób loguję się na telefonie tylko kilka razy w roku. Minusem jest to, że jeśli stracę ten token odświeżania, ktoś inny może korzystać z mojego konta przez miesiące. Token odświeżania jest tak ważny, że system iOS zapewnia pęk kluczy dla tokenów, w którym zapewnia ich bezpieczne szyfrowanie i przechowywanie.

Używanie OAuth2 w aplikacji internetowej działa w ten sam sposób. Zamiast korzystać z widoku internetowego, możesz otworzyć żądanie logowania OAuth2 w ramce, ramce iframe lub osobnym oknie. Możesz również otworzyć go na bieżącej stronie, ale spowoduje to utratę całego stanu aplikacji JavaScript, gdy ktoś będzie musiał się zalogować.

Gdy loguję się do Quora za pomocą przeglądarki internetowej, nie otrzymuję tokena odświeżania. Chcą, aby token wygasł i poprosił mnie o ponowne zalogowanie, gdy zamknę przeglądarkę lub nawet wyjdę na lunch. Niezaufani klienci nie mogą odświeżyć tokenu, ponieważ nie można im zaufać w przechowywaniu ważnego tokenu odświeżania. Jest to bezpieczniejsze, ale mniej wygodne, ponieważ znacznie częściej będą monitować o ponowne zalogowanie.

Korzystanie z OAuth2 w Twojej aplikacji

Teraz wiesz, jak działa OAuth2, ale prawdopodobnie nie chcesz implementować własnego klienta OAuth2. Możesz przeczytać całą 75-stronicową specyfikację OAuth 2.0, jeśli masz problemy ze snem, ale nie musisz. Do dyspozycji masz kilka świetnych bibliotek.

iOS ma wbudowaną obsługę OAuth2. Corrina Krych ma bardzo pomocny samouczek dotyczący korzystania z OAuth 2.0 w Swift. Przeprowadzi Cię przez proces pozyskiwania tokena, integrowania widoków w Twojej aplikacji i miejsca przechowywania tokenów.

Android ma również wbudowaną obsługę OAuth2. Muszę przyznać, że nie znam się na tym, bo skupiam się na iOS, ale w dokumentacji jest kilka dobrych rozdziałów, aby pokazać przykłady i kilka bibliotek open-source, aby było jeszcze łatwiej.

JavaScript nie ma wbudowanej obsługi OAuth2, ale istnieją klienci dla wszystkich głównych bibliotek JavaScript. React w pełni obsługuje protokół OAuth2. AngularJS ma wsparcie innych firm dla OAuth2.0 dla wielu projektów. Napisałem nawet jedną z nich.

Gdy masz już klienta OAuth2, musisz wybrać dostawcę.

Komu ufasz?

Wielkie założenie jest takie, że bardziej ufam Facebookowi niż Spotify. Nie mam ku temu dobrego powodu. Facebook nie upublicznia swoich wewnętrznych zabezpieczeń i nie ma dla mnie dobrego sposobu na jego audyt. Spotify nie. Nie ma raportów konsumenckich dotyczących zabezpieczeń OAuth2. Zasadniczo ufam Facebookowi, ponieważ jest większy. Ufam Facebookowi, tak jak inni.

Mam też większe zaufanie do Facebooka za każdym razem, gdy klikam przycisk „Zaloguj się przez Facebooka”. Jeśli Facebook zgubi moje hasło, hakerzy uzyskają dostęp nie tylko do mojego konta na Facebooku, ale także do mojego konta Spotify i do każdej innej usługi, do której zalogowałem się za pomocą mojego konta na Facebooku. Plusem jest to, że jest tylko jedno miejsce, w którym muszę zresetować hasło, aby naprawić problem.

Nie muszę ufać Facebookowi, ale muszę komuś zaufać. Ktoś musi mnie uwierzytelnić. Muszę wybrać dostawcę, któremu ufam.

Wybór dostawcy OAuth2

Wikipedia prowadzi listę dostawców OAuth, ale większość z nich nie będzie Cię obchodzić. Największe z nich to Facebook i Google. Możesz także spojrzeć na Amazon lub Microsoft.

Wszystkie cztery są duże i łatwe do zintegrowania. Facebook udostępnia instrukcje dotyczące rejestracji aplikacji. Google ma podobne kroki. Podstawowym pomysłem jest utworzenie konta programisty, a następnie utworzenie identyfikatora aplikacji. Dostawca udostępnia następnie identyfikator klienta, którego można używać do składania żądań.

Możesz także wybrać wielu dostawców. Quora umożliwia logowanie przez Facebook lub Google; ponieważ oba używają OAuth2, możesz użyć tego samego kodu dla obu.

Czego brakuje w OAuth2

OAuth2 bardzo dobrze radzi sobie z rozwiązywaniem złożonego problemu, ale brakuje mu kilku rzeczy:

• Standard nie jest całkowicie standardowy. Nigdy nie byłem w stanie napisać ani jednego klienta OAuth2, który może logować się zarówno do Facebooka, jak i Google bez kilku instrukcji if . Każdy interpretuje specyfikację w inny sposób, a każdy z nich zawiera niewiele odmiennych szczegółów. Zawsze mają też różne pomysły na to, jakie zakresy mają zapewnić. Korzystanie z biblioteki do integracji z OAuth2 bardzo pomaga w rozwiązaniu tego problemu, ale nigdy nie będzie w 100% przejrzyste w kodzie aplikacji.
• Wylogowanie jest trudne. . Każda aplikacja lub witryna korzystająca z protokołu OAuth2 ma przycisk wylogowania, ale większość z nich po prostu zapomni tokeny bez ich unieważniania. Aplikacja zapomni o wszystkich Twoich obecnych tokenach i pozwoli komuś innemu się zalogować, ale Twoje tokeny są nadal ważne. Jeśli haker ukradł Twój token, nadal może go użyć i zalogować się jako Ty.

Istnieje osobna specyfikacja dotycząca unieważniania tokenów OAuth2, ale nie została ona odebrana przez wielu głównych dostawców. OAuth2 nie zapewnia sposobu na odzyskanie, jeśli haker otrzyma Twój token odświeżania; nawet jeśli możesz usunąć lokalną kopię tokena, haker nadal będzie ją miał. Wielu dostawców umożliwia zawieszenie konta, ale nie ma na to standardowego sposobu.

W obronie OAuth2 jest to trudny problem, ponieważ wielu dostawców używa kryptografii klucza publicznego do tworzenia tokenów bezstanowych. Oznacza to, że serwer nie pamięta utworzonych przez siebie tokenów, więc nie może ich później zapomnieć.

Innym poważnym problemem związanym z OAuth2 jest uzależnienie od dostawcy. Kiedy Facebook przestaje działać, podobnie dzieje się z przyciskiem „Zaloguj się przez Facebooka” w Twojej aplikacji. Jeśli Google zdecyduje się zacząć pobierać opłaty za obsługę protokołu OAuth2 lub zażąda, abyś podzielił się z nim swoim zyskiem, nic nie możesz zrobić. To jest obosieczny miecz zaufania dostawcy: wiele dla Ciebie robią, ale mają kontrolę nad Twoimi użytkownikami.

OAuth2 rządzi światem

Nawet przy kilku brakujących funkcjach i dużej zależności OAuth2 jest nadal doskonałym wyborem. Ułatwia użytkownikom logowanie się do Twojej aplikacji, nie muszą pamiętać hasła do każdej witryny i ufają Twojemu bezpieczeństwu. OAuth2 to bardzo popularny wybór. Dominuje w branży. Żaden inny protokół bezpieczeństwa nie zbliża się do przyjęcia OAuth2.

Teraz wiesz, skąd pochodzi protokół OAuth2 i jak to działa. Dokonaj mądrych wyborów, komu zaufać, przestań czytać artykuły o bezpiecznym przechowywaniu zaszyfrowanych haseł i spędzaj więcej czasu na pisaniu swojej niesamowitej aplikacji.