بروتوكول OpenID Connect (OIDC) أصبح معيارًا معتمدًا على نطاق واسع لإدارة الهوية. ولكن هل تفهم حقًا أدوار وخصائص هذه الرموز؟
Bبروتوكول OpenID Connect، المعروف أيضًا باسم OIDC، أصبح معيارًا معتمدًا على نطاق واسع لتوفير إطار عمل أساسي لإدارة الهوية. إنه طبقة مصادقة مبنية على بروتوكول OAuth 2.0 المعروف. بينما OAuth 2.0 هو فقط لتفويض الموارد، فإن OIDC هو البروتوكول الذي يقيِّر ويوحِّد عملية مصادقة العميل، بمساعدة الرمز الجديد الذي تم إدخاله وهو رمز التعريف.
انتظر... قد تكون سمعت عن رموز الوصول ورموز التحديث في عصر OAuth، والآن هنا يأتي المفهوم الجديد في OIDC؟ هل تفهم حقًا الفروق بين هذه الرموز؟
لنبدأ بسيناريو عملي.
تخيل أنك تطور تطبيق عميل-خادم عادي، ويتواصلان مع بعضهما البعض عبر واجهات برمجة التطبيقات RESTful. تريد أن تحتفظ بمعظم واجهات برمجة التطبيقات الخاصة بك خاصة، مما يسمح فقط للعملاء المصرح لهم بالوصول. ستحتاج إلى آلية لمصادقة العميل وتفويض طلبات واجهة برمجة التطبيقات إلى الخادم الخاص بك.
يفضل أن تكون واجهات برمجة التطبيقات RESTful الخاصة بك بدون حالة، مما يعني أن الخادم لا ينبغي أن يخزن أي معلومات جلسة للعميل. كلما جاء طلب صالح، ينبغي على الخادم أن يستجيب فقط بالبيانات المطلوبة. هذا هو المكان الذي تأتي فيه الرموز. إذاً، ما نوع الرمز الذي ينبغي عليك استخدامه في مثل هذه الحالة؟
في OAuth 2.0 وOIDC، كل واجهة برمجة تطبيقات محمية تعتبر موردًا. يعتبر رمز الوصول هو الرمز الذي ينقله العميل إلى الخادم عند طلب موارد واجهة برمجة التطبيقات، عادةً عبر رأس الطلب وفي صيغة JWT.
على جانب الخادم، كلما جاء طلب، يجب على الخادم فقط التحقق مما إذا كان الطلب الوارد يحتوي على رمز وصول صالح. تتضمن عملية التحقق عادةً فك شفرة رمز JWT، والتحقق من التوقيع ووقت الانتهاء، وكذلك مطالبة النطاق لضمان أن العميل لديه الأذونات اللازمة.
ومع ذلك، قد تتساءل: إذا كان تطبيق العميل الخاص بي يمكن أن يكون لديه رمز وصول صالح بعد تسجيل دخول ناجح، ويستخدم رمز الوصول لطلب واجهات برمجة تطبيقات الخادم، أليس ذلك كافيًا؟ لماذا أحتاج الرموز الأخرى؟
بالفعل، سؤال وجيه، ودعونا نشرحه خطوة بخطوة.
بينما تقنيًا تلبي رموز الوصول المتطلبات الدنيا لجعل النظام يعمل، إلا أنه بسبب القضايا الأمنية تكون صلاحية رموز الوصول عادةً قصيرة جدًا (عادة ساعة واحدة). لذلك تخيل إذا كان لدينا فقط رموز وصول، سيضطر المستخدمون النهائيون إلى إعادة المصادقة في كل مرة تنتهي صلاحية رمز الوصول. بالنسبة لتطبيقات الويب الأحادية الصفحة الحديثة (SPAs) وخاصة التطبيقات المتنقلة، الخروج بشكل متكرر من الجلسة هو تجربة مؤلمة للمستخدمين، حتى وإن كنا نحاول فقط حماية أمانهم.
لذلك، نحتاج إلى توازن بين أمان الرمز وراحة المستخدم. ولهذا تم إدخال رموز التحديث.
تُستخدم رموز الوصول للوصول إلى موارد واجهة برمجة التطبيقات، لذا فإن طبيعتها قصيرة الأجل تساعد في التخفيف من خطر تسريبها أو اختراقها. من ناحية أخرى، نظرًا لأن رموز التحديث تُستخدم فقط لتبادل رموز وصول جديدة، فهي لا تُستخدم بشكل متكرر كما تُستخدم رموز الوصول، وبذلك ينخفض خطر التعرض لها. لذلك، يعتبر وجود فترة صلاحية أطول مقبول لرموز التحديث.
نظرًا لأن رمز التحديث يتم تخزينه أيضًا على جانب العميل، فإن ضمان عدم تعريضه للخطر يمثل تحديًا، خاصةً مع العملاء العموميين مثل تطبيقات الويب الأحادية الصفحة (SPA) والتطبيقات المتنقلة.
في Logto، تحتوي رموز التحديث على آلية تدوير تلقائية مفعلة افتراضيًا، مما يعني أن خادم التفويض سيصدر رمز تحديث جديد بمجرد أن يفي بالمعايير:
بينما لا يزال لديك الخيار لتعطيل تدوير رمز التحديث من صفحة تفاصيل التطبيق في وحدة التحكم الإدارية، يوصى بشدة بالاحتفاظ بهذه التدابير الوقائية.
رمز التعريف هو ميزة فريدة في OIDC توفر معلومات هوية عن المستخدم المصادق عليه.
بينما تُستخدم رموز الوصول للوصول إلى الموارد المحمية وتُستخدم رموز التحديث للحصول على رموز وصول جديدة، تُستخدم رموز التعريف عادةً لتخزين معلومات المستخدم مؤقتًا على جهة العميل، مما يقلل الحاجة لعمل طلبات إضافية إلى خادم التفويض للحصول على بيانات المستخدم. في معظم الحالات، يُعتبر وجود رمز التعريف بمثابة مصادقة للمستخدم.
في بروتوكول OIDC، تعمل رموز التحديث، رموز الوصول، ورموز التعريف سويًا لتوفير مصادقة آمنة وسلسة للمستخدم.
فهم دور وأهمية هذه الرموز هو أمر حيوي للمطورين الذين ينفذون مصادقة OIDC في تطبيقاتهم.