OAuth 2.0: mi ez, hogyan működik az engedélyezési protokoll

Czym jest OAuth 2.0?

OAuth 2.0 to protokół autoryzacji zdefiniowany w IETF RFC 6749, który umożliwia aplikacjom zewnętrznym uzyskanie ograniczonego dostępu do zasobów użytkownika bez ujawniania jego loginu i hasła. Protokół rozwiązuje fundamentalny problem modelu hasłowego: aplikacja, której zaufałeś hasło, uzyskuje nieograniczony dostęp do wszystkich danych konta. OAuth 2.0 zastępuje to podejście wydaniem tymczasowego tokena z wyraźnie ograniczonym zakresem dostępu (scope).

Architektura OAuth 2.0 to delegowana autoryzacja. Użytkownik (Resource Owner) autoryzuje aplikację (Client) do dostępu do swoich danych przechowywanych na serwerze zasobów (Resource Server) za pośrednictwem serwera autoryzacji (Authorization Server). Serwer autoryzacji wydaje Access Token — ciąg kryptograficzny, który aplikacja przedstawia serwerowi zasobów w celu uzyskania dostępu do danych. Ważna różnica między OAuth 2.0 a SAML i OpenID Connect: OAuth 2.0 rozwiązuje problem autoryzacji (co jest dozwolone), a nie uwierzytelniania (kim jest użytkownik). Do uwierzytelniania na bazie OAuth 2.0 budowany jest protokół OpenID Connect (OIDC).

Protokół jest obsługiwany przez wszystkie główne platformy. Google używa OAuth 2.0 do dostępu do Google APIs (Gmail, Drive, Calendar), Facebook — do Graph API, Apple — do Sign in with Apple (ASAuthorizationAppleIDProvider), GitHub — do dostępu do repozytoriów. W kontekście tworzenia aplikacji mobilnych OAuth 2.0 to standardowy mechanizm integracji usług zewnętrznych: logowanie przez media społecznościowe, dostęp do chmurowych magazynów, publikowanie treści w imieniu użytkownika.

Role i komponenty OAuth 2.0

Protokół OAuth 2.0 definiuje cztery role, których interakcja stanowi pełny cykl autoryzacji. Zrozumienie każdej roli jest niezbędne do poprawnej implementacji protokołu w aplikacji mobilnej.

Cztery role protokołu

Kluczowe jednostki protokołu to Access Token, Refresh Token i Authorization Code. Access Token to krótkożyciowy token (zwykle 15–60 minut) przedstawiany serwerowi zasobów przy każdym żądaniu danych. Refresh Token to długożyciowy token (doba lub tygodnie) używany do uzyskania nowego Access Token bez ponownego logowania użytkownika. Authorization Code to tymczasowy kod wydawany po autoryzacji użytkownika i wymieniany na Access Token i Refresh Token.

Grant Types: scenariusze autoryzacji

OAuth 2.0 definiuje kilka Grant Types — scenariuszy uzyskiwania tokena, z których każdy jest przeznaczony dla określonego typu klienta i kontekstu bezpieczeństwa. Wybór odpowiedniego Grant Type to kluczowa decyzja architektoniczna przy projektowaniu autoryzacji w aplikacji mobilnej.

Podstawowe Grant Types: Authorization Code (najbezpieczniejszy dla aplikacji mobilnych i webowych z komponentem serwerowym), Authorization Code z PKCE (Proof Key for Code Exchange — dla aplikacji mobilnych i SPA bez zaplecza serwerowego), Client Credentials (do uwierzytelniania serwer-serwer bez udziału użytkownika), Resource Owner Password Credentials (przestarzały — bezpośrednie przekazywanie hasła). PKCE jest obowiązkowym rozszerzeniem dla klientów publicznych (aplikacje mobilne, SPA) zgodnie z zaleceniami OAuth Security BCP (RFC 9700).

Podstawowe Grant Types

• Authorization Code + PKCE — zalecany Grant Type dla natywnych aplikacji mobilnych. Klient generuje kryptograficzny code_verifier, oblicza code_challenge (SHA-256 hash), a serwer sprawdza zgodność podczas wymiany kodu na token. Zapobiega to przechwyceniu authorization code między aplikacją a serwerem
• Client Credentials — używany do autoryzacji machine-to-machine, gdzie klient jest znany i uwierzytelniony. Aplikacja otrzymuje token używając swojego client_id i client_secret. Nie wymaga udziału użytkownika. Typowy scenariusz: aplikacja serwerowa uzyskuje dostęp do API do przetwarzania wsadowego danych
• Device Authorization Grant — dla urządzeń bez przeglądarki (Smart TV, IoT). Użytkownik przechodzi pod link na innym urządzeniu i wprowadza kod. Używane np. przy autoryzacji Netflix na telewizorze przez smartfon
• Resource Owner Password Credentials — przestarzały Grant Type, zabroniony przez OAuth Security BCP. Hasło jest przekazywane bezpośrednio klientowi, co narusza zasadę zero-knowledge authentication. Używane tylko do migracji z przestarzałych systemów

Authorization Code Flow z PKCE dla aplikacji mobilnych

Authorization Code Flow z PKCE to zalecana konfiguracja OAuth 2.0 dla natywnych aplikacji mobilnych. PKCE (Proof Key for Code Exchange) dodaje dodatkową warstwę ochrony, zapobiegającą atakowi przechwycenia authorization code (authorization code interception attack). Protokół jest opisany w IETF RFC 7636.

Krok po kroku sekwencja PKCE

Sekwencja kroków: (1) klient generuje losowy code_verifier (ciąg 43–128 znaków, tylko unreserved characters), (2) klient oblicza code_challenge = SHA-256(code_verifier), (3) klient otwiera przeglądarkę do autoryzacji użytkownika na Authorization Server, przekazując code_challenge, (4) po pomyślnej autoryzacji serwer zwraca authorization code do aplikacji przez niestandardowy scheme URI (app deep link), (5) klient wysyła do serwera authorization code + code_verifier, (6) serwer sprawdza SHA-256(code_verifier) === code_challenge i wydaje Access Token + Refresh Token.

Zaleta PKCE — nawet jeśli atakujący przechwyci authorization code w scheme URI, nie będzie mógł wymienić go na token bez code_verifier, który jest znany tylko legalnemu klientowi. W aplikacjach mobilnych do otwarcia przeglądarki należy używać Chrome Custom Tabs (Android) lub ASWebAuthenticationSession (iOS) — gwarantuje to, że przeglądarka systemowa nie ma dostępu do code_verifier z pamięci aplikacji.

Implementacja OAuth 2.0 na Android przez AppAuth

AppAuth to referencyjna implementacja OAuth 2.0 i OpenID Connect dla natywnych aplikacji, rekomendowana przez IETF. Biblioteka obsługuje PKCE, Chrome Custom Tabs, niestandardowe scheme URI do zwrotu authorization code i automatyczne odświeżanie tokenów. AppAuth dla Android jest dostępny przez dependencję `net.openid:appauth:0.11.1`.

val serviceConfig = AuthorizationServiceConfiguration.fromUrl(
    Uri.parse("https://accounts.google.com/.well-known/openid-configuration")
)

val request = AuthorizationRequest.Builder(
    serviceConfig,
    "CLIENT_ID.apps.googleusercontent.com",
    ResponseTypeValues.CODE,
    Uri.parse("com.example.app:/oauth2callback")
)
.setScope("openid profile email")
.setCodeVerifier(
    CodeVerifierUtil.generateRandomCodeVerifier()
)
.build()

val authService = AuthorizationService(context)
val intent = authService.getAuthorizationRequestIntent(request)

// Chrome Custom Tab indítása engedélyezéshez
startActivityForResult(intent, REQUEST_CODE_AUTH)

Po otrzymaniu authorization code (onActivityResult) aplikacja wymienia go na Access Token i Refresh Token przez TokenRequest. Tokeny są zapisywane w SharedPreferences z szyfrowaniem przez EncryptedSharedPreferences (Android Security Crypto). Refresh Token powinien być przechowywany w KeyStore — sprzętowym magazynie kluczy niedostępnym do odczytu dla innych aplikacji. Przy każdym wygaśnięciu Access Token aplikacja używa Refresh Token do uzyskania nowego — użytkownik nie musi ponownie się autoryzować.

// Authorization code cseréje tokenekre
val data = intent?.data ?: return
val resp = AuthorizationResponse.fromIntent(data)
val exchangeReq = resp?.createTokenExchangeRequest()
    ?: return

authService.performTokenRequest(
    exchangeReq,
    ClientAuthentication.none()
) { tokenResp, ex ->
    if (tokenResp != null) {
        // Access Token és Refresh Token megérkezett
        val accessToken = tokenResp.accessToken
        val refreshToken = tokenResp.refreshToken
        // Mentés EncryptedSharedPreferences-be
        saveTokens(accessToken, refreshToken)
    }
}

Przedstawiony kod demonstruje pełny cykl OAuth 2.0 z PKCE: utworzenie konfiguracji serwera przez OpenID Connect Discovery, wygenerowanie żądania autoryzacji z code_verifier, uruchomienie Chrome Custom Tab, przyjęcie authorization code przez niestandardowy scheme URI i wymianę kodu na tokeny przez Token Request. Ważne jest obsłużenie wygaśnięcia Access Token: przy odpowiedzi HTTP 401 od Resource Server aplikacja powinna użyć Refresh Token do uzyskania nowego Access Token i ponownie wykonać żądanie.

Bezpieczeństwo OAuth 2.0: typowe ataki i ochrona

OAuth 2.0 to złożony protokół z wieloma punktami ataku. IETF Security BCP (RFC 9700) opisuje ponad 20 klas podatności OAuth 2.0. Dla aplikacji mobilnych najbardziej krytyczne są: przechwycenie authorization code przez niestandardowe scheme URI, ataki CSRF na endpointy callback, kradzież Refresh Token z niebezpiecznego magazynu i podstawienie klienta przez przechwycenie intencji.

Ochrona przed tymi atakami obejmuje obowiązkowe środki: (1) PKCE z S256 code_challenge — zapobiega przechwyceniu authorization code nawet przy przechwyceniu scheme URI; (2) użycie nonce lub state parameter do zapobiegania CSRF — serwer sprawdza, czy authorization code odpowiada oryginalnemu żądaniu; (3) przechowywanie Refresh Token tylko w KeyStore (Android) lub Keychain (iOS) — ani w SharedPreferences, ani w UserDefaults; (4) używanie TLS z Certificate Pinning do ochrony MITM na poziomie transportu; (5) weryfikacja redirect_uri — serwer autoryzacji musi ściśle walidować zgodność z zarejestrowanym URI.

Dodatkowe zalecenia od IETF: aplikacje mobilne powinny używać AppAuth lub podobnych bibliotek po audycie bezpieczeństwa; nie polegać na WebView dla OAuth (WebView nie izoluje danych od głównej aplikacji); zaimplementować automatyczną rotację Refresh Token (jeden Refresh Token może być użyty jednokrotnie); dodać Certificate Pinning przez TrustManager dla Android i URLSession dla iOS. OpenID Connect Discovery (well-known endpoint) pomaga automatycznie określić poprawne endpointy serwera autoryzacji i uniknąć przekierowań na strony phishingowe.