Sanctum مقابل Passport: أغلب الفرق تختار الغالي

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

والسؤال ليس أي حزمة أفضل. بل من يحمل الرمز.

لماذا وُجد OAuth2 فعلًا

وُجد OAuth2 ليستطيع طرف ثالث التصرف نيابةً عن مستخدم دون أن يسلّمه المستخدم كلمة مروره. تلك هي المشكلة التي يحلها: التفويض عبر حد ثقة. وشاشة الموافقة، ورمز التخويل، وبيانات اعتماد العميل، والنطاقات - كل ذلك موجود لجعل ذلك التبادل بعينه آمنًا.

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

ماذا يكلّف ذلك حين يكون خطأ

يجلب Passport خادم OAuth2 إلى تطبيقك: جداول عملاء، ورموز تخويل، ورموز وصول وتجديد، وتوليد مفاتيح، وفحص رموز، ومساحة ترقية يجب إبقاؤها محدَّثة.

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

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

Sanctum، وهو ما تريده أغلب الواجهات

رموز معتمة، تُخزَّن مجزّأة، بقدرات وإبطال لكل رمز:

$token = $user->createToken('mobile', ['orders:read'])->plainTextToken;

لا شيء تقيمه، ولا شيء تدوّره، والإبطال حذف صف. ولتطبيق محمول، أو أداة سطر أوامر، أو مفتاح من خادم إلى خادم يُصدَر لعميل، تلك هي الصورة الصحيحة.

والجزء الذي يغفله الناس أن لـ Sanctum وضعًا ثانيًا أفضل منه.

لتطبيق صفحة واحدة خاص بك، لا رمز إطلاقًا

إن كان تطبيق الصفحة الواحدة لديك يُقدَّم من النطاق العلوي نفسه الذي تقدَّم منه الواجهة البرمجية، فإن Sanctum يصادقه بملف ارتباط الجلسة المعتاد:

GET  /sanctum/csrf-cookie      → يضع ملف ارتباط CSRF
POST /login                    → تسجيل دخول جلسة عادي
GET  /api/orders               → مصادَق بملف ارتباط، محمي بـ CSRF

لا رمز في localStorage، فلا شيء يسرقه عطل برمجة نصية عابرة للمواقع. HttpOnly وSameSite وحماية CSRF - مجموعة حماية المتصفح كاملةً التي تتخلى عنها المصادقة بالرمز في التخزين.

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

متى يكون Passport صحيحًا فعلًا

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

أنت مزوّد الهوية. أنظمة أخرى تصادق مقابلك.

متطلب معياري. شريك أو عملية شراء تشترط OAuth2 ولا تفاوض في ذلك.

لاحظ ما تشترك فيه هذه: شخص خارج مؤسستك يحمل بيان الاعتماد. تلك هي المحكّة كلها.

الانتقال بينهما

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

ومن Sanctum إلى Passport، حين يظهر تكامل طرف ثالث حقيقي: ثبّت Passport لتدفقات الأطراف الثالثة وأبقِ Sanctum لعملائك. يتعايشان بـ guards مختلفة. وهذا سبب آخر لكون البدء بـ Sanctum لا يكلّفك شيئًا - أنت لست محشورًا في زاوية، أنت فقط لا تدفع مقدمًا.

القاعدة، مرة أخرى

عميلك ورمزك: Sanctum. وعميل غيرك يتصرف نيابةً عن مستخدمك: Passport.

وإن لم تستطع تسمية الطرف الثالث، فأنت لا تحتاج OAuth2 بعد - وسياسة الإصدارات التي تكتبها لتلك الواجهة ستهم مستهلكيها أكثر بكثير من أي حزمة أصدرت الرمز.