تنفيذ Passkeys وWebAuthn بدل كلمات المرور: دليل عملي لدمج المصادقة بدون كلمة مرور مع OAuth وOpenID

مقدمة خاطفة: لماذا التخلي عن كلمات المرور الآن؟

كلمات المرور تظل سببًا رئيسيًا للاختراقات والهجمات القائمة على الاحتيال (phishing)، بينما توفر آليات مثل WebAuthn وPasskeys مصادقة خالية من كلمة المرور تعتمد على تشفير المفتاح العام، ما يجعل هجمات الصيد الاحتيالي وتقنيات إعادة الاستخدام أقل فعالية.

WebAuthn هو معيار Web (W3C) يعرّف واجهة برمجة للتعامل مع بيانات الاعتماد العامة من المتصفّح إلى المصادّق (authenticator).

مفهوم Passkeys مبني على مواصفات FIDO ويقدّم طريقة سهلة للمستخدم لحفظ ومزامنة بيانات الاعتماد القابلة للاكتشاف عبر أجهزة موثوقة دون كلمات مرور تقليدية.

في هذا الدليل العملي سنغطي: المفاهيم الأساسية، مراسم التسجيل والمطالبة، تكامل WebAuthn مع أنظمة الهوية القائمة على OAuth 2.0/OpenID Connect، نماذج بيانات، اعتبارات أمان، واستراتيجية هجرة من أنظمة كلمات المرور.

فهم المكونات: مصطلحات سريعة ومشهد التطوير

مصطلحات أساسية:

• Authenticator: الجهاز أو المكوّن (مثل الهاتف، Windows Hello، YubiKey) الذي يخزن المفتاح الخاص وينفذ التوقيع.
• Credential / Passkey: زوج مفتاح عام/خاص؛ المفتاح العام يُخزن لدى الخادم (Relying Party) والمفتاح الخاص يبقى محليًا على المصادّق أو في مخزن مزوّد (synced credential).
• Attestation: معلومات اختيارية تثبت نوع المصادّق (مثلاً معدات موثوقة) وتُستخدم عند التسجيل.
• Assertion: التوقيع الذي يقدم إثبات حيازية المفتاح الخاص أثناء تسجيل الدخول.

المطورون يتعاملون عادةً مع طرفين: جافاسكربت على المتصفح لاستدعاء navigator.credentials.create() وnavigator.credentials.get()، وخادم Relying Party الذي يولد تحديات (challenges) ويتحقق من التواقيع. تفاصيل الواجهة في مرجع MDN تفصّل واجهة WebAuthn وطريقة الاستخدام البرمجية.

ملاحظة: هناك نوعان من بيانات الاعتماد—discoverable (قابلة للاكتشاف) وnon-discoverable (غير قابلة للاكتشاف). اختيار النوع يؤثر على تجربة المستخدم وسيناريوهات الاسترجاع/الانتقال بين الأجهزة.

دمج WebAuthn/Passkeys مع OAuth 2.0 وOpenID Connect — سيناريو عملي

هناك طريقتان شائعتان لربط WebAuthn مع أنظمة الهوية (Authorization Server):

1. كطريقة مصادقة للـ IdP/OAuth Authorization Server: يجعل خادم الهوية (مثل Keycloak، Auth0، أو حل داخلي) يدعم مراسم WebAuthn كعامل تحقق أساسي أو ثانوي، وبالتالي يتحكم في إصدار id_token وaccess_token أثناء Authorization Code Flow. توجيهات مقدمي الهوية مثل Okta توضّح كيفية تفعيل WebAuthn كمصادقة.
2. كخط تحقق في تطبيق مستقل مع تبادل رمزي: يُنفّذ التطبيق المحلي مراسم WebAuthn للتحقق من هوية المستخدم، ثم يقوم بطلب رمز (token) من Authorization Server عبر مشغل معمول له (مثلاً via Resource Owner Password-like exchange أو عبر backend-for-frontend) مع إثبات مصداقية الجلسة. ملاحظة: يُفضّل ألا تُستبدل مبادئ OAuth الأصلية بآليات غير موثوقة—بل اجعل WebAuthn خطوة تحقق قبل إصدار الرموز.

تسلسل تسجيل نموذجي (Register / Create)

1. العميل يطلب إنشاء اعتمادية: الخادم يولد challenge ويُرسله مع relyingParty وuser metadata.
2. في المتصفح: استدعاء navigator.credentials.create({ publicKey }) ينتج attestationObject وclientDataJSON.
3. الخادم يتحقق من توقيع الـ attestation، يستخرج المفتاح العام ويخزنه مع سجل المستخدم (user.id, credential.id, publicKey, signCount، attestation metadata إذا لزم الأمر).

تسلسل تسجيل الدخول نموذجي (Authenticate / Get)

1. الخادم يولد تحديًا جديدًا ويرسله إلى العميل مع قائمة allowCredentials أو ترك الاعتماد قابلًا للاكتشاف حسب السيناريو.
2. المتصفح يستدعي navigator.credentials.get({ publicKey }) فينتج authenticatorData وsignature.
3. الخادم يتحقق من التوقيع بتابع المفتاح العام المخزن، ويتحقق من nonce/تحديات، ثم ينشئ جلسة ويصدر رموز OAuth/OpenID عند الاقتضاء.

لتوصيل هذا بسير عمل OAuth: بعد تحقق WebAuthn، اعمل خطوة تفويض داخل Authorization Server لإصدار id_token/access_token أو أربط جلسة المستخدم لدى مزود الهوية. حلول IdP الشائعة توفر أمثلة لوضع WebAuthn كمصادقة أساسية أو متعددة العوامل.

مثال بنية جدول اعتمادات مبسّط (SQL):

CREATE TABLE webauthn_credentials (
  id SERIAL PRIMARY KEY,
  user_id UUID NOT NULL,
  credential_id BYTEA UNIQUE NOT NULL,
  public_key BYTEA NOT NULL,
  sign_count BIGINT DEFAULT 0,
  transports TEXT,
  created_at TIMESTAMP DEFAULT now()
);

نقاط مهمة: خزّن credential_id وpublic_key بصيغة مصفوفة بايت (BLOB) أو BASE64URL، وتتبّع signCount لاكتشاف استنساخ المفاتيح.

اعتبارات أمان، هجرة المستخدمين، وممارسات تشغيلية

فوائد أمان رئيسية:

• مقاومة قوية للصيد الاحتيالي (phishing) لأن التوقيع يرتبط بالمجال (origin) للمتصفح ولا يمكن إرساله لمواقع طرف ثالث.
• لا توجد كلمات مرور قابلة للسرقة على الخادم (لا حاجة لتخزين password hashes).

إستراتيجية هجرة تدريجية

1. أضف Passkeys كخيار اختياري أولًا: اسمح للمستخدمين بإنشاء Passkey بجانب كلمة المرور، واربط الاعتماد بحسابه.
2. حفّز التبنّي: عرض تجربة تسجيل سهلة، زر "تفعيل المصادقة بدون كلمة مرور"، ورسائل بريدية/في المنتج تشرح الفوائد.
3. بعد فترة تقييم، اجعل Passkeys الخيار الافتراضي مع استمرار دعم الوسائل الاحتياطية (OTP، مفاتيح أمان) خلال نافذة الانتقال.

Fallbacks واحتياطات

• وفّر آليات لاسترداد الحساب (مفاتيح احتياطية، دعم حسابات بريدية مُحقّقَة، أو Helpdesk مع إجراءات تحقق هوية قوية).
• لا تعوّض WebAuthn بطريقة تُضعف الأمان—تجنّب إعادة كلمة المرور كخيار وحيد للاسترداد دون ضوابط إضافية.

ممارسات تشغيلية

• فعّل سجلات تدقيق للتسجيلات والمطالبات (attestation/assertion) مع حفظ clientDataJSON محدودًا للتحليل الحاصل على موافقة الخصوصية.
• اختبر على متصفحات رئيسية: Chrome, Edge, Firefox, Safari؛ واعمل اختبارات خاصة بتطبيقات سطح المكتب (Electron) لأن دعم WebAuthn قد يختلف.
• ضع مراقبة لــsignCount غير المتوقّع أو تسجيلات عادية لعملية attestation قد تدل على سوء استخدام.

تذكّر أن تبنّي Passkeys يزداد على مستوى الصناعة—التحرك نحو المصادقة بدون كلمات مرور مدعوم من شركات ومنصّات كبرى، ما يهيئ بيئة تطبيقية أفضل للمستخدمين.

قائمة فحص نهائية قبل الإطلاق:

• تحقق من صحة التواقيع وتخزين المفاتيح العامة بشكل صحيح.
• ادعم حالات الهجرة والاسترداد بآليات آمنة وواضحة للمستخدم.
• اختبر عبر متصفحات وأجهزة حقيقية (بيانات اعتماد جهازية ومزامنة Passkey).
• راقب مؤشرات الخلل الأمني وسجل الأحداث الحرجة.

للمراجع التقنية التفصيلية: راجع مواصفة WebAuthn (W3C) ودليل تنفيذ Passkeys من FIDO Alliance، كما توفّر منصات الهوية أمثلة تطبيقية لربط WebAuthn بخادم OAuth/OIDC.

خاتمة: اعتماد Passkeys وWebAuthn هو قفزة نوعية للأمن وتجربة المستخدم، لكن يتطلب تصميم سير هجرة حكيم، بنية خادم صحيحة، وخطة استرداد متينة قبل استبدال كلمات المرور نهائيًا.