OAuth 2.0: ما هو وكيف يعمل بروتوكول التفويض

ما هو OAuth 2.0؟

OAuth 2.0 هو بروتوكول تفويض مُعرّف في IETF RFC 6749 يسمح للتطبيقات الخارجية بالحصول على وصول محدود إلى موارد المستخدم دون الكشف عن اسم المستخدم وكلمة المرور. يحل البروتوكول مشكلة أساسية في نموذج كلمة المرور: التطبيق الذي تثق به بكلمة مرورك يحصل على وصول غير مقيد إلى جميع بيانات الحساب. يستبدل OAuth 2.0 هذا النهج بإصدار رمز مؤقت مع نطاق وصول محدد بشكل صريح.

بنية OAuth 2.0 هي التفويض المفوض. المستخدم (Resource Owner) يفوض تطبيقاً (Client) للوصول إلى بياناته المخزنة على خادم الموارد (Resource Server) عبر وسيط: خادم التفويض (Authorization Server). يصدر خادم التفويض Access Token: سلسلة تشفيرية يقدمها التطبيق لخادم الموارد للوصول إلى البيانات. فرق مهم بين OAuth 2.0 و SAML و OpenID Connect: OAuth 2.0 يحل مهمة التفويض (ما هو مسموح به)، وليس المصادقة (من هو المستخدم). للمصادقة فوق OAuth 2.0 يُبنى بروتوكول OpenID Connect (OIDC).

البروتوكول مدعوم من جميع المنصات الرئيسية. تستخدم 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 هو رمز قصير العمر (عادة 15–60 دقيقة) يُقدم لخادم الموارد مع كل طلب بيانات. 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)، ويتحقق الخادم من التطابق عند استبدال الرمز. يمنع هذا اعتراض authorization code بين التطبيق والخادم
• Client Credentials: يُستخدم للتفويض من آلة إلى آلة حيث يكون العميل معروفاً ومصادقاً عليه. يحصل التطبيق على رمز باستخدام client_id و client_secret. لا يتطلب مشاركة المستخدم. السيناريو النموذجي: تطبيق خادم يصل إلى API لمعالجة البيانات على دفعات
• Device Authorization Grant: للأجهزة بدون متصفح (Smart TV، IoT). ينتقل المستخدم إلى رابط على جهاز آخر ويدخل رمزاً. يُستخدم مثلاً عند تفويض Netflix على التلفزيون عبر الهاتف الذكي
• Resource Owner Password Credentials: Grant Type مهمل محظور بموجب OAuth Security BCP. تُنقل كلمة المرور مباشرة إلى العميل، مما ينتهك مبدأ المصادقة بدون معرفة. يُستخدم فقط للترحيل من الأنظمة القديمة

Authorization Code Flow مع PKCE للتطبيقات المحمولة

Authorization Code Flow مع PKCE هو التكوين الموصى به لـ OAuth 2.0 لتطبيقات الجوال الأصلية. يضيف PKCE (Proof Key for Code Exchange) طبقة حماية إضافية تمنع هجمات اعتراض authorization code. البروتوكول موصوف في IETF RFC 7636.

تسلسل خطوات PKCE

تسلسل الخطوات: (1) يولد العميل code_verifier عشوائياً (سلسلة من 43–128 حرفاً باستخدام أحرف غير محجوزة فقط)، (2) يحسب العميل code_challenge = SHA-256(code_verifier)، (3) يفتح العميل متصفحاً لتفويض المستخدم على Authorization Server، ويمرر code_challenge، (4) بعد التفويض الناجح، يعيد الخادم authorization code إلى التطبيق عبر مخطط URI مخصص (deep link)، (5) يرسل العميل authorization code + code_verifier إلى الخادم، (6) يتحقق الخادم من SHA-256(code_verifier) === code_challenge ويصدر Access Token + Refresh Token.

ميزة PKCE: حتى إذا اعترض المهاجم authorization code في مخطط 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 ومخططات 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)، يستبدله التطبيق بـ Access Token و Refresh Token عبر TokenRequest. تُحفظ الرموز في 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 عبر مخطط URI مخصص، واستبدال الرمز برموز عبر Token Request. من المهم معالجة انتهاء صلاحية Access Token: عند استلام استجابة HTTP 401 من Resource Server، يجب على التطبيق استخدام Refresh Token للحصول على Access Token جديد وإعادة تنفيذ الطلب.

أمان OAuth 2.0: الهجمات النموذجية والحماية

OAuth 2.0 هو بروتوكول معقد مع العديد من نواقل الهجوم. يصف IETF Security BCP (RFC 9700) أكثر من 20 فئة من ثغرات OAuth 2.0. بالنسبة للتطبيقات المحمولة، الأكثر خطورة هي: اعتراض authorization code عبر مخططات URI المخصصة، هجمات CSRF على نقاط نهاية الاستدعاء، سرقة Refresh Token من تخزين غير آمن، وانتحال العميل عبر اعتراض النية.

تشمل الحماية من هذه الهجمات إجراءات إلزامية: (1) PKCE مع S256 code_challenge: يمنع اعتراض authorization code حتى عند اعتراض مخطط URI؛ (2) استخدام معامل nonce أو state لمنع CSRF: يتحقق الخادم من أن authorization code يتوافق مع الطلب الأصلي؛ (3) تخزين Refresh Token فقط في KeyStore (Android) أو Keychain (iOS): ليس في SharedPreferences أو UserDefaults؛ (4) استخدام TLS مع Certificate Pinning للحماية من MITM في طبقة النقل؛ (5) التحقق من redirect_uri: يجب على خادم التفويض التحقق بدقة من تطابقه مع URI المسجل.

توصيات إضافية من IETF: يجب على التطبيقات المحمولة استخدام AppAuth أو مكتبات مماثلة خضعت لتدقيقات أمنية؛ عدم الاعتماد على WebView لـ OAuth (لا يعزل WebView البيانات عن التطبيق الرئيسي)؛ تنفيذ التدوير التلقائي لـ Refresh Token (يمكن استخدام كل Refresh Token مرة واحدة فقط)؛ إضافة Certificate Pinning عبر TrustManager لنظام Android و URLSession لنظام iOS. يساعد OpenID Connect Discovery (نقطة نهاية well-known) في تحديد نقاط نهاية خادم التفويض الصحيحة تلقائياً وتجنب إعادة التوجيه إلى صفحات التصيد.