الخلاصة

الشركة تملك الموعد والموقع يملك دفتر الحسابات

عندما رحّبت Google بمعيار OpenID Connect في فبراير 2014، أرفقت الترحيب بموعد لإنهاء طريقة أقدم: يتوقف دعم OpenID 2.0 في 20 أبريل 2015. أرادت جمع خدمات الدخول الموحد على المعيار الجديد، وقدمت للمطورين طريقًا عبر أدواتها. كانت أمام المواقع مهلة تزيد على سنة. لكنها مهلة يحددها مشغّل خدمة الهوية. يستطيع الموقع تغيير برنامجه، ولا يستطيع تمديد حياة نقطة الدخول القديمة لدى Google بقراره وحده.

وراء نقطة الدخول سجل محلي لا ينتقل تلقائيًا. قد يكون المعرّف الموثّق في OpenID 2.0 مفتاح حساب يحوي مشتريات وملفات وعضوية وصلاحيات. أما OpenID Connect فيصف الهوية بزوج جديد: جهة إصدار الرمز وموضوعه. يمكن أن يمثل الزوج الجديد الشخص نفسه، لكنه ليس المفتاح الذي حُفظت عليه بياناته. إن نجح الدخول الجديد من دون ربط، قد يرى المستخدم حسابًا فارغًا. وإن ربط الموقع المفتاحين بلا إثبات، قد يفتح تاريخ شخص لآخر.

في 20 مارس 2015، أعادت Google ذكر 20 أبريل وأسماء بروتوكولات قديمة أخرى ستتوقف. أوضحت أن التطبيقات التي لم تنتقل قد تفقد قدرتها على الاتصال بها، وربما تتعطل وظيفة الدخول، إلى أن تعتمد بروتوكولًا مدعومًا. كان الإعلان يصف أثرًا ممكنًا للموعد، لا يحصي حوادث وقعت. لكنه وضع سلطة الشركة في مكانها المحدد: إغلاق خدمة التحقق القديمة التي تديرها.

أربعة أيام بين اعتماد القاعدة النهائية وإطفاء المدخل

نشرت مؤسسة OpenID نتيجة التصويت في 16 أبريل 2015: 28 صوتًا موافقًا، لا صوت معارضًا، وأربع حالات امتناع. بقيت أربعة أيام على موعد Google. لم تكن تلك كل الفترة المتاحة للتطوير؛ فإعلان الشركة صدر في العام السابق، والملحق في المعيار النهائي يقارن نصه بدليل نقل نشرته Google في يونيو 2014. الشيء الذي اكتمل قبل الإغلاق بأربعة أيام هو القاعدة المشتركة النهائية لإثبات الصلة بين مفتاحين مختلفين للحساب.

تبدأ المواصفة بتعريف الفرق. في OpenID 2.0 يوجد معرّف مُطالب به جرى التحقق منه. وفي Connect توجد هوية مكونة من جهة إصدار وموضوع. يضيف الموقع النطاق openid2 إلى طلب المصادقة ليطلب المعرّف القديم إلى جانب الجديد. إذا كانت لدى مقدّم الخدمة علاقة محفوظة بهذا المعرّف، يعيده داخل ID Token في الحقل openid2_id. يتحقق الموقع أولًا من الرمز، ثم يواجه السؤال الذي لا تحله كتابة عنوان قديم داخل رمز جديد: هل جهة الإصدار مخولة أصلًا الحديث باسم ذلك العنوان؟

وضعت المواصفة حارسًا عند هذه النقطة. في حالة محدودة يمكن مقارنة سلطة نقطة الدخول القديمة بسلطة نقطة التفويض الجديدة. وإلا يطلب الموقع عنوان المعرّف القديم باستخدام Accept: application/json، ويقارن قيمة iss التي تعود منه بجهة الإصدار في الرمز مقارنة تامة. وللمعرّفات من نوع XRI طريق آخر. إذا فشل التحقق من السلطة، لا يقبل الموقع المعرّف القديم لأغراض الربط. وبعد نجاحه تنصح المواصفة بربط الحساب الموجود بالهوية الجديدة. التغيير الحاسم يقع في جدول الموقع المحلي، حيث تراكمت حقوق المستخدم.

يسرد الملحق B فروقًا بين المعيار ودليل Google المؤرخ في يونيو 2014. وفق مقارنة واضعي المواصفة، استخدم الدليل openid.realm بينما اختار النص النهائي openid2_realm، واستخدم openid_id بدل openid2_id. ويقول الملحق إن ذلك الدليل لم ينفذ تحقق الجهة الطالبة ولا تحقق سلطة المصدر على المعرّف القديم كما يصفهما النص النهائي. هذه مقارنة مع دليل محدد التاريخ، وليست قياسًا لكل نظام شغّلته Google. تكشف لماذا احتاج نقل الحسابات إلى قاعدة مستقلة عن تعليمات صاحب الموعد.

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