Wstęp

Coraz więcej stron internetowych wymaga od nas utworzenia konta w ich serwisie, aby móc w pełni korzystać z możliwości witryny. Bazując na bezpiecznych praktykach w sieci, zakładamy, że nasze hasła nie powtarzają się. To natomiast generuje niezliczoną liczbę ciągów znaków do zapamiętania. Całokształt sprawia, że coraz częściej decydujemy się na logowanie za pośrednictwem narzędzia uwierzytelniającego takiego jak Google, Facebook czy Twitter. Logowanie do witryny za pomocą zewnętrznego serwisu jest możliwe dzięki OAuth – ale czym on właściwie jest? Postaramy się to wyjaśnić w naszym artykule.

Czym jest OAuth?

OAuth nie jest interfejsem API ani usługą – to otwarty standard autoryzacji i każdy może go zaimplementować. Oznacza to, że dowolne aplikacje mogą używać tego standardu w celu zapewnienia aplikacjom klienckim „bezpiecznego dostępu delegowanego”, czyli umożliwienia aplikacjom uzyskania ograniczonego dostępu (tzw. zakresów) do danych użytkownika bez standardowych poświadczeń. 

OAuth obsługuje aplikacje typu serwer-serwer, aplikacje przeglądarkowe oraz aplikacje mobilne. Standard działa przez HTTPS i autoryzuje urządzenia, interfejsy API, serwery i aplikacje za pomocą tokenów dostępu, a nie poświadczeń, takich jak login i hasło. Jego działanie możemy zatem streścić w następujący sposób:

„OAuth zapewnia klientom bezpieczny dostęp do zasobów serwera w imieniu właściciela zasobów.”

Warto w tym miejscu podkreślić, że OAuth dotyczy w szczególności autoryzacji, a nie bezpośrednio uwierzytelniania. OAuth umożliwia wydawanie tokenów dostępu klientom zewnętrznym przez serwer autoryzacyjny za zgodą właściciela zasobu (np. profilu na Facebooku). Firma zewnętrzna może następnie użyć tokenu, aby uzyskać dostęp do chronionych zasobów hostowanych przez serwer zasobów.

Uwierzytelnianie to proces, w którym użytkownik/podmiot udowadnia, że jest właścicielem prezentowanej tożsamości, poprzez wprowadzenie loginu i hasła, odcisku palca czy poprzez biometrię behawioralną. Natomiast autoryzacja to proces nadający użytkownikowi, programowi lub procesowi odpowiednich uprawnień do korzystania z danych zasobów po pomyślnym uwierzytelnieniu.

Niewątpliwie autoryzacja w nowej witrynie za pomocą istniejącego już konta jest wygodna – przyspiesza ona proces rejestracji, eliminuje potrzebę ponownego wypełniania formularza naszymi danymi i zapamiętywania kolejnych, różnych dla każdej aplikacji nazw użytkownika i haseł (zakładając, że wszyscy używamy unikalnych nazw użytkowników i silnych haseł dla każdego serwisu). Wykorzystanie standardu OAuth sprawia, że zamiast zapamiętywać kolejne dane logowania do aplikacji, wystarczy użyć poświadczeń do wybranego serwisu, które już znamy na pamięć.

Rys. 1. Ekran logowania do aplikacji wspierającej autoryzację za pośrednictwem zewnętrznego serwisu..

Kolejnym z powodów rosnącej popularności OAuth jest fakt, że standard jest obsługiwany przez wielu dostawców usług, takich jak: Facebook, Twitter, Google, Yahoo, Windows Live, LinkedIn, GitHub, Bitbucket, PayPal, Amazon, Autodesk, Reddit, Evernote, Evernote (sandbox), Exact i wiele więcej, a ich liczba ciągle się zwiększa. Dodatkowo istnieje możliwość utworzenia własnego serwera autoryzacji, co przekłada się na nieograniczone możliwości implementacji.

OAuth. Jesteś zainteresowany tematem? Już wkrótce więcej na ten temat na naszym blogu!

Jak to działa?

Zasadniczo serwisy społecznościowe ręczą za Ciebie. Gdy zdecydujesz się zalogować do aplikacji za pomocą Google lub Facebooka, wyświetlone okno dialogowe logowania jest w rzeczywistości dostarczane przez serwis autoryzacyjny, a nie przez aplikację, w której próbujesz utworzyć konto. W przypadku, gdy nie jesteś zalogowany w serwisie autoryzacyjnym, musisz wprowadzić swoją nazwę użytkownika i hasło, a następnie zostaniesz poproszony o przyznanie zgody na dostęp do pewnego zakresu Twoich danych (rysunek nr 2). Następnie serwis zgłasza się z powrotem do aplikacji, mówiąc: „Tak, znamy tę osobę i potwierdziliśmy, że jest tym, za kogo się podaje. Możesz kontynuować”.

Rys. 2. Monit z prośbą o nadanie dostępu aplikacji klienckiej do pewnych zakresów danych uzytkownika.

Aplikacja innej firmy: „Aplikacja kliencka/Klient”

• Klient to aplikacja, która próbuje uzyskać dostęp do konta użytkownika (musi uzyskać pozwolenie od właściciela zasobów).

API: „Serwer zasobów”

• Serwer zasobów to serwer API używany do uzyskiwania dostępu do informacji użytkownika.

Użytkownik: „Właściciel zasobu”

• Właścicielem zasobu jest osoba, która daje dostęp do pewnej części swojego konta.

Proces autoryzacji rozpoczyna się, gdy użytkownik wyrazi zamiar uzyskania dostępu do interfejsu API. Dzieje się to tak (w dużym uproszczeniu):

KROK 1) Upoważnienie

Użytkownik wchodzi do aplikacji i wybiera żądanego dostawcę sieci społecznościowej (np. Facebook, Google, Github, itp.). Aplikacja kliencka wysyła żądanie do Serwera zasobów z prośbą o autoryzację. Przykładowe żądanie może wyglądać następująco:

https://authorization-server.com/oauth/authorize?
response_type=code
client_id=CLIENT_ID&
redirect_uri=REDIRECT
redirect_uri=REDIRECT_URI&
scope=EXAMPLE_SCOPE&
state=BfuQzzcMGWbhH

• response_type=code — wskazuje, że serwer oczekuje na kod autoryzacyjny;
• client_id — identyfikator klienta otrzymany podczas tworzenia aplikacji;
• redirect_uri — wskazuje identyfikator URI, do którego ma zwrócić użytkownika po zakończeniu autoryzacji;
• scope — wartość zawierająca listę zakresów (ang. scope), definiujących uprawnienia do Twojego konta, jakie mają zostać nadanie aplikacji klienckiej;
• state — losowy ciąg znaków wygenerowany przez Twoją aplikację, który zostanie później zweryfikowany.

W przypadku, gdy użytkownik nie jest zalogowany w aplikacji, wywołanie URLa oauth/authorize z opisanymi wyżej parametrami spowoduje przekierowanie do strony logowania w serwisie. Natomiast, gdy istnieje aktywna sesja użytkownika, właścicielowi zasobu pojawi się monit z prośbą o nadanie dostępu do pewnych zakresów danych o użytkowniku.

Zatwierdzenie nadania dostępu spowoduje przekierowanie do aplikacji klienckiej pod wskazany wcześniej adres REDIRECT_URI z uwzględnieniem parametrów code (klucz potrzebny do wygenerowania tokenu przez aplikację kliencką) oraz state (parametr otrzymany wcześniej z aplikacji klienckiej)

https://example-app.com/callback?code=AUTH_CODE&state=BfuQzzcMGWbhH

• kod — serwer zwraca kod autoryzacji w ciągu zapytania;
• state — serwer zwraca tę samą wartość stanu.

Przy odbiorze żądania wartość stanu jest weryfikowana.

KROK 2) Uzyskanie tokenu dostępu

Aplikacja kliencka wymienia kod autoryzacji na token dostępu, wysyłając żądanie POST pod wskazany endpoint serwera autoryzacji:

POST https://authorization-server.com/token
grant_type=authorization_code&
code=AUTH_CODE&
redirect_uri=REDIRECT_URI&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET

• grant_type=authorization_code — typ uprawnień dla tego żądania;
• code=AUTH_CODE — kod otrzymany w odpowiedzi na poprzednie żądanie;
• redirect_uri=REDIRECT_URI — wartość identyfikatora URI (analogiczna do wartości podanej w oryginalnym linku);
• client_id=CLIENT_ID — identyfikator klienta;
• client_secret=CLIENT_SECRET — klucz klienta.

Jeśli weryfikacja naszego żądania przebiegła pomyślnie, serwer autoryzacyjny w odpowiedzi przesyła nam token dostępu, czas jego wygaśnięcia oraz token odświeżający, który pozwala na wygenerowanie nowego tokenu dostępu bez ponownego przechodzenia całej ścieżki logowania Użytkownika.

{
„access_token”:”RsT5OjbzRn430zqMLgV3Ia”,
„refresh_token”:”eyJ0eXAiOiJKV1QiLCJhbG”,
„expires_in”:3600
}

Natomiast w przypadku niepowodzenia weryfikacji możemy otrzymać następującą odpowiedź:

{
„error”:”invalid_request”
}

Warto pamiętać, że Użytkownik nigdy nie musiał udostępniać Aplikacji klienckiej swoich danych logowania (nazwy użytkownika i hasła) do serwisu autoryzacyjnego – po prostu przekazał dostęp za pomocą OAuth w bezpieczny sposób. Użytkownik może w dowolnym momencie zalogować się do serwisu autoryzacyjnego i sprawdzić przyznane dostępy oraz unieważnić tokeny dla określonych aplikacji.

Przedstawione rozwiązanie jest wyłącznie uproszczonym schematem działania niebędącym rzeczywistą implementacją. 

Czy protokół OAuth jest bezpieczny?

Pod wieloma względami tak – w rzeczywistości logowanie do zewnętrznych serwisów za pośrednictwem Google lub Facebooka jest o wiele bezpieczniejsze niż tworzenie samodzielnego konta i hasła.

Jeśli w życiu codziennym nie wykorzystujesz menedżera haseł, zapewne nie tworzysz unikalnych poświadczeń dla każdej witryny lub Twoje hasła są słabe. W przypadku, gdy jedna z tych stron zostanie zhakowana, hakerzy będą mogli poskładać Twoje wzorce tworzenia haseł. Co gorsza, jeśli nie używałeś unikalnych haseł, teraz w zasadzie mają klucz do wszystkich Twoich kont. Dzięki OAuth możesz skupić się na utworzeniu jednego silnego hasła do serwisu autoryzacyjnego, z którego korzystasz na co dzień, a wtedy będzie to jedyne hasło, które będziesz musiał zapamiętać.

Słabe hasło – to krótkie, powszechne słowa/ciągi znaków, które są łatwe do odgadnięcia lub złamania wykonując techniki, takie jak atak brute force. Ludzie często używają oczywistych haseł, jak imiona swoich dzieci lub numer domu, aby ich nie zapomnieć. Jednak im prostsze hasło, tym łatwiej je wykryć/złamać.

Jednak co się wydarzy, jeśli Twoje hasło do serwisu autoryzacyjnego zostanie skradzione? Czy to nie daje hakerom dostępu do wszystkiego, a nie tylko do jednej rzeczy?

Jeśli chodzi serwisy takie jak Gmail, Twoje hasło jest już w pewnym sensie sposobem hakera na wszystko. Gdy otrzyma on hasło do Twojej poczty e-mail, może poprosić o link do zresetowania hasła do dowolnej, używanej przez Ciebie aplikacji, w której wykorzystałeś adres mailowy do utworzenia konta. Link zostanie wysłany na adres poczty, do którego właśnie utraciłeś dostęp – zatem używanie danych logowania Google do logowania się do innych aplikacji nie stanowi nowego zagrożenia bezpieczeństwa poza tym, co jest już możliwe dla hakera przy użyciu Twojego hasła.

Z drugiej strony wielkie platformy, jak Facebook, Google, Twitter, mają ogromne środki i zespoły specjalistów, którzy dbają o bezpieczeństwo Twoich danych, cały czas monitorują Twoje konto i sygnalizują podejrzaną aktywność. To wszystko minimalizuje zagrożenia związane z utratą dostępu do konta. Wspomniani giganci wiedzą jak istotne jest odpowiednie zabezpieczenie danych swoich klientów, tym bardziej, że każda luka bezpieczeństwa oraz podatność na ataki wiąże się z ogromnymi stratami pieniężnymi i wizerunkowymi.

Kolejnym czynnikiem zwiększającym bezpieczeństwo naszych danych w sieci jest wykorzystanie dwuetapowego uwierzytelniania (2FA), które w ostatnich latach stało się niejako standardem zwiększenia bezpieczeństwa danych, wykorzystywanym przez platformy takie jak Google czy Facebook. Jest to forma dodatkowej weryfikacji podczas uwierzytelniania, która utrudnia niepowołanym osobom uzyskanie dostępu do naszych danych. Tradycyjne aplikacje webowe, takie jak sklepy internetowe czy serwisy informacyjne, rzadko oferują nam podobne mechanizmy, a tym samym oferują niższy poziom bezpieczeństwa.

Niestety nie dla każdego serwisu bezpieczeństwo danych jest priorytetem – legendy o platformach przechowujących Twoje hasła w formie jawnej lub zakodowane za pomocą algorytmu kryptograficznego, który jest łatwy do złamania, mają w sobie o wiele więcej niż ziarno prawdy. Dlatego tak ważne jest, abyś ufał serwisowi, któremu powierzasz swoje dane. Ponadto w przypadku utraty hasła do konta w serwisie autoryzacyjnym pozostaje Ci do odzyskania jedno konto i hasło, a nie dziesiątki różnych kont w serwisach, z którymi musiałbyś się skontaktować w celu zastrzeżenia swoich danych lub próby odzyskania konta.

Podczas korzystania z logowania za pośrednictwem zewnętrznego serwisu, należy się upewnić, że aplikacja, której chcemy nadać uprawnienia, jest zaufana. Nieuczciwa witryna może wyłudzać dane uwierzytelniające użytkownika podczas części procesu, w której użytkownik jest zobowiązany do uwierzytelnienia się u dostawcy autoryzacji. 

Rozważmy przykład, że chciałbyś skorzystać z usług aplikacji XYZ, więc wybierasz funkcję, która wymusza transakcję OAuth do serwisu autoryzacyjnego. Możliwe jest, że aplikacja XYZ sfałszuje serwis, za pomocą którego odbywa się uwierzytelnianie użytkownika. Nieuczciwa witryna internetowa może następnie zebrać dane uwierzytelniające i zareagować tak, jakby transakcja OAuth przebiegła pomyślnie.

Niestety nie jest to tylko teoretyczne zagrożenie – w drugim kwartale 2017 roku milion kont Google zostało skutecznie wyłudzonych, a coraz częściej słyszymy o podobnych przypadkach w polskich serwisach. Ochrona przed tego typu próbami wyłudzenia danych polega na upewnieniu się, że wprowadzasz swoje dane uwierzytelniające w oryginalnej, prawdziwej domenie serwisu.

Jakie informacje serwis autoryzacyjny przekazuje aplikacji klienckiej?

Najważniejszą kwestią jest fakt, iż aplikacje autoryzacyjne nie przekazują aplikacjom klienckim takich danych jak login lub hasło.

Facebook udostępnia co najmniej to, co znajduje się na Twoim profilu publicznym, na przykład Twoje imię i nazwisko oraz zdjęcie profilowe. Google zazwyczaj przekazuje Twój adres e-mail lub Twój numer telefonu, dając możliwość skontaktowania się z Tobą, jeśli zajdzie taka potrzeba.

Jednakże oba serwisy mogą dostarczyć więcej informacji.

Jak możesz kontrolować, jakie informacje są udostępniane?

Niektóre serwisy umożliwiają kontrolę nad danymi, do których będą miały dostęp inne aplikacje. W niektórych przypadkach możesz zdecydować, które dane mogą zostać udostępnione – oczywiście z pewnymi ograniczeniami. Na przykład Facebook sprawia, że dość łatwo jest zarządzać danymi – listę uprawnień, w tym listę znajomych, datę urodzenia, polubienia i adres e-mail możesz odnaleźć w sekcji „Prywatność” na stronie Ustawienia konta. Ponadto w sekcji „Aplikacje i witryny” masz dostęp do listy aplikacji połączonych z kontem na Facebooku. W każdej chwili możemy wycofać upoważnienie dostępu do konta lub części naszych danych.

Rys. 3. Zarządzanie uprawnieniami oraz aplikacjami klienckimi połączonymi z kontem Facebook.

Google nie ma takiej elastyczności (przynajmniej jeszcze nie). Zazwyczaj dostawcy aplikacji decydują, o jakie informacje będą prosić Google, a w większości przypadków możesz zobaczyć, co jest udostępniane, ale niewiele możesz z tym zrobić. 

Jednakże w każdym serwisie autoryzacyjnym powinna znajdować się informacja o aplikacjach, którym nadałeś dostęp do pewnych zakresów swojego konta. Aby przejrzeć listę aplikacji i witryn innych firm, które są połączone z Twoim kontem Google, przejdź do sekcji „Bezpieczeństwo” na stronie Moje konto. Na stronie znajduje się sekcja „Aplikacje, które mają dostęp do Twojego konta” zawierająca listę aplikacji z opisanymi zakresami dostępu. 

Podobnie jak w przypadku Facebooka, możesz – i powinieneś okresowo – przeglądać i usuwać wszystkie aplikacje, których już nie używasz. Ale w przeciwieństwie do Facebooka nie możesz dokładnie określić, które dane są udostępniane, a które są prywatne.

Rys. 4. Zarządzanie uprawnieniami oraz aplikacjami klienckimi połączonymi z kontem Google.

Zalety

Dodanie logowania społecznościowego do aplikacji ma kilka zalet – zarówno z punktu widzenia użytkownika, jak i właściciela witryny.

Łatwiejsza i szybsza rejestracja 

• Z punktu widzenia użytkownika końcowego – możliwość rejestracji za pośrednictwem serwisu autoryzacyjnego niewątpliwie przyspiesza proces autoryzacji w nowej aplikacji oraz redukuje liczbę niezbędnych do zapamiętania poświadczeń. To z kolei przekłada się na zwiększenie liczby kont użytkowników, co pozytywnie wpływa na zainteresowanie witryną.

Lista aplikacji, w których założyłeś konto, w jednym miejscu

• Czy kiedyś zastanawiałeś się, gdzie użyłeś swoich danych do założenia konta lub dostałeś maila z witryny, o której istnieniu zapomniałeś? Zapewne większość z nas miała taką sytuację. Korzystając z serwisów autoryzacyjnych mamy dostęp do listy wszystkich aplikacji, które są powiązane z naszym profilem.

Aktualizacja danych

• Użytkownicy zwykle nie aktualizują swoich profili we wszystkich używanych aplikacjach, ale zazwyczaj robią to w sieciach społecznościowych. Dlatego posiadanie logowania za pośrednictwem konta społecznościowego sprawia, że dane wystarczy zmienić wyłącznie w jednym miejscu, a zostaną zaktualizowane we wszystkich powiązanych aplikacjach.

Zweryfikowane adresy e-mail 

• Dostawca sieci społecznościowej odpowiada za weryfikację adresu e-mail użytkownika – jeśli dostawca udostępni te informacje, właściciel aplikacji ma pewność, że otrzymany adres jest prawidłowy. Zatem aplikacja nie musi posiadać mechanizmu do weryfikacji adresów e-mail, zabezpieczenie poświadczeń czy odzyskiwania hasła (gdy logowanie społecznościowe jest jedynym sposobem autoryzacji), co może przełożyć się na niższe koszty wdrożenia i utrzymania aplikacji.
• Łatwość implementacji
  OAuth jest stosunkowo łatwy do zaimplementowania oraz pozwala na tworzenie własnych serwisów autoryzacyjnych co wpływa na nieograniczone możliwości zastosowania standardu.

Wady

Ograniczona kontrola 

• Dużym minusem tego nowego trendu jest mniejsza kontrola nad danymi, które zostają przekazane. Ponadto niektóre witryny umożliwiają logowanie się za pomocą Facebooka lub Twittera, aby móc publikować na naszym profilu. W celu zminimalizowania tego typu zagrożeń, pamiętaj, aby przed przyznaniem dostępu zapoznać się z polityką prywatności danej aplikacji oraz zwrócić uwagę na przyznawane uprawnienia.
• Wyłudzanie danych
  Prawidłowo przeprowadzona autoryzacja OAuth powinna być bezpieczna. Jednakże zdarzają się przypadki, gdy strona serwisu autoryzacyjnego, za pomocą którego chcemy przeprowadzić autoryzację, jedynie przypomina oryginalną stronę. Zawsze upewnij się, że wprowadzasz poświadczenia na stronie pod właściwym adresem url.
• Brak interoperacyjności implementacji
  Standard OAuth nie dostarcza gotowego rozwiązania, a jedynie zestaw pewnych reguł i wskazówek, przez co generuje szereg nieinteroperacyjnych implementacji. Oznacza to potrzebę stworzenia odrębnych fragmentów kodu dla różnych serwisów autoryzacyjnych np. Facebooka, Google itp.

Alternatywy

Wszystkie podobne rozwiązania łączy jeden cel – zapewnienie tożsamości federacyjnej, czyli wykorzystanie tożsamości elektronicznej użytkownika do autoryzacji w kilku systemach. Oznacza to, że aplikacja nie musi uzyskiwać poświadczeń w celu uwierzytelnienia użytkownika. Może natomiast używać systemu zarządzania tożsamością, który już przechowuje tożsamość elektroniczną użytkownika w celu autoryzacji, o ile aplikacja ufa temu systemowi zarządzania tożsamością.

Wiele osób ma trudności z rozróżnieniem między OAuth 2.0, OpenID Connect i Security Assertion Markup Language (SAML), z których każdy nadaje strukturę procesowi federacji. Postaramy się pokrótce wyjaśnić, co oznaczają te standardy i jakie są różnice pomiędzy nimi.

OAuth

Jak już wcześniej wspominaliśmy – OAuth zapewnia bezpieczny dostęp delegowany, co oznacza, że aplikacja może uzyskiwać dostęp do źródeł lub podejmować działania na serwerze w imieniu użytkownika, bez konieczności logowania się lub udostępniania danych logowania.

 Jeśli kiedykolwiek zarejestrowałeś się w nowej aplikacji i zgodziłeś się na automatyczną synchronizację kontaktów z Facebooka lub kontaktów mailowych, prawdopodobnie korzystałeś z OAuth 2.0.

OAuth a OpenID

OpenID został stworzony na potrzeby uwierzytelniania federacyjnego, co oznacza, że pozwala aplikacji innej firmy na uwierzytelnianie użytkowników przy użyciu kont, które już posiadasz. Natomiast OAuth został stworzony, aby wyeliminować potrzebę udostępniania haseł przez użytkowników aplikacjom innych firm.

OpenID wykorzystuje token ID, aby ujednolicić obszary, które OAuth 2.0 pozostawia do wyboru – w tym przekazywanie zakresów. Koncentruje się wyłącznie na uwierzytelnianiu użytkowników i służy głównie do umożliwienia użytkownikom logowania się do witryn konsumenckich i aplikacji mobilnych.

 Jeśli używałeś Google do logowania się do aplikacji takich jak YouTube lub Facebook w celu zalogowania się do koszyka zakupów, to znasz tę opcję uwierzytelniania.

Przepływ procesu jest podobny do OAuth 2.0, ale dodatkowo w procesie bierze udział ID Token. Składa się on z nagłówka, zawartości oraz sygnatury. Możesz myśleć o tokenie wydanym przez serwer zasobów, jak o bilecie na koncert – nie ma w nim żadnych informacji identyfikujących daną osobę, a jedynie jest poświadczeniem, iż masz pozwolenia na wejście.

OAuth a SAML

Security Assertion Markup Language (SAML) – standard wymiany danych uwierzytelniania i autoryzacji. Standard wykorzystuje XML do wymiany wiadomości uwierzytelniających i autoryzacyjnych między dostawcami tożsamości i dostawcami usług w celu weryfikacji tożsamości i uprawnień użytkownika, a następnie odpowiednio przyznaje lub odmawia dostępu. 

Najprawdopodobniej doświadczyłeś uwierzytelniania SAML w środowisku pracy, logując się do firmowego intranetu lub dostawcy tożsamości, a następnie otrzymując dostęp do wielu dodatkowych usług, takich jak Salesforce lub Workday, bez konieczności ponownego wprowadzania poświadczeń.

Podsumowanie:

OAuth służy do autoryzacji i obejmuje aplikacje, które żądają pewnych zakresów do danych, na które właściciele zasobów wyrażają zgodę. Nadanie dostępu powoduje przekazanie tokenów dostępu i tokenów odświeżania (w zależności od przepływu).

OpenID służy do uwierzytelniania – został przyjęty jako sposób logowania się przy użyciu tej samej nazwy użytkownika i hasła w wielu witrynach. Jak na ironię, w pewnym sensie internauci i tak to robią. Po wyświetleniu monitu o utworzenie nowej nazwy użytkownika i hasła do witryny internetowej często domyślnie podają te same dane uwierzytelniające, których wielokrotnie używali w innych aplikacjach. Chociaż pomaga im to zapamiętać swoje poświadczenia, praktyka może również narazić ich na cyberataki, zwiększa ona bowiem ryzyko przechwycenia poufnych danych użytkownika przez złośliwe podmioty.

SAML to protokół, który umożliwia dostawcy tożsamości przekazywanie danych uwierzytelniających użytkownika do dostawcy usług w celu przeprowadzenia zarówno uwierzytelniania, jak i autoryzacji w celu uzyskania dostępu do usługi. SAML wykorzystuje Extensible Markup Language (XML) do standaryzacji komunikacji między różnymi systemami.

SAML jest starszy niż inne protokoły ramowe, a ponieważ jest częściej używany w aplikacjach korporacyjnych, społeczność programistów starała się stworzyć lżejszy i bardziej zorientowany na klienta framework. Dlatego też OAuth używa do kodowania danych lżejszego formatu jakim jest JSON, który również lepiej działa na urządzeniach mobilnych.

Niezależnie od wykorzystanego rozwiązania – zachowaj czujność. Istnieje tyle sposobów na zapewnienie bezpieczeństwa danych, ile sposobów na ich zaatakowanie. Niezależnie czy tworzysz konto w sposób tradycyjny, czy wykorzystujesz logowanie za pośrednictwem innego serwisu, upewnij się, powierzasz swoje dane witrynie, która jest godna zaufania. 

Niestety przejęcia haseł zdarzają się o wiele częściej, niż mógłbyś się tego spodziewać. Pamiętaj, że w każdym momencie możesz włączyć dwuetapowe uwierzytelnianie z poziomu panelu zarządzania swoim kontem Google/Facebook oraz w innych serwisach oferujących dodatkową wartwę zabezpieczeń, jaką jest 2FA.

Mamy nadzieję, że był to dobry element wprowadzający, aby zapoznać się z OAuth, więc następnym razem, gdy zobaczysz „Zaloguj się przez Twittera” lub podobną delegowaną weryfikację tożsamości, będziesz wiedział na co należy zwrócić uwagę.

Jeśli zaciekawiła Cię tematyka tego wpisu, śledź nasze artykuły! Już wkrótce powiemy więcej o tworzeniu własnego serwisu autoryzacyjnego w frameworku Laravel.

---