Czy OAuth to to samo co uwierzytelnianie?

Nie. OAuth to autoryzacja — przyznaje klientowi uprawnienia dostępu do zasobów. OpenID Connect, zbudowany na OAuth, dodaje uwierzytelnianie. „Zaloguj się przez Google” to OIDC; Opcja „Połącz Kalendarz Google” może zależeć od tego, czy aplikacja musi wiedzieć, kim jesteś, czy po prostu potrzebuje dostępu do Twoich danych.

Czy powinienem używać OAuth czy przechowywać hasła?

Używaj protokołu OAuth, jeśli to możliwe. Przechowywanie haseł użytkowników oznacza dziedziczenie całej odpowiedzialności za haszowanie, sól, reakcję na naruszenia, odzyskiwanie haseł i 2FA. Delegowanie do Google/Apple/Microsoft/GitHub poprzez OAuth odciąża to wszystko. Kompromis jest taki, że Twoi użytkownicy potrzebują kont u tych dostawców.

Dlaczego tokeny OAuth można unieważnić, a haseł nie?

Tokeny odwołują się do wpisu w bazie danych serwera autoryzacyjnego. Unieważnienie wpisu powoduje natychmiastową unieważnienie tokenu. Hasła to wiedza — możesz je zmienić i wymusić ponowne uwierzytelnienie, ale stare hasło pozostaje ważne, dopóki tego nie zrobisz.

Jaka jest różnica między OAuth 2.0 a OAuth 1.0?

OAuth 1.0 (2007) wykorzystywał podpisy kryptograficzne przy każdym żądaniu. OAuth 2.0 (2012) opiera się na TLS w celu zapewnienia bezpieczeństwa transportu i wykorzystuje tokeny na okaziciela. OAuth 2.0 jest prostszy do wdrożenia i jest dostępny w prawie każdym nowoczesnym interfejsie API; OAuth 1.0 jest zasadniczo przestarzały.

Czy tokeny OAuth są niebezpieczne w przypadku wycieku?

Tak – każdy, kto posiada token, ma przyznany dostęp do czasu jego wygaśnięcia lub unieważnienia. Środki zaradcze: krótki czas życia tokenów dostępu (typowo 1 godzina), bezpieczniejsze przechowywanie tokenów odświeżania, minimalizacja zakresu, rejestrowanie audytu. Traktuj tokeny dostępu z taką samą ostrożnością jak hasła w okresie ich ważności.

Wyjaśnienie protokołu OAuth 2.0: jak właściwie działa „Zaloguj się przez Google”.

Każdy przycisk „Zaloguj się przez Google”, każdy link „Połącz swoje konto na Twitterze”, każda integracja API pomiędzy nowoczesnymi usługami opiera się na OAuth. Protokół zastępuje udostępnianie haseł przepływem tokenów i ekranów zgody, a zrozumienie ruchomych części wyjaśnia kategorię ataków i udogodnień.

Poniżej znajduje się pełna treść artykułu w języku angielskim.

OAuth 2.0 to platforma autoryzacji, która umożliwia jednej aplikacji uzyskanie ograniczonego dostępu do zasobów innej aplikacji w imieniu użytkownika — bez konieczności sprawdzania hasła użytkownika. Klasyczny przypadek użycia: aplikacja kalendarza, która musi czytać Twój Kalendarz Google, nie powinna wymagać podawania hasła Google. Zamiast tego OAuth umożliwia przyznanie aplikacji tokenu o ograniczonym zakresie i możliwym do odwołania.

Aktorzy

Cztery role w przepływie OAuth:

Właściciel zasobu — Ty, użytkownik posiadający gdzieś dane
Klient — aplikacja żądająca dostępu (np. przeglądarka kalendarza innej firmy)
Serwer autoryzacji — usługa, która Cię uwierzytelnia i wydaje tokeny (np. punkt końcowy OAuth firmy Google)
Serwer zasobów — interfejs API przechowujący Twoje dane (np. Kalendarz Google) API)

Przepływ kodu autoryzacyjnego

Standardowy przepływ po stronie serwera, uproszczony:

Klikasz „Połącz z Kalendarzem Google” w aplikacji klienckiej.
Klient przekierowuje Twoją przeglądarkę do serwera autoryzacji Google z parametrami: id_klienta, redirect_uri, zakres (calendar.read), stan (token CSRF).
Uwierzytelniasz się w Google, jeśli nie jesteś jeszcze zalogowany.
Google wyświetla ekran zgody: „CalendarViewer chce przeczytać Twój kalendarz. Zezwolić?”
Klikasz Zezwól. Google przekierowuje Twoją przeglądarkę z powrotem do redirect_uri klienta za pomocą jednorazowego kodu autoryzacyjnego.
Kod po stronie serwera klienta wymienia kod autoryzacyjny (plus sekret klienta) na token dostępu, wywołując bezpośrednio punkt końcowy tokenu Google.
Klient używa tokena dostępu, aby wywołać interfejs API Kalendarza Google w Twoim imieniu.
Gdy token dostępu wygasa (zwykle po godzinie), klient używa tokena odświeżającego, aby uzyskać nowy, nie przeszkadzając Ci.

Kluczowa właściwość bezpieczeństwa: Twoje hasło nigdy nie ma kontaktu z aplikacją kliencką. Klient otrzymuje token o określonym zakresie, który możesz w każdej chwili odwołać w panelu konta Google.

OAuth 2.0 vs OAuth 2.1 vs OIDC

OAuth 2.0 to standard z 2012 roku (RFC 6749). Od tego czasu dodano kilka rozszerzeń RFC i dokumentów z najlepszymi praktykami.
OAuth 2.1 (w wersji roboczej z 2026 r.) konsoliduje aktualne najlepsze praktyki w jedną specyfikację — obowiązkowe PKCE, usunięte Implicit Flow itp.
OpenID Connect (OIDC) to warstwa tożsamości na górze OAuth 2.0. Sam protokół OAuth zapewnia nieprzezroczysty token dostępu; OIDC dodaje token identyfikacyjny (JWT), który uwierzytelnia użytkownika. Większość przycisków „Zaloguj się za pomocą…” korzysta z OIDC, a nie zwykłego OAuth.

Typy uprawnień

OAuth 2.0 definiuje kilka przepływów dla różnych scenariuszy:

Kod autoryzacji — standardowy przepływ po stronie serwera opisany powyżej. Z rozszerzeniem PKCE, używanym także przez aplikacje mobilne i SPA.
Implicit Flow (przestarzałe) — wystawia tokeny dostępu bezpośrednio poprzez fragment adresu URL. Podatny na wyciek tokenów; zastąpione przez Kod autoryzacyjny + PKCE.
Resource Owner Password Credentials (rzadko używane) — klient zbiera hasło użytkownika i wymienia je na token. Należy go używać tylko w starszych scenariuszach migracji.
Poświadczenia klienta — w przypadku komunikacji maszyna-maszyna, gdzie nie ma użytkownika. Klient uwierzytelnia się i otrzymuje token do własnych zasobów.
Device Code — dla urządzeń bez przeglądarek (telewizory, IoT). Urządzenie pokazuje kod; użytkownik autoryzuje z telefonu lub laptopa.
Refresh Token — wymienia długotrwały token odświeżania na świeży token dostępu bez interakcji użytkownika.

PKCE: rozszerzenie, które musisz mieć

PKCE (Klucz próbny do wymiany kodów, wymawiane „pixie”) zapobiega atakom polegającym na przechwyceniu kodu autoryzacyjnego. Klient generuje losowy sekret, szyfruje go i wysyła skrót w żądaniu autoryzacji. Podczas wymiany kodu wysyła oryginalny sekret. Serwer autoryzacyjny weryfikuje dopasowania skrótu. Osoba atakująca, która przechwyci kod, nie będzie mogła go wymienić bez oryginalnego sekretu.

PKCE jest obecnie uważany za obowiązkowy dla wszystkich klientów OAuth — zarówno publicznych (w przeglądarce, na urządzeniu mobilnym), jak i poufnych (po stronie serwera).

Scopes

Tokeny są wydawane z określonymi zakresami — działaniami, które mogą wykonywać. Typowe zakresy Google wyglądają jak https://www.googleapis.com/auth/calendar.readonly. Klient żąda zakresów; użytkownik widzi je na ekranie zgody i zatwierdza lub odrzuca. Zasada najmniejszych uprawnień: pytaj tylko o zakresy, których faktycznie potrzebujesz.

Częste ataki OAuth

Open redirect. Źle skonfigurowany parametr redirect_uri umożliwia atakującemu przekierowanie kodu autoryzacyjnego na jego własny serwer.
Parametr stanu pominięcie. Bez wartości stanu powiązanej z sesją użytkownika przepływy OAuth są podatne na ataki CSRF — osoba atakująca nakłania ofiarę do ukończenia przepływu OAuth, który łączy konto atakującego z sesją ofiary.
Tekkenwyciek tokena w historii przeglądarki (główny ukryty przepływ słabość).
Tkradzież tokenów za pośrednictwem XSS. Jeśli aplikacja kliencka przechowuje tokeny w localStorage i ma lukę w zabezpieczeniach XSS, osoby atakujące mogą je ukraść.
Wyłudzanie informacji na ekranie zgody. Osoba atakująca rejestruje złośliwego klienta OAuth, który prosi o wrażliwe zakresy; użytkownik, po kliknięciu przycisku „Zezwalaj” na ekranach zgody, udziela dostępu bez kontroli.

Co robić jako użytkownik

Okresowo przeglądaj połączone aplikacje w ustawieniach konta Google/Apple/Microsoft/Facebook/GitHub. Unieważnij te, których nie używasz.
Przeczytaj zakresy ekranu zgody przed udzieleniem dostępu. „Zarządzaj kalendarzem” różni się od „Wyświetlaj swój kalendarz”.
Bądź sceptyczny wobec żądań OAuth pochodzących z aplikacji, których nie rozpoznajesz, nawet jeśli pojawiają się podczas znanej procedury.

Często zadawane pytania

Czy OAuth to to samo co uwierzytelnianie?: Nie. OAuth to autoryzacja — przyznaje klientowi uprawnienia dostępu do zasobów. OpenID Connect, zbudowany na OAuth, dodaje uwierzytelnianie. „Zaloguj się przez Google” to OIDC; Opcja „Połącz Kalendarz Google” może zależeć od tego, czy aplikacja musi wiedzieć, kim jesteś, czy po prostu potrzebuje dostępu do Twoich danych.
Czy powinienem używać OAuth czy przechowywać hasła?: Używaj protokołu OAuth, jeśli to możliwe. Przechowywanie haseł użytkowników oznacza dziedziczenie całej odpowiedzialności za haszowanie, sól, reakcję na naruszenia, odzyskiwanie haseł i 2FA. Delegowanie do Google/Apple/Microsoft/GitHub poprzez OAuth odciąża to wszystko. Kompromis jest taki, że Twoi użytkownicy potrzebują kont u tych dostawców.
Dlaczego tokeny OAuth można unieważnić, a haseł nie?: Tokeny odwołują się do wpisu w bazie danych serwera autoryzacyjnego. Unieważnienie wpisu powoduje natychmiastową unieważnienie tokenu. Hasła to wiedza — możesz je zmienić i wymusić ponowne uwierzytelnienie, ale stare hasło pozostaje ważne, dopóki tego nie zrobisz.
Jaka jest różnica między OAuth 2.0 a OAuth 1.0?: OAuth 1.0 (2007) wykorzystywał podpisy kryptograficzne przy każdym żądaniu. OAuth 2.0 (2012) opiera się na TLS w celu zapewnienia bezpieczeństwa transportu i wykorzystuje tokeny na okaziciela. OAuth 2.0 jest prostszy do wdrożenia i jest dostępny w prawie każdym nowoczesnym interfejsie API; OAuth 1.0 jest zasadniczo przestarzały.
Czy tokeny OAuth są niebezpieczne w przypadku wycieku?: Tak – każdy, kto posiada token, ma przyznany dostęp do czasu jego wygaśnięcia lub unieważnienia. Środki zaradcze: krótki czas życia tokenów dostępu (typowo 1 godzina), bezpieczniejsze przechowywanie tokenów odświeżania, minimalizacja zakresu, rejestrowanie audytu. Traktuj tokeny dostępu z taką samą ostrożnością jak hasła w okresie ich ważności.