طرق المصادقة الأربعة للـ CLI التي تهمك، كيف تنفذها GitHub و AWS وأدوات الذكاء الاصطناعي، وأخطاء الأمان التي يجب عليك تجنبها.
كل أداة أوامر خاصة بالمطورين (CLI) تأتي مع الأمر login كأول أمر. وكل واحدة منها تحل المصادقة بطريقة مختلفة.
تعرض لك GitHub رمزًا وتفتح متصفحك للتحقق منه. تفتح AWS المتصفح لتسجيل دخول مبني على PKCE. تطلب منك Stripe تأكيد رمز الاقتران في لوحة التحكم. أدوات الذكاء الاصطناعي الأحدث (Claude Code، OpenAI Codex CLI، Cursor) اختارت كل واحدة منها نهجها الخاص أيضًا.
إذا كنت تبني CLI، فإن المصادقة هي من أولى الأمور التي يجب أن تحددها. اختيار الطريقة الخطأ سيجلب لك المشاكل: مستخدمون محبطون، تدقيقات أمنية، أو كلاهما. ومع الموجة الأخيرة من وكلاء الترميز بالذكاء الاصطناعي الذين يستدعون أدوات CLI بشكل برمجي، أصبحت المخاطرة أكبر: أنت لا تصادق إنساناً فقط الآن. ربما تسلم الاعتمادات لعملية ذاتية التشغيل.
إليك الطرق الأربعة للمصادقة التي تهم، كيف تنفذها أكبر الأدوات، والأخطاء التي يجب أن تتجنبها.
قبل الدخول بالتفاصيل، إليك مقارنة سريعة:
| الطريقة | الأنسب لـ | الأمان | هل تحتاج متصفحًا؟ |
|---|---|---|---|
| تدفق رمز الجهاز OAuth | البيئات بدون واجهة، SSH | عالي | لا (على نفس الجهاز) |
| OAuth المعتمد على المتصفح (إعادة توجيه عبر localhost) | التطوير المحلي | الأعلى | نعم |
| مفاتيح API / رموز الوصول الشخصي | الأتمتة، CI/CD، النماذج السريعة | متوسط | لا |
| بيانات الاعتماد للعميل | آلة إلى آلة، الخدمات | عالي | لا |
لكل طريقة مميزات وعيوب. هذا ما تحتاج معرفته عن كل واحدة.
هذه هي الطريقة التي يعرض فيها CLI الخاص بك رمزًا مثل ABCD-1234 ورابطًا، ثم يخبرك بفتح هذا الرابط على أي جهاز وإدخال الرمز.
من يستخدمها: GitHub CLI (الافتراضي)، Azure CLI (باستخدام --use-device-code)، Vercel CLI (انتقلت مؤخرًا إلى هذه كخيار افتراضي)، OpenAI Codex CLI (كخيار تجريبي)
cli loginclient_id والنطاقات المطلوبةdevice_code (معرف داخلي)، user_code (الرمز القصير الذي تدخله)، و verification_uri (الرابط الذي تذهب إليه)النقطة الأساسية: تعمل في أي مكان. جلسة 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 8628:
expires_in لرموز الجهاز تحدد من مزود المصادقة. مثال RFC هو 1800 ثانية (30 دقيقة) لكن ليست إلزامية.slow_down، زد الفاصل الزمني 5 ثوانٍ إضافية.هذه الطريقة الأكثر شيوعًا للأدوات التي تعمل على جهاز المطور المحلي. تقوم بتشغيل login، يفتح المتصفح، تصادق، والمتصفح يعيد التوجيه إلى خادم محلي يقوم CLI بتشغيله مؤقتًا. التطبيقات الحديثة تضيف PKCE (تنطق "بكسي")، مما يجعل المصادقة أكثر أمانًا بكثير.
من يستخدمها: Claude Code، gcloud CLI، Terraform CLI، AWS CLI v2.22+ (لـ SSO، PKCE افتراضيًا)
cli loginhttp://127.0.0.1:8742)http://127.0.0.1:8742/callback?code=XXXX&state=YYYYتجربة المستخدم سلسلة تمامًا. لا رموز للنسخ، لا روابط للكتابة. فقط علامة متصفح تفتح وتغلق.
تعمل فقط عندما يتمكن CLI من فتح متصفح والاتصال عبر localhost. وهذا يستثني:
ولهذا أغلب الأدوات التي تعتمد على 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:
code_verifier (سلسلة عشوائية قوية)code_challenge بتجزئة التحقق عبر SHA-256code_verifier الأصليالمهاجم الذي يعترض رمز التفويض لن يكون معه code_verifier، لذا لن يتمكن من إتمام التبادل.
لهذا السبب أصبحت AWS CLI v2.22+ تعتمد PKCE افتراضيًا لـ SSO، مبتعدة عن تدفق رمز الجهاز. عندما يستطيع CLI فتح المتصفح على نفس الجهاز، OAuth مع PKCE أفضل أمنيًا بكثير – نفس تجربة المستخدم، بضمانات أمنية أقوى، ولا يوجد مجال للتصيد. تدفق رمز الجهاز يبقى الخيار الأنسب عندما لا يمكن للمتصفح التواجد على نفس الجهاز (SSH، حاويات، بيئات تطوير بعيدة)، لكنه ليس النموذج الشائع للتطوير المحلي.
النهج الأبسط. تولد رمزًا على لوحة التحكم في الويب، تلصقه في إعدادات CLI أو في متغير بيئة، وانتهى الأمر.
من يستخدمها: Stripe CLI (كخيار تسجيل الدخول)، npm، pip، أغلب أدوات الذكاء الاصطناعي كخيار بديل (Claude Code عبر ANTHROPIC_API_KEY، أدوات OpenAI عبر OPENAI_API_KEY، Aider)
sk_live_, ghp_, npm_)~/.config/stripe/config.toml, ~/.aws/credentials) أو متغير بيئةيقرأ CLI المفتاح عند بدء التشغيل ويضيفه لطلبات API عادة كـ Bearer token في ترويسة Authorization.
بالنسبة للأتمتة، يصعب التفوق على مفاتيح API. تعمل في CI/CD، في الحاويات، في السكربتات، وظائف الكرون ... إلخ. أي مكان يمكنه قراءة متغير بيئة. لا حاجة لمتصفح. لا مطالبات تفاعلية. لا يحتاج تدوير الرموز.
لوكلاء الذكاء الاصطناعي خصوصاً، مفاتيح API أبسط اختبار. حين يحتاج Claude Code أو Cursor لاستدعاء API، متغير بيئة به مفتاح هو أسهل نقطة تكامل.
أفضل ممارسة عند استخدام مفاتيح API: استبدلها أثناء التشغيل برموز مؤقتة قصيرة العمر.
كانت AWS رائدة في ذلك مع STS (خدمة الرموز الأمنية). تستخدم بيانات الاعتماد طويلة الأمد فقط لطلب بيانات اعتماد مؤقتة تنتهي خلال ساعة. أدوات مثل aws-vault تقوم بذلك آليًا.
حتى إذا بدأت بمفاتيح API، فكر في إضافة هذا النمط. هكذا تقلل نافذة الخطر لرمز مخترق من "حتى ينتبه شخص ما" إلى "ساعة واحدة فقط."
هذا التدفق من OAuth 2.0 مصمم لعمليات المصادقة بين الخدمات، بلا تدخل بشري.
يستخدم في: خطوط CI/CD، الخدمات الخلفية، الأدوات المؤتمتة
ترسل الخدمة client_id و client_secret مباشرة لخادم المصادقة وتحصل على رمز وصول قصير الأمد. لا متصفح، لا تفاعل بشري، لا إعادة توجيه.
استخدم بيانات اعتماد العميل حين:
لا تستخدمها لمصادقة البشر. لا تدعم MFA، SSO، أو أي تحقق تفاعلي.
إليك جدول محدث حسب الوثائق البرمجية والشيفرة المصدرية. كثير من المقالات تخطئ لأن الأدوات تغير الافتراضات باستمرار.
| أداة CLI | المصادقة الافتراضية | خيارات بديلة | مكان تخزين الرموز |
|---|---|---|---|
GitHub CLI (gh) | تدفق رمز الجهاز عبر المتصفح | PAT (--with-token), متغير (GH_TOKEN) | سلسلة المفاتيح للنظام (بديل: ملف نصي) |
| AWS CLI v2 | تدفق رمز التفويض مع PKCE (SSO) | تدفق رمز الجهاز (--use-device-code), ملفات الاعتماد | ~/.aws/sso/cache/ |
Azure CLI (az) | WAM على Windows؛ تدفق رمز التفويض في المتصفح على Linux/macOS | رمز الجهاز (--use-device-code) | ~/.azure/msal_token_cache.* |
| Vercel CLI | تدفق رمز الجهاز (الإعداد الافتراضي الجديد، سبتمبر 2025) | رمز API (--token, متغير) | ~/.local/share/com.vercel.cli/auth.json |
| Stripe CLI | تدفق اقتران عبر المتصفح | مفتاح API (--interactive, --api-key, أو متغير) | ~/.config/stripe/config.toml |
| gcloud CLI | OAuth المتصفح | تدفق يدوي --no-browser | ~/.config/gcloud/ |
| Claude Code | OAuth المتصفح | مفتاح API (متغير، apiKeyHelper) | سلسلة مفاتيح النظام / ~/.claude/.credentials.json |
| OpenAI Codex CLI | OAuth المتصفح | رمز الجهاز (تجريبي)، مفتاح API | ~/.codex/auth.json / سلسلة مفاتيح النظام |
| Terraform CLI | OAuth المتصفح | لصق الرمز | ~/.terraform.d/credentials.tfrc.json |
الاتجاه واضح: OAuth المعتمد على المتصفح هو الافتراضي للتطوير المحلي، مع تدفق رمز الجهاز كبديل للبيئات بدون واجهة، ومفاتيح API للأتمتة. PKCE أصبح الأكثر انتشارًا كخيار آمن حيث ما توفر المتصفح.
المصادقة السليمة لن تجدي إذا خزنت الرموز بطريقة غير آمنة.
كل نظام تشغيل كبير يملك مخزن اعتماد مشفر مدمج:
هذه توفر تشفيراً و تحكم وصول على مستوى النظام، و تكامل مع عتاد الأمان. CLI الخاص بك لا يحتاج تنفيذ تشفير مخصص.
إذا لم تتوفر سلسلة المفاتيح (الحاويات، أنظمة Linux الخفيفة)، استخدم ملفات إعداد مشفرة مع صلاحيات مقيدة:
الملفات النصية. ينبغي أن يكون واضحًا، لكن عددًا من الأدوات ما زال يفعل ذلك. ملف رمز نصي متاح لجميع العمليات العاملة بواسطة المستخدم، كل أداة نسخ احتياطي، و أي شخص يحصل وصولاً مؤقتًا للجهاز.
متغيرات البيئة لتخزين بعيد الأمد. متغيرات البيئة مرئية في قوائم العمليات، وغالبًا تُسجل في أنظمة تتبع الأعطال، وتورث للعمليات الابنة. مناسبة لـ CI/CD (حيث منصة الـ CI تدير السر)، لكنها خطرة في التطوير المحلي.
localStorage في المتصفح. إذا احتوى CLI على مكون ويب، لا تخزن الرموز في localStorage. ثغرة واحدة XSS ستكشف كل شيء.
أبقِها قصيرة الأمد. ساعة واحدة هي المعيار السائد. عند انتهاء صلاحية رمز الوصول، يجب على CLI تحديثه تلقائيًا. لا ينبغي للمستخدم إعادة تسجيل الدخول للعمليات الروتينية.
رموز التحديث هي بيانات الاعتماد طويلة الأمد التي تسمح بالحصول على رموز وصول جديدة دون إعادة المصادقة. هي هدف مرتفع للقراصنة لطول عمرها (أيام حتى شهور).
الأنظمة الحديثة تدير تدوير رمز التحديث مع كل استخدام:
هذا يقلل ضرر سرقة رمز التحديث. إذا حاول مهاجم استخدام رمز التحديث الذي استخدمه CLI بالفعل، يكتشف الخادم إعادة الاستخدام ويلغي صلاحية الرموز للعائلة كلها. رمز المهاجم المسروق ورمز المستخدم الشرعي يتوقفان عن العمل، مما يجبر إعادة المصادقة مع منع المهاجم من الحفاظ على الوصول.
ذكرت أعلاه، لكن تكرارها مفيد: اربط دوماً بـ 127.0.0.1، لا 0.0.0.0.
يحدث هذا كثيرًا أكثر من المتوقع. سطر سجل تصحيح، معالج أخطاء يطبع ترويسات الطلب، وضع مفصل يطبع كل شيء.
صور Docker ليست أماكن سرية. كل طبقة قابلة للاستخراج.
عندما ينتهي الرمز أثناء العملية، لا تنهار مع خطأ 401 فقط. حاول التحديث، واطلب إعادة المصادقة فقط إذا انتهى رمز التحديث أيضًا.
لا تطلب نطاق 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 بمصادقتك، تظهر السجلات أن أنت من قام بذلك. لا وجود لطريقة قياسية حتى الآن لتمييز "البشري فعل ذلك" من "الوكيل فعل ذلك نيابة عن البشري".
هذا مجال يتطور بسرعة. أفضل ما يمكنك فعله الآن:
تريد اختيار طريقة مصادقة؟ إليك الاختصار:
"مستخدمون هم مطورون على أجهزتهم المحلية" → OAuth عن طريق المتصفح مع PKCE (أعلى أمان + أفضل تجربة)
"CLI يجب أن يعمل في جلسات SSH وحاويات" → تدفق رمز الجهاز كخيار خارجي، OAuth المتصفح كخيار أساسي
"تشغيل في CI/CD بلا تدخل بشري" → تدفق بيانات اعتماد العميل أو مفاتيح API مقيدة الصلاحية
"أرغب في أسرع تنفيذ ممكن" → مفاتيح API (لكن أضف تدوير الرموز لاحقًا)
"العملاء المؤسسات يحتاجون SSO و MFA" → أي تدفق OAuth (رمز الجهاز أو المتصفح)، فكلاهما يدعم مجموعة مصادقة المؤسسات كاملة
"وكلاء ذكاء اصطناعي سيستخدمون CLI" → دعم مفاتيح API (لسهولة التكامل مع الوكلاء) + OAuth المتصفح (للمستخدمين البشريين)، مع صلاحيات مقيدة ورموز قصيرة الأجل
هو آمن ضد أغلب التهديدات، لكن له ثغرة تصيد معروفة. المهاجم يستطيع توليد رمز جهاز وخداع المستخدمين لتفويضه. لهذا انتقلت AWS إلى PKCE كافتراضي فقط لـ SSO. في البيئات دون واجهة حيث PKCE غير عملي، يبقى تدفق رمز الجهاز الخيار الأفضل. لكن عليك الوعي بمخاطر التصيد.
في CI/CD: نعم، لأن المنصة تشفرها وتحقنها وقت التشغيل. في التطوير المحلي: لا. استخدم سلسلة مفاتيح النظام بدلاً من ذلك. متغيرات البيئة مرئية في قوائم العمليات ويمكن تسجيلها أو تسريبها إلى العمليات الفرعية.
وظيفيًا، لا شيء تقريبًا. كلاهما بيانات اعتماد طويلة الأمد تصادق طلبات API. الفرق تنظيمي غالبًا: مفاتيح API غالبًا ترتبط بتطبيق أو مشروع، بينما رموز الوصول الشخصية مرتبطة بحساب المستخدم. بعض الخدمات تستخدم المصطلحين بالتبادل.
رموز الوصول: كل ساعة أو أقل (يتم تلقائيًا عن طريق تدفق التحديث). رموز التحديث: على كل استخدام (يجب أن يفعلها خادم المصادقة). مفاتيح API: كل 90 يومًا على الأقل، أو فورًا إذا تشككت في تسربها. عمليًا، أغلب الفرق لا تدور مفاتيح API إلا بعد حادث أمني، وذلك متأخر جدًا.
ثلاثة خيارات، حسب الأفضلية:
docker run -e API_KEY=${API_KEY}) لـ CI/CDdocker run -v ~/.config/tool:/root/.config/tool:ro) للتطوير المحليلا تدرج الاعتمادات أبدًا داخل صورة الحاوية. أبدًا.
MCP هو المعيار الناشئ لوكلاء الذكاء الاصطناعي للاتصال بالأدوات والخدمات الخارجية. يقدم بعد مصادقة جديد: الوكيل يحتاج بيانات اعتماد للاتصال بخادم MCP، الذي يحتاج بدوره بيانات اعتماد لاستدعاء APIs الأخرى. لا يزال يتم توحيده. حاليًا أغلب تطبيقات MCP تستخدم مفاتيح API أو رموز OAuth تمرر في الإعداد. توقع تطور الأمر بسرعة.
مصادقة CLI تتغير بسرعة. ما كان أفضل ممارسة قبل عامين (تدفق رمز الجهاز كافتراضي، ملفات اعتمادات نصية) أصبح بالفعل من الماضي. إذا كنت تضيف مصادقة لـ CLI اليوم، ابدأ مع OAuth المتصفح + PKCE للبشر، مفاتيح API للأتمتة، واستعد ليوم تصبح فيه وكلاء الذكاء الاصطناعي هم المستخدمون الرئيسيون لمصادقتك.