[MUSIC]
في الدروس السابقة،
رأينا عدة أنواع مختلفة من مخططات التوثيق.
بدأنا بالمصادقة الأساسية، ثم نظرنا في كيفية استخدام ملفات تعريف الارتباط
للقيام بالمصادقة، وحتى ملفات تعريف الارتباط الموقعة،
وبعد ذلك، نظرنا في المصادقة المستندة إلى الجلسة.
حيث يتتبع الخادم معلومات حول كل عميل،
ثم سيتم استخدام ملف تعريف الارتباط كطريقة للفهرسة في
قاعدة البيانات من جانب الخادم لاستخراج معلومات إضافية، للتحقق من صحة المستخدم.
الآن، ملفات تعريف الارتباط والمصادقة المستندة إلى جلسة العمل غير قابلة للتطوير،
لأن هناك خادم يحتاج إلى تتبع جميع المستخدمين المختلفين.
على الرغم من ذلك، يتم ذلك خارج بروتوكول HTTP نفسه، ولكن
لا يزال حقيقة أنك تحتاج إلى تتبع
جميع معلومات القسم من موقع الخادم، يجعلها غير قابلة للتطوير للغاية.
لذلك هذا هو المكان الذي
أثبتت المصادقة المستندة إلى الرمز المميز أنها مفيدة للغاية.
سنلقي نظرة على مصادقة قاعدة الرمز المميز أكثر تفصيلاً في هذه المحاضرة
وممارسة ما يلي.
مرة أخرى، مراجعة ملفات تعريف الارتباط والمصادقة القائمة على جلسة العمل بسرعة.
مع المصادقة المستندة إلى ملف
تعريف الارتباط، نلاحظ أن ملفات تعريف الارتباط يتم تخزينها على جانب العميل، ويتم تضمين ملفات تعريف الارتباط
في كل رسالة طلب صادرة حيث يتم تذكير الخادم
بذلك العميل المحدد، عن طريق استخراج المعلومات من ملف تعريف الارتباط.
يمكن استخدام ملف تعريف الارتباط مع جلسات العمل، حيث تقوم ملفات تعريف الارتباط بتخزين معرف الجلسة،
ثم عندما يتلقى الخادم الطلب الوارد من ملف تعريف الارتباط،
فإنه يستخرج معرف الجلسة ويستخدم ذلك كفهرس في
مخزن جلسة العمل من جانب الخادم لاسترداد معلومات جلسة العمل عميل معين.
الآن، هذا النهج كما قلت،
ليس قابلاً للتطوير لأنه إذا كان لديك آلاف الجلسات، يحتاج الخادم إلى
تتبع كل هذه الآلاف من الجلسات على جانب الخادم.
على الرغم من أنه يتم بشكل مستقل عن HTTP في متجر،
إما مخزن ملفات أو قاعدة بيانات.
ولكن
مع ذلك، حقيقة أنك تحتاج إلى تتبع كل هذه المعلومات يجعلها غير قابلة للتطوير.
لذا، مرة أخرى، لتذكيرك مرة أخرى،
لماذا نتحدث عن المصادقة المستندة إلى الرمز المميز؟
المصادقة المستندة إلى الجلسة، كما رأينا سابقًا، تعمل بشكل جيد تمامًا
لتطبيقات الويب ويمكن بسهولة العناية بمصادقة المستخدم.
ولكن بعد ذلك، المصادقة المستندة إلى جلسة العمل، في حين أنه مبدأ
الخوادم عديمة الجنسية ويؤدي أيضًا إلى مشاكل قابلية التوسع.
المسألة الثانية هي، تطبيقات الهاتف المحمول لا
تتعامل مع المصادقة المستندة إلى جلسة العمل بشكل جيد للغاية.
وبالمثل، تواجه تطبيقات الهاتف المحمول صعوبة في التعامل مع ملفات تعريف الارتباط.
لذلك، في مثل هذه الظروف حيث الخادم الخاص بك هو تقديم البيانات
لكل من تطبيق ويب، فضلا عن التطبيق المحمول.
بعد ذلك، لن تكون المصادقة المستندة إلى الجلسة مفيدة جدًا،
وهذا هو المكان الذي تصبح فيه المصادقة المستندة إلى الرمز المميز أكثر سهولة في الاستخدام.
في المصادقة المستندة إلى
الرمز المميز كاسم في المكان، سيصدر الخادم رمزًا مميزًا لمستخدم تم التحقق من صحته
، وستتحمل جميع الطلبات اللاحقة القادمة من جانب العميل الرمز المميز في الطلب نفسه.
إما في شكل رأس طلب أو في نص رسالة الطلب.
علاوة على ذلك، تساعدنا المصادقة المستندة إلى الرمز المميز أيضًا على
التعامل مع ما يسمى مشكلات CORS أو CSRF.
مشاكل مشاركة الموارد عبر الأصل وهلم
جرا، سأتحدث بإيجاز عن التكلفة في الوحدة التالية.
ولكن في الوقت الحالي، تعالج المصادقة المستندة إلى الرمز المميز بعض
المشكلات التي تكمن في السيارات والقضايا المتعلقة بالتزوير عبر الموقع.
ليس ذلك فقط، المصادقة المستندة إلى الرمز المميز هي أكثر سهولة
لتطبيق واحد لمشاركة المصادقة الخاصة به مع تطبيق آخر.
وبطبيعة الحال، يتم كل هذا بطريقة آمنة.
ولكن، مع المصادقة القائمة على جلسة العمل، وهذا ليس مباشرة إلى الأمام.
كيف تعمل المصادقة المستندة إلى الرمز المميز؟
في المصادقة المستندة إلى الرمز المميز،
يحتاج المستخدم أولاً إلى التحقق من صحة نفسه على جانب الخادم.
الآن، يمكن لهذا التحقق أن يأخذ النماذج التي رأيناها في وقت سابق.
حتى نتمكن من استخدام التحقق المحلي باستخدام اسم المستخدم وكلمة المرور.
أو، يمكننا حتى استخدام التحقق من صحة طرف ثالث باستخدام
تقنيات مثل، oauth أو oauth 2.0 أو معرف مفتوح.
سنتحدث بإيجاز عن oauth و oauth 2.0 في الوحدة التالية.
ولكن، بغض النظر عن الطريقة التي يصادق بها المستخدم، بمجرد
مصادقة المستخدم، مباشرة بعد ذلك، يمكن للخادم الخاص بك ببساطة إصدار رمز مميز للمستخدم.
وجميع الاتصالات اللاحقة بين المستخدم
والخادم، ويمكن القيام به ببساطة باستخدام هذا الرمز المميز.
JSON Web Token الذي سنتحدث عنه، هو أحد
مخططات المصادقة المستندة إلى الرمز المميز، وهناك خادم عندما يقوم بإنشاء هذا الرمز المميز، فإنه سيتم إنشاء رمز مميز موقعة.
استخدام سر على موقع الخادم الذي يعرفه الخادم فقط.
وبالتالي، حتى إذا كان طرف ثالث في اتجاه وبين
ويحاول التعامل مع الرمز المميز، حتى لو كان يلتقط الرمز المميز
ويحاول التعامل مع الرمز المميز، سيصبح الرمز غير صالح.
وهكذا، فإن هذه الطريقة لحماية المستخدم
ممكنة بسهولة،
يجب أن تحمل جميع الطلبات اللاحقة من جانب العميل الرمز المميز في الطلب
، إما، كما قلت، في الرأس أو في نص رسالة الطلب.
لذلك عندما يتلقى الخادم هذا الرمز المميز، سيقوم الخادم بالتحقق من الرمز المميز،
للتأكد من أن هذا رمز مميز صالح، ثم إذا كان رمزًا صالحًا،
فسيرد الخادم على الطلب الوارد.
كما ذكرت، فإن رموز JSON Web Tokens هي أحد مخططات المصادقة المستندة إلى الرمز المميز.
JSON Web Token، هي طريقة بسيطة جدًا لترميز
المعلومات في رمز مميز ثم تمريرها إلى موقع العميل.
ويستند جسون ويب رمز نفسه على المعايير،
وهذا يعتمد على إيتف رفك 7519.
IETF هنا، لتقف على فرقة عمل هندسة الإنترنت.
المنظمة التي تكلف كل شيء عن كيفية عمل الإنترنت،
وتتعامل مع البروتوكولات والسياسات، المتعلقة بالإنترنت.
RFC، لتقف على وثيقة المعايير،
في شروط IETF، RFC لتقف على طلب التعليقات.
وكل وثيقة معايير من هذا القبيل تحمل عددا.
7519 في هذه الحالة يشير إلى المستند،
المستند القياسي المتعلق بـ JSON Web Token. رمز
JSON Web Token نفسه هو رمز
مضمن ذاتيا، ويحمل جميع المعلومات في حد ذاته، وهذا ضروري لتحديد المستخدم.
ليس ذلك فقط، يمكن مشاركة JSON Web Token بين تطبيقين.
على سبيل المثال،
يمكن لتطبيق واحد عندما يصادق ثم يحصل على عقد من JSON Web Token، تمرير هذا JSON Web Token إلى وفي
هذا التطبيق، أنه على استعداد للتصريح بالوصول إلى الخادم نيابة عنه.
تتم مشاركة الرمز المميز هذه بطريقة آمنة للغاية،
لذلك لا تقلق كثيرًا بشأن الأمان هناك.
هذا ليس بطريقة آمنة،
حيث من خلال مشاركة الرمز المميز بين تطبيق إلى آخر.
وبالتالي، يتم نقل التفويض إلى تطبيق ثان،
ويمكن للتطبيق الثاني أن يأذن نيابة عن التطبيق الأول،
للتواصل مع الخادم.
هذا ممكن مع الرموز.
الآن بالطبع، من الواضح أن المهندس في داخلك يتساءل ما هو بالضبط
داخل رمز ويب JSON، وكيف يكون مفيدًا؟
يتم ترميز رمز JSON Web Token، كما قلت، في سلسلة طويلة
ويمكن تفسير هذه السلسلة نفسها على أنها تتكون من ثلاثة أجزاء.
السلسلة نفسها يمكن، أو السلسلة المشفرة نفسها تحتوي على ثلاثة أجزاء،
الرأس، الحمولة، والتوقيع.
هذا يحمل معلومات كافية حول كيفية ترميز هذا الرمز المميز.
يحتوي الرأس نفسه على الخوارزمية المحددة التي يتم استخدامها
لترميز رمز ويب JSON هذا، ونوع الرمز المميز نفسه.
الخوارزمية في هذه الحالة، ستكون HS256 وهو مخطط ترميز 256 بت، والذي
يستخدم لتجزئة المعلومات داخل الرمز المميز.
وفي هذه الحالة، يحدث أن يكون هذا هو JSON Web Token، وبالتالي
سيتم تعيين حقل النوع إلى JWT.
وهكذا هذه هي المعلومات التي يتم تخزينها في رأس JSON Web Token.
الحمولة نفسها، يحمل المعلومات التي تساعدك على التعرف على المستخدم.
في التمرين الذي سنقوم به، لا
تحمل حمولة الساعة إلا هوية المستخدم داخل الحمولة.
لا توجد معلومات أخرى ضرورية.
يمكن استخدام هذا المعرف على جانب الخادم،
لفهرسة في DB Mongo لاسترداد معلومات المستخدم الكاملة إذا لزم الأمر.
لذا، سترى أننا سنقوم بترميز المعرف
ثم تخزينه في حمولة تلك الرسالة.
يمكنك تخزين معلومات إضافية في حمولة الرسالة إذا كنت بحاجة إليها.
ولكن كلما زادت المعلومات التي قمت بتخزينها هناك،
كلما كان رمز JSON Web Token مناسبًا لي.
لذا، حاول تحديد مقدار المعلومات التي قمت بتخزينها في حمولة
JSON Web Token.
كما سنرى في التمرين، لدينا وحدة عقدة
تمكننا من ترميز وإنشاء رمز ويب JSON،
استنادًا إلى المعلومات التي نريد وضعها في الحمولة.
الآن، عند إنشاء JSON Web Token، يمكنك أيضًا توفير توقيع.
مفتاح سري على جانب الخادم يستخدم لترميز رمز JSON Web Token هذا،
ويتم تضمين هذا السر أيضًا في جزء التوقيع من JSON Web Token.
يتم تضمين التوقيع نفسه في مثل هذه الطريقة أن
هناك أساسيات قبل رأس المشفرة والحمولة،
والتي يتم بعد ذلك ترميز باستخدام سر معين الذي يستخدمه الخادم.
وهذا مشفر في، كما قلت HMAC،
التي أشرنا إليها في أحد الدروس السابقة
واستخدام تجزئة 256 بت، والتي يتم تضمينها في التوقيع.
لذلك، عندما يتم استلام رمز JSON Web Token هذا على جانب
الخادم، وعندما يقوم الخادم بفك تشفير هذا الرمز المميز، فإن الخادم قادر على عبور التحقق
للتأكد من أن JSON Web Token لم يتم العبث به من قبل أي شخص،
بينما يتم تمرير الرمز المميز بين العميل وموقع الخادم.
حتى إذا كنت تعرف أي شيء عن الأمن،
والمتسللين، وهلم جرا، فإنك تفهم لماذا من المهم ترميز الرمز المميز،
والتحقق من صحة الرمز المميز على موقع الخادم.
كما ذكرت، إذا كنت بحاجة إلى التعامل مع رموز JSON Web Tokens في تطبيق العقدة الخاص بك.
هناك وحدة عقدة محددة تسمى وحدة عقدة jsonwebtoken.
تنفذ وحدة العقدة هذه المعايير ذات الصلة JSON Web Token،
ويمكن تضمينها في تطبيق العقدة الخاص بك.
توفر هذه الوحدة نفسها طريقة تسمى علامة والتي تسمح لك بالتوقيع
وإصدار الرمز المميز للعميل من جانب الخادم.
كما أنه يحتوي على طريقة التحقق.
والتي يمكن استخدامها للتحقق من الأصالة أو
لضمان صحة رمز JSON ويب الوارد،
لذلك سنستخدم وحدة JSON Web المميزة، في ممارستنا.
جنبا إلى جنب مع وحدة JSON Web Token،
استخدمنا أيضا وحدة Passport-JWT، وحدة العقدة.
الذي يوفر الاستراتيجيات المستندة إلى jwt لوحدة مصادقة جواز السفر لدينا.
لذلك يوفر هذا استراتيجية جواز سفر للمصادقة باستخدام JSON Web Token.
لذلك يسمح لك هذا بمصادقة نقطة النهاية RESTful باستخدام JWT كطريقة
للتحقق من الصحة، دون الحاجة إلى الخادم لاستخدام الجلسات.
الآن، وحدة جواز السفر JWT،
تدعم طريقة حتى استخراج رمز JWT من
رسالة الطلب الواردة، ومن ثم التحقق من الرمز المميز نيابة عنك.
يستخدم متدرب الوحدة النمطية Passport-JWT، وحدة JSON Web Token
للقيام بالتحقق من هذا JSON Web Token.
يمكن حمل الرمز المميز نفسه في رأس الطلب الوارد،
في الرأس، حتى في رأس المصادقة للطلب الوارد،
وهو ما سنقوم به في التمرين.
يمكن أيضًا حمل الرمز المميز في نص الطلب الوارد، وفي هذه الحالة،
يجب علينا استخراج الرمز المميز من نص الطلب الوارد
ثم الاستفادة منه.
وحدة Passport-JWT، تدعم ذلك أيضًا إذا اخترت
استخدام ذلك كطريقة لتمرير الرمز المميز مرة أخرى من العميل إلى موقع الخادم.
يمكن تضمين JSON Web Token أيضًا في معلمات استعلام URL إذا
اخترت ذلك، ويمكن استخراجها من هناك b Passport-JWT
واستخدامها للمصادقة.
الآن، مع هذا الفهم السريع لـ JSON Web Tokens
وكيف تكون مفيدة، سننتقل إلى التمرين حيث سنستخدم وحدة
Passport-JWT، جنبًا إلى جنب مع وحدة JSON Web Token،
ونقوم بتكوين خادم Express Rest API لاستخدام JSON Web Tokens.
[ موسيقى]