تصادق واجهات HTTP المتّصلين بها ببيان اعتماد في ترويسة Authorization — مفتاح واجهة أو رمز bearer (Authorization: Bearer <token>). وتوقّع المخطّطاتُ الأقوى كلَّ طلب بـ HMAC على طلب قانوني بحيث لا يكون بيان الاعتماد قابلًا لإعادة التشغيل، وتستخدم تفويض OAuth 2.0 بصلاحيات العميل لرموز من آلة إلى آلة، وتضيف TLS المتبادل حيث تُطلَب هوية عند طبقة النقل.
رموز bearer ومفاتيح الواجهة
أبسط مصادقة هي بيان اعتماد bearer: يقدّم العميل رمزًا سريًا في ترويسة Authorization فيتحقّق منه الخادم. ويُعرّف RFC 9110 ترويسةَ Authorization وبادئة مخطّطها، ويُعرّف OAuth 2.0 مخطّط Bearer — Authorization: Bearer <token> — الذي خاصّيته المميّزة أن مجرّد الحيازة يمنح الوصول، لذا يجب أن يسافر الرمز عبر TLS فقط وألّا يظهر أبدًا في عنوان أو سجلّ أو رسالة خطأ. ومفتاح الواجهة هو الفكرة نفسها بسرّ أطول عمرًا وغالبًا غير منتهٍ. ولأن بيان اعتماد bearer قابل لإعادة التشغيل إن التُقِط، فهو الأساس لا السقف: سهل التكامل وكافٍ تمامًا عبر TLS لمعظم الحركة، لكن العمليات عالية القيمة كثيرًا ما تُطبّق فوقه توقيع الطلبات.
POST /v1/messages HTTP/1.1
Host: api.example
Authorization: Bearer eyJhbGciOi... # secret; TLS only, never logged
Content-Type: application/jsonتوقيع الطلبات بـ HMAC
يرفع توقيع الطلبات المستوى: فبدل إرسال السرّ، يستخدمه العميل لحساب HMAC على تمثيل قانوني للطلب، ويرسل التوقيع فقط. ويعيد الخادم، الحائز للسرّ نفسه، حساب التوقيع ويقارن. ولأن التوقيع يغطّي الطريقة والمسار والترويسات المفتاحية وتجزئة الجسم، لا يمكن إعادة تشغيل توقيع ملتقَط ضد طلب مختلف، ولأن السرّ نفسه لا يغادر العميل أبدًا، لا يكشف التقاطُ طلبٍ واحدٍ بيانَ الاعتماد. والبناء يعكس توقيع webhook في الاتجاه الآخر وهو أوّليّة HMAC-SHA256 نفسها (RFC 2104 / RFC 6234). والجزء الدقيق هو الطلب القانوني: على الطرفين الاتفاق بايتًا بايتًا على كيفية تسلسله، وإلّا اختلف كل توقيع.
canonical =
HTTP-METHOD + '\n' +
URI-PATH + '\n' +
SORTED-QUERY + '\n' +
SIGNED-HEADERS (name:value, sorted, '\n'-joined) + '\n' +
HEX(SHA256(raw_body))
signature = HMAC_SHA256(secret, canonical)
Authorization: SIGV1 Credential=<key-id>,
SignedHeaders=host;x-date;content-type, Signature=<hex>الترويسات الموقَّعة وتاريخ الطلب
تفصيلان يجعلان توقيع الطلبات سليمًا. أولًا، قائمة SignedHeaders الصريحة تُسمّي بالضبط أيّ الترويسات مغطّى، بحيث لا يُبطِل وسيطٌ يضيف أو يعيد ترتيب ترويسات غير ذات صلة التوقيعَ، بينما تبقى أي ترويسة اختار العميل توقيعها كاشفةً للعبث. ثانيًا، تاريخ الطلب (X-Date موقَّع أو ترويسة Date القياسية) جزء من الطلب القانوني ويُفحَص مقابل ساعة الخادم ضمن تسامح — دفاع إعادة التشغيل نفسه في الـ webhooks مطبَّقًا على نداءات الواجهة الواردة. وهما معًا يعنيان أن الطلب الموقَّع مربوط بمحتواه بالضبط وبترويساته المعلَنة وبنافذة زمنية ضيّقة؛ فالطلب الملتقَط عديم الفائدة بعد بضع دقائق.
نطاق المفاتيح وتدويرها
ينبغي أن تحمل بيانات الاعتماد أقلّ امتياز يفي بالغرض وأن تكون قابلة للتدوير دون توقّف. والنطاق يربط الأذونات بمفتاح — أيّ عمليات يستدعي، ومن أي مصدر، وبأي معدّل — بحيث لا يستطيع مفتاح لا يرسل إلّا الرسائل قراءةَ إعدادات الحساب، ويكون نطاق الضرر لمفتاح مُسرَّب محدودًا. ويتبع التدوير نمط المفاتيح المتداخلة: أصدِر بيان اعتماد جديد، وشغّل كليهما بالتوازي أثناء انتقال العملاء، ثم ألغِ القديم، فلا ينكسر شيء في منتصف الطريق. وينبغي أن تكون المفاتيح قابلة للتعريف (معرّف مفتاح غير سرّي يسافر في الطلب فيعرف الخادم أي سرّ يتحقّق مقابله وأي نطاق يطبّق) وقابلة للإلغاء فرديًا، بحيث يُقطَع تكامل واحد مخترَق دون إزعاج الباقي.
| المخطط | ما الذي يُنقل | القوة / الاستخدام |
|---|---|---|
| مفتاح API | سر طويل الأمد في ترويسة Authorization | خط أساس بسيط؛ عبر TLS فقط؛ سهل التسرّب في السجلات |
| رمز حامل (OAuth 2.0) | رمز وصول قصير الأجل | صالحة لمدة محددة ومقيّدة النطاق؛ تُجدَّد عبر نقطة نهاية الرموز (token endpoint) |
| توقيع طلب HMAC | التوقيع (السر يبقى محلياً) | مقاوم لإعادة الإرسال (replay)، ويكشف العبث لكل طلب |
| mTLS | شهادة العميل X.509 | هوية على مستوى النقل؛ قوية لكن عملياتها أثقل |
TLS المتبادل
يصادق TLS المتبادل العميل عند طبقة النقل: فإضافةً إلى تقديم الخادم شهادةً، يقدّم العميل شهادة X.509 خاصة به أثناء المصافحة، ولا يقبل الخادم إلّا الاتصالات التي تتسلسل شهادتها إلى مرجع تصديق موثوق وتطابق هوية مسجّلة. وهذا يربط هوية الواجهة بمفتاح تشفيري يُدار عند مستوى الاتصال بدل سرّ bearer في ترويسة، وهو جذّاب للوصلات عالية التوكيد من آلة إلى آلة ولتثبيت شريك بشهادات محدّدة. والكلفة تشغيلية — إصدار الشهادات وتوزيعها وتدويرها وإلغاؤها — لذا يُحجَز mTLS عادةً لأكثر التكاملات حساسية، وكثيرًا ما يُقرَن برمز bearer أو توقيع لتفويض دقيق فوق هوية النقل الخشنة.
OAuth 2.0 بصلاحيات العميل من آلة إلى آلة
للتكاملات من خادم إلى خادم دون مستخدم نهائي حاضر، يُعرّف OAuth 2.0 (RFC 6749) تفويضَ صلاحيات العميل. فيصادق العميل نقطةَ رمز عبر client_id وclient_secret (أو شهادة عميل) ويتلقّى رمز وصول قصير العمر، ثم يقدّمه كرمز bearer على نداءات الواجهة حتى ينتهي فيُجدَّد. والميزة على مفتاح واجهة ثابت هي العمر والنطاق: الرموز قصيرة العمر، فرمزٌ ملتقَط ينتهي بسرعة، وتحمل نطاقات صريحة، فرمزٌ سُكّ للإرسال لا يمكن استخدامه لإدارة الحساب. وهذا هو النمط القياسي للوصول من آلة إلى آلة والآليّة التي يوثّقها دليل مصادقة BroadNet بشكل ملموس لوصلاته.
POST /oauth/token HTTP/1.1
Host: auth.example
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
&client_id=<id>
&client_secret=<secret>
&scope=messages:send
-> { "access_token": "...", "token_type": "Bearer",
"expires_in": 3600, "scope": "messages:send" }الأسئلة المتكررة
ما الفرق بين رمز bearer وتوقيع HMAC؟
رمز bearer يُرسَل مع كل طلب ويمنح الوصول بالحيازة، فرمزٌ ملتقَط قابل لإعادة التشغيل حتى ينتهي. أما توقيع HMAC فلا يرسل السرّ أبدًا — يوقّع العميل طلبًا قانونيًا ويرسل التوقيع فقط، فلا يمكن إعادة تشغيل طلب ملتقَط ضد نداء مختلف ولا يُكشَف بيان الاعتماد نفسه.
لماذا يحتاج توقيع HMAC إلى طلب قانوني؟
لأن على الطرفين حساب السلسلة نفسها بالضبط للحصول على تواقيع متطابقة. والطلب القانوني يُثبِّت كيفية تسلسل الطريقة والمسار والاستعلام المرتّب والترويسات الموقَّعة وتجزئة الجسم بالضبط. وأي خلاف — ترتيب ترويسة أو فراغ أو جسم أُعيد ترميزه — ينتج توقيعًا مختلفًا فيُرفَض الطلب حتى لو لم يُعبَث بشيء.
ماذا يمنحني OAuth 2.0 بصلاحيات العميل زيادةً على مفتاح واجهة؟
عمرًا قصيرًا ونطاقًا صريحًا. يبادل العميل بيانات اعتماده عند نقطة رمز برمز وصول قصير العمر ومحدَّد النطاق (RFC 6749). فرمزٌ ملتقَط ينتهي بسرعة، ورمزٌ سُكّ للإرسال لا يمكنه إدارة الحساب. أما مفتاح الواجهة الثابت فطويل العمر وواسع النطاق عادةً.
كيف ينبغي تحديد نطاق مفاتيح الواجهة وتدويرها؟
امنح أقلّ امتياز — قيّد كل مفتاح بالعمليات والمصادر والمعدّل الذي يحتاجه — بحيث يكون التسريب محتوى. ودوّر بمفاتيح متداخلة: أصدِر بيان اعتماد جديد، وشغّل كليهما بالتوازي أثناء انتقال العملاء، ثم ألغِ القديم. وينبغي أن تحمل المفاتيح معرّفًا غير سرّي وأن تكون قابلة للإلغاء فرديًا بحيث يُقطَع تكامل واحد مخترَق وحده.
متى يستحقّ TLS المتبادل كلفته التشغيلية؟
حين تحتاج هوية تشفيرية عند طبقة النقل لوصلة عالية التوكيد من آلة إلى آلة، أو لتثبيت شريك بشهادات محدّدة. ويقبل mTLS العملاء الذين تتسلسل شهادة X.509 لهم إلى مرجع تصديق موثوق فقط. وهو أثقل تشغيلًا — إصدار وتدوير وإلغاء — لذا يُحجَز عادةً لأكثر التكاملات حساسية، وكثيرًا ما يُطبَّق فوقه رمز أو توقيع للتفويض.
لماذا يجب ألّا تظهر بيانات اعتماد bearer في عنوان أو سجلّ؟
لأن بيان اعتماد bearer يمنح الوصول بالحيازة وحدها. والعناوين تُسجّلها الوسائط وتُخزَّن في تاريخ المتصفّح وتُسرَّب عبر ترويسة Referer، وسجلّات التطبيق مقروءة على نطاق واسع، فرمزٌ في أيٍّ منها مكشوف فعليًا. ويجب أن تسافر بيانات اعتماد bearer في ترويسة Authorization عبر TLS فقط وأن تُنقّى من السجلّات.
مواصفات المصدر
تستند هذه الصفحة إلى المعايير المنشورة. يفتح في علامة تبويب جديدة.