Passkey و WebAuthn: تسجيل الدخول بدون كلمة مرور، بدون سحر

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

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

ماذا يحدث حقا

أ passkey هي بيانات اعتماد تعتمد على WebAuthn. عندما يقوم المستخدم بإنشائه، يقوم الجهاز بإنشاء زوج مفاتيح:

• المفتاح الخاص الذي يبقى على الجهاز أو في مدير كلمات المرور؛
• مفتاح عام يمكن للخادم حفظه.

عند تسجيل الدخول لا يطلب الخادم "أخبرني بكلمة المرور". إرسال تحدي عشوائي. يقوم الجهاز بتوقيعه بالمفتاح الخاص. يتحقق الخادم من التوقيع باستخدام المفتاح العام.

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

يعمل المتصفح كجسر

في المتصفح الرئيسيين API هما:

• navigator.credentials.create() لإنشاء passkey؛
• navigator.credentials.get() لاستخدامه أثناء تسجيل الدخول.

لكن المنطق المهم موجود على الخادم. يجب على الخادم إنشاء التحدي وحفظه مؤقتًا والتحقق من الاستجابة والتحقق من المصدر وRelying Party ID ثم إنشاء الجلسة.

يجب أن يكون جزء العميل مملًا تقريبًا:

const options = await fetch('/api/passkeys/login/options').then((r) => r.json());

const credential = await navigator.credentials.get({
  publicKey: PublicKeyCredential.parseRequestOptionsFromJSON(options),
});

await fetch('/api/passkeys/login/verify', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify(credential?.toJSON()),
});

إذا وجدت نفسك تنفذ تشفير WebAuthn يدويًا، توقف. استخدم مكتبة قوية من جانب الخادم. الأخطاء هنا ليست "أخطاء لطيفة"، بل هي ثغرات في المصادقة.

ما يجب حفظه في قاعدة البيانات

ليست هناك حاجة لإنقاذ نصف العالم. عادة ما يكفي:

• معرف أوراق الاعتماد.
• المفتاح العام؛
• مستخدم متصل؛
• أي عداد تحقق أو بيانات وصفية؛
• وسائل النقل، إذا كانت مفيدة لتجربة المستخدم؛
• الاسم الذي اختاره المستخدم؛
• تاريخ الإنشاء وآخر استخدام.

قد يبدو الجدول البسيط كما يلي:

create table passkey_credentials (
  id uuid primary key default gen_random_uuid(),
  user_id uuid not null references users(id),
  credential_id text not null unique,
  public_key text not null,
  name text,
  created_at timestamptz not null default now(),
  last_used_at timestamptz
);

ثم أود إضافة سجلات التدقيق والإشعارات: إذا قام شخص ما بإنشاء passkey جديد على حسابي، فأنا أريد أن أعرف ذلك.

تجربة المستخدم أكثر أهمية من العرض التجريبي

العرض التوضيحي لـ passkey جميل دائمًا: انقر فوق Face ID، أنت في المنتج الفعلي أكثر تعقيدًا.

شخص ما يغير هاتفه. يستخدم شخص ما كمبيوتر شركة مقفلة. بعض الأشخاص لا يفهمون سبب اقتراح المتصفح لـ passkey. شخص ما يفقد الوصول إلى أجهزته.

ولهذا السبب لن أبدأ بـ "من اليوم لن يكون هناك المزيد من كلمات المرور للجميع". سأبدأ هكذا:

1. passkey اختياري للمستخدمين الداخليين؛
2. اقتراح لإنشاء واحدة بعد تسجيل الدخول الناجح؛
3. صفحة الحساب لإعادة تسمية وإزالة passkey؛
4. تراجع واضح.
5. الطرح التدريجي في تسجيل الدخول الرئيسي.

يجب أن يكون النص الموجود في الواجهة بسيطًا. يعد "استخدام شاشة قفل جهازك" أفضل من "المصادقة باستخدام بيانات اعتماد FIDO2 المقيمة".

أخطاء يجب أن أتجنبها

لا تولد تحديات على العميل. يتم إنشاء التحدي على الخادم ويجب التحقق منه مرة واحدة فقط.

لا تثق فقط بمعرف بيانات الاعتماد. تحتاج إلى التحقق من التوقيع والتحدي والأصل وRelying Party ID.

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

لا تتعامل مع passkey كزر أمامي بحت. إخفاء زر ليس أمرًا أمنيًا: فالتحقق الحقيقي يتم من جانب الخادم.

Passkey-الأول أم passkey-صديق؟

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

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

الخلاصة

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

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

المصادر

• MDN: Passkeys
• MDN: Web Authentication API
• W3C: Web Authentication
• passkeys.dev