ما هو PKCE: من المفاهيم الأساسية إلى الفهم العميق

إثبات المفتاح لتبادل الشفرات (PKCE) هو امتداد لتدفق رمز التفويض، تم تصميمه أساسًا لتأمين تدفق رموز التفويض في تطبيقات الأجهزة المحمولة ، والآن يُوصى باستخدامه بواسطة تطبيقات الصفحة الواحدة أيضًا . في OAuth 2.1، يتم تطبيق PKCE لجميع أنواع العملاء، بما في ذلك العملاء العامين والعملاء الخاصين (المستترين).

في هذه المقالة، سنساعدك على فهم لماذا تم إنشاء PKCE وكيف يحمي تطبيقاتك، مما يمنحك فهمًا عميقًا لـ PKCE.

لماذا نحتاج إلى PKCE؟#

في تدفق رمز التفويض لـ OAuth 2.0، يطلب المستخدمون تسجيل الدخول من خلال تطبيق. يوجه خادم المصادقة المستخدمين إلى صفحة المصادقة. بعد مصادقة المستخدم، يرجع الخادم رمز التفويض إلى التطبيق، والذي يستخدم هذا الرمز بعد ذلك لطلب رمز وصول من خادم المصادقة.

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

يتم عرض عملية الاعتراض في الرسم البياني أدناه:

الخطوة (1): يقوم التطبيق بإجراء طلب تفويض عبر واجهة برمجة تطبيقات آمنة لا يمكن اعتراضها. في هذه الخطوة، يقدم المستخدم أيضًا عنوان URI لإعادة التوجيه.

الخطوة (2): يتم إرسال الطلب بعد ذلك إلى خادم التفويض OAuth 2.0. نظرًا لأنّ OAuth يتطلب استخدام TLS، يتم حماية هذا الاتصال بواسطة TLS ولا يمكن اعتراضه.

الخطوة (3): يعيد خادم التفويض رمز التفويض.

الخطوة (4.a): يتم إرجاع رمز التفويض للمستخدم عبر عنوان URI لإعادة التوجيه الذي تم تقديمه في الخطوة (1). في هذه الخطوة ، إذا قام التطبيق الضار بتسجيل نفسه كمعالج لعنوان URI لإعادة التوجيه، فيمكن للتطبيق الضار اعتراض رمز التفويض. مع رمز التفويض ، يمكن للمهاجم طلب والحصول على رمز وصول في الخطوات (5.a) و (6.a) على التوالي.

كما هو موضح أعلاه ، في تدفق رمز التفويض لـ OAuth 2.0 ، إذا تم اعتراض رمز التفويض ، يمكن للمهاجمين استخدامه للحصول على رموز وصول. لذلك، نحتاج إلى آلية لمنع اعتراض رمز التفويض، مما أدى إلى إنشاء PKCE.

كيف يعمل PKCE؟#

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

يحل PKCE هذه المشكلة عن طريق إدخال مفهوم "مفتاح إثبات".

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

مدقق الرمز هو سلسلة تم إنشاؤها عشوائيًا ، ويتم اشتقاق رمز التحدي من مدقق الرمز من خلال التحويل. يتم دعم طريقتي تحويل:

• plain: يستخدم مدقق الرمز مباشرة كرمز تحدي

• S256: يطبق تجزئة SHA-256 على مدقق الرمز، متبوعًا بتشفير Base64URL. نظرًا لأنّ مخرجات التجزئة لا يمكن عكسها للحصول على مدقق الرمز، ولأنّ طريقة plain قد تكون عرضة لهجمات الرجل في الوسط أثناء الإرسال، يوصى بشدة باستخدام S256 لأسباب أمنية.

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

الخطوة (1-3): يُنشئ التطبيق ويسجل سرًا يسمى "مدقق الرمز" ويستمد منه نسخة محولة "رمز التحدي"، والذي يتم إرساله في طلب التفويض لـ OAuth 2.0 مع طريقة التحويل "طريقة رمز التحدي".

الخطوة (3-6): يرد الخادم المصادق كما هو معتاد ولكنه يسجل "رمز التحدي" و"طريقة رمز التحدي".

الخطوة (7.a): يرسل التطبيق بعد ذلك رمز التفويض إلى نقطة نهاية الرمز كما هو معتاد، ولكنه يتضمن السر الذي تم إنشاؤه في الخطوة (1) "مدقق الرمز".

الخطوة (8.a-9.a): يقوم خادم المصادقة بتحويل "مدقق الرمز" إلى "رمز التحدي" ويقارنه بـ "رمز التحدي" من الخطوة (1-3). يتم رفض الوصول إذا لم يكونا متساويين.

في هذه الحالة، حتى ولو تمكن التطبيق الضار من اعتراض رمز التفويض في الخطوة (6.b)، فإنه لا يستطيع استبدال رمز الوصول به ، لأنه ليس بحوزته السر "مدقق الرمز"، ولأنّ "مدقق الرمز" يرسل عبر TLS، لا يمكن اعتراضه.

الخلاصة#

توضح هذه المقالة كيف يعمل PKCE ولماذا هو ضروري لحماية تدفق رمز التفويض. من خلال إضافة آلية مفتاح إثبات، يمنع PKCE التطبيقات الضارة من اعتراض رموز التفويض وإساءة استخدامها. نأمل أن يساعدك هذا الشرح في فهم PKCE بشكل عميق.