OAuth 2.0 to jeden z tych tematów, które bardzo często pojawiają się w aplikacjach webowych, API, Postmanie i testowaniu, ale wiele osób rozumie go tylko powierzchownie.
Klikasz „Zaloguj przez Google”, aplikacja przekierowuje Cię do logowania, potem wracasz do systemu i nagle jesteś zalogowany. Niby proste, ale pod spodem dzieje się kilka ważnych rzeczy.
W tym wpisie pokażę, jak działa OAuth 2.0 w praktyce i co tak naprawdę dzieje się podczas takiego logowania.
OAuth 2.0 to nie tylko logowanie
Na początku warto wyjaśnić jedną rzecz.
OAuth 2.0 nie został stworzony głównie jako mechanizm logowania. To przede wszystkim mechanizm autoryzacji, czyli nadawania dostępu do określonych zasobów.
Przykład?
Masz aplikację, która chce pobrać Twój adres e-mail z konta Google. Nie chcesz przecież podawać tej aplikacji swojego hasła do Google. Zamiast tego logujesz się po stronie Google, a aplikacja dostaje specjalny token dostępu.
Dzięki temu aplikacja nie zna Twojego hasła. Dostaje tylko ograniczony dostęp do wybranych danych.
Kto bierze udział w OAuth 2.0?
W typowym procesie mamy kilka elementów:
Użytkownik – osoba, która chce się zalogować albo udzielić dostępu.
Aplikacja – system, który chce uzyskać dostęp do danych użytkownika.
Serwer autoryzacji – np. Google, Microsoft, GitHub. To tam użytkownik się loguje.
API / serwer zasobów – miejsce, z którego aplikacja chce pobrać dane.
Access token – tymczasowy token, który pozwala aplikacji wykonać określone żądanie do API.
Jak wygląda proces krok po kroku?
Załóżmy, że użytkownik klika przycisk:
Zaloguj przez Google
Aplikacja przekierowuje go na stronę Google. To ważne, bo użytkownik nie wpisuje hasła w naszej aplikacji, tylko bezpośrednio u dostawcy logowania.
Adres takiego przekierowania może zawierać różne parametry, na przykład:
client_id
redirect_uri
response_type=code
scope=email profile
stateclient_id identyfikuje aplikację.
redirect_uri mówi, gdzie użytkownik ma wrócić po zalogowaniu.
scope określa, do jakich danych aplikacja chce uzyskać dostęp.
state pomaga zabezpieczyć cały proces.
Po poprawnym logowaniu Google przekierowuje użytkownika z powrotem do aplikacji i przekazuje tzw. authorization code.
Przykład:
https://moja-aplikacja.pl/callback?code=abc123Ten kod nie jest jeszcze tokenem. To tylko tymczasowy kod, który aplikacja może wymienić na access token.
Wymiana kodu na token
Aplikacja wysyła kod autoryzacyjny do serwera autoryzacji i prosi o token.
W odpowiedzi może otrzymać coś takiego:
{ "id": 1, "name": "Jan Kowalski", "email": "jan@example.com" }Najważniejszy jest tutaj access_token.
To właśnie ten token aplikacja wysyła później do API.
Przykład:
GET /user/profile Authorization: Bearer eyJhbGciOi...Jeśli token jest poprawny, API zwraca dane użytkownika.
Access token i refresh token
Access token zwykle działa krótko. Może być ważny kilka minut, kilkanaście minut albo godzinę.
Dlaczego?
Bo gdyby ktoś go przechwycił, nie powinien mieć dostępu do konta użytkownika przez długi czas.
Do odświeżania dostępu służy refresh token. Dzięki niemu aplikacja może pobrać nowy access token bez ponownego logowania użytkownika.
Refresh token jest jednak bardzo wrażliwy i powinien być dobrze chroniony.
Gdzie tutaj jest JWT?
Bardzo często access token ma format JWT, ale nie zawsze.
To ważna różnica:
OAuth 2.0 opisuje proces uzyskania dostępu.
JWT to format tokena.
Czyli OAuth 2.0 może wydać token w formacie JWT, ale sam OAuth 2.0 nie jest tym samym co JWT.
Co warto sprawdzić jako tester?
Jeżeli testujesz aplikację korzystającą z OAuth 2.0, warto zwrócić uwagę na kilka rzeczy.
Czy użytkownik jest przekierowywany do prawdziwego dostawcy logowania?
Czy redirect_uri nie da się podmienić na dowolny adres?
Czy aplikacja nie prosi o zbyt szerokie uprawnienia?
Czy token wygasa po określonym czasie?
Czy po wygaśnięciu tokena aplikacja zachowuje się poprawnie?
Czy tokeny nie są zapisywane w logach, adresie URL albo innych niebezpiecznych miejscach?
To są bardzo praktyczne rzeczy, które mogą prowadzić do poważnych błędów bezpieczeństwa.
OAuth 2.0 w Postmanie
OAuth 2.0 często spotkasz też w Postmanie.
Przy konfiguracji autoryzacji możesz zobaczyć pola takie jak:
Auth URL
Access Token URL
Client ID
Client Secret
Scope
Redirect URI
Grant TypeNa początku wygląda to skomplikowanie, ale po zrozumieniu procesu wszystko zaczyna mieć sens.
Auth URL to adres logowania.
Access Token URL to adres, pod którym aplikacja wymienia kod na token.
Client ID identyfikuje aplikację.
Scope mówi, do czego aplikacja chce mieć dostęp.
Redirect URI wskazuje, gdzie użytkownik wróci po logowaniu.
Najprostsze podsumowanie
OAuth 2.0 pozwala aplikacji uzyskać dostęp do danych użytkownika bez poznawania jego hasła.
Użytkownik loguje się u zaufanego dostawcy, np. Google.
Aplikacja otrzymuje kod autoryzacyjny.
Kod jest wymieniany na access token.
Access token jest używany do komunikacji z API.
Dzięki temu aplikacja może działać bezpieczniej, a użytkownik nie musi przekazywać swojego hasła każdej zewnętrznej aplikacji.
OAuth 2.0 może wydawać się trudny, ale gdy rozbijemy go na kroki, okazuje się, że cały proces jest całkiem logiczny.
