- رمز التفويض + سر العميل: لتطبيقات الويب التي لديها خادم خلفي
- رمز التفويض + PKCE: للتطبيقات الأصلية وأدوات CLI وتطبيقات الصفحة الواحدة وغيرها من العملاء العامّين الذين لا يمكنهم تخزين سر العميل بأمان
- منح التفويض للجهاز: للعملاء الذين لا يمكنهم تلقي إعادة توجيه من المتصفح مطلقًا، مثل أداة CLI تعمل عبر SSH أو داخل حاوية أو في بيئة تطوير سحابية
إنشاء تطبيق OAuth
- انتقل إلى الإعدادات > تطبيقات OAuth في حسابك على Teable.
- انقر على تطبيقات OAuth جديدة لإنشاء تطبيق جديد.
-
أدخل المعلومات المطلوبة:
- اسم تطبيق OAuth: اسم وصفي لتطبيقك
- عنوان URL للصفحة الرئيسية: عنوان URL الكامل لموقع تطبيقك
- عنوان URL لمعاودة الاتصال: عنوان URL الذي سيُعاد توجيه المستخدمين إليه بعد التفويض
- النطاقات: الأذونات التي يحتاج إليها تطبيقك
- تمكين مسار الجهاز: يكون معطّلًا افتراضيًا. لا تمكّنه إلا إذا كان تطبيقك يسجّل دخول المستخدمين باستخدام رمز جهاز
- بعد إنشاء التطبيق، أنشئ سر العميل. تأكد من نسخه وحفظه بأمان، إذ لن تتمكن من رؤيته مرة أخرى.
ستتلقى معرّف العميل، وستحتاج إلى إنشاء سر العميل. حافظ على أمان بيانات الاعتماد هذه ولا تكشفها مطلقًا في الشيفرة من جانب العميل. عند استخدام مسار PKCE، لا يلزم سر عميل.
النطاقات المتاحة
تحدد النطاقات الإجراءات التي يمكن لتطبيق OAuth تنفيذها. تُنظّم النطاقات المتاحة حسب نوع المورد:مسار رمز التفويض في OAuth 2.0
يطبّق Teable مسار رمز التفويض القياسي في OAuth 2.0:الخطوة 1: إعادة توجيه المستخدمين إلى التفويض
وجّه المستخدمين إلى نقطة نهاية التفويض مع معلمات تطبيقك:
مثال:
الخطوة 2: تفويض المستخدم
سيرى المستخدمون صفحة تفويض تعرض ما يلي:- اسم تطبيقك وشعاره
- الأذونات المطلوبة (النطاقات)
- خياري الموافقة على الوصول أو رفضه
الخطوة 3: معالجة معاودة الاتصال
بعد موافقة المستخدم (أو رفضه)، يعيد Teable التوجيه إلى عنوان URL لمعاودة الاتصال: عند النجاح:الخطوة 4: استبدال الرمز برموز وصول
استبدل رمز التفويض برمز وصول ورمز تحديث:
مثال على الطلب:
مسار التفويض باستخدام PKCE
صُمم PKCE (إثبات المفتاح لتبادل الرمز) للتطبيقات التي لا يمكنها تخزين سر العميل بأمان، مثل تطبيقات سطح المكتب الأصلية وتطبيقات الأجهزة المحمولة وأدوات CLI وتطبيقات الصفحة الواحدة.الخطوة 1: إنشاء معلمات PKCE
قبل بدء التفويض، يحتاج العميل إلى إنشاء زوج من معلمات PKCE:الخطوة 2: إعادة توجيه المستخدمين إلى التفويض
مثال:
الخطوة 3: معالجة معاودة الاتصال
كما في مسار رمز التفويض القياسي، يُعاد رمز التفويض عبر إعادة التوجيه بعد موافقة المستخدم.الخطوة 4: استبدال الرمز وcode_verifier برموز وصول
لا يتطلب وضع PKCE القيمة
client_secret. تُستخدم القيمة code_verifier بدلاً منها للتحقق من هوية العميل.مسار تفويض الجهاز
يُستخدم منح تفويض الجهاز (RFC 8628) للعملاء الذين لا يمكنهم تلقي إعادة توجيه من المتصفح: مثل أداة CLI تعمل عبر SSH أو داخل حاوية أو في بيئة تطوير سحابية. يعرض عميلك عنوان URL ورمزًا قصيرًا، ويوافق المستخدم في أي متصفح، ولا يلزم إدخال أي شيء مجددًا في الطرفية. يتبع Teable معيار RFC 8628، لذا يمكن لمعظم مكتبات عميل OAuth تشغيل هذا المسار من دون شيفرة مخصصة. وفيما يلي ما يخص Teable تحديدًا.طلب رمز جهاز
أرسلPOST /api/oauth/device/code مع client_id وscope اختياري. نقطة النهاية مجهولة الهوية ومحدودة بمعدل 30 طلبًا لكل 15 دقيقة لكل عنوان IP.
BACKEND_OAUTH_DEVICE_CODE_EXPIRE_IN)، وتمثل interval الحد الأدنى لعدد الثواني الواجب انتظاره بين عمليات الاستقصاء.
اعرض verification_uri وuser_code. في تلك الصفحة، يسجّل المستخدم الدخول ويدخل الرمز ويراجع اسم تطبيقك وصفحته الرئيسية ونطاقاته المطلوبة قبل الموافقة أو الرفض. تحذّره الصفحة من الموافقة على رمز لم يبدأ طلبه بنفسه. ولا يمكن استخدام كل رمز إلا مرة واحدة.
لا يُرجع Teable القيمة
verification_uri_complete، وينبغي ألا ينشئ عميلك واحدة. يُسجّل الرمز الموافق عليه دخول الشخص الذي وافق إلى حسابه الخاص في Teable؛ ولذلك فإن الرابط الذي يحمل الرمز مسبقًا هو تحديدًا ما تعتمد عليه هجمات التصيد الاحتيالي لرمز الجهاز.الاستقصاء عن رموز الوصول
أرسلPOST /api/oauth/access_token مع grant_type=urn:ietf:params:oauth:grant-type:device_code وdevice_code وclient_id. لا يرسل العملاء العامّون client_secret، بينما يضيفه العملاء السريون كما في المسارات الأخرى.
إلى أن يوافق شخص على الرمز، تستجيب نقطة النهاية بخطأ بدلاً من رموز الوصول:
بعد موافقة المستخدم، تكون الاستجابة هي حمولة رموز الوصول نفسها المستخدمة في المسارات الأخرى.
استخدام رموز الوصول
ضمّن رمز الوصول في ترويسةAuthorization لطلبات API:
baseId من الاستجابة في استدعاءات API اللاحقة.
تحديث رموز الوصول
عند انتهاء صلاحية رمز الوصول، استخدم رمز التحديث للحصول على رمز جديد:
مثال على الطلب:
إلغاء الوصول
لمالكي تطبيق OAuth
ألغِ وصول التطبيق لجميع المستخدمين (لا يمكن تنفيذ ذلك إلا بواسطة منشئ التطبيق):للمستخدمين
ألغِ تفويضك الخاص لتطبيق محدد:للتطبيقات
يمكن للتطبيقات إلغاء وصولها باستخدام رمز وصول:لا تقبل نقطة النهاية هذه إلا المصادقة باستخدام رمز الوصول، وليس مصادقة الجلسة.
انتهاء صلاحية الرموز
معالجة الأخطاء
استجابات الأخطاء الشائعة:أفضل الممارسات
- اختيار الوضع المناسب: استخدم وضع سر العميل لتطبيقات الويب ذات الخادم الخلفي، ووضع PKCE للتطبيقات الأصلية وأدوات CLI وتطبيقات الصفحة الواحدة، ومسار الجهاز عندما يتعذر على العميل تلقي إعادة توجيه من المتصفح
- حفظ الأسرار بأمان: لا تكشف سر العميل مطلقًا في الشيفرة من جانب العميل
- استخدام معلمة state: ضمّن دائمًا معلمة
stateعشوائية لمنع هجمات CSRF - طلب الحد الأدنى من النطاقات: لا تطلب إلا الأذونات التي يحتاج إليها تطبيقك فعليًا
- معالجة تحديث الرموز: نفّذ تحديثًا تلقائيًا للرموز قبل انتهاء صلاحيتها
- تأمين تخزين الرموز: خزّن رموز الوصول والتحديث بأمان على خادمك

