عندما تبدأ في بناء واجهات برمجة التطبيقات باستخدام Node.js ويتعين عليك الاهتمام بجانب الأمان، عاجلاً أم آجلاً يظهر نفس البطل: رموز الويب JSON (JWT) كنظام مصادقةإنها خفيفة الوزن، وتعمل بشكل رائع مع البنى الحديثة، وتتيح لك التوسع دون الحاجة إلى إدارة جلسات الخادم بشكل مفرط.
ستشاهد في هذا الدليل، خطوة بخطوة وبتفاصيل دقيقة، كيفية عمل JWT داخليًا وكيفية دمجه في واجهة برمجة تطبيقات Node.js باستخدام Expressيشمل هذا الدليل كلاً من تسجيل الدخول التقليدي باستخدام اسم المستخدم وكلمة المرور، وتسجيل الدخول عبر جوجل، بالإضافة إلى أفضل الممارسات الأمنية، وإلغاء الصلاحيات، واستخدام بروتوكول HTTPS، والبرمجيات الوسيطة، وهيكلة المشروع. والهدف هو أن تحصل، عند الانتهاء من القراءة، على نظرة شاملة وتتمكن من تطبيقها في واجهة برمجة التطبيقات الخاصة بك دون أي مفاجآت.
ما هو JWT وكيف يتم تنظيم الرمز المميز؟
رمز JSON للويب هو، رسميًا، معيار مفتوح (RFC 7519) لنقل المطالبات بتنسيق JSON بين جزأين بطريقة مختصرة. ولأغراض عملية، فهو عبارة عن سلسلة نصية بسيطة تتكون من ثلاثة أجزاء Base64 مفصولة بنقاط: رأس الصفحة، والحمولة، والتوقيع.
عندما يقوم المستخدم بالتسجيل أو تسجيل الدخول بنجاح إلى واجهة برمجة التطبيقات الخاصة بك، يقوم النظام الخلفي بإنشاء رمز JWT يحتوي على بياناته وإعادته إلى العميل. ثم ينتقل هذا الرمز المميز في كل طلب لاحق.، عادةً ما يتم تضمينها داخل رأس Authorization باسم Bearer، لإظهار من هو المستخدم وما هي الأذونات التي يمتلكها.
سيكون المثال النموذجي للرمز المميز مشابهاً لهذا الهيكل: رأس مشفر بصيغة Base64، وحمولة مشفرة بصيغة Base64، وتوقيع محسوب باستخدام خوارزمية تجزئةجميعها مرتبطة ببعضها البعض بنقاط. على الرغم من أنها قد تبدو كطلاسم، إلا أنها في الواقع صيغة منهجية للغاية.
إذا أخذت تلك السلسلة ولصقتها على أدوات مثل jwt.ioسترى كيف يتم فك تشفيرها أثناء التنفيذ: على جانب الرمز المميز الخام وعلى الجانب الآخر، كنص عادي، العنوان والحمولة، مع المفاتيح والقيم التي أدخلتها عند إنشائها.
El رأس يتضمن عادةً حقولاً مثل ALG (خوارزمية، على سبيل المثال HS256) و نوع (نوع الرمز المميز، عادةً JWT). الـ الحمولة يحتوي على المطالبات، أي المعلومات التي تريد نقلها: معرف المستخدم، الاسم، الدور، تاريخ انتهاء الصلاحية، إلخ. توقيع يتم حسابها عن طريق تطبيق خوارزمية HMAC أو خوارزمية التوقيع على الرأس المشفر والحمولة، بالإضافة إلى مفتاح سري أو زوج من المفاتيح العامة/الخاصة.
آلية التوقيع الأكثر شيوعًا في واجهات برمجة التطبيقات (APIs) مع Node.js و Express هي HMAC-SHA256 (HS256)وهي تجمع بين رمز مصادقة الرسائل القائم على التجزئة وسر مشترك. يتم إنشاء التوقيع بتطبيق الدالة على: رأس مشفر بصيغة Base64، وحمولة مشفرة بصيغة Base64، وسر لا يعرفه إلا الخادمبالإضافة إلى ذلك، يُنصح بمعرفة كيفية إدارة الشهادات والتوقيعات عند العمل باستخدام المفاتيح العامة/الخاصة.
يكمن جمال كل هذا في أنه إذا عبث أحدهم بالرمز المميز على طول الطريق، لم يعد التوقيع متطابقًا عندما يتحقق الخادم من الرمز المميز.بمجرد فشل التحقق من التوقيع، يعرف النظام الخلفي أن الرمز المميز قد تم تعديله أو أنه لا يأتي من مصدر شرعي، ويجب رفض الطلب برمز 401 أو 403.
من المهم أن نفهم ذلك Base64 ليس تشفيرًا، إنه مجرد ترميزكل ما تضعه في الحمولة يمكن قراءته إذا تمكن شخص ما من الحصول على الرمز المميز، ولهذا السبب يجب ألا تُضمّن معلومات حساسة كنص عادي داخل رمز JWT. ولهذا السبب أيضًا يُعدّ دمج JWT مع HTTPSبحيث تنتقل جميع البيانات مشفرة ولا يمكن التجسس عليها بسهولة على الشبكة.
مزايا استخدام JWT في واجهات برمجة تطبيقات Node.js
أحد الأسباب الرئيسية التي جعلت شركة JWT تحظى بشعبية كبيرة هو أن الرموز مكتفية ذاتيًا ولا تحتفظ بحالة.وهذا يعني أنه للتحقق من صحة المستخدم، لا يحتاج الخادم إلى الوصول إلى قاعدة البيانات في كل طلب، لأن المعلومات ذات الصلة موجودة داخل الرمز المميز الموقع.
بما أنها مجرد سلسلة نصية، يمكن إرسال JWT في عناوين URL، أو في نص طلب POST، أو في رؤوس HTTP.يتكامل بسلاسة مع واجهات برمجة تطبيقات REST التقليدية وتطبيقات الصفحة الواحدة (SPA). يتميز بتنسيق مضغوط، مثالي لتطبيقات الجوال، والواجهات الأمامية في React وVue وAngular وغيرها، وحتى للتواصل بين الخدمات المصغرة.
ومن نقاط القوة الأخرى مرونة خوارزميات التوقيع: يمكنك استخدام HMAC مع سر مشترك (HS256) أو يمكنك اختيار مخططات غير متماثلة مثل RSA أو ECDSA، حيث تقوم بالتوقيع باستخدام مفتاح خاص والتحقق باستخدام مفتاح عام، وهو أمر مفيد للغاية في بيئات الأعمال المعقدة.
في البنى التي تحتوي على خدمات متعددة، يُعد JWT خيارًا مثاليًا لأن يسمح ذلك للخدمات المصغرة المختلفة بالوثوق بنفس الرمز المميز. دون الحاجة إلى مشاركة الجلسات في الذاكرة أو إعادة توزيع بيانات المستخدم. كل خدمة تحتاج فقط إلى المفتاح للتحقق والقواعد لتفسير البيانات.
من منظور تجربة المستخدم، إذا تم تنفيذه بشكل جيد، تُسهّل JWT جلسات سلسة وقابلة للتطوير، ودعم آليات تجديد الرموز، وانتهاء الصلاحية الخاضعة للتحكم، وبشكل عام، تحقيق توازن جيد بين الأمان وراحة المستخدم.
قم بإعداد بيئة التطوير باستخدام Node.js و Express
لإعداد واجهة برمجة تطبيقات (API) مع مصادقة JWT في Node.js، فإن النهج المعتاد هو الاعتماد على Express كإطار عمل HTTP وقم بدمجها مع بعض المكتبات الرئيسية التي تبسط الحياة بشكل كبير.
تتمثل آلية العمل النموذجية لبدء التشغيل في إنشاء مجلد جديد للمشروع، والدخول إليه، وتشغيله. npm الحرف الأول لإنشاء ملف package.json. ومن ثم، تقوم بتثبيت التبعيات اللازمة: Express للخادم، وjsonwebtoken لإدارة JWT، وbcrypt أو bcryptjs لتشفير كلمات المرور، وdotenv للتعامل مع متغيرات البيئة..
إذا كنت ستعمل مع قاعدة بيانات حقيقية، مثل MongoDB، فإن هذا الأمر عادةً ما يكون ذا أهمية. مونغوس لتحديد النماذج والمخططاتفي هذه الحالة، سيكون لديك في دليل مشروعك شيء مثل: ملف بدء التشغيل الرئيسي (على سبيل المثال، app.js)، ومجلد النماذج مع نموذج User.js، وملف .env مع المفاتيح الحساسة.
يمكنك تخزين أشياء مثل... داخل ملف .env JWT_SECRET، وURI اتصال قاعدة البيانات، ووقت انتهاء صلاحية الرمز المميزستقوم بعد ذلك بتحميل هذه البيانات باستخدام dotenv بحيث لا يتم تضمينها بشكل ثابت في الكود المصدري أو تحميلها إلى المستودعات.
يتضمن نموذج المستخدم عادةً حقولاً مثل اسم المستخدم أو البريد الإلكتروني وكلمة المروروخطاف ما قبل الحفظ الذي يقوم بتشفير كلمة المرور قبل تخزينها. وبهذه الطريقة، حتى لو تمكن شخص ما من الوصول إلى قاعدة البيانات، فلن يحصل على كلمات المرور كنص عادي، بل سيحصل على تجزئات تم إنشاؤها باستخدام bcrypt.
من الطبيعي تهيئة Express في الملف الرئيسي للتطبيق. قم بتفعيل برنامج الوسيط لتحليل JSONقم بالاتصال بقاعدة بيانات MongoDB (إذا كنت تستخدمها) وحدد مسارات التسجيل، وتسجيل الدخول، والوصول إلى الموارد المحمية. ومن هنا يأتي الجزء الأهم: إنشاء رموز JWT والتحقق منها.
عملية مصادقة كاملة باستخدام JWT
في نظام المصادقة القائم على JWT، يتضمن التسلسل النموذجي عادةً تسجيل المستخدم، وتسجيل الدخول، وإصدار الرموز المميزة، والتحقق من كل طلب، وحماية المسارات الخاصةعلى الرغم من أن التفاصيل قد تختلف، إلا أن الهيكل العام يبقى هو نفسه دائماً.
في تسجيلعندما يُرسل المستخدم بياناته من خلال التطبيق، يستقبل واجهة برمجة التطبيقات (API) الخاصة بك نص الطلب، ويُشفّر كلمة المرور باستخدام bcrypt، ويحفظ بيانات المستخدم في قاعدة البيانات (أو في بنية بيانات في الذاكرة إذا كنت تُجري عرضًا توضيحيًا)، ثم يُرسل ردًا لتأكيد التسجيل. ليس من الضروري إرجاع رمز مميز أثناء التسجيل، مع أن العديد من واجهات برمجة التطبيقات تفعل ذلك لتجنب خطوة تسجيل دخول إضافية.
في تسجيل الدخولالأمور تصبح مثيرة للاهتمام: تتلقى اسم مستخدم وكلمة مرور، وتبحث عن المستخدم في قاعدة البيانات، وتقارن كلمة المرور المُقدمة مع التجزئة المخزنة باستخدام bcrypt، وإذا تطابقت، يتم إنشاء رمز JWT باستخدام الدالة علامة مكتبة jsonwebtokenفي هذا الرمز المميز، تقوم بتضمين مطالبات مفيدة: معرف المستخدم، والاسم، والدور، والأهم من ذلك، تاريخ انتهاء الصلاحية.
عند إعداد الرمز المميز، من الممارسات الجيدة إنشاء مدة صلاحية معقولة، مثل ساعة أو ساعتين لرمز الوصوليقلل هذا من مدة التعرض في حال وصول الرمز المميز إلى يد شخص غير مصرح له. أما بالنسبة للجلسات الطويلة، فيُستخدم رمز التحديث، والذي سنتناوله لاحقًا.
يجب أن يأتي المفتاح السري الذي تستخدمه لتوقيع الرمز المميز من لا ينبغي كتابة متغير البيئة مباشرة في الكود.إذا كنت تشك في أن هذا المفتاح قد تم اختراقه في أي وقت، فيجب أن تتضمن استراتيجيتك الأمنية تغيير الأسرار، وإلغاء الرموز القديمة، وإنشاء رموز جديدة.
بمجرد أن تُعيد عملية تسجيل الدخول الرمز المميز إلى العميل، يقوم العميل بتخزينه (على سبيل المثال، في ملف تعريف ارتباط httpOnly أو في الذاكرة) ثم يرسله. في رأسية التفويض مع مخطط حامل البيانات في كل استدعاء لنقاط النهاية المحمية، يقوم الخادم، على نقاط النهاية تلك، بتفعيل برنامج وسيط للتحقق من صحة الرمز المميز قبل المتابعة مع منطق وحدة التحكم.
برنامج وسيط للتحقق من JWT وحماية المسار
عادةً ما يكون جوهر المصادقة في واجهة برمجة التطبيقات (API) باستخدام Node.js و Express هو برنامج وسيط قابل لإعادة الاستخدام يتحقق من الرمز المميز في كل طلبمن الناحية الفيزيائية، هي وظيفة تعمل قبل معالج المسار وتحدد ما إذا كان الطلب يجتاز عامل التصفية أم يتم رفضه.
يمكن لهذا البرنامج الوسيط البحث عن الرمز المميز في أماكن مختلفة، ولكن الطريقة الأكثر شيوعًا هي قراءة الترويسة. ترخيص بتنسيق حاملفي مشاريع أخرى سترى أنه يتم استخدام رأس مخصص مثل x-auth-token؛ المفهوم هو نفسه، فقط اسم الرأس يتغير.
بمجرد استرداد الرمز المميز، يقوم البرنامج الوسيط باستدعاء jwt.verify باستخدام الرمز المميز والمفتاح السريإذا تطابقت التوقيعات ولم تنتهِ صلاحية الرمز المميز، فستحصل على البيانات المُفكَّكة. عادةً ما تُرفق هذه البيانات بكائن الطلب (على سبيل المثال، req.user) لكي تعرف وحدات التحكم الأخرى هوية المستخدم وما هي صلاحياته.
إذا فشلت عملية التحقق، إما بسبب عدم تطابق التوقيع، أو تعديل الرمز المميز، أو انتهاء صلاحيته، أو ببساطة عدم وجوده، سيكون الرد المناسب من البرنامج الوسيط هو 401 (غير مصادق عليه) أو 403 (ممنوع).وذلك بحسب ما إذا كانت المشكلة تكمن في نقص بيانات الاعتماد أو في عدم كفاية الصلاحيات.
بفضل هذا الأسلوب، يمكنك حماية نقاط النهاية الخاصة بك بسهولة بالغة: ما عليك سوى قم بإدراج البرنامج الوسيط كوسيط ثانٍ في تعريف المسارعلى سبيل المثال، في مسار /clients الذي يُرجع بيانات العملاء، يمكن وضع برنامج الوسيط الخاص بالمصادقة كمعامل ثانٍ، بحيث إذا لم يحتوي الطلب على رمز مميز صالح، فلن يتم إرجاع المعلومات.
إذا حاولت إرسال طلب إلى نقطة نهاية محمية بدون رمز مميز، فسيقطع البرنامج الوسيط مسار الطلب وستظهر لك رسالة خطأ واضحة. بمجرد تضمين رمز مميز صالح في رأس الطلب، ستعيد نقطة النهاية نفسها البيانات المحميةمما يدل على أن نظام التحكم في الوصول يعمل بشكل صحيح.
يمكن تطبيق هذا النمط نفسه على مستويات أمان أكثر: يمكنك استخدام برنامج وسيط عام يتحقق من مصادقة المستخدم، وعلى هذا الأساس، برامج وسيطة أخرى لمراجعة أدوار أو نطاقات أو أذونات محددة. قبل السماح بإجراء عمليات أكثر حساسية.
التحكم في الوصول، والأدوار، وأفضل الممارسات لإنشاء الرموز المميزة
بمجرد أن يصبح لديك مسار المصادقة الأساسي يعمل، فإن الخطوة الطبيعية التالية هي إدارة الأدوار والصلاحيات داخل رمز JWT الخاص بكللقيام بذلك، يمكنك تضمين مطالبات في الحمولة مثل الأدوار (مسؤول، مستخدم، إلخ) أو النطاقات التي تشير إلى الإجراءات التي يمكن للمستخدم القيام بها.
من المغري جداً حشر أكبر قدر ممكن من المعلومات في الحمولة، ولكن من الأفضل مقاومة ذلك: لم يتم تصميم JWT لنقل كميات كبيرة من البيانات أو المعلومات الحساسةكلما أمكن ذلك، قلل المحتوى إلى الحد الأدنى الضروري لتحديد هوية المستخدم وسياق التفويض الخاص به.
يُعد تاريخ انتهاء الصلاحية جانبًا بالغ الأهمية. كلما قصر عمر رمز الوصول، كلما قلت فرصة الهجوم في حال سرقته.تتمثل الممارسة المعتادة في استخدام رموز الوصول ذات فترات انتهاء الصلاحية القصيرة (على سبيل المثال، ساعة أو ساعتين) وإدارة استمرارية الجلسة باستخدام رموز التحديث.
رموز التحديث هي رموز ثانوية، وعادةً ما تكون مصحوبة بـ مدة صلاحية أطول وتخزين آمن للغايةيُفضّل استخدام ملفات تعريف الارتباط من نوع httpOnly مع تفعيل خاصية الأمان. وتتمثل وظيفتها في السماح للعميل بالحصول على رموز وصول جديدة دون الحاجة إلى طلب بيانات الاعتماد من المستخدم بشكل متكرر.
من وجهة نظر أمنية، يجب أن يحتوي تطبيقك على آليات لـ إبطال صلاحية الرموز المميزة في الحالات الحرجةمثل تغيير كلمات المرور، أو إغلاق الجلسات بشكل صريح، أو اكتشاف الأنشطة المشبوهة. وبما أن JWT لا يحتفظ بحالة، فلا توجد قائمة جلسات على الخادم، لذا يجب استخدام استراتيجيات مثل القائمة السوداء، أو التخزين المؤقت، أو تقليل أوقات انتهاء الصلاحية بشكل كبير.
لا تنس أبدًا أن يُعد المفتاح السري لرمز JWT أحد أكثر أصول النظام حساسية.يجب حفظ هذا السر دائمًا ضمن متغيرات البيئة، ويجب تقييد الوصول إليه، كما يجب التخطيط لاستبداله في حال الاشتباه باختراقه. فإذا تمكن شخص ما من الحصول على هذا السر، فبإمكانه توليد رموز صالحة متى شاء.
استراتيجيات الإلغاء، وتحديث الرموز، والتخزين الآمن
إحدى النقاط الحساسة لدى وكالة JWT هي الإلغاء المبكر للرموز النشطةبما أن الخادم لا يخزن حالة لكل رمز مميز، فليس من الكافي ببساطة حذفه من جدول الجلسة كما يحدث مع الحلول التقليدية الأخرى.
تتمثل إحدى الاستراتيجيات الشائعة الاستخدام في الحفاظ على قوائم سوداء في الذاكرة أو في قاعدة بيانات سريعة (مثل Redis)حيث يتم تخزين مُعرّفات الرموز المميزة التي تم إبطالها قبل تاريخ انتهاء صلاحيتها. في كل مرة يصل فيها طلب مُصادق عليه، بالإضافة إلى التحقق من التوقيع، يتم التحقق من عدم وجود الرمز المميز في تلك القائمة. تتوافق هذه الاستراتيجية مع أفضل ممارسات إدارة الحوادث السحابية باستخدام Azure للسيناريوهات التجارية.
خيار آخر يتضمن التلاعب بالوقت: يمكنك ضبط رموز وصول قصيرة جدًا وافترض أنه على الرغم من عدم إمكانية إلغائها فورًا، إلا أن التأثير المؤقت يقل بشكل ملحوظ. بالتوازي، يمكنك إدارة استمرارية الجلسة باستخدام رموز التحديث، والتي يمكنك إبطالها صراحةً في قاعدة البيانات.
فيما يتعلق بتخزين البيانات من جانب العميل، فإن الموقع الأكثر توصية لتحديث الرمز المميز في تطبيقات الويب هو ملف تعريف ارتباط httpOnly ذو سمات آمنة، وفي كثير من الحالات، ملف تعريف ارتباط sameSite مُهيأ بشكل صحيح لتقليل مخاطر XSS و CSRF، يمكن تخزين رمز الوصول في الذاكرة (على سبيل المثال، في حالة تطبيق الواجهة الأمامية) وتجديده قبل انتهاء صلاحيته.
لا تنس أن تُكمل ذلك بـ تشمل التدابير الأمنية الأخرى: الاستخدام الإلزامي لبروتوكول HTTPS، ورؤوس الحماية (Content-Security-Policy، وX-Frame-Options، وما إلى ذلك)، والتحقق الشامل من صحة المدخلات، وضوابط الحماية من هجمات تزوير الطلبات عبر المواقع (CSRF) عند استخدام ملفات تعريف الارتباط، ومراجعة أحداث المصادقة. (محاولات تسجيل الدخول الفاشلة، تغييرات كلمة المرور، تسجيل الخروج، إلخ).
في بيئات الشركات أو المشاريع واسعة النطاق، يُنصح عادةً دمج JWT مع أنظمة إدارة الهوية الأكثر تطوراسياسات الأمن الداخلي واختبارات الأمن السيبراني المنتظمة، بما في ذلك اختبارات الاختراق ومراجعات البنية.
مثال عملي: واجهة برمجة تطبيقات (API) باستخدام Node.js و Express و MongoDB
إذا كنت تفكر في واجهة برمجة تطبيقات أقرب إلى بيئة الإنتاج، فستقوم عادةً بدمج Node.js و Express و MongoDB و Mongoose لإعداد طبقة الواجهة الخلفية. يتم تعريف نموذج المستخدم بمخطط يتضمن الحقول المطلوبة، ويتم إضافة برنامج وسيط للحفظ المسبق يقوم بتشفير كلمة المرور باستخدام bcrypt قبل حفظها.
في ملف واجهة برمجة التطبيقات الرئيسية، بعد الاتصال بـ MongoDB وتكوين Express، يتم تعريف ما يلي: المساران /register و /loginفي أمر `/register`، يستقبل النظام اسم المستخدم وكلمة المرور، وينشئ نسخة من المستخدم، وينفذ برنامج التشفير الوسيط، ويحفظ المستخدم في قاعدة البيانات. إذا سارت الأمور على ما يرام، فإنه يستجيب برمز حالة 201، مما يشير إلى أنه تم إنشاء المستخدم بنجاح.
في مسار /login، يتحقق الخادم أولاً من وجود المستخدم، ثم يتحقق من صحة كلمة المرور بمقارنتها بالتجزئة المخزنة. إذا نجح التحقق، يقوم الخادم بإنشاء الرمز المميز باستخدام jwt.sign. معرّف المستخدم كخاصية رئيسية (فرعية أو معرّف)، والمفتاح السري المقروء من process.env.JWT_SECRET، ووقت انتهاء الصلاحية المُكوّن.
تتضمن استجابة تسجيل الدخول عادةً بيانات المستخدم الأساسية ورمز JWTحتى يتمكن العميل من البدء في استخدام نقاط النهاية المحمية. باستخدام أدوات مثل Postman أو Insomnia، يمكنك بسهولة تكرار هذه العملية: أولاً، تقوم باستدعاء /login، ثم تنسخ الرمز المميز المُعاد، ثم ترسله في رأس Authorization عند إجراء طلبات إلى مسارات خاصة مثل /clients.
إذا حاولت تعديل الرمز المميز يدويًا، على سبيل المثال عن طريق تغيير الأحرف في الحمولة لمنح نفسك أذونات لا تملكها، لن يكون التوقيع صالحًا بعد الآن وسيرفض برنامج المصادقة الوسيط الطلب. وهذا يُظهر أهمية توقيع HMAC وضرورة وجود سر قوي ومحمي جيدًا.
في بعض المشاريع، بالإضافة إلى بيانات المستخدم، تُستخدم وظيفة التوقيع لإدخال معلمات إضافية مثل معرّف الموارد الموحد لقاعدة البيانات، أو سلاسل عشوائية، أو أوقات انتهاء صلاحية محددةيتم تكوين كل هذا باستخدام متغيرات البيئة ويتم تحميله باستخدام dotenv بحيث تستخدم كل بيئة (التطوير، والتجريب، والإنتاج) قيمها الخاصة.
المصادقة مع جوجل ومزودي خدمات آخرين تابعين لجهات خارجية
بالإضافة إلى تسجيل الدخول التقليدي باستخدام اسم المستخدم وكلمة المرور، تسمح العديد من التطبيقات الحديثة سجّل الدخول باستخدام حسابات جوجل أو فيسبوك أو حسابات مشابهة.الفكرة هي الاستفادة من نظام مصادقة تابع لجهة خارجية، ومن ثم إصدار رمز JWT الخاص بك للاستهلاك الداخلي بواسطة واجهة برمجة التطبيقات الخاصة بك.
لدمج خدمات جوجل، تتمثل الخطوة الأولى في الانتقال إلى وحدة تحكم واجهات برمجة تطبيقات جوجل و إنشاء مشروعبمجرد إنشائها، تقوم بتمكين واجهة برمجة التطبيقات المقابلة (المعروفة سابقًا باسم Google+، والآن باسم خدمات هوية Google) وإنشاء بيانات اعتماد OAuth للويب.
في تلك العملية، عليك أن تقوم بالتكوين أصول جافا سكريبت الموثوقة (النطاقات التي يمكن بدء عملية المصادقة منها) و عناوين إعادة التوجيه المعتمدةأي المسارات الموجودة في تطبيقك والتي يقوم جوجل بإعادة التوجيه إليها بعد مصادقة المستخدم باستخدام حسابه.
عندما يسجل المستخدم دخوله إلى جوجل من واجهة المستخدم، يتلقى تطبيق العميل رمز تفويض. ينتقل هذا الرمز إلى الخادم عبر مسار محدد، على سبيل المثال، /auth/google، حيث تقوم بإنشاء طلب POST إلى نقطة نهاية جوجل، والتي يتم من خلالها تبادل البيانات. رمز التفويض لرمز الوصول.
في هذا الاستدعاء إلى جوجل، تُرسل معلمات مثل الرمز المُستلم، ومعرّف العميل (client_id) وسر العميل (client_secret) المُقدمين من جوجل، وعنوان إعادة التوجيه (redirect_uri) المرتبط، ونوع المنح (grant_type) بقيمة رمز التفويض (authorization_code). إذا نجحت العملية، تُرسل جوجل رمز وصول يُتيح لك الاستعلام عن واجهة برمجة تطبيقات ملف تعريف المستخدم.
باستخدام رمز الوصول هذا، يقوم النظام الخلفي بإرسال طلب GET إلى واجهة برمجة تطبيقات مستخدمي جوجل، مع تمرير رمز الوصول في رأس Authorization بتنسيق Bearer. في حال عدم وجود أخطاء، ستتضمن الاستجابة معلومات ملف تعريف المستخدم. (الهوية، الاسم، البريد الإلكتروني، الصورة، إلخ).
ومن ثم، يكون المنطق مشابهاً لأي عملية تسجيل/دخول: تقوم بالبحث في قاعدة البيانات الخاصة بك لمعرفة ما إذا كان هناك مستخدم لديه معرف الموفر الذي تقدمه لك جوجل؛ إذا كان موجودًا بالفعل، فما عليك سوى إنشاء رمز JWT باستخدام بياناتك الخاصة وإعادته.إذا لم يكن موجودًا، يمكنك إنشاء مستخدم جديد باستخدام معرف الموفر والبريد الإلكتروني والاسم والصورة، وحفظه، ثم إصدار الرمز المميز.
لإنشاء رمز JWT في هذا السياق، من الشائع استخدام خدمة محددة، على سبيل المثال tokenService، والتي تغلف منطق قم ببناء الحمولة وفقًا للمواصفات (sub، iat، exp، والحقول الأخرى مثل البريد الإلكتروني، أو اسم العرض، أو الصورة) ثم قم باستدعاء jwt.sign باستخدام الخوارزمية والمفتاح الخاص المُكوّنين.
وبالتالي، بغض النظر عما إذا كان المستخدم قد سجل الدخول باستخدام جوجل، أو اسم المستخدم وكلمة المرور، أو مزود خدمة آخر، تعمل واجهة برمجة التطبيقات الخاصة بك دائمًا بنفس تنسيق JWTمما يؤدي إلى تبسيط كبير في عملية الترخيص والتحكم في الوصول على بقية نقاط النهاية.
في نهاية المطاف، يُعد دمج مزودي الخدمات الخارجيين طريقة رائعة لتقليل التعقيدات بالنسبة للمستخدم وتفويض جزء من عملية المصادقة إلى أنظمة مجربة وموثوقة، دون التضحية بـ طبقة أمان خاصة بك تعتمد على JWT في الواجهة الخلفية.
إن إتقان JWT في واجهة برمجة تطبيقات Node.js يتطلب فهمًا دقيقًا لبنيتها الداخلية، ومعرفة كيفية توقيع الرموز المميزة والتحقق منها بشكل صحيح، واستخدام برامج وسيطة للمصادقة، وتأمين المسارات المناسبة، ودمجها مع HTTPS، وإدارة الأسرار، وتواريخ انتهاء الصلاحية، وتحديثات الرموز المميزة، وعمليات الإلغاء، وإذا لزم الأمر، دمجها مع عمليات تسجيل الدخول الاجتماعية مثل Google؛ مع تنفيذ كل هذا بشكل صحيح، سيكون لديك أساس متين لبناء خدمات آمنة وقابلة للتوسع وجاهزة للنمو جنبًا إلى جنب مع مشروعك.
