OpenID Connect: ما هو، بروتوكول المصادقة والترخيص

ما هو OpenID Connect؟

OpenID Connect (OIDC) هو بروتوكول مصادقة مفتوح مبني كامتداد فوق OAuth 2.0. إنه يوحد ما كان ينقص OAuth 2.0: التحقق من هوية المستخدم. إذا كان OAuth 2.0 يجيب على السؤال “أي تطبيق لديه الوصول؟”، فإن OIDC يجيب على “من هو هذا المستخدم بالضبط؟”.

يستخدم البروتوكول ID Token — JSON Web Token (JWT) يحتوي على مجموعة من المطالبات: معرف فريد للموضوع، البريد الإلكتروني، الاسم، الصورة الرمزية، طوابع زمنية للإصدار والانتهاء. يمكن للتطبيق العميل التحقق من ID Token تشفيريًا — يوقع الخادم الرمز باستخدام RS256 أو ES256، ويتحقق العميل من التوقيع مقابل المفتاح العام الذي تم الحصول عليه من خلال نقطة نهاية JWKS.

وفقًا Auth0, 2025، أكثر من 78% من التطبيقات المحمولة التي تستخدم المصادقة الخارجية توظف OIDC من خلال Google Sign-In أو Sign in with Apple. وهذا يجعل البروتوكول المعيار الفعلي لتسجيل الدخول الاجتماعي والمصادقة المؤسسية.

كيف يعمل OpenID Connect

OpenID Connect يحدد عدة تدفقات (flows) حسب نوع العميل. للتطبيقات المحمولة، المعيار هو Authorization Code Flow مع Proof Key for Code Exchange (PKCE) — يوفر الأمان حتى بدون client secret على الجهاز.

مزود الهوية ودوره

مزود الهوية (IdP) هو خادم يقوم بمصادقة المستخدم وإصدار الرموز. في نظام OIDC، يوفر IdP نقطتي نهاية رئيسيتين: Authorization Endpoint لتسجيل دخول المستخدم و Token Endpoint لاستبدال الكود برموز. يكتشف العميل عناوين نقاط النهاية هذه من خلال Discovery URL — المسار القياسي /.well-known/openid-configuration، الذي يعيد مستند JSON مع تكوين كامل للمزود.

ينشر كل IdP JWKS الخاص به (JSON Web Key Set) — مجموعة من المفاتيح العامة للتحقق من توقيع ID Token. يخزن العميل هذه المفاتيح مؤقتًا ويستخدمها للتحقق من كل رمز مستلم دون الاتصال بالخادم.

Authorization Code Flow مع PKCE

Authorization Code Flow هو عملية من ثلاث خطوات. أولاً، يولد التطبيق المحمول code verifier (سلسلة عشوائية من 43–128 حرفًا) وhash الخاص به — code challenge. يفتح التطبيق متصفحًا أو WebView بعنوان URL يحتوي على client_id وredirect_uri وscope (openid profile email) وcode challenge. يدخل المستخدم بيانات الاعتماد في صفحة IdP ويؤكد الموافقة. يعيد IdP توجيه المتصفح إلى التطبيق مع authorization code.

في الخطوة الثانية، يرسل التطبيق authorization code وcode verifier وclient_id إلى Token Endpoint للخادم. يتحقق الخادم من code verifier مقابل code challenge المخزن ويعيد ID Token وAccess Token واختياريًا Refresh Token. في الخطوة الثالثة، يتحقق التطبيق من ID Token: يتحقق من صحة التوقيع مقابل JWKS، ويتحقق من issuer (iss) وaudience (aud) ووقت الانتهاء (exp). إذا نجح التحقق، يعتبر المستخدم موثقًا.

PKCE (Proof Key for Code Exchange) يزيل ثغرة متأصلة في Authorization Code Flow القياسي للعملاء العامين. نظرًا لأن التطبيق المحمول لا يمكنه تخزين client secret بأمان، يمكن للمهاجم الذي يعترض authorization code استبداله برموز. Code verifier يحل هذه المشكلة: حتى إذا تم اعتراض الكود، بدون code verifier الأصلي يكون الاستبدال مستحيلاً. تتطلب OAuth Security Best Practices (RFC 9700) PKCE لجميع العملاء العامين، بما في ذلك التطبيقات المحمولة.

ID Token و Access Token

يعيد OpenID Connect رمزين مختلفين جوهريًا: ID Token و Access Token. ID Token هو دائمًا JWT يمكن للعميل قراءته والتحقق منه بنفسه. يحتوي على معلومات المستخدم ويستخدم للمصادقة، وليس للوصول إلى API.

هيكل ID Token

ID Token يتكون من header وpayload وsignature، مشفرة بـ Base64 ومفصولة بنقاط. يحتوي header على alg (خوارزمية التوقيع) و kid (معرف المفتاح). يتضمن payload مطالبات إلزامية: iss (issuer)، sub (subject — معرف فريد للمستخدم)، aud (audience — معرف العميل)، exp (expiration)، iat (issued at). تشمل المطالبات الاختيارية name وemail وpicture وlocale.

مثال على payload مُفكك لـ ID Token من Google:

{
  "iss": "https://accounts.google.com",
  "sub": "1234567890",
  "aud": "my-app-123.apps.googleusercontent.com",
  "exp": 1812345678,
  "iat": 1812342078,
  "name": "Ivan Petrov",
  "email": "ivan@example.com"
}

Access Token هو رمز غير شفاف (سلسلة عشوائية) أو JWT يمرره العميل في طلبات API. على عكس ID Token، access token ليس مخصصًا للقراءة من قبل العميل — تنسيقه ومحتواه معروفان فقط لخادم الموارد وخادم الترخيص. Access Token له نطاق (scope) — تقييد للأذونات — وعمر قصير، عادة 15–60 دقيقة.

الاختلافات بين OpenID Connect و OAuth 2.0

OAuth 2.0 هو إطار ترخيص يحدد كيف يحصل التطبيق على الوصول إلى موارد المستخدم. OpenID Connect هو امتداد يضيف المصادقة إلى هذه العملية. الفرق الرئيسي: OAuth 2.0 لا يحدد تنسيق الرمز ولا يعطي التطبيق طريقة لمعرفة من قام بالطلب بالضبط.

متى تختار OpenID Connect

OpenID Connect ضروري عندما يحتاج التطبيق إلى معرفة المستخدم، وليس فقط الوصول إلى بياناته. إذا كنت تستخدم “تسجيل الدخول مع Google” أو “تسجيل الدخول مع Apple” — فهذا هو OIDC. إذا كان تطبيقك يستدعي API خارجي نيابة عن المستخدم دون الحاجة إلى معرفة هويته — OAuth 2.0 الخالص كافٍ. للأنظمة المؤسسية مع Single Sign-On (SSO)، الاختيار واضح: فقط OpenID Connect، لأنه يوفر تسجيل خروج موحد وإدارة جلسات.

تنفيذ OpenID Connect في التطبيقات المحمولة

دمج OpenID Connect في تطبيق محمول يتطلب اختيار المكتبة المناسبة وتكوين التدفق بشكل صحيح. لنظام Android، استخدم مدير بيانات الاعتماد (AndroidX Credentials) أو مكتبة AppAuth. لنظام iOS، استخدم إطار AuthenticationServices مع ASWebAuthenticationSession.

مثال كود بلغة Kotlin (Android)

أدناه مثال لبدء Authorization Code Flow باستخدام مكتبة AppAuth-Android. ينشئ التطبيق طلب ترخيص، ويفتح متصفحًا لتسجيل دخول المستخدم، ويعالج callback مع الرموز.

val authRequest = AuthorizationRequest.Builder(
    serviceConfig,
    clientId,
    "code",
    Uri.parse("com.example.app:/oauth")
)
.setScope("openid profile email")
.build()

val authService = AuthorizationService(this)
val intent = authService.getAuthorizationRequestIntent(authRequest)
startActivityForResult(intent, REQUEST_CODE)

override fun onActivityResult(
    requestCode: Int,
    resultCode: Int,
    data: Intent?
) {
    if (requestCode == REQUEST_CODE) {
        val response = AuthorizationResponse.fromIntent(data)
        if (response?.authorizationCode != null) {
            exchangeCodeForTokens(response.authorizationCode)
        }
    }
}

مثال كود بلغة Swift (iOS)

ASWebAuthenticationSession من Apple يوفر متصفحًا مدمجًا لتدفق OIDC مع دعم SSO من خلال iCloud Keychain. تبدأ الجلسة بعنوان URL للترخيص، ويتم التعامل مع callback من خلال completion handler.

عند اختيار مكتبة لـ OpenID Connect، ضع في اعتبارك دعم PKCE المدمج: AppAuth-Android و AppAuth-iOS يدعمان PKCE افتراضيًا. يستخدم Firebase Authentication OIDC داخليًا لـ Google Sign-In و Sign in with Apple و Microsoft — لا يحتاج المطور إلى تنفيذ التدفق يدويًا. للأنظمة المؤسسية مع IdP مخصص (مثل Keycloak أو Okta)، يبقى AppAuth الخيار القياسي مع تحكم كامل في التكوين ومعالجة الأخطاء.

let authURL = URL("https://accounts.google.com/o/oauth2/v2/auth")!
let callbackURL = URL("com.example.app://oauth")!

let session = ASWebAuthenticationSession(
    url: authURL,
    callbackURLScheme: callbackURL.scheme!
) { url, error in
    guard let url = url else { return }
    let components = URLComponents(url: url)
    let code = components?.queryItems?.first(where: { $0.name == "code" })?.value
    if let code = code { exchangeCode(code) }
}
session.start()