OAuth 2.0: چیست، چگونه پروتکل احراز هویت کار می‌کند

OAuth 2.0 چیست؟

OAuth 2.0 یک پروتکل احراز هویت است که در IETF RFC 6749 تعریف شده و به برنامه‌های شخص ثالث امکان می‌دهد بدون افشای نام کاربری و رمز عبور کاربر، دسترسی محدودی به منابع او داشته باشند. این پروتکل مشکل اساسی مدل رمز عبوری را حل می‌کند: برنامه‌ای که رمز عبور به آن اعتماد شده، به تمام داده‌های حساب دسترسی نامحدود پیدا می‌کند. OAuth 2.0 این رویکرد را با صدور یک توکن موقت با حوزه دسترسی به‌وضوح محدود (scope) جایگزین می‌کند.

معماری OAuth 2.0 احراز هویت تفویضی است. کاربر (Resource Owner) برنامه (Client) را برای دسترسی به داده‌های خود که در سرور منابع (Resource Server) ذخیره شده، از طریق یک واسطه — سرور احراز هویت (Authorization Server) — مجاز می‌کند. سرور احراز هویت Access Token را صادر می‌کند — یک رشته رمزنگاری که برنامه برای دسترسی به داده‌ها به سرور منابع ارائه می‌دهد. تفاوت مهم OAuth 2.0 با SAML و OpenID Connect: OAuth 2.0 مشکل احراز هویت (چه چیزی مجاز است) را حل می‌کند، نه احراز هویت هویتی (کاربر کیست). برای احراز هویت هویتی، پروتکل OpenID Connect (OIDC) بر روی OAuth 2.0 ساخته می‌شود.

این پروتکل توسط تمام پلتفرم‌های بزرگ پشتیبانی می‌شود. Google از OAuth 2.0 برای دسترسی به Google APIs (Gmail, Drive, Calendar)، Facebook — برای Graph API، Apple — برای Sign in with Apple (ASAuthorizationAppleIDProvider)، GitHub — برای دسترسی به مخازن استفاده می‌کند. در زمینه توسعه موبایل، OAuth 2.0 مکانیزم استاندارد برای یکپارچه‌سازی سرویس‌های شخص ثالث است: ورود از طریق شبکه‌های اجتماعی، دسترسی به ذخیره‌سازهای ابری، انتشار محتوا از طرف کاربر.

نقش‌ها و مؤلفه‌های OAuth 2.0

پروتکل OAuth 2.0 چهار نقش را تعریف می‌کند که تعامل آنها چرخه کامل احراز هویت را تشکیل می‌دهد. درک هر نقش برای پیاده‌سازی صحیح پروتکل در برنامه موبایل ضروری است.

چهار نقش پروتکل

موجودیت‌های کلیدی پروتکل Access Token، Refresh Token و Authorization Code هستند. Access Token یک توکن کوتاه‌مدت (معمولاً ۱۵–۶۰ دقیقه) است که در هر درخواست داده به سرور منابع ارائه می‌شود. Refresh Token یک توکن طولانی‌مدت (روزها یا هفته‌ها) است که برای دریافت Access Token جدید بدون ورود مجدد کاربر استفاده می‌شود. Authorization Code یک کد موقت است که پس از احراز هویت کاربر صادر شده و با Access Token و Refresh Token مبادله می‌شود.

Grant Types: سناریوهای احراز هویت

OAuth 2.0 چندین Grant Types — سناریوهای دریافت توکن را تعریف می‌کند که هر کدام برای نوع خاصی از مشتری و زمینه امنیتی طراحی شده‌اند. انتخاب Grant Type مناسب یک تصمیم معماری حیاتی در طراحی احراز هویت در برنامه موبایل است.

Grant Types اصلی: Authorization Code (امن‌ترین برای برنامه‌های موبایل و وب با مؤلفه سروری)، Authorization Code با PKCE (Proof Key for Code Exchange — برای برنامه‌های موبایل و SPA بدون بک‌اند سروری)، Client Credentials (برای احراز هویت سرور به سرور بدون مشارکت کاربر)، Resource Owner Password Credentials (منسوخ — انتقال مستقیم رمز عبور). PKCE یک افزونه اجباری برای مشتریان عمومی (برنامه‌های موبایل، SPA) مطابق با توصیه‌های OAuth Security BCP (RFC 9700) است.

Grant Types اصلی

• Authorization Code + PKCE — Grant Type توصیه‌شده برای برنامه‌های بومی موبایل. مشتری یک code_verifier رمزنگاری تولید می‌کند، code_challenge (SHA-256 hash) را محاسبه کرده و سرور تطابق را در هنگام مبادله کد با توکن بررسی می‌کند. این از رهگیری authorization code بین برنامه و سرور جلوگیری می‌کند
• Client Credentials — برای احراز هویت machine-to-machine استفاده می‌شود، جایی که مشتری شناخته شده و احراز هویت شده است. برنامه با استفاده از client_id و client_secret خود توکن دریافت می‌کند. نیازی به مشارکت کاربر ندارد. سناریوی معمول: برنامه سروری برای پردازش دسته‌ای داده به API دسترسی پیدا می‌کند
• Device Authorization Grant — برای دستگاه‌های بدون مرورگر (Smart TV، IoT). کاربر روی دستگاه دیگر به یک لینک رفته و کد را وارد می‌کند. به عنوان مثال در احراز هویت Netflix در تلویزیون از طریق گوشی هوشمند استفاده می‌شود
• Resource Owner Password Credentials — Grant Type منسوخ، ممنوع‌شده توسط OAuth Security BCP. رمز عبور مستقیماً به مشتری منتقل می‌شود که اصل zero-knowledge authentication را نقض می‌کند. فقط برای مهاجرت از سیستم‌های قدیمی استفاده می‌شود

Authorization Code Flow با PKCE برای برنامه‌های موبایل

Authorization Code Flow با PKCE پیکربندی توصیه‌شده OAuth 2.0 برای برنامه‌های بومی موبایل است. PKCE (Proof Key for Code Exchange) یک لایه حفاظتی اضافی اضافه می‌کند که از حمله رهگیری authorization code (authorization code interception attack) جلوگیری می‌کند. این پروتکل در IETF RFC 7636 توضیح داده شده است.

توالی گام‌به‌گام PKCE

توالی مراحل: (1) مشتری یک code_verifier تصادفی تولید می‌کند (رشته ۴۳–۱۲۸ کاراکتری، فقط unreserved characters)، (2) مشتری code_challenge = SHA-256(code_verifier) را محاسبه می‌کند، (3) مشتری مرورگر را برای احراز هویت کاربر در Authorization Server باز می‌کند و code_challenge را ارسال می‌کند، (4) پس از احراز هویت موفق، سرور authorization code را از طریق یک scheme URI سفارشی (app deep link) به برنامه برمی‌گرداند، (5) مشتری authorization code + code_verifier را به سرور ارسال می‌کند، (6) سرور SHA-256(code_verifier) === code_challenge را بررسی کرده و Access Token + Refresh Token صادر می‌کند.

مزیت PKCE — حتی اگر مهاجم authorization code را در scheme URI رهگیری کند، بدون code_verifier که فقط برای مشتری قانونی شناخته شده است، نمی‌تواند آن را با توکن مبادله کند. در برنامه‌های موبایل برای باز کردن مرورگر باید از Chrome Custom Tabs (Android) یا ASWebAuthenticationSession (iOS) استفاده کرد — این تضمین می‌کند که مرورگر سیستم به code_verifier از حافظه برنامه دسترسی ندارد.

پیاده‌سازی OAuth 2.0 در Android از طریق AppAuth

AppAuth یک پیاده‌سازی مرجع OAuth 2.0 و OpenID Connect برای برنامه‌های بومی است که توسط IETF توصیه شده است. این کتابخانه از PKCE، Chrome Custom Tabs، scheme URI سفارشی برای بازگشت authorization code و به‌روزرسانی خودکار توکن‌ها پشتیبانی می‌کند. AppAuth برای Android از طریق وابستگی `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 برای احراز هویت
startActivityForResult(intent, REQUEST_CODE_AUTH)

پس از دریافت authorization code (onActivityResult)، برنامه آن را از طریق TokenRequest با Access Token و Refresh Token مبادله می‌کند. توکن‌ها در SharedPreferences با رمزنگاری از طریق EncryptedSharedPreferences (Android Security Crypto) ذخیره می‌شوند. Refresh Token باید در KeyStore — فروشگاه کلید سخت‌افزاری غیرقابل خواندن برای سایر برنامه‌ها — ذخیره شود. با هر بار انقضای Access Token، برنامه از Refresh Token برای دریافت توکن جدید استفاده می‌کند — کاربر نیازی به احراز هویت مجدد ندارد.

// مبادله authorization code با توکن‌ها
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 و Refresh Token دریافت شد
        val accessToken = tokenResp.accessToken
        val refreshToken = tokenResp.refreshToken
        // ذخیره در EncryptedSharedPreferences
        saveTokens(accessToken, refreshToken)
    }
}

کد ارائه‌شده چرخه کامل OAuth 2.0 با PKCE را نشان می‌دهد: ایجاد پیکربندی سرور از طریق OpenID Connect Discovery، تولید درخواست احراز هویت با code_verifier، راه‌اندازی Chrome Custom Tab، دریافت authorization code از طریق scheme URI سفارشی و مبادله کد با توکن‌ها از طریق Token Request. مدیریت انقضای Access Token مهم است: در پاسخ HTTP 401 از Resource Server، برنامه باید از Refresh Token Flow برای دریافت Access Token جدید استفاده کرده و درخواست را دوباره اجرا کند.

امنیت OAuth 2.0: حملات معمول و محافظت

OAuth 2.0 یک پروتکل پیچیده با نقاط حمله متعدد است. IETF Security BCP (RFC 9700) بیش از ۲۰ کلاس آسیب‌پذیری OAuth 2.0 را توصیف می‌کند. برای برنامه‌های موبایل، بحرانی‌ترین آنها عبارتند از: رهگیری authorization code از طریق scheme URI سفارشی، حملات CSRF به endpointهای callback، سرقت Refresh Token از ذخیره‌ساز ناامن و جعل مشتری از طریق intent interception.

محافظت در برابر این حملات شامل اقدامات اجباری است: (1) PKCE با S256 code_challenge — حتی در صورت رهگیری scheme URI از رهگیری authorization code جلوگیری می‌کند؛ (2) استفاده از nonce یا state parameter برای جلوگیری از CSRF — سرور بررسی می‌کند که authorization code با درخواست اصلی مطابقت دارد؛ (3) ذخیره Refresh Token فقط در KeyStore (Android) یا Keychain (iOS) — نه در SharedPreferences و نه در UserDefaults؛ (4) استفاده از TLS با Certificate Pinning برای محافظت MITM در سطح انتقال؛ (5) بررسی redirect_uri — سرور احراز هویت باید مطابقت با URI ثبت‌شده را به‌طور دقیق اعتبارسنجی کند.

توصیه‌های اضافی از IETF: برنامه‌های موبایل باید از AppAuth یا کتابخانه‌های مشابهی که ممیزی امنیتی شده‌اند استفاده کنند؛ برای OAuth به WebView اعتماد نکنند (WebView داده‌ها را از برنامه اصلی جدا نمی‌کند)؛ چرخش خودکار Refresh Token را پیاده‌سازی کنند (یک Refresh Token می‌تواند یک‌بار استفاده شود)؛ Certificate Pinning را از طریق TrustManager برای Android و URLSession برای iOS اضافه کنند. OpenID Connect Discovery (well-known endpoint) به تعیین خودکار endpointهای صحیح سرور احراز هویت و جلوگیری از تغییر مسیر به صفحات فیشینگ کمک می‌کند.