OAuth 2.0: wat is het, hoe werkt het autorisatieprotocol

OAuth 2.0 nədir?

OAuth 2.0 IETF RFC 6749-da müəyyən edilmiş avtorizasiya protokoludur, üçüncü tərəf proqramlarına istifadəçinin login və şifrəsini açıqlamadan onun resurslarına məhdud giriş əldə etməyə imkan verir. Protokol şifrə modelinin fundamental problemini həll edir: şifrəni etibar etdiyiniz proqram hesabın bütün məlumatlarına limitsiz giriş əldə edir. OAuth 2.0 bu yanaşmanı açıq şəkildə məhdudlaşdırılmış giriş sahəsi (scope) olan müvəqqəti token verməklə əvəz edir.

OAuth 2.0 arxitekturası nümayəndəli avtorizasiyadır. İstifadəçi (Resource Owner) proqramı (Client) resurs serverində (Resource Server) saxlanılan məlumatlarına giriş üçün avtorizasiya serveri (Authorization Server) vasitəsilə səlahiyyətləndirir. Avtorizasiya serveri Access Token — proqramın məlumatlara giriş üçün resurs serverinə təqdim etdiyi kriptoqrafik sətir buraxır. OAuth 2.0-ın SAML və OpenID Connect-dən mühüm fərqi: OAuth 2.0 avtorizasiya problemini (nəyə icazə verilir) həll edir, autentifikasiyanı deyil (istifadəçi kimdir). Autentifikasiya üçün OAuth 2.0 üzərində OpenID Connect (OIDC) protokolu qurulur.

Protokol bütün böyük platformalar tərəfindən dəstəklənir. Google OAuth 2.0-ı Google APIs-ə (Gmail, Drive, Calendar) giriş üçün, Facebook — Graph API üçün, Apple — Sign in with Apple (ASAuthorizationAppleIDProvider) üçün, GitHub — repozitoriyalara giriş üçün istifadə edir. Mobil tərtibat kontekstində OAuth 2.0 üçüncü tərəf xidmətlərinin inteqrasiyası üçün standart mexanizmdir: sosial şəbəkələr vasitəsilə giriş, bulud anbarlarına giriş, istifadəçi adından məzmun dərc etmə.

OAuth 2.0 rolları və komponentləri

OAuth 2.0 protokolu dörd rol müəyyən edir, onların qarşılıqlı əlaqəsi tam avtorizasiya dövrünü təşkil edir. Hər bir rolun başa düşülməsi protokolun mobil proqramda düzgün tətbiqi üçün zəruridir.

Protokolun dörd rolu

Protokolun əsas vahidləri Access Token, Refresh Token və Authorization Code-dur. Access Token qısaömürlü token (adətən 15–60 dəqiqə) hər məlumat sorğusunda resurs serverinə təqdim olunur. Refresh Token uzunömürlü token (gün və ya həftələr) istifadəçinin yenidən daxil olmadan yeni Access Token əldə etmək üçün istifadə olunur. Authorization Code istifadəçinin avtorizasiyasından sonra verilən müvəqqəti koddur və Access Token və Refresh Token-ə dəyişdirilir.

Grant Types: avtorizasiya ssenariləri

OAuth 2.0 bir neçə Grant Types — token əldə etmə ssenariləri müəyyən edir, hər biri müəyyən müştəri tipi və təhlükəsizlik konteksti üçün nəzərdə tutulub. Düzgün Grant Type seçimi mobil proqramda avtorizasiyanın layihələndirilməsində kritik memarlıq qərarıdır.

Əsas Grant Types: Authorization Code (server komponenti olan mobil və veb proqramlar üçün ən təhlükəsiz), PKCE ilə Authorization Code (Proof Key for Code Exchange — server backend olmadan mobil və SPA proqramlar üçün), Client Credentials (istifadəçi iştirakı olmadan server-server autentifikasiyası üçün), Resource Owner Password Credentials (köhnəlmiş — şifrənin birbaşa ötürülməsi). PKCE OAuth Security BCP (RFC 9700) tövsiyələrinə əsasən açıq müştərilər (mobil proqramlar, SPA) üçün məcburi genişlənmədir.

Əsas Grant Types

• Authorization Code + PKCE — yerli mobil proqramlar üçün tövsiyə edilən Grant Type. Müştəri kriptoqrafik code_verifier yaradır, code_challenge (SHA-256 hash) hesablayır və server kodun tokenə dəyişdirilməsi zamanı uyğunluğu yoxlayır. Bu, proqram və server arasında authorization code-un ələ keçirilməsinin qarşısını alır
• Client Credentials — müştərinin tanındığı və autentifikasiya edildiyi machine-to-machine avtorizasiyası üçün istifadə olunur. Proqram öz client_id və client_secret istifadə edərək token alır. İstifadəçi iştirakı tələb etmir. Tipik ssenari: server proqramı məlumatların toplu emalı üçün API-yə müraciət edir
• Device Authorization Grant — brauzeri olmayan cihazlar üçün (Smart TV, IoT). İstifadəçi başqa cihazda linkə keçid edir və kodu daxil edir. Məsələn, Netflix-in televizorda smartfon vasitəsilə avtorizasiyasında istifadə olunur
• Resource Owner Password Credentials — OAuth Security BCP tərəfindən qadağan edilmiş köhnəlmiş Grant Type. Şifrə birbaşa müştəriyə ötürülür, bu da zero-knowledge authentication prinsipini pozur. Yalnız köhnəlmiş sistemlərdən miqrasiya üçün istifadə olunur

Mobil proqramlar üçün PKCE ilə Authorization Code Flow

PKCE ilə Authorization Code Flow yerli mobil proqramlar üçün OAuth 2.0-ın tövsiyə edilən konfiqurasiyasıdır. PKCE (Proof Key for Code Exchange) authorization code-un ələ keçirilmə hücumunun (authorization code interception attack) qarşısını alan əlavə qoruma qatı əlavə edir. Protokol IETF RFC 7636-da təsvir edilmişdir.

PKCE-nin addım-addım ardıcıllığı

Addımların ardıcıllığı: (1) müştəri təsadüfi code_verifier yaradır (43–128 simvol, yalnız unreserved characters), (2) müştəri code_challenge = SHA-256(code_verifier) hesablayır, (3) müştəri Authorization Server-da istifadəçinin avtorizasiyası üçün brauzer açır, code_challenge ötürür, (4) uğurlu avtorizasiyadan sonra server xüsusi URI scheme (app deep link) vasitəsilə proqrama authorization code qaytarır, (5) müştəri serverə authorization code + code_verifier göndərir, (6) server SHA-256(code_verifier) === code_challenge yoxlayır və Access Token + Refresh Token buraxır.

PKCE-nin üstünlüyü — hətta təcavüzkar URI schemedə authorization code-u ələ keçirsə belə, onu yalnız qanuni müştəriyə məlum olan code_verifier olmadan tokenə dəyişə bilməz. Mobil proqramlarda brauzer açmaq üçün Chrome Custom Tabs (Android) və ya ASWebAuthenticationSession (iOS) istifadə edilməlidir — bu, sistem brauzerinin proqram yaddaşından code_verifier-ə girişinin olmamasını təmin edir.

AppAuth vasitəsilə Android-də OAuth 2.0 tətbiqi

AppAuth IETF tərəfindən tövsiyə edilən yerli proqramlar üçün OAuth 2.0 və OpenID Connect-in istinad tətbiqidir. Kitabxana PKCE, Chrome Custom Tabs, authorization code-un qaytarılması üçün xüsusi URI schemeləri və tokenlərin avtomatik yenilənməsini dəstəkləyir. Android üçün AppAuth `net.openid:appauth:0.11.1` dependency vasitəsilə mövcuddur.

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 starten voor autorisatie
startActivityForResult(intent, REQUEST_CODE_AUTH)

Authorization code aldıqdan sonra (onActivityResult) proqram onu TokenRequest vasitəsilə Access Token və Refresh Token-ə dəyişir. Tokenlər EncryptedSharedPreferences (Android Security Crypto) vasitəsilə şifrələnmiş SharedPreferences-da saxlanılır. Refresh Token KeyStore-da — digər proqramların oxuması üçün əlçatmaz olan aparat açar anbarında saxlanmalıdır. Hər Access Token müddəti bitdikdə proqram yenisini əldə etmək üçün Refresh Token istifadə edir — istifadəçi yenidən avtorizasiyadan keçməli deyil.

// Authorization code inwisselen voor tokens
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 en Refresh Token ontvangen
        val accessToken = tokenResp.accessToken
        val refreshToken = tokenResp.refreshToken
        // Opslaan in EncryptedSharedPreferences
        saveTokens(accessToken, refreshToken)
    }
}

Təqdim olunan kod PKCE ilə OAuth 2.0-ın tam dövrünü nümayiş etdirir: OpenID Connect Discovery vasitəsilə server konfiqurasiyasının yaradılması, code_verifier ilə avtorizasiya sorğusunun generasiyası, Chrome Custom Tab-ın işə salınması, xüsusi URI scheme vasitəsilə authorization code-un qəbulu və Token Request vasitəsilə kodun tokenlərə dəyişdirilməsi. Access Token müddətinin bitməsini idarə etmək vacibdir: Resource Server-dan HTTP 401 cavabı aldıqda proqram yeni Access Token əldə etmək üçün Refresh Token Flow-dan istifadə etməli və sorğunu təkrarlamalıdır.

OAuth 2.0 təhlükəsizliyi: tipik hücumlar və müdafiə

OAuth 2.0 çoxlu hücum nöqtələri olan mürəkkəb protokoldur. IETF Security BCP (RFC 9700) OAuth 2.0-ın 20-dən çox zəiflik sinfini təsvir edir. Mobil proqramlar üçün ən kritik olanlar: xüsusi URI schemeləri vasitəsilə authorization code-un ələ keçirilməsi, callback endpointlərə CSRF hücumları, təhlükəsiz olmayan anbarlardan Refresh Token-in oğurlanması və intent interception vasitəsilə müştərinin əvəz edilməsi.

Bu hücumlardan qorunma məcburi tədbirləri əhatə edir: (1) S256 code_challenge ilə PKCE — URI scheme-nin ələ keçirilməsində belə authorization code-un ələ keçirilməsinin qarşısını alır; (2) CSRF-nin qarşısını almaq üçün nonce və ya state parametrinin istifadəsi — server authorization code-un orijinal sorğuya uyğunluğunu yoxlayır; (3) Refresh Token-in yalnız KeyStore-da (Android) və ya Keychain-də (iOS) saxlanması — nə SharedPreferences, nə də UserDefaults-da; (4) nəqliyyat səviyyəsində MITM-dən qorunmaq üçün TLS-in Certificate Pinning ilə istifadəsi; (5) redirect_uri-nin yoxlanılması — avtorizasiya serveri qeydiyyatdan keçmiş URI-yə uyğunluğu ciddi şəkildə yoxlamalıdır.

IETF-dən əlavə tövsiyələr: mobil proqramlar təhlükəsizlik auditi keçmiş AppAuth və ya oxşar kitabxanalardan istifadə etməlidir; OAuth üçün WebView-ə etibar etməməlidir (WebView məlumatları əsas proqramdan təcrid etmir); Refresh Token-in avtomatik rotasiyasını tətbiq etməlidir (bir Refresh Token yalnız bir dəfə istifadə edilə bilər); Android üçün TrustManager və iOS üçün URLSession vasitəsilə Certificate Pinning əlavə etməlidir. OpenID Connect Discovery (well-known endpoint) avtorizasiya serverinin düzgün endpointlərini avtomatik müəyyən etməyə və fişinq səhifələrinə yönləndirmələrin qarşısını almağa kömək edir.