لماذا يحتاج منتجك إلى OAuth 2.0 و OIDC — خاصة في عصر الذكاء الاصطناعي

منذ البداية، تم بناء Logto على اعتقاد قوي في المعايير المفتوحة. لقد اخترنا اتباع بروتوكولات مثل OIDC، وOAuth 2.0، وSAML — ليس فقط لأنها مستخدمة على نطاق واسع، بل لأنها تمثل ممارسات آمنة وموثوقة عبر الصناعة. كان الأمان دائمًا أولوية بالنسبة لنا. وكذلك الاستمرار في الروح المفتوحة المصدر، والتزام بأفضل الممارسات في إدارة هوية العميل والمصادقة الحديثة.

ولكننا تعلمنا أيضًا شيئًا على طول الطريق:

OAuth 2.0 و OIDC ليسا سهلاً للجميع. بالنسبة للمطورين الجدد على هذه البروتوكولات، قد تبدو المفاهيم غريبة وأحيانًا حتى غير بديهية. وقد أدى ذلك إلى تحديات حقيقية أثناء عملنا على كيفية تبسيط تجربة المطور دون المساس بالأمان.

برز أمران:

1. على الرغم من أننا عملنا بجهد لجعل التكامل سلسًا قدر الإمكان، لا يزال هناك منحنى تعلم حول فهم المفاهيم الأساسية مثل رموز المعرفات، ورموز الدخول، وكيفية عملها.
2. سؤال شائع نتلقاه هو: "هل يمكنني تخطي إعادة التوجيه على شاشة تسجيل الدخول؟" للأسف، إعادة التوجيه هي جزء أساسي من كيف يعمل OIDC وضرورية للمصادقة الآمنة.

سؤال شائع من مستخدمي Discord لدينا (مع طمس معرفاتهم وصورهم الرمزية للخصوصية).

كل قرار يأتي مع التنازلات — ولكن أحيانًا، يكون الخيار الذي اتخذته في وقت مبكر ذا قيمة خاصة عندما تظهر حالات استخدام جديدة. ونحن الآن ندخل عصرًا جديدًا: عصر الذكاء الاصطناعي.

في هذا المقال، سأستكشف متى يجب على منتجك استخدام OIDC و OAuth 2.0، ومتى قد لا يحتاج إليهما، ولماذا كنت دائمًا أدعو إلى اعتماد هذه المعايير المفتوحة منذ البداية — خاصة إذا كنت تبني عملاً حقيقيًا وتختار حلاً لإدارة هوية العميل (CIAM). سأشرح أيضًا لماذا يجعل صعود الذكاء الاصطناعي هذا القرار أكثر أهمية من أي وقت مضى.

ما الذي يفعله OAuth 2.0 حقًا (بمقارنة بسيطة)#

بالنسبة للقراء الذين ليسوا مطلعين كثيرًا على OAuth 2.0، دعني أنتهج لحظة لأقوم بمراجعة بعض المفاهيم الأساسية مرة أخرى — فقط لتوضيح الأمور.

OAuth 2.0 مخصص للترخيص المفوض: OAuth 2.0 هو بروتوكول معيار صناعي للترخيص — يسمح لخدمة واحدة بالوصول إلى الموارد نيابة عن خدمة أخرى مع موافقة مالك الموارد.

في سيناريو OAuth، يمنح المستخدم (مالك الموارد) تطبيق العميل وصولًا محدودًا (أذونات محددة) إلى API أو خادم موارد، دون مشاركة كلمة المرور الخاصة بهم. يحدد OAuth كيفية طلب وإصدار رموز الدخول التي يمكن للعميل استخدامها لاستدعاء APIs المحمية. كان هذا بمثابة تغيير جذري مقارنة بالأيام الأولى عندما قد تطلب التطبيقات بيانات اعتمادك للوصول إلى خدمة أخرى (وهو خطر أمني كبير). مع OAuth 2.0، يوافق المستخدمون على وصول محدد ويحصل العميل على رمز مع الأذونات والمدة اللازمة فقط — لا يتم تبادل كلمات المرور، مما يحسن الأمان بشكل كبير.

فكر في OAuth 2.0 مثل تسجيل الوصول إلى فندق.

أنت (المستخدم) مالك الغرفة (بياناتك). ولكن بدلًا من إعطاء شخص ما مفتاح غرفتك (كلمة المرور الخاصة بك)، تذهب إلى مكتب الاستقبال وتطلب بطاقة وصول مؤقتة (رمز دخول) تعمل فقط لضيفك أو صديقك للدخول إلى الجيم أو حمام السباحة — وليس إلى الغرفة بالكامل.

يصدر موظفو الفندق (نظام OAuth) هذه البطاقة المحدودة بقواعد محددة:

• تعمل فقط للجيم (مورد معين).
• صالحة لفترة قصيرة.
• لا تسمح لأحد بدخول غرفتك.

بهذه الطريقة، لا يتعين عليك التخلي عن مفتاحك الرئيسي — ويبقى النظام آمنًا حتى لو حصل شخص آخر على تلك البطاقة المحدودة.

لنلقي نظرة على مثال آخر. يتم استخدام OAuth 2.0 على نطاق واسع في سيناريو تسجيل الدخول الاجتماعي.

لنقل أنك تقوم بالتسجيل في تطبيق جديد مثل Notion، وبدلًا من إنشاء اسم مستخدم وكلمة مرور جديدة، تنقر على “الاستمرار مع Google.”

إليك ما يحدث وراء الكواليس باستخدام OAuth 2.0:

1. يتم توجيهك إلى صفحة تسجيل الدخول الخاصة بـ Google، حيث تقوم بتسجيل الدخول (إذا لم تكن مسجلًا بالفعل).

2. يسأل Google:

   "هل تسمح لهذا التطبيق بعرض ملفك الشخصي الأساسي وعنوان بريدك الإلكتروني؟"

3. تنقر على "السماح"، ويرسل Google إلى التطبيق رمز دخول.

4. يستخدم التطبيق ذلك الرمز لـ:

   • تأكيد هويتك (عبر بريدك الإلكتروني ومعلومات ملفك الشخصي).
   • إنشاء حساب لك أو تسجيل دخولك — دون أن يرى كلمة مرور Google الخاصة بك.

ما الذي يفعله OIDC حقًا (بمقارنة بسيطة)#

الآن دعونا نلقي نظرة على OIDC — معيار أحدث وأكثر تقدمًا. يهدف OpenID Connect إلى الهوية والمصادقة: إنه طبقة المصادقة المبنية فوق OAuth 2.0. في حين أن OAuth 2.0 بمفرده لا يخبر التطبيق من هو المستخدم (فقط يتعلق برموز الوصول والنطاقات)، يضيف OIDC طريقة معيارية للتعامل مع تسجيل دخول المستخدم والهوية.

عند استخدام OIDC، يعمل خادم الترخيص أيضًا كمزود OpenID (مزود هوية) يصادق المستخدم ويصدر رمز المعرف الذي يحتوي على معلومات عن المستخدم ("ادعاءات الهوية").

باختصار، يجيب OAuth 2.0 على “هل يمكن لهذا العميل الوصول إلى هذا المورد؟” ويجيب OIDC على “من هو المستخدم الذي قام بتسجيل الدخول للتو؟”. معًا، يتيحان للتطبيق التحقق من هوية المستخدم ثم استخدام الرموز المصرح بها للوصول إلى APIs نيابة عن المستخدم.

لنستخدم المقارنة الفندقية لفهم OAuth 2.0 مقابل OIDC مجددًا.

تخيل أنك تقوم بتسجيل الوصول إلى فندق.

• OAuth 2.0 يشبه طلب السماح للفندق باستخدام صديقك الجيم والمسبح نيابة عنك.

  تذهب إلى مكتب الاستقبال، تقدم الإذن، ويعطي الفندق لصديقك تصريح ضيف.

  الفندق لا يهتم من الصديق — فقط بأنهم مسموح لهم باستخدام المرافق.

  👉 هذا هو OAuth: “يمكن لهذا التطبيق الوصول إلى بعض بياناتي أو خدماتي.”

• OIDC يشبه طلب الفندق التحقق من هو الشخص قبل إعطائه الوصول.

  لذا يظهر صديقك أيضًا بطاقة هوية — والآن يعرف الفندق اسمه، حالته، وأنه نزيل معتمد.

  👉 هذا هو OIDC: “من هو المستخدم، وهم الآن مسجلون.”

كيف يستخدم Logto OAuth 2.0 و OpenID Connect (OIDC)#

ميزات المصادقة الأساسية لـ Logto مبنية على OIDC (OpenID Connect)#

في جوهره، يعد Logto مزود OpenID Connect (OIDC) — معيار مبني فوق OAuth 2.0 يركز على مصادقة المستخدم الآمنة والحديثة. Logto هو حل CIAM احترافي، حيث تكون الهويات هي البنية الأساسية التي نديرها.

لقد صممنا Logto مع الأمان كأساس. هذا يعني فرض PKCE افتراضيًا، وحظر التدفقات غير الآمنة مثل التدفق الضمني، والاعتماد على إعادة التوجيه للتعامل مع تسجيل الدخول بأمان.

لماذا إعادة التوجيه؟#

تم تصميم OIDC من أجل المصادقة القائمة على المتصفح. ليست مجرد خيار تقني — بل يتعلق بتقديم تجربة آمنة ومتسقة عبر المنصات للمستخدمين. يساعد إعادة توجيه المستخدم إلى مزود الهوية (مثل Logto أو Google أو Microsoft) على جعل ذلك ممكنًا.

إليك كيف تبدو التدفق النموذجي:

1. ينقر المستخدم على "تسجيل الدخول"

   → يرسل تطبيقك المستخدمين إلى صفحة تسجيل الدخول الخاصة بـ Logto.

2. يقومون بتسجيل الدخول بأمان

   → هنا تحدث أشياء مثل MFA أو البيومترية أو تسجيل الدخول الاجتماعي.

3. يرسلهم Logto مرة أخرى

   → مع رمز آمن أو رمز ترخيص.

4. يكمل تطبيقك تسجيل الدخول

   → يتم التحقق من الرمز، ويدخل المستخدم.

هذه النمط قد يبدو بسيطًا، لكنه يجلب فوائد قوية:

• تطبيقك لا يتعامل مباشرة مع بيانات اعتماد — مما يعني تقليل المخاطر.
• من السهل إضافة ميزات مثل MFA دون تغيير شفرة التطبيق.
• يعمل بشكل رائع للجوال أيضًا:
  • تستخدم iOS ASWebAuthenticationSession
  • تستخدم Android Custom Tabs

وإذا كان منتجك يمتد إلى تطبيقات متعددة، يتيح إعادة التوجيه الدخول الموحد — يسجل المستخدمون الدخول مرة واحدة ويتنقلون بين التطبيقات دون أي عقبات.

لا يدعم Logto جمع كلمات المرور مباشرة في تطبيقك. ذلك عن قصد. لا يُوصى بتدفق ROPC من أجل أفضل الممارسات الأمنية لـ OAuth 2.0 لأسباب وجيهة — فهو أقل أمانًا وأصعب في التوسع بأمان.

يعد Logto أيضًا مزود OAuth 2.0/OIDC (مزود هوية)#

Logto هو أكثر من مجرد خادم مصادقة — إنه مزود OAuth 2.0، OpenID Connect (OIDC)، ومزود هوية (IdP) كامل. هذا يعني أنه يمكنه إدارة هويات المستخدم بأمان وإصدار رموز يمكن لبقية التطبيقات الوثوق بها.

بالإضافة إلى تمكين تجارب تسجيل الدخول لتطبيقاتك الخاصة، يدعم Logto أيضًا تكامل التطبيقات من الطرف الثالث، مما يتيح للخدمات الخارجية الاعتماد على Logto كمصدر هويتها.

ماذا يعني ذلك في الممارسة؟

باعتباره مزود هوية (IdP)، يتولى Logto التحقق من المستخدم، وإدارة بيانات الاعتماد، وإصدار الرموز المميزة للمصادقة. بمجرد دخول المستخدم، يمكن لـ Logto السماح له بالوصول إلى التطبيقات المختلفة — حتى من بائعين آخرين — دون الحاجة لتسجيل الدخول مرة أخرى. إنه نفس المفهوم خلف "تسجيل الدخول مع Google" أو "تسجيل الدخول مع Microsoft".

هناك نوعان من التطبيقات في هذا السياق:

• تطبيقات الطرف الأول: التطبيقات التي تبنيها وتتحكم فيها بالكامل، متكاملة مباشرة مع Logto.
• تطبيقات الطرف الثالث: الخدمات الخارجية التي تبنيها الشركاء أو المطورين خارج مؤسستك.

تمكن Logto المستخدمين لديك من تسجيل الدخول إلى هذه التطبيقات الطرف الثالث باستخدام حساباتهم الحالية في Logto — مثلما يسجل المستخدمون المؤسسيون الدخول إلى أدوات مثل Slack باستخدام بيانات اعتماد Google Workspace الخاصة بهم. هذا يتيح لك:

• تقديم الدخول الموحد (SSO) عبر نظامك البيئي.
• بناء منصة مفتوحة، حيث يمكن للمطورين الخارجيين إضافة "تسجيل الدخول مع Logto" إلى تطبيقاتهم.

متى تحتاج حقًا إلى OAuth 2.0 و OIDC؟#

1. إذا كنت تستخدم Auth0 (أو ما شابه) سابقًا: Auth0 هو بالفعل مزود OAuth 2.0 و OIDC. يدير تسجيل دخول المستخدمين، وإصدار الرموز، ويتكامل مع APIs أو التطبيقات الخاصة بك.
2. تفويض M2M: خادم إلى خادم (تدفق بيانات الاعتمادات العميل) الآلات (أو الخدمات الخلفية) بحاجة إلى التواصل بأمان دون وجود مستخدم.
3. تدفق الجهاز: أجهزة التلفزيون الذكية، وحدة التحكم، أجهزة IoT: يحتاج الأجهزة مثل أجهزة التلفزيون أو الطابعات إلى مصادقة مستخدم. تدفق الجهاز هو جزء من OIDC.
4. لديك احتياجات التفاعل: لا تقوم بمجرد مصادقة المستخدمين — أنت تبني نظامًا بيئيًا حيث يمكن للتطبيقات الخارجية، الشركاء، أو الوكلاء التفاعل مع نظامك والوصول إلى بيانات المستخدم بأمان.

لماذا يعد OAuth و OIDC أكثر أهمية من أي وقت مضى في عصر الذكاء الاصطناعي#

في عصر الذكاء الاصطناعي، نشهد زيادة في احتياجات التكامل والوصول الجديدة — خاصة في مجالات مثل الوكلاء المستقلة، الأجهزة الذكية، والتواصل بين النظام والنظام. هذه الاتجاهات تجعل OAuth 2.0 و OIDC أكثر أهمية من أي وقت مضى. إليك بعض الأمثلة:

1. خوادم MCP البعيدة

   تبني خادم MCP (بروتوكول سياق النموذج) وتريد من الوكلاء الخارجيين الاتصال به. يحتاج هؤلاء الوكلاء إلى وصول آمن لطلب السياق، تنفيذ الإجراءات، وتبادل البيانات — كل ذلك دون المساس بثقة المستخدم. يوفر OAuth الآلية لتفويض الوصول بأمان.

2. فتح منتجك للتكاملات

   تدير خدمات أعمالك الخاصة — مثل أداة إدارة المشروع أو منصة العملاء — وتريد السماح للمنتجات الأخرى أو الوكلاء بالاندماج معها. قد يعني ذلك سحب البيانات، تنفيذ تدفقات العمل، أو تضمين ميزاتك في بيئات أخرى. يتيح OAuth 2.0/OIDC التحكم في الوصول المعتمد على الرموز المميزة بدقة دون مشاركة بيانات اعتماد المستخدم.

3. بناء وكيلك الخاص

   تبني وكيل ذكاء اصطناعي أو مساعد وتريد منه التعامل مع التطبيقات الأخرى وخوادم MCP — جدولة الاجتماعات، إرسال الرسائل الإلكترونية، نشر التحديثات، استعلام البيانات. يتطلب ذلك وصولًا آمنًا ومصدقًا إلى الخدمات الخارجية. OAuth 2.0 هو الطريقة التي يحصل بها وكيلك على التفويض للتصرف نيابة عن المستخدم.

4. صعود الأجهزة الذكية

   الأجهزة المادية مثل المترجمين الذكيين أو ملاحظات الاجتماعات الذكية أصبحت أكثر قدرة بفضل LLMs. ومع التكلفة المنخفضة والأداء العالي، يزداد عدد هذه الأجهزة في السوق. غالبًا ما تحتاج هذه الأجهزة إلى طريقة لمصادقة المستخدمين والوصول إلى الخدمات المستندة إلى السحابة — خصوصًا مع واجهات الإدخال المحدودة. هنا تأتي أهمية تدفقات مثل تدفق تفويض الجهاز و التحقق من الهوية المبني على OIDC.

متى قد لا تحتاج إلى OAuth 2.0/OIDC#

بالطبع، هناك حالات قد لا تحتاج فيها إلى OAuth 2.0 أو OIDC — على الأقل ليس الآن. بمعنى آخر، إذا كان حالتك الحالية بسيطة أو مكتفية بالذات، فقد لا تجلب هذه البروتوكولات قيمة فورية.

ومع ذلك، مع نمو منتجك أو توسع نظامك البيئي، يصبح الاحتياج لـ OAuth 2.0 و OIDC أكثر وضوحًا على المدى الطويل.

1. تطبيقات بسيطة، داخلية

   إذا كان تطبيقك يستخدم فقط من قبل فريق صغير داخل الشركة ولا يحتاج إلى التكامل مع خدمات الطرف الثالث أو كشف APIs، فقد يكون نظام مصادقة أساسي باستخدام اسم المستخدم وكلمة المرور (مثل جلسات الكوكي) كافيًا.

2. لا حاجة لمصادقة المستخدمين

   إذا كان منتجك لا يحتوي على حسابات مستخدمين أو ميزات تعتمد على الهوية — مثل موقع محتوى عام أو أداة خادم لخادم بمفاتيح API ثابتة — لا حاجة لـ OIDC.

3. لا تتطلب وصولًا مفوضًا

   يبرز قوة OAuth عندما تحتاج إلى السماح للمستخدمين لتفويض تطبيقك للوصول إلى بياناتهم في نظام آخر (مثل Google Drive). إذا لم تكن تتكامل مع APIs الطرف الثالث أو تبني تدفقات عمل متعددة الخدمات، فإن OAuth يزيد التعقيد دون قيمة.

4. بيئة واحدة، مخاطر دنيا

   بالنسبة للنماذج الأولية المبكرة، MVPs، أو أدوات الاختبار الداخلية حيث تفوق البساطة والسرعة الحاجة إلى الأمان، يمكنك تأجيل تنفيذ OAuth/OIDC حتى وقت لاحق.

الأفكار النهائية بشأن اختيار استراتيجية المصادقة الصحيحة#

قد لا تحتاج إلى OAuth 2.0 أو OIDC على الفور — وهذا مقبول تمامًا. في المراحل المبكرة، غالبًا ما تؤدي الحلول البسيطة المهمة. لكن مع نمو منتجك، ومع دمج الوكلاء والذكاء الاصطناعي أكثر في طريقة البناء، وعندما يفتح نظامك البيئي للشركاء والأطراف الثالثة، تصبح المصادقة المضمونة والمستندة إلى معايير أقل فائدة وأكثر ضرورة.

بدلًا من اللعب بلعبة اللحاق في وقت لاحق، يستحق وضع الأساس الآن. قد لا يتعلق اعتماد OAuth 2.0 و OIDC فقط بحل مشاكل اليوم — بل يتعلق بالاستعداد لما هو قادم.