إتقان مصادقة CLI: الدليل الشامل لجميع الطرق الأربعة

كل أداة أوامر خاصة بالمطورين (CLI) تأتي مع الأمر login كأول أمر. وكل واحدة منها تحل المصادقة بطريقة مختلفة.

تعرض لك GitHub رمزًا وتفتح متصفحك للتحقق منه. تفتح AWS المتصفح لتسجيل دخول مبني على PKCE. تطلب منك Stripe تأكيد رمز الاقتران في لوحة التحكم. أدوات الذكاء الاصطناعي الأحدث (Claude Code، OpenAI Codex CLI، Cursor) اختارت كل واحدة منها نهجها الخاص أيضًا.

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

إليك الطرق الأربعة للمصادقة التي تهم، كيف تنفذها أكبر الأدوات، والأخطاء التي يجب أن تتجنبها.

الطرق الأربعة باختصار#

قبل الدخول بالتفاصيل، إليك مقارنة سريعة:

لكل طريقة مميزات وعيوب. هذا ما تحتاج معرفته عن كل واحدة.

1. تدفق رمز الجهاز OAuth (RFC 8628)#

هذه هي الطريقة التي يعرض فيها CLI الخاص بك رمزًا مثل ABCD-1234 ورابطًا، ثم يخبرك بفتح هذا الرابط على أي جهاز وإدخال الرمز.

من يستخدمها: GitHub CLI (الافتراضي)، Azure CLI (باستخدام --use-device-code)، Vercel CLI (انتقلت مؤخرًا إلى هذه كخيار افتراضي)، OpenAI Codex CLI (كخيار تجريبي)

كيف تعمل#

1. تقوم بتشغيل cli login
2. يطلب CLI رمز الجهاز من خادم المصادقة، بإرسال client_id والنطاقات المطلوبة
3. يعيد الخادم ثلاث أشياء: device_code (معرف داخلي)، user_code (الرمز القصير الذي تدخله)، و verification_uri (الرابط الذي تذهب إليه)
4. يعرض CLI الرمز والرابط ويبدأ في الاستفسار من خادم المصادقة كل 5+ ثوانٍ
5. تفتح الرابط من أي جهاز (جوال، كمبيوتر محمول، أو كمبيوتر آخر)، وتدخل الرمز وتوثق بأي طريقة (كلمة مرور، SSO، مفاتيح مرور، MFA ...إلخ)
6. بعد الموافقة، يعيد الاستفسار التالي رمز وصول ورمز تحديث
7. يخزن CLI الرموز وانتهى الأمر

لماذا يفضلها المطورون#

النقطة الأساسية: تعمل في أي مكان. جلسة SSH إلى خادم بعيد؟ تعمل. داخل حاوية Docker؟ تعمل. بيئة تطوير سحابية دون متصفح محلي؟ تعمل. المتصفح لا يجب أن يكون على نفس الجهاز مع CLI.

تدعم كامل نطاق مصادقات المؤسسات (SAML، OIDC، MFA) لأن كل ذلك يتم في المتصفح، ليس في الطرفية. CLI لا يرى أبداً كلمة مرورك.

نقطة الضعف الأمنية التي يجهلها الكثير#

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

هذا الأمر خطير بما فيه الكفاية حتى أن AWS غيرت إعدادها الافتراضي. بدءًا من AWS CLI v2.22.0، أصبح الافتراضي لـ aws sso login استخدام تدفق رمز التفويض المبني على PKCE. لا يزال رمز الجهاز متاحًا عبر --use-device-code، لكنه لم يعد المسار الافتراضي.

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

إذاً لدينا انقسام مثير: اعتمدت Vercel تدفق رمز الجهاز كإعداد افتراضي في سبتمبر 2025، بينما ابتعدت AWS عنه. النموذج هو أن تدفق رمز الجهاز رائع عندما لا يمكنك فتح المتصفح فعلاً، لكن إذا كنت تستطيع، فإن PKCE أكثر أمانًا.

من ناحية مزودي المصادقة، الطلب بوضوح يتزايد. أطلقت Logto (https://logto.io) دعم OAuth 2.0 Device Authorization Grant للتطبيقات المحلية في v1.38.0 (مفتوح المصدر) و Logto Cloud، وبالتالي يمكنك الآن تفعيل تدفق الجهاز كطريقة تفويض لأي تطبيق محلي. هذا مهم إذا كنت تبني CLI. تنفيذ RFC 8628 بشكل صحيح (انتهاء صلاحية الرموز، تحديد المعدل، منطق الاستفسار، UX تسجيل الدخول في صفحة التحقق) يتطلب وقتًا وجهدًا أكبر مما يتوقع أغلب الفرق، ووجود مزود مصادقة يدير ذلك يجعل الأمر أبسط بكثير.

تفاصيل تقنية من RFC#

بعض الأمور المهمة من RFC 8628:

• قيمة expires_in لرموز الجهاز تحدد من مزود المصادقة. مثال RFC هو 1800 ثانية (30 دقيقة) لكن ليست إلزامية.
• إذا لم يحدد الخادم فاصل الاستفسار، يجب أن تعتمد العملاء على 5 ثوانٍ افتراضيًا.
• إذا حصلت على خطأ slow_down، زد الفاصل الزمني 5 ثوانٍ إضافية.
• يجب أن تكون رموز الجهاز لمرة واحدة وتنتهي بسرعة.
• يجب أن تتم جميع تبادلات الرموز عبر HTTPS.

2. OAuth المعتمد على المتصفح (إعادة توجيه عبر localhost)#

هذه الطريقة الأكثر شيوعًا للأدوات التي تعمل على جهاز المطور المحلي. تقوم بتشغيل login، يفتح المتصفح، تصادق، والمتصفح يعيد التوجيه إلى خادم محلي يقوم CLI بتشغيله مؤقتًا. التطبيقات الحديثة تضيف PKCE (تنطق "بكسي")، مما يجعل المصادقة أكثر أمانًا بكثير.

من يستخدمها: Claude Code، gcloud CLI، Terraform CLI، AWS CLI v2.22+ (لـ SSO، PKCE افتراضيًا)

كيف تعمل#

1. تقوم بتشغيل cli login
2. يبدأ CLI خادم HTTP مؤقت على منفذ عشوائي محلي (مثلاً http://127.0.0.1:8742)
3. يفتح المتصفح الافتراضي لنقطة نهاية مزود المصادقة، ممررًا رابط localhost كعنوان إعادة التوجيه
4. تصادق في المتصفح (SSO، كلمة مرور، مفاتيح مرور... إلخ)
5. يعيد مزود المصادقة المتصفح إلى http://127.0.0.1:8742/callback?code=XXXX&state=YYYY
6. الخادم المحلي يلتقط رمز التفويض، ويتبادله للحصول على الرموز عبر طلب HTTPS في الخلفية
7. يعرض المتصفح صفحة "تم بنجاح! يمكنك إغلاق هذا التبويب"
8. يخزن CLI الرموز ويوقف الخادم المحلي

تجربة المستخدم سلسلة تمامًا. لا رموز للنسخ، لا روابط للكتابة. فقط علامة متصفح تفتح وتغلق.

متى تفشل هذه الطريقة#

تعمل فقط عندما يتمكن CLI من فتح متصفح والاتصال عبر localhost. وهذا يستثني:

• جلسات SSH إلى خوادم بعيدة
• حاويات Docker (ما لم تستخدم تحويل البورتات)
• خطوط CI/CD
• الخوادم بدون واجهة رسومية
• بعض بيئات الشركات المحدودة

ولهذا أغلب الأدوات التي تعتمد على OAuth عن طريق المتصفح تدعم طريقة بديلة غالبًا، عادة تدفق رمز الجهاز أو API Keys.

ثلاثة مطبات أمنية تتكرر باستمرار#

المطب الأول: الربط على 0.0.0.0 بدلاً من 127.0.0.1

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

هذا الخطأ حدث فعلاً في بعض أدوات CLI المنتجة. من السهل ارتكابه لأن مكتبات خوادم HTTP غالبًا ما تكون على 0.0.0.0 افتراضيًا.

المطب الثاني: عدم التحقق من متغير state

معامل state هو حمايتك من CSRF. بدونه، يمكن لمهاجم خداع CLI لقبول رمز تفويض من جلسة ضارة.

المطب الثالث: عدم استخدام PKCE

إذا لم تستخدم تدفق OAuth مع PKCE، يمكن اعتراض رمز التفويض وإعادة استخدامه.

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

إليك ما يضيفه PKCE:

1. قبل البدء، ينشئ CLI code_verifier (سلسلة عشوائية قوية)
2. ينشئ code_challenge بتجزئة التحقق عبر SHA-256
3. يرسل التحدي مع طلب التفويض الأولي
4. حين يتبادل الكود بالرموز، يرسل CLI في الطلب code_verifier الأصلي
5. يتحقق خادم المصادقة أن التحقق يطابق التحدي

المهاجم الذي يعترض رمز التفويض لن يكون معه code_verifier، لذا لن يتمكن من إتمام التبادل.

لهذا السبب أصبحت AWS CLI v2.22+ تعتمد PKCE افتراضيًا لـ SSO، مبتعدة عن تدفق رمز الجهاز. عندما يستطيع CLI فتح المتصفح على نفس الجهاز، OAuth مع PKCE أفضل أمنيًا بكثير – نفس تجربة المستخدم، بضمانات أمنية أقوى، ولا يوجد مجال للتصيد. تدفق رمز الجهاز يبقى الخيار الأنسب عندما لا يمكن للمتصفح التواجد على نفس الجهاز (SSH، حاويات، بيئات تطوير بعيدة)، لكنه ليس النموذج الشائع للتطوير المحلي.

3. مفاتيح API ورموز الوصول الشخصي#

النهج الأبسط. تولد رمزًا على لوحة التحكم في الويب، تلصقه في إعدادات CLI أو في متغير بيئة، وانتهى الأمر.

من يستخدمها: Stripe CLI (كخيار تسجيل الدخول)، npm، pip، أغلب أدوات الذكاء الاصطناعي كخيار بديل (Claude Code عبر ANTHROPIC_API_KEY، أدوات OpenAI عبر OPENAI_API_KEY، Aider)

كيف تعمل#

1. سجل دخولك للوحة خدمة الويب
2. انتقل للإعدادات → مفاتيح API (أو رموز الوصول الشخصية)
3. أنشئ مفتاحًا جديدًا، عادة سلسلة طويلة عشوائية مع بادئة (مثلاً، sk_live_, ghp_, npm_)
4. خزنه في ملف إعداد (~/.config/stripe/config.toml, ~/.aws/credentials) أو متغير بيئة

يقرأ CLI المفتاح عند بدء التشغيل ويضيفه لطلبات API عادة كـ Bearer token في ترويسة Authorization.

لماذا ما زالت شائعة رغم المخاطر#

بالنسبة للأتمتة، يصعب التفوق على مفاتيح API. تعمل في CI/CD، في الحاويات، في السكربتات، وظائف الكرون ... إلخ. أي مكان يمكنه قراءة متغير بيئة. لا حاجة لمتصفح. لا مطالبات تفاعلية. لا يحتاج تدوير الرموز.

لوكلاء الذكاء الاصطناعي خصوصاً، مفاتيح API أبسط اختبار. حين يحتاج Claude Code أو Cursor لاستدعاء API، متغير بيئة به مفتاح هو أسهل نقطة تكامل.

المخاطر حقيقية#

• التسريبات. مفاتيح API كثيرًا ما تنتهي في Commits git، سجلات الأخطاء، رسائل الخطأ، خطوط CI. تقوم GitHub بفحص الرموز المكشوفة وتبلغ عن أكثر من مليون تسريب سنويًا.
• صلاحيات واسعة. معظم مفاتيح API تمنح صلاحيات واسعة. إذا تم تسريبها، تتسع دائرة الخطر كثيرًا.
• لا توجد MFA. مفاتيح API تتجاوز المصادقة متعددة العوامل التي أعددتها بعناية.
• صعوبة التدوير. في كل مرة تقوم بتدوير مفتاح، يجب تحديثه في كل مكان مخزن به. مع الفرق، هذه مشكلة تنسيق.

تحسين عصري: تبادل الرموز المؤقت#

أفضل ممارسة عند استخدام مفاتيح API: استبدلها أثناء التشغيل برموز مؤقتة قصيرة العمر.

كانت AWS رائدة في ذلك مع STS (خدمة الرموز الأمنية). تستخدم بيانات الاعتماد طويلة الأمد فقط لطلب بيانات اعتماد مؤقتة تنتهي خلال ساعة. أدوات مثل aws-vault تقوم بذلك آليًا.

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

4. تدفق بيانات اعتماد العميل#

هذا التدفق من OAuth 2.0 مصمم لعمليات المصادقة بين الخدمات، بلا تدخل بشري.

يستخدم في: خطوط CI/CD، الخدمات الخلفية، الأدوات المؤتمتة

كيف يعمل#

ترسل الخدمة client_id و client_secret مباشرة لخادم المصادقة وتحصل على رمز وصول قصير الأمد. لا متصفح، لا تفاعل بشري، لا إعادة توجيه.

متى تستخدمها#

استخدم بيانات اعتماد العميل حين:

• خدمة أو بوت يحتاج المصادقة، ليس شخصًا
• أنت في CI/CD
• تحتاج وصولاً آليًا دون تدخل بشري
• "المستخدم" هو التطبيق نفسه

لا تستخدمها لمصادقة البشر. لا تدعم MFA، SSO، أو أي تحقق تفاعلي.

ماذا تستخدم أدوات CLI فعليًا#

إليك جدول محدث حسب الوثائق البرمجية والشيفرة المصدرية. كثير من المقالات تخطئ لأن الأدوات تغير الافتراضات باستمرار.

الاتجاه واضح: OAuth المعتمد على المتصفح هو الافتراضي للتطوير المحلي، مع تدفق رمز الجهاز كبديل للبيئات بدون واجهة، ومفاتيح API للأتمتة. PKCE أصبح الأكثر انتشارًا كخيار آمن حيث ما توفر المتصفح.

تخزين الرموز: ما الأنسب وما يجب تجنبه#

المصادقة السليمة لن تجدي إذا خزنت الرموز بطريقة غير آمنة.

الطريقة السليمة: سلاسل مفاتيح النظام#

كل نظام تشغيل كبير يملك مخزن اعتماد مشفر مدمج:

• macOS: Keychain (يستخدم بواسطة GitHub CLI، Claude Code)
• Windows: Credential Manager
• Linux: Secret Service API (GNOME Keyring، KDE Wallet)

هذه توفر تشفيراً و تحكم وصول على مستوى النظام، و تكامل مع عتاد الأمان. CLI الخاص بك لا يحتاج تنفيذ تشفير مخصص.

البديل: ملفات إعداد مشفرة#

إذا لم تتوفر سلسلة المفاتيح (الحاويات، أنظمة Linux الخفيفة)، استخدم ملفات إعداد مشفرة مع صلاحيات مقيدة:

ما يجب تجنبه#

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

متغيرات البيئة لتخزين بعيد الأمد. متغيرات البيئة مرئية في قوائم العمليات، وغالبًا تُسجل في أنظمة تتبع الأعطال، وتورث للعمليات الابنة. مناسبة لـ CI/CD (حيث منصة الـ CI تدير السر)، لكنها خطرة في التطوير المحلي.

localStorage في المتصفح. إذا احتوى CLI على مكون ويب، لا تخزن الرموز في localStorage. ثغرة واحدة XSS ستكشف كل شيء.

إدارة دورة حياة الرموز#

رموز الوصول#

أبقِها قصيرة الأمد. ساعة واحدة هي المعيار السائد. عند انتهاء صلاحية رمز الوصول، يجب على CLI تحديثه تلقائيًا. لا ينبغي للمستخدم إعادة تسجيل الدخول للعمليات الروتينية.

رموز التحديث#

رموز التحديث هي بيانات الاعتماد طويلة الأمد التي تسمح بالحصول على رموز وصول جديدة دون إعادة المصادقة. هي هدف مرتفع للقراصنة لطول عمرها (أيام حتى شهور).

تدوير رموز التحديث#

الأنظمة الحديثة تدير تدوير رمز التحديث مع كل استخدام:

1. CLI يرسل رمز التحديث للحصول على رمز وصول جديد
2. يعيد خادم المصادقة رمز وصول جديد ورمز تحديث جديد
3. يتم إلغاء صلاحية رمز التحديث القديم فورًا
4. يخزن CLI الرموز الجديدة

هذا يقلل ضرر سرقة رمز التحديث. إذا حاول مهاجم استخدام رمز التحديث الذي استخدمه CLI بالفعل، يكتشف الخادم إعادة الاستخدام ويلغي صلاحية الرموز للعائلة كلها. رمز المهاجم المسروق ورمز المستخدم الشرعي يتوقفان عن العمل، مما يجبر إعادة المصادقة مع منع المهاجم من الحفاظ على الوصول.

المطبات الشائعة (مع كود)#

1. الربط على كل الواجهات#

ذكرت أعلاه، لكن تكرارها مفيد: اربط دوماً بـ 127.0.0.1، لا 0.0.0.0.

2. تسجيل الرموز#

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

3. إدراج بيانات الاعتماد في صور الحاويات#

صور Docker ليست أماكن سرية. كل طبقة قابلة للاستخراج.

4. عدم التعامل مع انتهاء صلاحية الرموز بشكل جيد#

عندما ينتهي الرمز أثناء العملية، لا تنهار مع خطأ 401 فقط. حاول التحديث، واطلب إعادة المصادقة فقط إذا انتهى رمز التحديث أيضًا.

5. تجاهل مبدأ أقل صلاحية#

لا تطلب نطاق admin:* عندما تحتاج فقط repo:read. هذا ينطبق على OAuth و صلاحيات مفاتيح API.

عندما يستخدم وكيل ذكاء اصطناعي CLI الخاص بك، يصبح ذلك أكثر أهمية. من غير المرغوب أن يحوز مساعد الذكاء الاصطناعي صلاحيات حذف فقط لأنه يحتاج لقراءة الكود.

متغير وكلاء الذكاء الاصطناعي#

ما يجعل 2026 مختلفًا عن 2023: CLI لم يعد فقط للبشر الذين يكتبون أوامر. وكلاء الترميز بالذكاء الاصطناعي مثل Claude Code، Codex، و Cursor بنمط الوكيل ينادون أدوات CLI برمجياً. هذا يخلق تحديات مصادقة جديدة:

الصلاحيات المفوضة. عندما ينفذ Claude Code أمر gh pr create نيابة عنك، يستخدم بيانات اعتماد GitHub الخاصة بك. لكن هل يجب أن يمتلك وكيل الذكاء الاصطناعي نفس الصلاحيات مثلك؟ مبدأ أقل صلاحية يقول لا، لكن معظم الأدوات لا تتيح حتى الآن تقييد صلاحيات الوكلاء.

كشف الاعتمادات. إذا كان مفتاح API في متغير بيئة، جميع العمليات يمكن قراءته، بما فيها عملية الوكيل الفرعية. أدوات مثل Claude Code عالجت هذا عبر سكربتات apiKeyHelper لتوليد رموز قصيرة الأمد، لكن هذا ليس معمماً حتى الآن.

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

سجلات التدقيق. وعندما ينفذ الوكيل استدعاءات API بمصادقتك، تظهر السجلات أن أنت من قام بذلك. لا وجود لطريقة قياسية حتى الآن لتمييز "البشري فعل ذلك" من "الوكيل فعل ذلك نيابة عن البشري".

هذا مجال يتطور بسرعة. أفضل ما يمكنك فعله الآن:

• استخدم رموز ذات صلاحيات مقيدة في أعمال الوكلاء
• فضل بيانات الاعتماد القصيرة الأمد (رموز مؤقتة، لا مفاتيح طويلة الأجل)
• استخدم بيانات اعتماد مخصصة لوكلاء الذكاء الاصطناعي، بعيدًا عن بياناتك الشخصية
• راقب استخدام API لأي أنماط غير متوقعة

إطار اتخاذ القرار#

تريد اختيار طريقة مصادقة؟ إليك الاختصار:

"مستخدمون هم مطورون على أجهزتهم المحلية" → OAuth عن طريق المتصفح مع PKCE (أعلى أمان + أفضل تجربة)

"CLI يجب أن يعمل في جلسات SSH وحاويات" → تدفق رمز الجهاز كخيار خارجي، OAuth المتصفح كخيار أساسي

"تشغيل في CI/CD بلا تدخل بشري" → تدفق بيانات اعتماد العميل أو مفاتيح API مقيدة الصلاحية

"أرغب في أسرع تنفيذ ممكن" → مفاتيح API (لكن أضف تدوير الرموز لاحقًا)

"العملاء المؤسسات يحتاجون SSO و MFA" → أي تدفق OAuth (رمز الجهاز أو المتصفح)، فكلاهما يدعم مجموعة مصادقة المؤسسات كاملة

"وكلاء ذكاء اصطناعي سيستخدمون CLI" → دعم مفاتيح API (لسهولة التكامل مع الوكلاء) + OAuth المتصفح (للمستخدمين البشريين)، مع صلاحيات مقيدة ورموز قصيرة الأجل

الأسئلة الشائعة#

هل تدفق رمز الجهاز آمن؟#

هو آمن ضد أغلب التهديدات، لكن له ثغرة تصيد معروفة. المهاجم يستطيع توليد رمز جهاز وخداع المستخدمين لتفويضه. لهذا انتقلت AWS إلى PKCE كافتراضي فقط لـ SSO. في البيئات دون واجهة حيث PKCE غير عملي، يبقى تدفق رمز الجهاز الخيار الأفضل. لكن عليك الوعي بمخاطر التصيد.

هل يجب أن أخزن الرموز في متغيرات البيئة؟#

في CI/CD: نعم، لأن المنصة تشفرها وتحقنها وقت التشغيل. في التطوير المحلي: لا. استخدم سلسلة مفاتيح النظام بدلاً من ذلك. متغيرات البيئة مرئية في قوائم العمليات ويمكن تسجيلها أو تسريبها إلى العمليات الفرعية.

ما الفرق بين مفتاح API ورمز وصول شخصي؟#

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

كم مرة يجب تدوير بيانات الاعتماد؟#

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

كيف أتعامل مع المصادقة في حاويات Docker؟#

ثلاثة خيارات، حسب الأفضلية:

1. تدفق رمز الجهاز للاستخدام التفاعلي (يعمل لأن المتصفح يمكن أن يكون على جهاز مختلف)
2. متغيرات البيئة تمرر وقت التشغيل (docker run -e API_KEY=${API_KEY}) لـ CI/CD
3. أدلة الاعتماد الموصولة كـ volume (docker run -v ~/.config/tool:/root/.config/tool:ro) للتطوير المحلي

لا تدرج الاعتمادات أبدًا داخل صورة الحاوية. أبدًا.

ماذا عن مصادقة بروتوكول سياق النموذج (MCP)؟#

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

---

مصادقة CLI تتغير بسرعة. ما كان أفضل ممارسة قبل عامين (تدفق رمز الجهاز كافتراضي، ملفات اعتمادات نصية) أصبح بالفعل من الماضي. إذا كنت تضيف مصادقة لـ CLI اليوم، ابدأ مع OAuth المتصفح + PKCE للبشر، مفاتيح API للأتمتة، واستعد ليوم تصبح فيه وكلاء الذكاء الاصطناعي هم المستخدمون الرئيسيون لمصادقتك.