ما هي رموز الحامل (Bearer Tokens)؟
تعرّف على رموز الحامل، وكيفية عملها في OAuth 2.0 و JWT، وما الفرق بينها وبين رموز الوصول، وأفضل الممارسات.
خلف كل تسجيل دخول لتطبيق حديث أو طلب API تقريبًا، يوجد بطل هادئ: رمز الحامل. قد لا تلاحظ وجوده، لكنه موجود في كل مرة تربط فيها خدمات، أو تسجّل الدخول، أو تجلب بيانات من السحابة.
يستعرض هذا الدليل ما تفعله رموز الحامل، ولماذا هي مهمة، وكيفية التعامل معها بأمان.
ما هو رمز الحامل؟
رمز الحامل هو بيانات، عادةً سلسلة من الأحرف، يثبت أن حامل الرمز مخوّل للوصول إلى مورد ما. الشيء الأهم هو أن من يحمل الرمز يمكنه استخدامه، دون الحاجة لتقديم إثبات إضافي.
تخيل بطاقة صعود الطائرة (Boarding Pass) الخاصة بشركة طيران. بمجرد أن تمتلكها، يمكنك المرور من الأمن وركوب الطائرة. لا يطلب منك أحد إثبات الهوية مجدداً إذا كانت البطاقة صالحة. بنفس الطريقة، يسمح رمز الحامل لتطبيقك "بركوب الـ API" دون التحقق من هويتك في كل مرة.
مثلاً، بعد تسجيل الدخول إلى سبوتيفاي (Spotify) على هاتفك، لا تحتاج إلى إدخال كلمة المرور كلما أردت تشغيل أغنية. بدلاً من ذلك، يخزن التطبيق رمز الحامل الذي يخبر خوادم سبوتيفاي: "هذا الطلب يأتي من مستخدم مخوّل".
كيف تعمل رموز الحامل عملياً
يمكن تلخيص تدفق رموز الحامل في خطوات:
-
تسجيل المستخدم الدخول
لنفترض أنك سجلت الدخول إلى تطبيق مصرفي باسم المستخدم وكلمة المرور.
-
مزود الهوية يصدر الرمز
بعد التحقق، يرسل خادم المصادقة رمز حامل. قد يبدو كالتالي:
-
العميل يستخدم الرمز
في كل مرة تضغط فيها "فحص الرصيد" أو "تحويل أموال"، يرسل التطبيق الرمز مع طلب HTTP:
-
الـ API يتحقق منه
يتحقق الخادم من أن الرمز لا يزال صال حاً، وغير منتهي الصلاحية، ويشمل الصلاحيات المطلوبة (مثل
read:balance
أوwrite:transfer
). -
يتم منح الوصول
إذا نجحت جميع عمليات التحقق، يستجيب الخادم بالمعلومات المطلوبة.
يُستخدم هذا النموذج على نطاق واسع في خدمات مثل GitHub APIs، حيث يصادق المطورون باستخدام رمز حامل بدلاً من إدخال بيانات الاعتماد في كل مرة.
لماذا أصبحت رموز الحامل شائعة
اكتسبت رموز الحامل شعبيتها لأنها حلت مشاكل شائعة في أمان الويب. على عكس الجلسات المبنية على الخادم، لا تتطلب تخزين بيانات لكل مستخدم مسجّل دخول. بدلاً من ذلك، يحتوي الرمز ذاته على معلومات كافية تسمح للخادم بالتحقق.
على سبيل المثال، في بنية خدمات مصغرة (مايكروسيرفس)، حيث تتواصل العديد من الخدمات مع بعضها البعض، سيكون الحفاظ على تخزين مركزي للجلسات أمرًا معقدًا وغير فعّال. باستخدام رموز الحامل، يمكن لكل خدمة التحقق من الطلبات بشكل مستقل، مما يجعل النظام خفيف الوزن وقابل للتوسع.
مثال عملي: تعتمد واجهات برمجة تطبيقات Slack بشكل كبير على رموز الحامل. عندما تبني روبوت Slack، تحصل على رمز يسمح لروبوتك بالوصول إلى نقاط Slack دون الحاجة لإدارة جلسة لكل مستخدم.
ما بداخل رمز الحامل؟
يتم تنفيذ العديد من رموز الحامل كـ JWTs (رموز JSON ويب). هذه الرموز عبارة عن سلاسل مشفّرة تتضمن معلومات عن المستخدم وصلاحياته.
لنقم بفك ترميز JWT كمثال:
هذا معناه:
sub
: الموضوع أو معرف المستخدم الفريد.name
: اسم المستخدم.iat
: وقت الإصدار.exp
: وقت انتهاء الصلاحية (عندها يصبح الرمز غير صالح).scope
: الصلاحيات الممنوحة، في هذه الحالة السماح للتطبيق بقراءة وكتابة الرسائل.
في الواقع، إذا كان رمز جين يحتوي فقط على النطاق read:messages
، سيستطيع التطبيق جلب رسائلها دون إرسال رسالة جديدة باسمها.
رموز الحامل مقابل رموز الوصول: ما الفرق؟
من السهل الخلط بين رموز الحامل و**رموز الوصول** لأن المصطلحين كثيراً ما يظهران معاً. في الواقع، هما مرتبطان لكنهما غير متطابقين.
رمز الوصول: "إذن الدخول"
رمز الوصول هو اعتماد يمثل ترخيص المستخدم للوصول إلى مورد. يتضمن معلومات مثل:
- من هو المستخدم (معرّفه)
- ما المسموح له فعله (النطاقات/الصلاحيات)
- متى ينتهي الرمز
فكر فيه كـ إذن دخول موقع من مدير المدرسة. يخبر المدرس (API) بأنك مسموح لك بالخروج في الرحلة (الوصول للمورد).
مثال: عند تسجيل الدخول إلى خدمة تخزين سحابي، يصدر النظام رمز وصول بنطاق read:files
. هذا الرمز يخبر API التخزين: "يمكن لهذا المستخدم قراءة الملفات، لكن لا يمكنه حذفها".
رمز الحامل: "صيغة التسليم"
رمز الحامل هو نوع من رموز الوصول. كلمة حامل تصف كيفية استخدام الرمز: كل من يقدمه يمكنه "حمله" للوصول للموارد، دون إثبات هوية إضافي.
بعبارة أخرى:
- كل رموز الحامل هي رموز وصول.
- ليست كل رموز الوصول بالضرورة رموز حامل.
هناك أنواع رموز أخرى، مثل رموز الحامل للمفتاح (holder-of-key)، التي تتطلب من العميل إثبات امتلاكه لمفتاح تشفير بجانب الرمز. رموز الحامل تتجنب هذه الخطوة الإضافية، مما يجعلها أبسط لكن أكثر خطورة إذا تم سرقتها.
مثال عملي
- رمز وصول (عام): قد يكون بيانات موقعة، أحيانًا يُطلب من العميل إثبات امتلاكه لمفتاح خاص أيضًا.
- رمز حامل (محدد): معظم تطبيقات OAuth 2.0 اليوم تصدر رموز وصول بصيغة الحامل. مثلاً، يُرجع Google OAuth رمز وصول يستخدم في عنوان Authorization: Bearer
<token>
.
يعني هذا أنه عندما ترى عبارة "رمز الوصول" في شروحات OAuth، فعادةً يقصد بها رمز حامل إلا إذا تم التوضيح خلاف ذلك.
مقارنة بأنواع رموز أخرى
لتوضيح الصورة أكثر، لنقارن رموز الحامل بأنواع الرموز الشائعة الأخرى:
- رمز التحديث (Refresh token): يُستخدم للحصول على رمز وصول جديد بعد انتهاء القديم. رموز التحديث عادةً ليست رموز حامل، لأنها تُستخدم بشكل آمن مع خادم التفويض ولا تُرسل مباشرة إلى الـ APIs.
- رمز الهوية (ID token): يُستخدم للمصادقة وليس التفويض. يحمل معلومات هوية المستخدم (مثل البريد، الاسم، أو المعرّف). حسب النظام، يمكن أن يكون رمز الهوية أيضاً رمز حامل، لكن هدفه يختلف عن رمز الوصول.
- مفتاح API (API key): شكل أبسط من الاعتماد يحدد التطبيق المتصل. في حالات كثيرة، تعمل مفاتيح الـ API كرموز حامل، حيث كل من يمتلك المفتاح يمكنه استخدام الـ API.
رموز الحامل ورموز الوصول ليستا متضادتين — بل مرتبطتان:
- غالبية رموز الوصول هي رموز حامل.
- رمز الحامل يصف شكل استخدام الرمز (قدمه للوصول).
- في الاستخدام اليومي، غالبًا ما يُستخدم مصطلحا "رمز الوصول" و"رمز الحامل" بالتبادل، لكنهما تقنيًا يركزان على جوانب مختلفة.
كيفية التحقق من صحة رمز وصول JWT (رمز حامل)
التحقق من صحة رمز الحامل هو ما يفصل بين API الخاص بك والوصول غير المصرح به. إذا كانت رموزك JWT، يحدث التحقق محليًا وبسرعة. يمكن للـ API التحقق من الرمز دون الرجوع لمصدره كل مرة.
الفكرة الأساسية
- فك الرمز.
- تحقق من التوقيع باستخدام المفتاح العام للجهة المصدرة.
- تحقق من البيانات الأساسية مثل المصدر (issuer) ، الجمهور (audience)، انتهاء الصلاحية، وعدم الصلاحية قبل وقت معين (nbf).
- تطبيق قواعد التطبيق مثل النطاقات، الأدوار، ونوع الرمز.
- اختياريًا: مراجعة قوائم الإبطال أو حالة الجلسة للعمليات عالية الخطورة.
قائمة تحقق التحقق (JWT)
استخدم هذا كدليل عملي عند بناء بوابة API أو وسيط (middleware).
-
التوقيع
تحقق من التوقيع باستخدام الخوارزمية الموجودة في العنوان (مثلاً RS256). اجلب نقطة JWKS للجهة المصدرة، اختر المفتاح المناسب لـ kid، وقم بتخزينه مؤقتاً.
-
المصدر (iss)
طابق قيمة iss في الرمز مع عنوان الجهة المصدرة الموثوق، بدقة وببروتوكول صحيح.
-
الجمهور (aud)
تأكد أن الرمز مخصص لـ API الخاص بك. قارن مع معرف الـ API الخاص بك مثل https://api.example.com أو سلسلة جمهور منطقية.
-
انتهاء الصلاحية (exp) وعدم الصلاحية قبل (nbf)
ارفض الرموز المنتهية. احترم قيمة nbf بحيث لا يمكن للرمز أن يُستخدم قبل وقته. عادةً يسمح بتحيز زمني بسيط (30 إلى 60 ثانية).
-
وقت الإصدار (iat)
مفيد لاستكشاف الأخطاء ورفض الرموز القديمة جدًا في البيئات الصارمة.
-
نوع الرمز
تأكد أنه رمز وصول. بعض المزودين يضيفون typ: "at+jwt" أو ما شابه. لا تقبل رموز الهوية للوصول إلى الـ API.
-
النطاقات / الصلاحيات
اقرأ scope أو مطالبات المزود الخاصة (مثل صلاحيات، أدوار). طبق أقل صلاحية مطلوبة في كل نقطة نهاية.
-
الموضوع (sub)
معرف المستخدم أو العميل المستقر. استخدمه لربط الموارد وإجراء مراقبة.
-
الحماية من التكرار والإبطال (اختياري لكنه حكيم)
للنقاط الحساسة، تحقق من قائمة رفض قصيرة المدى لقيم jti، أو تحقق من سجل جلسة نشط. هذا مفيد بعد تسجيل الخروج أو في حالة الاشتباه بالاختراق.
مخاطر رموز الحامل الأمنية
نظرًا لأن رموز الحامل هي "كل من يحملها يمكنه استخدامها"، يجب التعامل معها كما لو كانت مفاتيح منزلية. إذا سرق أحدهم المفتاح، يمكنه فتح الباب حتى تغير القفل.
تشمل المخاطر الشائعة:
- سرقة الرمز – إذا تمكن مخترق من الوصول إلى localStorage على المتصفح حيث يُخزن الرمز، يمكنه انتحال المستخدم. مثلاً، اكتُشف في 2018 بعض الإضافات تسرق الرموز من localStorage وتبيعها.
- هجمات إعادة الاستخدام (Replay) – إذا اعترض المهاجم الرمز، يمكنه استخدامه مجددًا حتى انتهاء صلاحيته. من السهل تحقيق ذلك بدون HTTPS.
- رموز طويلة الأمد – إذا كان الرمز صالحًا لأسابيع أو شهور، يزداد احتمال استغلاله.
حوادث حقيقية حدثت عندما قام مطورون عن طريق الخطأ بإدراج رموز الحامل في مستودعات GitHub عامة. يمكن للمهاجمين البحث عن هذه الرموز واستغلالها فورًا للوصول غير المصرح به.
أفضل الممارسات لاستخدام رموز الحامل
لاستخدام رموز الحامل بأمان، من المهم اتباع أفضل الممارسات. لنستعرضها بالأمثلة:
-
استخدم HTTPS دائمًا
تخيل إرسال رمز عبر HTTP عادي على شبكة مقهى عامة. أي شخص يلتقط الشبكة يمكنه نسخ الرمز وتسجيل الدخول كمستخدم.
-
استخدم رموز وصول قصيرة الأجل
تصدر معظم المنصات رموزًا تنتهي خلال ساعة. مثلاً، تدوم رموز Google OAuth عادة ساعة قبل الحاجة للتحديث.
-
تعامل مع رموز التحديث بحذر
يمكن لرمز التحديث طلب رموز وصول جديدة دون تسجيل الدخول مجددًا، لكن يجب تخزينه بأمان (مثلاً في قاعدة بيانات مشفرة على الخادم) وليس في التخزين المحلي للعميل.
-
حدد نطاق الصلاحيات لأقل ما يمكن
إذا كان تطبيقك يحتاج فقط لقراءة تقويم المستخدم، لا تطلب صلاحية الكتابة. هذا يقلل حجم الضرر إذا تم اختراق الرمز.
-
قم بإبطال الرموز عند الحاجة
تسمح العديد من تطبيقات SaaS للمستخدمين بمراجعة الجلسات النشطة وإبطالها. على سبيل المثال، يتيح لك GitHub إبطال رموز الوصول الشخصية في أي وقت.
-
راقب الاستخدام
يمكن أن يكشف تسجيل استخدام الرموز عن نشاط مريب. إذا استخدم الرمز نفسه فجأة من لندن ونيويورك خلال دقائق، فهذه إشارة خطر.
رموز الحامل مقابل طرق مصادقة أخرى
من المفيد مقارنة رموز الحامل بطرق شائعة أخرى:
-
الكوكيز والجلسات
تعتمد المواقع التقليدية على جلسات مخزنة على الخادم يُحددها كوكي. يعمل ذلك جيدًا مع تطبيقات المتصفح لكنه أقل كفاءة مع APIs أو التطبيقات المتنقلة. مثلاً، عند تسجيل الدخول لفيسبوك عبر الكمبيوتر تُستخدم الكوكيز، بينما واجهات برمجة التطبيقات للهاتف تستخدم الرموز.
-
مفاتيح API
مفتاح API هو سلسلة ثابتة تصادق التطبيق وليس المستخدم. على سبيل المثال، قد يستخدم تطبيق طقس مفتاح API لجلب البيانات، لكن المفتاح لا يحدد من هو المستخدم. بإمكان رموز الحامل نقل بيانات خاصة بالمستخدم، مما يجعلها أكثر مرونة.
-
TLS المتبادل (mTLS)
تستخدم بعض الأنظمة عالية الأمان شهادات على العميل والخادم معًا. رغم أنها أكثر أمانًا، فهي أصعب في النشر على نطاق واسع. في معظم منصات SaaS، تحقق رموز الحامل التوازن بين سهولة الاستخدام والأمان.
ملخص النقاط الرئيسية
- رموز الحامل بسيطة لكنها قوية: من يحمل الرمز يصل إلى المورد.
- تُستخدم بشكل واسع في OAuth 2.0 وتدفقات OIDC، وخصوصاً مع APIs وتطبيقات الجوال.
- الأمان يعتمد على إدارتها: العمر القصير، النطاقات، HTTPS، والإبطال أمور مهمة.
- ليست دائماً الخيار الأمثل، لكنها غالبًا تحقق أفضل توازن بين الأمان والمرونة في أغلب تطبيقات SaaS وواجهة برمجة التطبيقات.