Logto x Hasura: استخدام JWT للتحكم في الوصول

Hasura هي أداة يمكنها بسرعة توفير خدمات API تتوافق مع بياناتك من نوع GraphQL وREST. نظرًا لأمان البيانات، توفر Hasura أيضًا القدرة على تحسين التحكم في الوصول لكل واجهة برمجة تطبيقات مختلفة.

عادةً ما يستخدم مستخدمو Hasura خدمات إدارة الهوية والمصادقة الأخرى، و Logto واحدة من أشهرها.

في هذا المُدوّنة، سنفترض أنك تستخدم خدمات Hasura بالفعل. سنقدم كيف يمكن دمج Hasura وLogto لتعظيم أمان بياناتك. إذا لم يكن لديك حساب على Logto، اشترك وابدأ في استخدامه الآن!

الخلفية#

تستخدم Hasura إدارة الوصول المستند إلى الأدوار، بينما يستخدم Logto التحكم القياسي في الوصول المستند إلى الأدوار RBAC.

في نموذج Logto وأفضل الممارسات لـ RBAC، نوصي المستخدمين بتخصيص النطاقات لتتناسب مع أدق تفاصيل الترخيصات، واستخدام الأدوار كمجموعة من النطاقات لعمليات الدفعات الملائمة، وأخيرًا التحقق من النطاقات (عادةً في جانب موفري الموارد) للتحقق إذا ما كان بإمكان المستخدم تنفيذ عملية معينة.

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

يمكن لـ Hasura دعم التحكم في الوصول باستخدام Webhooks أو JWT. في مقالنا السابق قدمنا كيفية استخدام Webhooks، وفي الأقسام التالية، سنشرح كيف يمكن استخدام وضع JWT للتحكم في الوصول.

البداية#

لنبدأ بمثال بسيط. لنفترض أن مستخدمًا لديه بالفعل واجهتان برمجة تطبيقات في Hasura، GET /user وPATCH /user، حيث يتوافقان مع دورين: user:reader وuser:maintainer، على التوالي.

1. إنشاء مورد API في Hasura في Logto#

أنشئ مورد API لـ Hasura في Logto.

2. إنشاء الأدوار وفقاً لإعدادات Hasura في Logto#

نحتاج إلى إنشاء اثنين من النطاقات لمورد API لـ Hasura المذكور في الخطوة 1، وهما read:user وmaintain:user، ثم إنشاء دورين: user:reader (يشمل نطاق read:user) وuser:maintainer (يشمل نطاق maintain:user) ليتوافقا مع أدوار Hasura واحد لواحد. وأيضًا تعيين هذه الأدوار إلى مستخدمي Logto حسب الحاجة.

3. تكوين متغير بيئة Hasura HASURA_GRAPHQL_JWT_SECRET لتمكين وضع JWT#

من خلال النظر في خيارات تكوين Hasura JWT، نحتاج إلى إضافة وتكوين متغير البيئة HASURA_GRAPHQL_JWT_SECRET قبل أن نتمكن من استخدام JWT للتحكم في الوصول.

هناك العديد من الخيارات المختلفة التي يمكن تكوينها، لكن نقدم هنا أبسط حالة: تحتاج فقط إلى تكوين jwk_url. يمكن الحصول على هذه القيمة من نقطة نهاية تكوين OpenID الخاصة بك في Logto (https://your.logto.domain/oidc/.well-known/openid-configuration).

4. تخصيص المطالبات الإضافية لرمز وصول المستخدم#

باستخدام ميزة Logto's Custom JWT، قم بتخصيص المنطق لإضافة مطالبات إضافية إلى رمز الوصول بنسق JWT الخاص بالمستخدم.

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

كما قمنا بتعريف متغير بيئة USER_DEFAULT_ROLE_NAMES لتجنب التشفير الثابت.

5. دمج Logto SDK#

بعد تكوين Logto وHasura، قم بدمج تطبيقك مع Logto SDK. هنا نستخدم مثال Next لمعاينة رمز Access Token الصادر عن Logto بعد تسجيل دخول المستخدم.

أولاً، نقوم بتعيين الأدوار التي تم إنشاؤها سابقًا user:reader وuser:maintainer إلى المستخدم، ثم نسجل الدخول كذاك المستخدم.

احصل على رمز Access Token للمستخدم واطلب واجهات برمجة تطبيقات Hasura:

الخاتمة#

في هذه المقالة، نقدم طريقة أخرى للتحكم في الوصول القائم على JWT التي يدعمها Hasura، بخلاف Webhook.

من خلال مقارنة عمليات الوصول والتحكم لكلاً من Webhook وJWT في Hasura، يمكننا أن نرى أن نهج Webhook يرسل Webhook إلى Logto وينتظر استجابة مع كل طلب Hasura؛ بينما يمكن استخدام نهج JWT باستمرار حتى انتهاء صلاحية JWT.

يمكن أن يقلل نهج JWT من تحميل الشبكة ويزيل التأخير الزمني للشبكة الذي تجلبه Webhooks؛ في المقابل، يتيح نهج Webhook تزامن التغييرات في أذونات المستخدم في الوقت الفعلي.

يمكن للمستخدمين اختيار النهج المناسب بناءً على هذه الاستنتاجات، مقترنة باحتياجات عملهم الفعلية.