ما هو التوكن؟ في عالم البرمجة، التوكن (token) سلسلة أحرف عشوائية لا يمكن تخمينها، يستخدمها النظام ليعرف من يطلب ماذا: مفتاح API، جلسة تسجيل دخول، رابط إعادة تعيين كلمة المرور. ولا علاقة له هنا بتوكنات العملات الرقمية. لو كنت مطوّرًا في الرياض أو القاهرة أو دبي تربط متجرك ببوابة دفع وتحتاج 20 مفتاحًا تجريبيًا لبيئة الاختبار قبل أول عملية بقيمة 100 ريال، فهذه الأداة تنشئها لك في ثانية، داخل متصفحك، دون أن تفتح سطر الأوامر.
ما هو مولّد التوكن، في فقرة واحدة
التوكن سلسلة نصية لا يمكن تخمينها، يستخدمها النظام لتمييز شيء ما: طلب API، أو جلسة، أو رابط دخول بنقرة واحدة، أو طلب إعادة تعيين كلمة مرور. مولّد التوكن ينشئ هذه السلاسل بعشوائية آمنة تشفيريًا: كل حرف مأخوذ من crypto.getRandomValues، وهو مولّد أرقام عشوائية آمن تشفيريًا (CSPRNG) من النوع الذي توصي به OWASP لمعرّفات الجلسات. أنت تختار الطول، ومجموعة الأحرف، وبادئة اختيارية على طريقة الشركات الكبرى، والأداة تُنتج توكنًا واحدًا أو دفعة تصل إلى خمسين.
ليس بديلًا عن مولّد كلمات المرور (المصمَّم لكلمات مرور يكتبها البشر، مع مقياس قوة وزر إظهار وإخفاء). إنه بديل عن فتح Node REPL وكتابة require('crypto').randomBytes(32).toString('hex').
كيف يعمل مولّد التوكن من Microapp
اسحب شريط التمرير لتحديد الطول (من 8 إلى 128 حرفًا). اختر مجموعة الأحرف: الأبجدية الرقمية هي الخيار الافتراضي الذي يصلح في كل مكان، وhex للسلاسل المناسبة للروابط، وbase64-url وهي الأبجدية التي تستخدمها JWT وتوكنات OAuth، والأرقام فقط لرموز التحقق بأسلوب الرسائل النصية، وhex بالأحرف الكبيرة حين تحتاج HEX مقروءًا للأنظمة. أضف بادئة اختيارية مثل tk_ أو sk_live_ أو pk_ (حتى 16 حرفًا). شركة Stripe هي من جعلت هذه العادة شائعة، وواجهات API الحديثة تتبعها لأن البادئة تخبرك بنوع التوكن من النظرة الأولى. حدّد الكمية (من 1 إلى 50) إن احتجت عدة توكنات دفعة واحدة. اضغط زر الإنشاء، ثم انسخ كل توكن على حدة، أو انسخ الدفعة كلها بزر «نسخ الكل» الذي يظهر حين تُنشئ أكثر من توكن.
كل بايت من العشوائية يأتي من crypto.getRandomValues. لا يوجد Math.random في أي مكان من المسار، فهذه الدالة قابلة للتنبؤ بما يكفي لكسرها بالتخمين في ثوانٍ. لا شيء يغادر متصفحك، والتوكنات التي تراها هي النسخة الوحيدة الموجودة منها.
sk_test_، وطول 24، ومجموعة أحرف أبجدية رقمية. النتيجة: 20 توكنًا مختلفًا، كلٌّ منها على شكل sk_test_aB8cD9eF1gH2iJ3kL4mN5oP6. ضعها في جدول بيانات الاختبار، فاحتمال أن يتكرر أيٌّ منها مع الآخر ضئيل إلى حدٍّ لا معنى عمليًا له.
ماذا يعني طول التوكن فعلًا
أمان التوكن لا يتعلق بالطول بحد ذاته، بل بالإنتروبيا (مقدار العشوائية). التوكن الأبجدي الرقمي المكوَّن من 32 حرفًا له 6232 قيمة ممكنة، أي نحو 1057 (قرابة 190 بت). لكسره بالتجربة، يحتاج المهاجم إلى تجربة عدد من التوكنات يفوق ما تستطيع كل حواسيب العالم مجتمعةً تجربته خلال عمر الكون. هذا أمان من النوع الذي لا داعي للقلق بشأنه.
في معظم الاستخدامات، 32 حرفًا أبجديًا رقميًا هو الطول المثالي: طويل بما يكفي ليستحيل تخمينه، وقصير بما يكفي ليظهر في السجلات دون أن يملأ السطر، وسهل النسخ بنقرة ثلاثية. الذهاب إلى 64 لا يضيف أمانًا حقيقيًا، بل يضيف مساحة تخزين وزحامًا بصريًا. أما تحت 16 حرفًا فهامش الأمان يتقلص، وبسرعة كبيرة مع مجموعات الأحرف الضيقة: 16 رقمًا فقط تعطي نحو 53 بت، وهذا قليل لهدف ثمين.
أي مجموعة أحرف تختار
| مجموعة الأحرف | الأنسب لـ | السبب |
|---|---|---|
| أبجدية رقمية | مفاتيح API، معرّفات الجلسات | الخيار الافتراضي العام: تعمل في كل مكان، ولا تحتاج إلى أي ترميز خاص |
| Hex (أحرف صغيرة) | الروابط، أسماء الملفات | آمنة في الروابط، ولا التباس بين الأحرف الكبيرة والصغيرة |
| Base64-url | JWT، توكنات OAuth | أبجدية أوسع = إنتروبيا أكثر لكل حرف |
| أرقام فقط | رموز التحقق عبر الرسائل النصية | سهلة الكتابة على لوحة الأرقام |
| Hex (أحرف كبيرة) | سجلات الأنظمة، معرّفات قواعد البيانات | واضحة بخط ثابت العرض، ومعيار في كثير من الأنظمة |
ما فائدة البادئة
البادئة مثل tk_ أو sk_live_ أو ghp_ تخبر كل من يجد التوكن في سجل، أو في مستودع كود، أو في رسالة على Slack، بنوع السر الذي أمامه. Stripe هي من نشرت هذه الممارسة: sk_ تعني مفتاحًا سريًا، وpk_ مفتاحًا قابلًا للنشر، و_live_ مقابل _test_ تحدد البيئة. GitHub تبنّتها (ghp_، gho_، ghs_)، وSlack تفعلها أيضًا (xoxb-، xoxp-).
لمسة صغيرة تمنع ارتباكًا هائلًا وقت الحوادث: حين يرفع مهندس مبتدئ توكنًا بالخطأ إلى مستودع عام، تخبر البادئة فريق الأمن خلال ثوانٍ هل عليهم تغيير مفتاح دفع حقيقي في بيئة الإنتاج، أم مجرد توكن API تجريبي. تستحق الأحرف الأربعة الإضافية.
أخطاء شائعة
استخدام Math.random. مغرٍ لأنه أقصر في الكتابة، وكارثي لأن Math.random مولّد شبه عشوائي حتمي يعتمد على حالة النظام، ومع عينات كافية يستطيع المهاجم توقّع القيمة التالية. لا تُنشئ توكنات بـ Math.random أبدًا. مولّد التوكن يستخدم crypto.getRandomValues وحده لهذا السبب تحديدًا.
تخزين التوكنات نصًا صريحًا. التوكنات تعمل مثل كلمات المرور: تمنح صلاحية الدخول. خزّنها مُجزّأة (hashed) على الخادم (bcrypt أو Argon2، أو SHA-256 للتوكنات العشوائية الطويلة)، وأرسلها إلى العميل مرة واحدة عند الإنشاء، ودع العميل يحتفظ بالقيمة. إن اختُرقت قاعدة بياناتك، فالتوكنات المجزّأة لا تفيد المهاجم بشيء.
بلا تاريخ انتهاء. التوكن الذي لا تنتهي صلاحيته يصبح خطرًا دائمًا. حدّد دائمًا تاريخ انتهاء (حقل exp في JWT، أو مدة صلاحية TTL على صف قاعدة البيانات في غير ذلك) وأعد إصدار التوكنات دوريًا.
استخدام السر نفسه في كل البيئات. توكنات الإنتاج يجب أن تختلف عن توكنات بيئة التجهيز (staging)، وهذه تختلف عن بيئة التطوير. عادة البادئات تساعد على فرض ذلك: إن أنشأت بيئة التطوير لديك توكنًا يبدأ بـ sk_live_ بالخطأ، فهذه إشارة تحذير واضحة.
أدوات ذات صلة
لكلمات المرور التي يكتبها البشر مع مقياس للقوة، استخدم مولّد كلمات المرور. للمعرّفات الفريدة (UUID) التي تُستخدم مفاتيح أساسية في قواعد البيانات، مولّد UUID هو الخيار المناسب. لتجزئة التوكن قبل تخزينه، يغطي مولّد SHA-256 معظم الحالات. للرموز التي تُستخدم مرة واحدة (TOTP / التحقق بخطوتين)، راجع مولّد OTP. وللتوكنات المنظَّمة الموقَّعة التي تحمل بيانات (JWT)، استخدم مولّد توكن JWT.