OAuth مفيد، لكن Google وMicrosoft تحولانه إلى بوابة تتحكمان بها

OAuth تحسين أمني

كان الابتعاد عن Basic Authentication وكلمات المرور طويلة الأجل وبيانات الدخول واسعة الامتيازات قراراً صحيحاً. يتيح OAuth صلاحيات محدودة ورموز وصول قصيرة العمر واتصالات قابلة للإلغاء وتحكماً أفضل فيما يستطيع التطبيق فعله فعلاً.

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

قد يتحول معيار مفتوح مع ذلك إلى بوابة مغلقة

ظهر SMTP وIMAP في إنترنت بُني حول قابلية التشغيل البيني. كان بمقدور مقدم خدمة تشغيل خادم بريد، ومطور بناء عميل، وكان الاثنان يتواصلان بمعايير موثقة.

لا يهدم OAuth هذا الانفتاح. لكن عندما يعتمد الوصول إلى البريد أيضاً على موافقة مالك المنصة، يتغير السؤال الحاسم: هل يخول المستخدم التطبيق، أم تقرر Google أو Microsoft ما إذا كان مسموحاً بتخويله أصلاً؟

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

Microsoft 365: تتوقف الموافقة غالباً عند حدود المستأجر

الحاجز لدى Microsoft الموصوف هنا ليس غالباً مراجعة فيديو بأسلوب Google. بل هو تفاعل Microsoft Entra ID والتحقق من الناشر وموافقة المسؤول وسياسات كل مستأجر Microsoft 365.

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

قد يكون التحقق من الناشر حاسماً أيضاً للتطبيقات الأحدث متعددة المستأجرين. ومن المتطلبات حساب متحقق منه في Microsoft AI Cloud Partner Program مرتبط بتسجيل التطبيق. إنها إشارة ثقة مفهومة، لكنها تربط أيضاً قابلية استخدام التخويل المفتوح بإجراءات Microsoft التجارية وإجراءات الشركاء.

Google وGmail: قد تصبح مراجعة الصلاحيات عنق زجاجة للمنتج

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

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

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

لحد 100 مستخدم عواقب عملية

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

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

لماذا تحتاج Hassolux إلى هذه الصلاحيات

Hassolux منصة عمل لشركات البناء والخدمات، تجمع المشاريع والوثائق والفواتير والتواصل في مسار قابل للتتبع. يفعّل مستخدم مخوّل اتصال البريد الاختياري فيها عن قصد.

في Microsoft 365، يدعم وصول Mail.Read وMail.Send المفوّض قراءة الرسائل الواردة نيابةً عن المستخدم المسجل وإرسال رسائل المستندات التي يطلبها صراحةً. وفي Gmail، تسترجع gmail.readonly الرسائل المحددة ومرفقات PDF/XML، بينما تُستخدم gmail.send منفصلةً للبريد الصادر بمبادرة المستخدم.

تبحث Hassolux فقط في الفترة التي اختارها المستخدم، وتقرأ المرسل والموضوع ووقت الاستلام، وتستورد مرفقات PDF أو XML المدعومة لمعالجة الفواتير. ولا تنقل رسائل Gmail أو تضع علامات عليها أو تعدلها أو تحذفها. الإرسال منفصل ولا يحدث إلا بعد إجراء محدد من المستخدم. يمكن إزالة الاتصال وإلغاء تخويله أيضاً لدى مقدم الخدمة.

قد يصبح طلب صلاحية أضيق متناقضاً تقنياً هنا. إذ لا توفر صلاحية البيانات الوصفية وحدها محتوى الرسالة أو مرفقات الفاتورة؛ ولا يستطيع التطبيق استيراد مستند لا يُسمح له بقراءته. لهذه الميزة المرئية، تُطلب gmail.readonly باعتبارها أضيق صلاحية Google توفر الوصول اللازم، لا تجميعاً احتياطياً لحقوق أوسع.

تجربتنا: عروض متكررة ورفض رغم ذلك

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

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

ما الذي ينبغي أن توفره عملية تحقق عادلة

تهدف التحسينات المقترحة إلى الحفاظ على الحماية مع جعل التكاملات المستقلة ممكنة.

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

ينبغي أن يبقى التخويل المفتوح مفتوحاً

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

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