OAuth 2.0 وOpenID Connect

أصبحت عبارة «تسجيل الدخول عبر Google» أمرًا بديهيًا لدى المستخدم، لكنها ما زالت مصدر التباس دائم لدى المطوّر. والسبب بسيط: OAuth 2.0 ليس بروتوكول مصادقة، بل بروتوكول لتفويض الصلاحيات، صُمّم ليتمكّن تطبيق ما من الوصول إلى مورد باسم مستخدم دون أن يعرف كلمة مروره. أما سؤال «من هو هذا المستخدم؟» فليس له مكان فيه.

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

لذلك يميّز هذا الدرس بين الأمرين بعناية، ويعرض الأطراف الأربعة والتدفق الذي ينبغي استخدامه اليوم، وهو رمز التفويض مع PKCE، أما بقية التدفقات فهي إما متقادمة أو مخصّصة لحالات خاصة. ثم ستضبطون الدورين اللذين يجيد Spring Security أداءهما: دور العميل الذي يفوّض تسجيل الدخول إلى مزوّد هوية، ودور خادم الموارد الذي يتحقق من الرموز المقدَّمة إليه.

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