Jak działa OAuth?

Czym jest OAuth?

OAuth jest standardem autoryzacji, który może zostać zaimplementowany w ramach dowolnej aplikacji. Korzystając z tego standardu, użytkownik udziela uprawnień aplikacji A do wykorzystania danych z aplikacji B. Od strony użytkownika spotykamy się z OAuth np. pozwalając aplikacji publikować wpisy na Facebooku. Aplikacja z niebieskim logo jest tutaj stroną implementującą omawiany standard.

Wracając jednak do wspomnianej wcześniej aplikacji Quickbooks - implementuje ona OAuth w wersji 2.0, pozwalając na autoryzację i późniejszą komunikację z aplikacjami zewnętrznymi. Pracując nad naszą aplikacją np. do rozliczenia czasu pracy, mamy możliwość wykorzystania tego standardu. Przykładem wykorzystania może być tutaj wystawienie faktury na podstawie zaraportowanego czasu pracy. Nasza aplikacja, po przeprowadzeniu procesu autoryzacji, może generować faktury w systemie zewnętrznym. Nasza aplikacja tym samym deleguje zarządzanie fakturami do QuickBooks.

• Uwierzytelnianie — weryfikacja tożsamości
• Autoryzacja — sprawdzenie czy operacja jest dozwolona dla użytkownika.

Wersje OAuth

Mamy obecnie dwie wersje standardu OAuth: 1.0a oraz 2.0. Patrząc na algorytm ich działania można stwierdzić, że są do siebie podobne. Nie jest to jednak prawda. Obie wersje standardu są oczywiście wykorzystywane do osiągnięcia tego samego celu, jednak nie są ze sobą kompatybilne. Jedną z fundamentalnych różnic jest odrzucenie kwestii związanych z kryptografią w nowszym standardzie. Deleguje on bowiem kwiestie szyfrowania połączenia do protokołu HTTPS. Wyciek danych autoryzujących wysyłane żądania, umożliwia wykorzystanie danych przez nieupoważniony podmiot. Starszy standard jest zatem niezależny od warstwy transportowej w przeciwieństwie do najnowszego OAuth 2.0.

Jedną z różnic jest także kwestia długości życia tokena służącego do autoryzacji. W przypadku OAuth 1.0, token taki mógł być przechowywany przez bardzo długi czas, a w niektórych przypadkach nawet bezterminowo. OAuth 2.0 wprowadza pojęcie dodatkowych tokenów wykorzystywanych do odświeżania tokena autoryzacyjnego. Dzięki temu token autoryzacyjny może być ważny przez krótki okres, co ogranicza ryzyko nieautoryzowanego dostępu do danych.

Dodatkowo standard OAuth 2.0 wprowadza nowe metody pozyskania tokena, wykorzystywane np. w aplikacjach desktopowych. W poprzedniej implementacji, przy użyciu standardowej metody, użytkownik przekierowywany z aplikacji desktopowej do przeglądarki. Tam przeprowadzał proces autoryzacji, po czym kopiował otrzymany token z powrotem do aplikacji desktopowej. Istny horror dla specjalistów od UX oraz użytkowników…

Rozwiązywane problemy

Standard Oauth rozwiązuje wiele problemów związanych z komunikacją pomiędzy aplikacjami. Użytkownik nie musi za każdym razem autoryzować aplikacji, ani przechowywać klucza wykorzystywanego do autoryzacji. Klucz taki zapisany jest w aplikacji i użytkownik nie ma do niego dostępu. Nie może zatem przekazać go do innego podmiotu, niezależnie czy nastąpi to celowo czy też nie. W ramach standardu definiujemy także zakres dostępu do danych. Jeśli udostępniamy naszej aplikacji możliwość wystawiania faktur w systemie zewnętrznym, nie musimy dzielić się z nią swoimi danymi presonalnymi.

Ponadto wykorzystywane klucze są ważne przez określony termin. W przypadku klucza wykorzytywanego do autoryzacji, będzie to zwykle czas rzędu kilkudziesięciu minut lub godzin. Po upływie tego czasu nie może być on wykorzytany do komunikacji pomiędzy aplikacjami.

Algorytm “Authorization Code Flow”

Na początku przedstawmy sobie wykorzystane w dalszej części pojęcia:

• Zasób - chronione dane, do których aplikacja chce uzyskać dostęp
• Właściciel zasobu - podmiot będący właścicielem chronionego zasobu, do którego dostęp wymaga autoryzacji.
• Klient - aplikacja która chce uzyskać dostęp do zasobu.
• Serwer autoryzacyjny - serwer udzielający poświadczenia, wymaganego by uzyskać dostęp do zasobu.
• Serwer zasobu - serwer przechowujący chroniony zasób. W wielu przypadkach, będzie to ten sam serwer, co serwer autoryzacyjny.
• Zakres – definiuje o jakie uprawnienia do chronionych zasobów wnioskuje Klient
• Access token – token wystawiany przez serwer autoryzacyjny - wymagany do skorzystania z chronionego zasobu
• Refresh token - token wystawiany przez serwer autoryzacyjny - wymagany do odświerzenia Access tokena
• Sekret - ciąg znaków znany wyłącznie klientowi, pozwalający go zidentyfkować

Standard OAuth 2.0, jak wpomniałem we wcześniejszych akapitach, definiuje kilka metod pozyskiwania tokena. Najczęściej spotykanym z nich jest metoda nazwana “Authorization Code Flow”. Zakłada ona występowanie trzech stron podczas procesu autoryzacji: klienta, właściciela zasobu oraz serwera autoryzacyjnego.

Osobiście uważam, że algporytmy najlepiej przedstawia się za pomocą list oraz wszelkiego rodzaju grafów. Dlatego też zróbmy to w ten sposób. Poniżej lista kolejnych kroków wykonywanych podczas procesu autoryzacji:

1. Klient rejestruje się w serwerze autoryzacyjnym - Rejestracja wymaga podania przez klienta swojego identyfikatora, sekretu oraz adresu zwrotnego. Pierwsze dwie informacje pozwalają na identyfikację klienta. Adres zwrotny wykorzystywany jest natomiast po zakończeniu procesu autoryzacji i definiuje pod jaki adres ma nastąpić wtedy przekierowanie. Dodatkowo podczas rejestracji definiowany jest zakres uprawnień.

2. Serwer autoryzacyjny sprawdza, czy właściciel zasobu jest uwierzytelniony w serwerze autoryzacji. - Weryfikowane jest czy należy wyświetlić ekran z listą wnioskowanych uprawnień, czy też uprawnienia te zostały udzielone już wcześniej.

3. Serwer autoryzacyjny wyświetla informację podsumowującą wnioskowane przez klienta uprawnienia. - Użytkownik na tym etapie ma możliwość weryfikacji o jakie uprawnienia wnioskuje klient. Ten krok ma na celu przedstawienie właścicielowi zasobu wnioskowanych przez klienta uprawnień. Ekran jest wyświetlany jedynie w przypadku, kiedy właściciel zasobu nie był wcześniej uwierzytelniony w serwerze autoryzacji.

4. Użytkownik akceptuje udzielenie przedstawionych uprawnień klientowi.

5. Serwer autoryzacyjny wykonuje przekierowanie z powrotem do klienta - Przekierowanie następuje na adres zwrotny, który został przekazany podczas rejestracji w serwerze autoryzacyjnym(krok pierwszy algorytmu). W adresie URL przekazany zostaje także kod autoryzacyjny (nie jest to jeszcze access token).

6. Klient wnioskuje o Access token w serwerze autoryzacyjnym - Klient wysyła rządanie zawierające dane identyfikacyjne (sekret oraz identyfikator klienta) oraz kod autoryzacyjny uzyskany w poprzednim kroku.

7. Serwer autoryzacyjny przekazuje access token oraz refresh token klientowi - Klient, po poprawnej identyfikacji tożsamości oraz weryfikacji kodu autoryzacyjnego, odpowiada przekazując access token. Token ten będzie wykorzystywany podczas wykonywania zapytań poprzez API do zasobu. Ponadto klient otrzymuje refresh token, który pozwala na odświeżenie access tokena. Oba tokeny powinny zostać zatem zapisane przez klienta.

Podsumowanie

To by było na tyle. Jak widać w siedmiu krokach możemy autoryzować naszą aplikację do korzytania z zasobów zewnętrznych. Standard OAuth jest wykorzystywany bardzo często w aplikacjach udostępniających publiczne API. Mam nadzieję, że powyższy opis pomoże Wam w jego zrozumieniu.