(وصف الموضوع)
في ظل حيرة المبتدئين عن ماهية الAuthorization أيسر لهم العسير وأجمع لهم ما استعصى عليهم جمعه وفهم عسى أن يقّربهم ذلك من مبتغاهم ولو حتى بالشيء القليل مستخدما العامّيّة المصريّة لنيل المراد وتذليلا لصعوبة الفهم، فإن أخطأت فالخير أردت، وإن أصبت فالحمد لله
فكرة الـ authintication فكرة بسيطة جدًا بتتلخص في إثبات ادعائك إنك الشخص المالك للحساب اللي بتحاول تسجل بيه.
ده اختصار للموضوع وهو الفكرة الـ abstracted للمستخدم العادي.
بس لما تيجي تغوص فيها وفي آلية عملها من ورا الكواليس هتعرف الصداع الحقيقي بيبدأ من فين بالظبط (في كل مكان).
وعشان كده هنقسم الموضوع إلى 3 أجزاء هنتكلم فيهم عن:
#1 ما يحدث عند تسجيل الحساب أول مرة (signup) والطريقة اللي بيتم بيها حفظ كلمة السر.
#2 الحل الأريح.
#3 المصادر.
لما تيجي تسجّل لأوّل مرة في أي موقع بيتم حفظ كل بياناتك بشكل طبيعي في قاعدة البيانات، الا حاجة وحدة بس وهي كلمة السر (password) الخاص بيك، واللي الشغل فيها بيبدأ من اللحظة اللي بتسجل فيها وتبعت بياناتك للسيرفر،
كل البيانات بتتحفظ عادي ك(plain text) الا كلمة السر بتخضع لنوع معيّن من أنواع التشفير أو ما يعرف بالHashing (في فرق بين التشفير الطبيعي والhashing بس ده تبسيط مخل لتسهيل وصول المعلومة لحد ما أوضّح الفرق)
وخليني هنا أرغيلك شوية عن “ما هو الHashing؟”
عندنا مبدأ جميل جدا في البرمجة اسمه Hashing يمكن تكون مريت عليه في الdata_strucure وانت بتذاكر الhashmap بس يمكن اللي هقوله فيه شيء من التفصيل ف المهم معانا دلوقتي هو عملية الhashing ازاي بتتم، واللي لازم تتوفر فيه عدد من الشروط عشان يكون “Hashing” مش مجرد “Encryption”
1- إنه يكون (determinate) يعني لو كتبت anas وكان ناتج التشفير ده بالخوارزمية اللي انت مستخدمها (ده موال طويل) كل مرة لازم الشفرة اللي هتطلع تكون وحدة مهما كان عدد المرات اللي كررت فيها العملية دي
2- انها تكون (irreversible) يعني لو كتبنا anas مرة تانية وكان ناتج التشفير هو x منقدرش نعكس العملية ونستنتج anas من الرمز x، ويمكن الكلام ده ميكنش أدق حاجة لان في تشفير بيتكسر بسهولة بالbrute force بس كل ما زاد مستوى التشفير كان توقع ايه هو فعلا أصعب وبياخد وقت وفي أغلب الأوقات مش هيوصله
3- انه يكون خاضع لتأثير الavalanche وهو ان اي تغيير بسييط من زيادة حرف او حذف حرف او حتى تغير ترتيب هيغير الشفرة بشكل كامل
4- ودي بتكون نتيجة ل3 انه عمره ما هيحصل collision وهو ان الشفرة اللي بتطلع كout put مستحيل يكون فيها احتمالات زي انها تكون بترمز لكلمة السر anas وanaaas في نفس الوقت
بس مازال في مشكلة حاضرة عندنا هنا وهي ان لو الهاكر اللي بيحاول يخترق حسابك عارف خوارزمية الhashing ومعاه قائمة بكلمات السر المشهورة مثلا او توقعات لpassword حساب بعينه، فهو هيفضل يحاول وهيطلّعها في الآخر، هياخد وقت أيوة، بس في احتمال ينجح (الاحتمال ده خطر على سمعة الشركة وأمان عملاءها)
فطلّعوا طريقة تانية أشد أمانا وهي إضافة الSalt فمبقوش يشفروا كلمة السر لوحدها لا، بقى في عدد معين من الرموز العشوائية بتضاف لكلمة السر بتاعتك وبتتضاف ليها وبيتشفروا سوا، (الsalt بيكون متخزن في قاعدة البيانات برضه)، بس لان كل كلمة سر ليها الsalt بتاعها فده بيمنعهم يعملوا هجمات تقيلة وسريعة (تحديدا الrainbow tables) حتى على افتراض ان كلمات سر المستخدمين كلها وحدة
طيب خلصنا المرحلة دي، وحاليا وصلنا للlogin العادي، حفظنا كلمات السر وقفلنا عليها بالمفتاح والأمور تمام، بس السؤال… بالتشفير اللي عملناه، أنا صاحب الحساب هسجل الزاي؟ ده سؤال ظريف واجابته أظرف، انت كصاحب الحساب مهتم بايه؟ مش بس انك تدخل؟ انت مش مهتم بأي حاجة من الحجات المجعلصة دي
فهنترجم طلبك ل”بس اتأكدلي ان الكلمة دي هي نفس اللي عندك جوا وخلاص”، وهو ده اللي بيحصل فعلا هو بيقارن كلمة السر بعد ما يضيف ليها الsalt ويشفرها بخوارزمية التشفير المستعملة واذا اتطابقوا بيبعت اذن الدخول، وهنا هندخل في شرح النقطة اللي انا عملت المسرحية دي كلها عشانها وهو الفرق بين الJWT والSession،
ومحتاجك تكون فاهم حجات بسيطة جدا من النتوورك عشان تستوعب اللي هقوله، كل أمر “request” المستخدم بيبعته للسيرفر عشان يعالجه سواء اضافة صورة للانستقرام أو إضافة منتج لسلة المشتريات، هو ازاي بيعرف ان المنتج ده يتضاف لسلة أنس مش محسن مثلا، لازم يكون عارف ان الطلب ده مبعوت من حساب انس، وهنا عندك كمبرمج backend خيارين يا تستعمل الstateless أو الstateful، وخلينا ندبأ بالطريقة الأقدم وهي الsession
آليته بتبدأ انك اول ما تسجل دخول لحسابك بيكون في جدول للsessions متكوّن عندك في قاعدة البيانات، الserver بيعملك (session id) خاص بيك وبيبعتهولك عشان يتخزن عندك في الcookies فأي طلب بيتبعت منك بيكون معاه الcookies جوا الHeaders اللي بتروح للسيرفر، واللي بدوره بيدوّر عنده في جدول السيشن “أوه ده أنس إعمله اللي هو عايزه يعم”
– السيرفر
في مشاكل عظيمة طبعا في الحوار ده وهي انك لو فكرت تتوسع وتخدّم على عدد كبير من المستخدمين لازم الجدول ده يكون معروف لكل السيرفرات ولازم يكون بيتم تحديثه باستمرار عشان يتعاملوا معاه بصورة صحيحة، بس لان مفيش حاجة كاملة هيكون في عبئ كبير لازم تكون عامل حسابك ليه (هندخل في زحمة الsystem design وده مش موضوعنا بالمرة) وعشان كده دي اسمها (stateful authentication) لانها لازم تكون محفوظة في قاعدة البيانات، ده غير مشكلة تانية ممكن تقرأ عنها أكتر في ما يخص هجمات الCSRF (Cross-Site Request Forgery) او ممكن أكتب عنها بعدين مش متأكد،
النوع التانية وهو الJWT او ( JSON Web Token) وهو عكس الsession لانه (**stateless** authentication) مبيهلكش السيرفر ومبيحتجش لوجود جدول إضافي محفوظ في قاعدة البيانات (الDATA BASE) بسبب انها بتعتمد على فكرة الTokens اللي السيرفر بينشئها (generate) بعد عملية تسجيل الدخول وبيبعتها للمتصفح بتاعك واللي بدوره بيحفظها عنده على شكل كوكيز أو في ال(local Storage) ومع كل request بيبعتها بيبعت الToken دي معاه واللي ممكن يبطأ العملية شوية، بس ده مطلوب عشان يتأكد فعلا انك انت الشخص اللي باعتها مش حد تاني بيحاول ينتحل هويتك،
ومعلومة مهمة ان الtoken صلاحيتها مبتنتهيش غير بعد ما الوقت اللي السيرفر يخلّص (انت بتحدد الوقت اللي الToken دي تفضل شغالة فيه)، وبيكون متقسم ل3 أقسام
1- الHeader وبيكون فيه الخوارزمية ونوع الtoken،
2- الPayload وده بيكون فيه معلومات المستخدم ودوره المسموحله بيه،
3- وأخيرا ثالث حاجة وهي الSignature ودي اللي بتتأكد ان الToken بتاعك مخوّلة فعلا انها تتم العملية دي وانها مش ملعوب فيها، لانه اساسا بيتكون من الHeader والPayload متشفرين مع بعض بSecret Key
وطبعا حتى الطريقة دي ليها مشاكل ومعرضة لنوع معين من أنواع الاختراق زي أي حاجة تانية موجودة على الانترنت ذات قيمة وممكن الHacker يستفيدوا من الحصول عليها سواء عن طريق هجمات الXSS أول CSRF أو سرقة الTokens بأي طريقة كانت
النوع التانية وهو الJWT او ( JSON Web Token) وهو عكس الsession لانه (**stateless** authentication) مبيهلكش السيرفر ومبيحتجش لوجود جدول إضافي محفوظ في قاعدة البيانات (الDATA BASE) بسبب انها بتعتمد على فكرة الTokens اللي السيرفر بينشئها (generate) بعد عملية تسجيل الدخول وبيبعتها للمتصفح بتاعك واللي بدوره بيحفظها عنده على شكل كوكيز أو في ال(local Storage) ومع كل request بيبعتها بيبعت الToken دي معاه واللي ممكن يبطأ العملية شوية، بس ده مطلوب عشان يتأكد فعلا انك انت الشخص اللي باعتها مش حد تاني بيحاول ينتحل هويتك، ومعلومة مهمة ان الtoken صلاحيتها مبتنتهيش غير بعد ما الوقت اللي السيرفر يخلّص (انت بتحدد الوقت اللي الToken دي تفضل شغالة فيه)، وبيكون متقسم ل3 أقسام 1- الHeader وبيكون فيه الخوارزمية ونوع الtoken، 2- الPayload وده بيكون فيه معلومات المستخدم ودوره المسموحله بيه، 3- وأخيرا ثالث حاجة وهي الSignature ودي اللي بتتأكد ان الToken بتاعك مخوّلة فعلا انها تتم العملية دي وانها مش ملعوب فيها، لانه اساسا بيتكون من الHeader والPayload متشفرين مع بعض بSecret Key وطبعا حتى الطريقة دي ليها مشاكل ومعرضة لنوع معين من أنواع الاختراق زي أي حاجة تانية موجودة على الانترنت ذات قيمة وممكن الHacker يستفيدوا من الحصول عليها سواء عن طريق هجمات الXSS أول CSRF أو سرقة الTokens بأي طريقة كانت
فانت تعمل ايه لو هتعمل مشروع لنفسك؟ ريّح دماغك من الوّش ده كله، والباب اللي يجيلك منه الريح سده واستريح وخلي تسجيل الدخول يكون بجوجل أو جيتهاب (طبعاً لازم في الحالتين كمبرمج تكون فاهم المبدأ وقادر تشتغل بيه بغض النظر عن جوجل وغيرها) وده الخيار اللي موجود في مواقع جميلة جداً زي http://enjazat.io اللي عمله البشمهندس @mahyoussef_
عملاً بنفس مبدأ إضافة Stripe للمواقع عشان الدفع يكون من خلالها، باعتبارها متخصصة في ده أصلاً.
مقالات موقع Medium:
https://akcoding.medium.com/what-is-jwt-json-web-token-purpose-structure-and-use-cases-a3283ab0e6ef
اليوتيوب: