تعريف رموز الوصول الشخصية، التوثيق بين الآلات، ومفاتيح API وسيناريوهاتهم في العالم الحقيقي
تعلم الفروقات بين رموز الوصول الشخصية (PATs)، التوثيق بين الآلات (M2M)، ومفاتيح API، وكيف يمكن استخدامها.
تعلم الفروقات بين رموز الوصول الشخصية (PATs)، التوثيق بين الآلات (M2M)، ومفاتيح API، وكيف يمكن استخدامها.
إذا كنت تبني منتج برمجي أو منتج SaaS، فسوف تصادف غالبًا حالة استخدام واسعة أو طلب ميزة: طلبات API. خاصة العملاء من الشركات الكبيرة قد يرغبون في الوصول البرمجي إلى الموارد، إما على المستوى الشخصي أو التنظيمي.
في هذه الحالات، هناك حاجة غالبًا لمفاتيح API، رموز الوصول الشخصية (PATs)، والتوثيق بين الآلات (M2M). في هذه المقالة، سنستكشف الفروقات بين هذه الأساليب وكيف يمكن استخدامها في تطوير المنتجات B2B للمطورين.
دعنا نلقي أولاً نظرة على أوجه التشابه بين هذه الثلاثة.
فهم هذه التشابهات يساعد في التعرف على الأسس المشتركة لهذه الأساليب التوثيقية. تسمح الفروقات بينهم باختيار الحل الأنسب لحالات الاستخدام والمتطلبات الأمنية المحددة.
الآن، لنناقش اختلافاتهم، مع التركيز على حالات الاستخدام ومتى يمكن استخدام كل طريقة.
تُستخدم مفاتيح API لتحديد وتفويض التطبيق أو الخدمة المستدعية. عادة ما تكون طويلة الأمد وثابتة حتى يتم تدويرها وغالبًا ما تكون لديها مجموعة ثابتة من الصلاحيات. تُستخدم بشكل أساسي في الاتصالات من خادم إلى خادم أو في الوصول إلى البيانات العامة، عادةً لا تمثل هذه الرموز مستخدمًا محددًا.
يتم إصدار مفتاح API من قبل موفر API ويُعطى للمستهلك المسجل [1]، والذي يتضمنه مع كل طلب. ثم يقوم خادم API بفحص مفتاح API للتحقق من هوية المستهلك قبل إعادة البيانات المطلوبة.
مفاتيح API ليست فعالة مثل الأشكال الأخرى من توثيق API ، مثل OAuth و JWT ، لكنها لا تزال تلعب دورًا مهمًا في مساعدة منتجي API على مراقبة الاستخدام مع الحفاظ على البيانات الحساسة آمنة.
[1]: مستهلك API هو أي تطبيق أو خدمة أو مستخدم يتفاعل مع API للوصول إلى وظيفتها أو بياناتها. يرسلون طلبات إلى API لإجراء عمليات مثل استرداد، إنشاء، تحديث، أو حذف الموارد. يمكن أن يكون مستهلكو API تطبيقات ويب، تطبيقات جوال، خوادم أخرى، أو حتى مطورين فرديين يستخدمون API للتكامل مع خدمات أخرى أو لإنشاء وظائف جديدة على منصات قائمة.
Postman: ما هو مفتاح API؟
عندما يناقش الناس حالات استخدام مفتاح API، فإنهم غالبًا ما يذكرون الأتمتة، مشاركة البيانات، الاختبار، التطوير، والتحكم في الأمان. ومع ذلك، فهذه تقنيات إلى حد ما. في سيناريوهات العالم الحقيقي، الغرض الأكثر شيوعًا عند بناء المنتجات هو التكامل.
Zapier: إضافة توثيق باستخدام مفتاح API
Zapier هو أداة أتمتة شائعة تربط بين تطبيقات الويب المختلفة. عند دمج تطبيق مع Zapier، تُستخدم مفاتيح API للتوثيق وتفويض الوصول إلى API التطبيق. على سبيل المثال، إذا كنت ترغب في أتمتة المهام بين نظام إدارة علاقات العملاء (CRM) وأداة التسويق عبر البريد الإلكتروني، ستقوم بإنشاء مفتاح API من نظام CRM وتقديمه إلى Zapier. يتم استخدام هذا المفتاح بعد ذلك لتوثيق الطلبات من Zapier إلى API CRM، مما يسمح بتدفق البيانات بشكل آمن بين النظامين.

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

يمثل رمز الوصول الشخصي مفهومًا مشابهًا ولكنه يمثل هوية وصلاحيات مستخدم محدد، يتم إنشاؤه ديناميكيًا عند التوثيق أو تسجيل الدخول الناجح، وعادةً ما يكون لديه عمر محدود لكنه يمكن تحديثه. يوفر تحكمًا دقيقًا في الوصول إلى البيانات والقدرات الخاصة بالمستخدم ويُستخدم عمومًا لأدوات CLI، السكربتات، أو الوصول الشخصي إلى API.
هناك سيناريوهان نموذجيان،
الأتمتة والسكربتات
يعني ذلك عندما يستخدم المطور PAT لأتمتة نشر الكود من مستودع إلى بيئة الإنتاج، مما يقلل التدخل اليدوي ويضمن الاتساق.
على سبيل المثال، يمكن لمستخدمي GitHub إنشاء PATs لتوثيق عمليات Git عبر HTTPS والتفاعل مع REST API الخاص بـ GitHub. هذا مفيد للمطورين الذين يحتاجون إلى أتمتة مهام مثل استنساخ المستودعات، دفع الالتزامات، أو إدارة القضايا وطلبات الدمج.
التكامل مع التطبيقات الخارجية
يعني ذلك، تمكين الاتصال الآمن بين الأنظمة والتطبيقات المختلفة. يبدو ذلك مشابهًا لسيناريو تكامل مفتاح API ولكن PAT يمثل المستخدم، وليس العميل أو التطبيق.
على سبيل المثال، يستخدم مدير مشروع PAT لدمج أداة إدارة المشروع مع نظام تتبع القضايا الخارجي، مما يتيح تبادل البيانات بشكل سلس وتزامنها، مثل Atlassian (Jira وConfluence).
السيناريوهات المذكورة أعلاه تشبه أكثر الأدوات للمطورين. هل تعتبر PATs مفيدة فقط لهذا النوع من المنتجات؟ لا. إليك مثالان إضافيان: أحدهما نظام CMS، والآخر أداة إنتاجية.
Contentful: رموز الوصول الشخصية
Contentful هو منصة CMS بدون رأس تقدم PATs كبديل لرموز OAuth للوصول إلى Content Management API (CMA) الخاص بهم.
تشمل الميزات الرئيسية:

إنشاء رموز الوصول الشخصية | دعم Airtable
Airtable - منصة سحابية للتعاون، تطبق PATs للوصول إلى API.
يسمح نظامهم بـ:

تم تصميم M2M للتواصل بين الخدمات بدون تدخل بشري. ينبع من الفكرة أن أسماء المستخدمين وكلمات المرور غير كافية لحماية الخدمات وليست فعالة لأتمتة فعالة.
تتبنى تطبيقات التوثيق بين الآلات (M2M) الآن تدفق بيانات العميل، والذي يُحدد في بروتوكول تفويض OAuth 2.0 RFC 6749. يمكنه أيضًا دعم بروتوكولات معيارية مماثلة. أجل، التوثيق بين الآلات (M2M) أكثر صرامة في الالتزام بالمعايير المفتوحة مقارنة بـ PATs ومفاتيح API.
يقوم بتوثيق التطبيق أو الخدمة نفسها، وليس المستخدم، وغالبًا ما يقوم بتنفيذ JWT (رموز ويب JSON) للتوثيق عديم الحالة. يوفر ذلك طريقة آمنة لتفاعل الخدمات مع بعضها البعض في الأنظمة الموزعة.
يتبع عملية مماثلة:
إليك مثال مختصر لاستخدام التوثيق بين الآلات (M2M) للتواصل الخلفي مع الخلفي:
سيناريو: تحتاج الخدمة A للوصول إلى البيانات من API الخدمة B.
الإعداد:
التوثيق:
تطلب الخدمة A رمز وصول من خادم التوثيق:
إصدار الرمز:
طلب API:
تستخدم الخدمة A الرمز لطلب البيانات من الخدمة B:
التحقق:
الاستجابة:
تسمح هذه العملية بالتواصل الآمن والمباشر بين الخدمة A والخدمة B دون تدخل المستخدم، باستخدام تدفق بيانات العميل لـ OAuth 2.0.
التواصل بين الأجهزة
التواصل بين الأجهزة، خصوصًا في سياق إنترنت الأشياء (IoT)، يعتمد بشكل كبير على التوثيق بين الآلات (M2M) لضمان تبادل البيانات بشكل آمن وفعال.
على سبيل المثال، مثل أجهزة المنزل الذكية، يتواصل ترموستات ذكي مع مركز تحكم منزلي مركزي لتعديل إعدادات الحرارة استنادًا إلى تفضيلات المستخدم. يستخدم الترموستات التوثيق بين الآلات (M2M) لإرسال البيانات بأمان إلى المركز واستقبال الأوامر، مما يضمن أن الأجهزة المخولة فقط يمكنها التفاعل مع نظام التدفئة في المنزل.
حسنًا، لقد وصلت إلى نهاية هذه المقالة. هل يمكنني الحصول على ملخص سريع؟ بالتأكيد! إليك نظرة على النقاط الرئيسية: