تعريف رموز الوصول الشخصية، التوثيق بين الآلات، ومفاتيح API وسيناريوهاتهم في العالم الحقيقي

إذا كنت تبني منتج برمجي أو منتج SaaS، فسوف تصادف غالبًا حالة استخدام واسعة أو طلب ميزة: طلبات API. خاصة العملاء من الشركات الكبيرة قد يرغبون في الوصول البرمجي إلى الموارد، إما على المستوى الشخصي أو التنظيمي.

في هذه الحالات، هناك حاجة غالبًا لمفاتيح API، رموز الوصول الشخصية (PATs)، والتوثيق بين الآلات (M2M). في هذه المقالة، سنستكشف الفروقات بين هذه الأساليب وكيف يمكن استخدامها في تطوير المنتجات B2B للمطورين.

أوجه التشابه#

دعنا نلقي أولاً نظرة على أوجه التشابه بين هذه الثلاثة.

1. غرض أمني: تُستخدم جميع الأساليب الثلاثة لتأمين والتحكم في الوصول إلى APIs أو الخدمات أو الموارد. جميعها تعمل كوسيلة للتحقق من الهوية و/أو التفويض.
2. نهج قائم على الرموز: كل طريقة تتضمن عادةً استخدام سلسلة فريدة أو رمز للتعريف. يتم إرسال هذه الرموز عادةً مع طلبات API، غالبًا في الرأس أو كمعلمات استفسار.
3. يمكن إبطالها: يمكن إبطال أو تعطيل الرموز أو المفاتيح في جميع الأساليب الثلاثة إذا تم اختراقها أو إذا لم تعد هناك حاجة لها. يتيح ذلك استجابات أمنية سريعة دون تغيير النظام الأساسي.
4. الوصول البرمجي: تيسّر جميع الأساليب الثلاثة الوصول البرمجي إلى APIs أو الخدمات. تتيح الأتمتة والتكامل بين الأنظمة أو التطبيقات المختلفة.
5. قابلة للتدقيق: يمكن تسجيل واستخدام هذه الأساليب التوثيقية في التدقيق. يتيح ذلك تتبع الوصول إلى API، ومراقبة الأنشطة المشبوهة، وتقديم تقارير الامتثال.
6. متأقلمة مع التحكم في الوصول: يمكن تنفيذ كل الأساليب الثلاثة بمستويات مختلفة من التحكم في الوصول والصلاحيات. يمكن تكييفها مع نماذج أمنية مختلفة ومتطلبات بنية معمارية متنوعة.
7. استقلال البروتوكول: رغم استخدامها غالبًا مع REST APIs، يمكن تطبيق هذه الأساليب على أنواع مختلفة من APIs والبروتوكولات.

فهم هذه التشابهات يساعد في التعرف على الأسس المشتركة لهذه الأساليب التوثيقية. تسمح الفروقات بينهم باختيار الحل الأنسب لحالات الاستخدام والمتطلبات الأمنية المحددة.

الآن، لنناقش اختلافاتهم، مع التركيز على حالات الاستخدام ومتى يمكن استخدام كل طريقة.

الاختلافات#

مفاتيح API#

تُستخدم مفاتيح API لتحديد وتفويض التطبيق أو الخدمة المستدعية. عادة ما تكون طويلة الأمد وثابتة حتى يتم تدويرها وغالبًا ما تكون لديها مجموعة ثابتة من الصلاحيات. تُستخدم بشكل أساسي في الاتصالات من خادم إلى خادم أو في الوصول إلى البيانات العامة، عادةً لا تمثل هذه الرموز مستخدمًا محددًا.

كيف تعمل مفاتيح API؟#

يتم إصدار مفتاح API من قبل موفر API ويُعطى للمستهلك المسجل [1]، والذي يتضمنه مع كل طلب. ثم يقوم خادم API بفحص مفتاح API للتحقق من هوية المستهلك قبل إعادة البيانات المطلوبة.

مفاتيح API ليست فعالة مثل الأشكال الأخرى من توثيق API ، مثل OAuth و JWT ، لكنها لا تزال تلعب دورًا مهمًا في مساعدة منتجي API على مراقبة الاستخدام مع الحفاظ على البيانات الحساسة آمنة.

[1]: مستهلك API هو أي تطبيق أو خدمة أو مستخدم يتفاعل مع API للوصول إلى وظيفتها أو بياناتها. يرسلون طلبات إلى API لإجراء عمليات مثل استرداد، إنشاء، تحديث، أو حذف الموارد. يمكن أن يكون مستهلكو API تطبيقات ويب، تطبيقات جوال، خوادم أخرى، أو حتى مطورين فرديين يستخدمون API للتكامل مع خدمات أخرى أو لإنشاء وظائف جديدة على منصات قائمة.

Postman: ما هو مفتاح API؟

حالات الاستخدام#

عندما يناقش الناس حالات استخدام مفتاح API، فإنهم غالبًا ما يذكرون الأتمتة، مشاركة البيانات، الاختبار، التطوير، والتحكم في الأمان. ومع ذلك، فهذه تقنيات إلى حد ما. في سيناريوهات العالم الحقيقي، الغرض الأكثر شيوعًا عند بناء المنتجات هو التكامل.

مثال 1: التكامل مع Zapier#

Zapier: إضافة توثيق باستخدام مفتاح API

Zapier هو أداة أتمتة شائعة تربط بين تطبيقات الويب المختلفة. عند دمج تطبيق مع Zapier، تُستخدم مفاتيح API للتوثيق وتفويض الوصول إلى API التطبيق. على سبيل المثال، إذا كنت ترغب في أتمتة المهام بين نظام إدارة علاقات العملاء (CRM) وأداة التسويق عبر البريد الإلكتروني، ستقوم بإنشاء مفتاح API من نظام CRM وتقديمه إلى Zapier. يتم استخدام هذا المفتاح بعد ذلك لتوثيق الطلبات من Zapier إلى API CRM، مما يسمح بتدفق البيانات بشكل آمن بين النظامين.

مثال 2: التكامل مع Stripe#

تستفيد Stripe من مفاتيح API للتكامل الآمن مع المنصات والتطبيقات المختلفة. استخدم لوحة القيادة للمطورين لإنشاء، الكشف، حذف، وتجديد مفاتيح API.

رموز الوصول الشخصية (PATs)#

يمثل رمز الوصول الشخصي مفهومًا مشابهًا ولكنه يمثل هوية وصلاحيات مستخدم محدد، يتم إنشاؤه ديناميكيًا عند التوثيق أو تسجيل الدخول الناجح، وعادةً ما يكون لديه عمر محدود لكنه يمكن تحديثه. يوفر تحكمًا دقيقًا في الوصول إلى البيانات والقدرات الخاصة بالمستخدم ويُستخدم عمومًا لأدوات CLI، السكربتات، أو الوصول الشخصي إلى API.

كيف تعمل رموز الوصول الشخصية (PATs)#

1. الإنشاء والإدارة: يُنشئ المستخدمون رموز الوصول الشخصية عبر إعدادات حساباتهم في المنصة المعنية.
   • على سبيل المثال، في GitHub، يمكن للمستخدمين إنشاء PATs دقيقة أو تقليدية مع صلاحيات محددة وتواريخ انتهاء.
   • في منتجات Atlassian مثل Jira وConfluence، يمكن للمستخدمين إنشاء PATs من إعدادات ملفاتهم الشخصية، مع تحديد اسم الرمز وانتهاء اختياري.
2. الاستخدام: تُستخدم PATs كرموز حاملة في رأس التوثيق لطلبات API. يعني ذلك أنها تُدرج في رؤوس HTTP لتوثيق الطلب.
   • تتيح الوصول الآمن إلى موارد API، مما يسمح للمستخدمين بإجراء عمليات مثل إنشاء، قراءة، تحديث، وحذف الموارد بناءً على الصلاحيات الممنوحة للرمز.
   • يمكن استخدام PATs عبر تطبيقات متعددة داخل منصة واحدة، مما يوفر طريقة موحدة لإدارة الوصول والصلاحيات.
3. الإبطال وتحديد انتهاء الصلاحية:
   • توفر PATs أمانًا معززًا من خلال السماح للمستخدمين بإبطال الرموز إذا تم اختراقها، دون الحاجة لتغيير كلمة مرور الحساب.
   • توصي المنصات غالبًا بتحديد تاريخ انتهاء لـ PATs لتقليل خطر استغلال الرموز طويلة الأمد.

حالات الاستخدام#

هناك سيناريوهان نموذجيان،

الأتمتة والسكربتات

يعني ذلك عندما يستخدم المطور PAT لأتمتة نشر الكود من مستودع إلى بيئة الإنتاج، مما يقلل التدخل اليدوي ويضمن الاتساق.

على سبيل المثال، يمكن لمستخدمي GitHub إنشاء PATs لتوثيق عمليات Git عبر HTTPS والتفاعل مع REST API الخاص بـ GitHub. هذا مفيد للمطورين الذين يحتاجون إلى أتمتة مهام مثل استنساخ المستودعات، دفع الالتزامات، أو إدارة القضايا وطلبات الدمج.

التكامل مع التطبيقات الخارجية

يعني ذلك، تمكين الاتصال الآمن بين الأنظمة والتطبيقات المختلفة. يبدو ذلك مشابهًا لسيناريو تكامل مفتاح API ولكن PAT يمثل المستخدم، وليس العميل أو التطبيق.

على سبيل المثال، يستخدم مدير مشروع PAT لدمج أداة إدارة المشروع مع نظام تتبع القضايا الخارجي، مما يتيح تبادل البيانات بشكل سلس وتزامنها، مثل Atlassian (Jira وConfluence).

السيناريوهات المذكورة أعلاه تشبه أكثر الأدوات للمطورين. هل تعتبر PATs مفيدة فقط لهذا النوع من المنتجات؟ لا. إليك مثالان إضافيان: أحدهما نظام CMS، والآخر أداة إنتاجية.

مثال 1: Contentful#

Contentful: رموز الوصول الشخصية

Contentful هو منصة CMS بدون رأس تقدم PATs كبديل لرموز OAuth للوصول إلى Content Management API (CMA) الخاص بهم.

تشمل الميزات الرئيسية:

• يمكن للمستخدمين إنشاء عدة رموز بصلاحيات ونطاقات مختلفة.
• ترتبط الرموز بحساب المستخدم، وتورث صلاحياتها.
• تعتبر PATs مفيدة بشكل خاص لأغراض التطوير والأتمتة.

مثال 2: Airtable#

إنشاء رموز الوصول الشخصية | دعم Airtable

Airtable - منصة سحابية للتعاون، تطبق PATs للوصول إلى API.

يسمح نظامهم بـ:

• إنشاء عدة رموز بنطاقات ومستويات وصول متنوعة.
• يمكن تقييد الرموز لتشمل قواعد معينة أو مساحات عمل.
• يمكن لمديري الشركات إنشاء رموز مع وصول أوسع عبر المنظمة.

التوثيق بين الآلات (M2M)#

تم تصميم M2M للتواصل بين الخدمات بدون تدخل بشري. ينبع من الفكرة أن أسماء المستخدمين وكلمات المرور غير كافية لحماية الخدمات وليست فعالة لأتمتة فعالة.

تتبنى تطبيقات التوثيق بين الآلات (M2M) الآن تدفق بيانات العميل، والذي يُحدد في بروتوكول تفويض OAuth 2.0 RFC 6749. يمكنه أيضًا دعم بروتوكولات معيارية مماثلة. أجل، التوثيق بين الآلات (M2M) أكثر صرامة في الالتزام بالمعايير المفتوحة مقارنة بـ PATs ومفاتيح API.

يقوم بتوثيق التطبيق أو الخدمة نفسها، وليس المستخدم، وغالبًا ما يقوم بتنفيذ JWT (رموز ويب JSON) للتوثيق عديم الحالة. يوفر ذلك طريقة آمنة لتفاعل الخدمات مع بعضها البعض في الأنظمة الموزعة.

كيف يعمل التوثيق بين الآلات#

يتبع عملية مماثلة:

1. بيانات الاعتماد للعميل: كل آلة (أو خدمة) لديها معرف عميل فريد وسرية.
2. طلب توكن: ترسل الخدمة هذه الاعتمادات إلى خادم التوثيق.
3. رمز الوصول: عند التحقق، يقوم خادم التوثيق بإصدار رمز وصول، غالبًا ما يكون JWT (رموز ويب JSON).
4. طلبات API: تستخدم الخدمة هذا الرمز لتوثيق وتفويض طلبات API إلى خدمة أخرى.
5. التحقق: تتحقق الخدمة المستقبلة من الرمز قبل منح الوصول إلى مواردها.

حالات الاستخدام#

إليك مثال مختصر لاستخدام التوثيق بين الآلات (M2M) للتواصل الخلفي مع الخلفي:

سيناريو: تحتاج الخدمة A للوصول إلى البيانات من API الخدمة B.

1. الإعداد:

   • يتم تسجيل الخدمة A كعميل مع خادم توثيق.
   • تُعطى الخدمة A معرف عميل وسرية.

2. التوثيق:

   • تطلب الخدمة A رمز وصول من خادم التوثيق:

3. إصدار الرمز:

   • يتحقق خادم التوثيق من الاعتمادات ويصدر رمز وصول JWT.

4. طلب API:

   • تستخدم الخدمة A الرمز لطلب البيانات من الخدمة B:

5. التحقق:

   • تتحقق الخدمة B من الرمز مع خادم التوثيق.

6. الاستجابة:

   • إذا كان الرمز صالحًا، تعيد الخدمة B البيانات المطلوبة إلى الخدمة A.

تسمح هذه العملية بالتواصل الآمن والمباشر بين الخدمة A والخدمة B دون تدخل المستخدم، باستخدام تدفق بيانات العميل لـ OAuth 2.0.

التواصل بين الأجهزة

التواصل بين الأجهزة، خصوصًا في سياق إنترنت الأشياء (IoT)، يعتمد بشكل كبير على التوثيق بين الآلات (M2M) لضمان تبادل البيانات بشكل آمن وفعال.

على سبيل المثال، مثل أجهزة المنزل الذكية، يتواصل ترموستات ذكي مع مركز تحكم منزلي مركزي لتعديل إعدادات الحرارة استنادًا إلى تفضيلات المستخدم. يستخدم الترموستات التوثيق بين الآلات (M2M) لإرسال البيانات بأمان إلى المركز واستقبال الأوامر، مما يضمن أن الأجهزة المخولة فقط يمكنها التفاعل مع نظام التدفئة في المنزل.

ملخص رئيسي#

حسنًا، لقد وصلت إلى نهاية هذه المقالة. هل يمكنني الحصول على ملخص سريع؟ بالتأكيد! إليك نظرة على النقاط الرئيسية:

1. النطاق: مفاتيح API واسعة، رموز الوصول الشخصية (PATs) خاصة بالمستخدم، ورموز التوثيق بين الآلات (M2M) خاصة بالخدمة.
2. مدة الحياة: مفاتيح API طويلة الأمد، PATs لها عمر أقصر، ورموز M2M يمكن أن تتفاوت.
3. التمثيل: مفاتيح API سلاسل مبهمة، PATs يمكن أن تكون مبهمة أو مهيكلة، ورموز M2M تستخدم غالبًا JWTs.
4. حالة الاستخدام: مفاتيح API للوصول البسيط إلى API، PATs للعمليات المركزية للمستخدم، ورموز M2M للاتصال بين الخدمات.