Dlaczego logowanie zewnętrzne

Każdy formularz rejestracji to bariera. Użytkownik musi wymyślić hasło, potwierdzić email, zapamiętać kolejne dane logowania. Według badań branżowych nawet 30% użytkowników porzuca proces rejestracji, jeśli wymaga on tworzenia nowego konta.

Logowanie przez Google, Facebook, GitHub czy Apple eliminuje tę barierę. Użytkownik klika przycisk, potwierdza dostęp i jest zalogowany — bez nowego hasła, bez weryfikacji maila, bez dodatkowych kroków. Za kulisami tego procesu stoi protokół OAuth2.

OAuth2 (Open Authorization 2.0) to standard autoryzacji, który pozwala aplikacji uzyskać ograniczony dostęp do konta użytkownika w zewnętrznym serwisie, bez poznawania jego hasła. To kluczowe rozróżnienie — Twoja aplikacja nigdy nie widzi hasła do konta Google czy Facebook. Otrzymuje jedynie token dostępu z określonymi uprawnieniami.

Kluczowe pojęcia

Resource Owner — użytkownik, który posiada konto u dostawcy (np. konto Google).

Client — Twoja aplikacja, która chce uzyskać dostęp do danych użytkownika.

Authorization Server — serwer dostawcy, który wydaje tokeny (np. accounts.google.com).

Resource Server — serwer z danymi użytkownika, do których chcesz uzyskać dostęp (np. Google People API).

Access Token — krótkotrwały token uprawniający do dostępu do zasobów użytkownika. Zazwyczaj ważny 1 godzinę.

Refresh Token — długotrwały token służący do uzyskania nowego access tokena bez ponownego logowania użytkownika.

Scope — zakres uprawnień, o które prosi aplikacja. Na przykład openid email profile oznacza dostęp do podstawowych danych użytkownika i adresu email.

Authorization Code Flow — najważniejszy flow

Authorization Code Flow to rekomendowany typ flow dla aplikacji webowych z backendem. Przebieg wygląda następująco:

  1. Użytkownik klika "Zaloguj przez Google" na Twojej stronie
  2. Przeglądarka przekierowuje na serwer autoryzacji Google z parametrami: client_id, redirect_uri, scope, state
  3. Użytkownik loguje się do Google (jeśli nie jest zalogowany) i potwierdza uprawnienia
  4. Google przekierowuje z powrotem na Twoją stronę z kodem autoryzacyjnym (code) w URL
  5. Twój backend wymienia kod na access token, wysyłając żądanie do Google z code, client_id i client_secret
  6. Google zwraca access token (i opcjonalnie refresh token)
  7. Twój backend używa access tokena do pobrania danych użytkownika z Google API

Kluczowe jest to, że kod autoryzacyjny jest wymieniany na token po stronie backendu, a nie w przeglądarce. client_secret nigdy nie trafia do klienta. To fundamentalna zasada bezpieczeństwa tego flow.

PKCE — rozszerzenie dla aplikacji bez backendu

Authorization Code Flow z PKCE (Proof Key for Code Exchange, wymawiane "pixy") to wariant zaprojektowany dla aplikacji mobilnych i SPA (Single Page Applications), które nie mają bezpiecznego backendu do przechowywania client_secret.

Mechanizm dodaje dodatkowy krok: przed wysłaniem żądania autoryzacji klient generuje losowy code_verifier i jego hash (code_challenge). Hash jest wysyłany z żądaniem autoryzacji, a oryginalny verifier — z żądaniem wymiany kodu na token. Serwer autoryzacji weryfikuje, że oba pochodzą od tego samego klienta.

PKCE jest dziś rekomendowany nawet dla aplikacji z backendem jako dodatkowa warstwa ochrony.

OpenID Connect — tożsamość na OAuth2

OAuth2 sam w sobie to protokół autoryzacji, nie uwierzytelniania. Mówi "ta aplikacja ma dostęp do tych zasobów", ale nie mówi wprost "ten użytkownik to Jan Kowalski z emailem jan@example.com".

OpenID Connect (OIDC) to warstwa tożsamości zbudowana na OAuth2. Dodaje standardowy sposób uzyskania informacji o użytkowniku. Główna różnica to ID Token — token JWT zawierający dane użytkownika (imię, email, identyfikator), podpisany cyfrowo przez dostawcę.

W praktyce, gdy chcesz wdrożyć "Zaloguj przez Google", używasz OpenID Connect, nie czystego OAuth2. Scope openid aktywuje OIDC, a serwer zwraca ID Token oprócz access tokena.

Wdrożenie krok po kroku

Rejestracja aplikacji — każdy dostawca wymaga zarejestrowania aplikacji w konsoli deweloperskiej (Google Cloud Console, Facebook Developer Portal, GitHub Settings). Otrzymujesz client_id i client_secret.

Konfiguracja redirect URI — adres, na który dostawca przekieruje po autoryzacji. Musi być dokładnie taki sam jak zarejestrowany w konsoli — nawet trailing slash robi różnicę. Używaj HTTPS w produkcji.

Implementacja backendu — obsługa endpointów: /auth/google (przekierowanie na Google), /auth/google/callback (odbiór kodu i wymiana na token). W Go można to zrealizować pakietem golang.org/x/oauth2 lub nawet ręcznie za pomocą standardowej biblioteki.

Tworzenie lub łączenie konta — po otrzymaniu danych użytkownika (email, nazwa, identyfikator dostawcy) musisz zdecydować: czy tworzyć nowe konto, czy łączyć z istniejącym. Typowa strategia: szukaj użytkownika po emailu; jeśli istnieje — łącz konta; jeśli nie — twórz nowe.

Bezpieczeństwo — na co uważać

Parametr state jest obowiązkowy. To losowy ciąg generowany przed przekierowaniem i weryfikowany po powrocie. Chroni przed atakami CSRF — bez niego atakujący mógłby podrzucić własny kod autoryzacyjny.

Walidacja ID Token — zawsze weryfikuj podpis JWT, datę ważności, wystawcę (issuer) i odbiorcę (audience). Nie ufaj danym z tokena bez weryfikacji podpisu.

Nie ufaj emailowi bezwarunkowo — sam fakt, że Google zwraca email, nie oznacza, że użytkownik jest właścicielem tego emaila w Twoim systemie. Sprawdzaj flagę email_verified i bądź ostrożny z automatycznym łączeniem kont.

Przechowuj tokeny bezpiecznie — access tokeny i refresh tokeny to wrażliwe dane. Nigdy nie przechowuj ich w localStorage (podatny na XSS). W aplikacjach z backendem przechowuj tokeny po stronie serwera, a klientowi wydaj sesję HTTP-only cookie.

Minimalny scope — proś tylko o uprawnienia, które faktycznie potrzebujesz. Scope openid email profile wystarczy do logowania. Nie proś o dostęp do kontaktów, kalendarza czy plików, jeśli tego nie potrzebujesz — użytkownicy słusznie reagują nieufnością na szerokie żądania uprawnień.

Podsumowanie

OAuth2 z OpenID Connect to standard logowania zewnętrznego, który łączy wygodę użytkownika z bezpieczeństwem. Authorization Code Flow z PKCE jest rekomendowany dla większości zastosowań. Kluczowe jest przestrzeganie zasad bezpieczeństwa — walidacja state, weryfikacja tokenów i minimalne uprawnienia.

Chcesz wdrożyć logowanie przez Google czy inne serwisy w swojej aplikacji? Skontaktuj się z nami — zaprojektujemy bezpieczny i wygodny system autoryzacji.