تدفقات OAuth في Salesforce: إزاي تختار تصميم المصادقة الصحيح

إزاي تختار تدفق OAuth الصحيح في Salesforce؟ وجّه الإنسان عبر Authorization Code Flow مع PKCE، واربط مهمة server-to-server بـ JWT Bearer Flow (أو Client Credentials Flow)، ولا تعد أبدًا إلى اسم المستخدم وكلمة المرور وsecurity token لمجرد أنها أسرع في الإعداد. هذا الاختصار الأخير بدأ عدّه التنازلي. أعلنت Salesforce إيقاف OAuth 2.0 username-password flow للـ connected apps في Spring '26، وأدرجته في البداية للتطبيق مع إطلاق Winter '27، ثم ثبّتته على تاريخ واحد محدد: 20 فبراير 2027. هذا التاريخ واحد لكل org على المنصة، ولا يرتبط بعطلة نهاية أسبوع ترقية الـ instance لديك، فلا توجد نافذة متدرجة تختبئ خلفها. والـ orgs التي أُنشئت في Summer '23 أو بعدها تحظر هذا التدفق بالفعل. وإذا أخطأت في التصميم، فإما أن تمنع تكاملات مشروعة من الوصول إلى الـ org، أو تترك بيانات اعتماد طويلة العمر في مكان يمكن للمهاجم أن يجدها فيه.

إزاي تختار تدفق OAuth الصحيح في Salesforce؟

كل قرار OAuth يبدأ بسؤال واحد: هل الذي يفوّض هذا الاتصال شخص أم آلة؟

إذا كان هناك شخص حاضر، فوجّهه عبر Authorization Code Flow مع PKCE (Proof Key for Code Exchange)، الذي توثقه Salesforce باسم OAuth 2.0 web server flow مع امتداد PKCE، وتسميه الآن البديل الموصى به لتسجيلات الدخول القائمة على المستخدم. يربط PKCE رمز التفويض بالعميل الذي طلبه، فيصبح الرمز المعترَض عديم الفائدة للمهاجم. فضّله على OAuth 2.0 Device Flow، الذي تتراجع عنه Salesforce: فقد أزالت دعم Device Flow من الـ connected app المثبت تلقائيًا لـ Data Loader في 2 سبتمبر 2025، وتخلى Data Loader 64.1.0 عن Device Flow وUser-Agent Flow معًا. كان كلاهما سهل الاستغلال لأنه يمكن تشغيله بما لا يزيد كثيرًا عن client ID، وهو هدف مفضل للهندسة الاجتماعية.

وإذا لم يكن هناك شخص حاضر، مثل مهمة ETL ليلية أو middleware يدفع سجلات إلى Salesforce، فاختر تدفق server-to-server: إما JWT Bearer Flow أو Client Credentials Flow. كلاهما يسمح لخدمة خلفية بالمصادقة دون متصفح أو جلسة لإعادة التوجيه. وهذا الاختيار نفسه يكمن تحت معظم أنماط هندسة التكامل التي تتوسع فعلًا، لأن تصميم المصادقة يجب أن يصمد أمام كل إعادة محاولة وانتهاء مهلة وتدوير لبيانات الاعتماد تفرضه هذه الأنماط.

JWT Bearer أم Client Credentials: أي تدفق server-to-server تختار؟

كلا التدفقين يصادق على التطبيق نفسه دون مستخدم، لكنهما يختلفان في طريقة التعامل مع الأسرار.

• JWT Bearer Flow يصادق بشهادة موقعة رقميًا بدلًا من سر مشترك. لا يوجد client secret في ملف إعدادات يمكن أن يتسرب، والـ assertion الموقع قصير العمر، وتدوير المفتاح يعني استبدال شهادة وليس إعادة نشر الكود. اختره عندما تريد أقوى وضع أمني وتستطيع إدارة مفتاح خاص.
• Client Credentials Flow يستبدل consumer key وconsumer secret بـ access token ويعمل باسم مستخدم تكامل محدد. إعداده أبسط، لكن السر هنا bearer credential: أي شخص يعترضه يستطيع انتحال هوية التكامل، لذلك يجب تخزينه وتدويره بانضباط حقيقي.

أيًا كان اختيارك، حدد صلاحيات مستخدم التشغيل أو التكامل بدقة عبر profile وpermission sets مخصصة، بدلًا من منح صلاحيات admin واسعة من باب السهولة. حساب الآلة الذي لا يصل إلا إلى الكائنات التي يحتاجها هو الفرق بين حادث محدود واختراق الـ org بالكامل.

Connected Apps أم External Client Apps: ما الذي تغير في 2026؟

تقسّم Salesforce الـ connected app التقليدي إلى نوعين مصممين لغرض محدد، والجدول الزمني الآن يفرض القرار. اعتبارًا من Spring '26، تحظر Salesforce إنشاء connected apps جديدة عبر الواجهة والـ API معًا، والاستثناء الوحيد هو تثبيت الحزم، وتوصي باستخدام external client apps بدلًا منها. تستمر الـ connected apps الحالية في العمل أثناء التغيير وبعده، فلا شيء يتعطل في الـ org خلال عطلة نهاية أسبوع الترقية. وإذا كنت مضطرًا فعلًا لإنشاء connected app جديد، فيمكن لدعم Salesforce إعادة تفعيل الإنشاء لمؤسستك حاليًا، لكن Salesforce أعلنت أن هذه الإمكانية ستُزال في إصدار لاحق، فهي جسر وليست خطة طويلة الأمد.

الـ external client apps هي المسار الأحدث والموصى به لأي نظام خارجي يصادق مع Salesforce عبر OAuth، بما في ذلك middleware الخاص بك وأدوات ETL وتكاملات الشركاء. وهي تتبنى موقفًا أكثر صرامة عن قصد: تدعم تدفقات OAuth الآمنة فقط وتستبعد username-password flow تمامًا. كما تدعم Metadata API بالكامل وتبقي consumer secrets خارج المكونات المُغلَّفة، مما يجعل إدارتها أسهل بكثير عبر إدارة الإصدارات ومسارات CI/CD مقارنة بالـ connected app القديم.

الخلاصة العملية في مراجعة المعمارية: اجعل external client app هو الخيار الافتراضي للتكاملات الجديدة، واحتفظ بالـ connected apps للحالات الخاصة بـ Salesforce التي ما زالت تحتاجها، مثل canvas وmobile publishing. واللجوء إلى connected app قديم بحكم العادة يعني الآن الاصطدام بقيد الإنشاء في مشروعك التالي.

أين تقع Named Credentials في تصميم تكامل آمن؟

تحل Named Credentials مشكلة مختلفة: الـ callouts الصادرة من Salesforce إلى الأنظمة الخارجية، سواء من Apex أو Flow. بدلًا من كتابة عنوان endpoint وتفاصيل OAuth مباشرة داخل class، تسجل Named Credential مرة واحدة وتشير إليه بالاسم، على مستوى المستخدم أو الـ org كله، وتتولى Salesforce تبادل الـ token وتجديده في الخلفية.

هذا مهم للمراجعة الأمنية لأنه يزيل بيانات الاعتماد من الكود تمامًا. سواء كانت آلية المصادقة الأساسية JWT Bearer أو Client Credentials، يبقى السر أو المفتاح خارج كود التكامل، فيتم التدوير في مكان واحد بدلًا من البحث داخل Apex classes وتعريفات Flow. وعندما تربط Salesforce بنظام سجلات ثقيل مثل ERP، هذا ما يبقي أنماط تكامل Salesforce وSAP قابلة للتدقيق بدلًا من كومة كلمات مرور مدمجة.

إزاي تنقل تكاملات username-password القديمة إلى تدفقات OAuth الحديثة؟

معظم الـ orgs التي نراجعها ما زال فيها تكامل واحد على الأقل يصادق باسم مستخدم وكلمة مرور وsecurity token، وأحيانًا من سكربت لا يتذكر أحد أنه كتبه. وقد تأجل موعد 20 فبراير 2027 مرة بالفعل عن قائمة تطبيق Winter '27، فتعامل مع الوقت الإضافي كوقت للترحيل وليس كمهلة. لا توجد رسالة تحذير في الواجهة: في تاريخ الإيقاف، يتوقف التكامل القائم على كلمة المرور ببساطة عن استلام access token ويبدأ في إرجاع خطأ مصادقة. يبدو الترحيل المنظم هكذا:

• اجرد كل مستخدم تكامل وكل profile مفعّل له API لتعرف أين ما زالت تسجيلات الدخول بكلمة المرور مستخدمة.
• صنّف كل تكامل كـ "مستخدم حاضر" أو server-to-server، ثم اربطه بـ Authorization Code Flow مع PKCE أو JWT Bearer Flow أو Client Credentials Flow.
• سجّل External Client App مخصصًا لكل تكامل بدلًا من مشاركة تطبيق واحد بين أنظمة لا علاقة بينها.
• انقل الـ callouts الصادرة خلف Named Credentials حتى تبقى الأسرار خارج قاعدة الكود.
• غيّر كلمة مرور مستخدم التكامل القديم وألغِ وصوله إلى الـ API بعد انتقال حركة البيانات بالكامل.

نفّذ الانتقال تكاملًا بعد تكامل، وتأكد من مصادقة كل اتصال في sandbox قبل لمس بيانات الاعتماد التي يعتمد عليها الإنتاج. وتصميم المصادقة نفسه هو أساس أنماط أحدث مثل تشغيل إجراءات CRM من مركز agentic، حيث تمتد هوية آلة واحدة عبر إجراءات كثيرة، وسيكون تسريب السر أشد ضررًا.

هذا نوع العمل الذي يتولاه فريق الاستشارات لدينا بانتظام. إذا كان الـ org لديك ما زال يشغّل تكاملات قائمة على كلمات المرور، فيمكننا رسم مسار الترحيل قبل 20 فبراير 2027 بوقت كافٍ، حتى لا يتحول الأمر إلى حالة طوارئ. تواصل معنا لمناقشة إعداداتك.

FAQ

متى يتوقف username-password OAuth flow في Salesforce؟

نقلت Salesforce الإيقاف من إطلاق Winter '27 إلى تاريخ واحد محدد، 20 فبراير 2027، ينطبق على كل الـ orgs في وقت واحد بدلًا من اتباع عطلة نهاية أسبوع الترقية لكل org. والـ orgs التي أُنشئت في Summer '23 أو بعدها تحظر هذا التدفق بالفعل. انقل التكاملات المتأثرة إلى web server flow مع PKCE أو JWT Bearer Flow أو Client Credentials Flow قبل ذلك.

هل ما زال بإمكاني إنشاء Connected App جديد في 2026؟

تقيد Salesforce إنشاء connected apps جديدة اعتبارًا من Spring '26 وتوصي بـ external client apps بدلًا منها. تستمر الـ connected apps الحالية في العمل، ويمكنك طلب استثناء عبر دعم Salesforce إذا كنت تحتاج إلى ذلك فعلًا.

ما الفرق بين تدفقي JWT Bearer وClient Credentials؟

كلاهما تدفق server-to-server دون مستخدم حاضر. يصادق JWT Bearer بشهادة موقعة وليس فيه سر مشترك يمكن أن يتسرب، بينما يستبدل Client Credentials مفتاح consumer وسره ويعمل باسم مستخدم تكامل محدد، وهو أبسط لكنه يعتمد على bearer secret يجب تخزينه وتدويره بعناية.

هل يجب أن تستخدم التكاملات الجديدة Connected Apps أم External Client Apps؟

اجعل external client apps الخيار الافتراضي للتكاملات الخارجية الجديدة. فهي تدعم تدفقات OAuth الآمنة فقط، وتعمل بالكامل مع Metadata API في CI/CD، وهي المسار الذي توصي به Salesforce الآن. احتفظ بالـ connected apps للحالات الخاصة بـ Salesforce مثل canvas وmobile publishing.

هل تحل Named Credentials محل تدفقات OAuth؟

لا. تدير Named Credentials مصادقة الـ callouts الصادرة ويمكنها استخدام تدفقات OAuth مثل JWT Bearer في الخلفية، فتبقي الأسرار خارج Apex وFlow دون أن تحل محل التدفق نفسه.