Jak zabezpieczyć REST API (uwierzytelnianie, autoryzacja, transport)?

Question

IT Interview Practice · Accepted Answer

Zabezpieczenie REST API oznacza odpowiedź na trzy pytania przy każdym żądaniu: **kim jesteś** (uwierzytelnianie), **co wolno ci robić** (autoryzacja) i **czy kanał jest prywatny** (transport). Ponieważ REST jest **bezstanowy**, poświadczenia muszą podróżować z każdym żądaniem, a nie żyć w sesji serwera.

## Transport: zawsze HTTPS

Wszystko poniżej zakłada **TLS/HTTPS**. Bez tego tokeny i klucze API podróżują otwartym tekstem i mogą zostać podsłuchane. To niepodlegające negocjacji — bearer token przez HTTP to wyciekły token.

## Opcje uwierzytelniania

**Klucze API** — statyczny sekret w nagłówku. Proste; dobre dla server-to-server i identyfikacji *aplikacji*, nie użytkownika. Same w sobie słabe (brak wygaśnięcia, brak zakresu) bez połączenia z czymś więcej.
```http
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
```

**OAuth 2.0** — standard dla dostępu **delegowanego** („pozwól aplikacji X czytać moje dane bez mojego hasła"). Aplikacja uzyskuje **access token** przez flow (np. Authorization Code) i wysyła go jako bearer token. Tak działa „Zaloguj się przez Google" i integracje firm trzecich.

**JWT (JSON Web Token)** — popularny *format* tokenów: podpisany, samowystarczalny token niosący twierdzenia (claims) (id użytkownika, role, wygaśnięcie). Serwer weryfikuje podpis — bez potrzeby odpytywania bazy danych, co pasuje do bezstanowego REST.
```text
header.payload.signature   (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
```

## Autoryzacja: zakresy i role

Uwierzytelnianie dowodzi tożsamości; **autoryzacja** decyduje o dostępie. Tokeny niosą **zakresy (scopes)** (`orders:read`, `orders:write`) lub role; serwer sprawdza je per endpoint i zwraca `403 Forbidden`, gdy są niewystarczające (w przeciwieństwie do `401` przy brakującym/nieprawidłowym uwierzytelnieniu).

```text
No/invalid token         → 401 Unauthorized
Valid token, no scope    → 403 Forbidden
```

## Inne rzeczy niezbędne

```text
✓ Short-lived access tokens + refresh tokens (limit blast radius if leaked)
✓ Rate limiting (429) to blunt brute-force and abuse
✓ Validate/sanitize all input; never trust the client
✓ Principle of least privilege on scopes
```

## Dlaczego to ważne

Bezpieczeństwo to miejsce, gdzie mały błąd staje się naruszeniem, więc rozmówcy używają tego, by zobaczyć, czy rozumujesz o nim strukturalnie, a nie recytujesz buzzwordy. Sygnał, którego szukają, to że **rozdzielasz trzy warstwy** — transport (HTTPS, zawsze), uwierzytelnianie (dowodzenie tożsamości, bezstanowo, przez bearer tokeny/JWT/OAuth) i autoryzację (zakresy i najmniejsze uprawnienia) — i że ich nie mylisz, np. poprawnie używając `401` dla „nieuwierzytelniony" a `403` dla „uwierzytelniony, ale bez uprawnień". Mocne odpowiedzi pokazują świadomość praktycznych kompromisów: JWT są wygodne i bezstanowe, ale trudne do odwołania przed wygaśnięciem (stąd krótkie czasy życia plus refresh tokeny), klucze API identyfikują aplikacje, nie użytkowników, a OAuth istnieje właśnie po to, by użytkownicy nie oddawali swojego hasła firmom trzecim. Powiązanie tego z bezstanowością REST — poświadczenia przy każdym żądaniu, brak sesji serwera — pokazuje, że rozumiesz, *dlaczego* bezpieczeństwo API wygląda tak, jak wygląda.

Transport: zawsze HTTPS

Opcje uwierzytelniania

Autoryzacja: zakresy i role

Inne rzeczy niezbędne

Dlaczego to ważne

Powiązane pytania