OAuth 2.0

OAuth 2.0 to otwarty standard (formalnie: framework) autoryzacji, w którym właściciel zasobu pozwala aplikacji uzyskać ograniczony zakresem i czasem token dostępu do swoich danych w innej usłudze, bez ujawniania jej hasła. RFC 6749 z października 2012 roku opisuje go jako framework, który pozwala aplikacji zewnętrznej uzyskać ograniczony dostęp do usługi HTTP w imieniu właściciela zasobu albo we własnym imieniu ^[1]. OAuth 2.0 zastąpił protokół OAuth 1.0 z RFC 5849 ^[1]. Służy do delegowania dostępu, a nie do uwierzytelniania.

Jak działa

RFC 6749 definiuje cztery role ^[1]:

Token dostępu to według RFC ciąg znaków reprezentujący autoryzację udzieloną klientowi ^[1]. Zakres (scope) określa, do czego token uprawnia ^[1]. Token odświeżania pozwala uzyskać nowy token dostępu bez ponownego udziału właściciela ^[1].

Najważniejszy przepływ to przyznanie kodu autoryzacji (authorization code). Uproszczony przebieg z rozszerzeniem PKCE pokazuje schemat poniżej.

RYS. 1Kod autoryzacji z PKCE

Rodzaje przyznań

RFC 6749 opisuje cztery rodzaje przyznania (grant): kod autoryzacji, niejawny (implicit), hasło właściciela zasobu i dane uwierzytelniające klienta ^[1]. Praktyka bezpieczeństwa zmieniła ocenę części z nich. RFC 9700 ze stycznia 2025 roku, opublikowane jako BCP 240, podaje obecne zalecenia ^[2].

• Kod autoryzacji jest przepływem zalecanym. Klienci publiczni muszą używać PKCE, a dla poufnych jest ono zalecane ^[2].
• Przepływ niejawny nie powinien być używany, bo naraża token na wyciek i powtórne użycie ^[2].
• Hasło właściciela zasobu nie może być używane: ujawnia hasło klientowi i nie współpracuje z uwierzytelnianiem wieloskładnikowym ^[2].
• Dane uwierzytelniające klienta służą do dostępu aplikacji we własnym imieniu, bez udziału użytkownika ^[1].

PKCE opisano w RFC 7636 z września 2015 roku ^[3]. Chroni przed przechwyceniem kodu autoryzacji: klient wysyła skrót losowego sekretu, a przy wymianie kodu na token musi przedstawić sam sekret ^[3]. Kto przechwyci tylko kod, nie uzyska tokenu ^[3]. Zalecaną metodą jest S256, w której skrót liczy się funkcją SHA-256 ^[3]. RFC 9700 wymaga, by serwery autoryzacji obsługiwały PKCE i broniły się przed atakami polegającymi na wymuszeniu jego pominięcia ^[2]. Pierwotnie rozszerzenie projektowano dla aplikacji mobilnych, w których złośliwa aplikacja mogła przechwycić kod przekazywany przez własny schemat adresów ^[3].

Uwierzytelnianie użytkownika dodaje nadbudowa OpenID Connect, opisana jako prosta warstwa tożsamości nad protokołem OAuth 2.0 ^[4]. Wprowadza ona ID Token w formacie JWT (JSON Web Token) z informacjami o zalogowaniu ^[4]. Na niej opiera się wiele wdrożeń SSO i dostawców tożsamości.

W WordPressie

Rdzeń WordPressa nie ma serwera OAuth 2.0. Podręcznik REST API wymienia jako standardowe uwierzytelnianie przez ciasteczka ^[5]. Od wersji 5.6 WordPress ma też hasła aplikacji, generowane na ekranie edycji użytkownika ^[5]. Inne metody dla zdalnych aplikacji dodają wtyczki; podręcznik podaje jako przykłady serwer OAuth 1.0a i JSON Web Tokens ^[5].

OAuth 2.0 pojawia się w WordPressie głównie w dwóch rolach. Pierwsza to strona jako klient: wtyczki logowania przez zewnętrzne konta, integracje z pocztą, analityką czy mediami społecznościowymi. Taka wtyczka przechowuje tokeny dostępu i odświeżania w bazie danych strony. Druga to WordPress.com i Jetpack, których REST API korzysta z OAuth2 ^[6]. Dokumentacja zaleca tam przepływ z kodem autoryzacji, a przepływ z hasłem dopuszcza tylko do prac rozwojowych, bo pomija zgodę użytkownika ^[6]. Zakres global daje szeroki dostęp do usług WordPress.com ^[6].

Tokeny zapisane w bazie są tak cenne jak hasła. Wyciek bazy albo SQL injection w dowolnej wtyczce może je ujawnić. Tokeny należy traktować jak inne sekrety; zob. zarządzanie sekretami.

Zagrożenia i skutki

Błędy w OAuth wynikają zwykle z wdrożenia, a nie z samego standardu.

• Luźne dopasowanie adresu przekierowania pozwala przechwycić kod albo token. RFC 9700 wymaga dokładnego porównania ciągów znaków z zarejestrowanym adresem ^[2]. Zob. open redirect.
• Brak ochrony adresu przekierowania przed CSRF (Cross-Site Request Forgery) pozwala atakującemu wstrzyknąć własny kod autoryzacji albo token. RFC 6749 wymaga takiej ochrony od klienta i zaleca przekazywanie wiązanej z sesją wartości w parametrze state ^[1].
• Token z nadmiernym zakresem zamienia wyciek z jednej aplikacji w dostęp do całego konta.
• Skradziony token odświeżania daje długotrwały dostęp. RFC 9700 wymaga, by tokeny odświeżania klientów publicznych były powiązane z nadawcą albo rotowane ^[2].

Zgoda udzielona przez OAuth omija hasło i często drugi składnik, więc przejęty token jest furtką do ataku na łańcuch dostaw.

Jak się bronić

• Używać przepływu z kodem autoryzacji i PKCE ^[2].
• Nie używać przepływu niejawnego ani przepływu z hasłem ^[2].
• Ograniczać tokeny do konkretnego serwera zasobów oraz konkretnych zasobów i akcji ^[2], zgodnie z zasadą najmniejszych uprawnień.
• Rejestrować dokładne adresy przekierowania ^[2].
• Okresowo przeglądać aplikacje, którym udzielono zgody, i cofać nieużywane.

Historia i przykłady

W kwietniu 2022 roku GitHub ujawnił kampanię z użyciem skradzionych tokenów OAuth wydanych dwóm integratorom: Heroku i Travis CI ^[7]. Zespół bezpieczeństwa GitHuba wykrył atak 12 kwietnia 2022 roku, gdy zauważył nieuprawniony dostęp do infrastruktury npm ^[7]. Atakujący użył tokenów, by pobrać prywatne repozytoria kilkudziesięciu organizacji ^[7]. GitHub podkreślił, że nie przechowuje tych tokenów w oryginalnej, użytecznej postaci, więc źródłem wycieku byli integratorzy ^[7].