توقف عن بناء مصادقة كلمة المرور بشكل افتراضي_

تقلل معظم الفرق من أهمية مفهوم "امتلاك المصادقة".

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

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

المشكلة ليست في التشفير

تشفير كلمات المرور أمر ضروري. لكنه ليس المشكلة بأكملها.

نظام المصادقة الجاد يحتاج أيضًا إلى:

• عملية استعادة آمنة
• مقاومة لملء بيانات الاعتماد
• حماية ضد الاحتيال وتثبيت الجلسات
• إمكانية التدقيق حول أحداث تسجيل الدخول
• دعم لتسجيل الدخول متعدد العوامل أو المفاتيح
• عمليات تشغيلية للدعم والاسترداد

غالبًا ما تقوم الفرق بتنفيذ الـ 20% الأولى وتتحمل المسؤولية عن الـ 80% الأخرى دون أن تلاحظ.

ماذا يمنحك OIDC في الواقع

يضيف OpenID Connect طبقة هوية فوق OAuth 2.0. في الممارسة العملية، يسمح لتطبيقك بالاعتماد على مزود هوية مثل Google وMicrosoft Entra ID وOkta وAuth0 وWorkOS أو Clerk لمصادقة المستخدم وإصدار رموز موحدة.

هذا يغير تطبيقك من:

• جمع كلمات المرور مباشرة
• التحقق من بيانات الاعتماد
• تشغيل عمليات الاسترداد

إلى:

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

هذا مكان أفضل بكثير لمعظم فرق SaaS.

التدفق الذي ترغب فيه عادةً

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

على مستوى عالٍ:

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

التفصيل الهام هو أن منتجك لا يحتاج إلى التعامل مع كلمة المرور مباشرةً.

ما زلت بحاجة إلى التنفيذ

تفويض المصادقة لا يلغي كل المسؤولية. بل يضيقها.

لا يزال عليك أن:

• تحقق من المصدر، والجمهور، والانتهاء، والتوقيع بشكل صحيح
• استخدم state و nonce حيثما كان ذلك مطلوبًا
• إنشاء وتدوير جلستك الخاصة بشكل آمن
• فصل المصادقة عن التفويض
• نمذجة المستخدمين في قاعدة بياناتك بمعرفات ثابتة

خطأ شائع هو تخزين عنوان البريد الإلكتروني فقط كهوية. ذلك ليس مستقرًا بما يكفي بمفرده. في أنظمة OIDC، يكون المعرف الدائم عادةً هو المزود بالإضافة إلى مطلب sub.

type Identity = {
  provider: "google" | "microsoft" | "okta";
  subject: string;
  email: string;
  emailVerified: boolean;
};

function getIdentityKey(identity: Identity) {
  return `${identity.provider}:${identity.subject}`;
}

هذا يتجنب الأخطاء الدقيقة في ربط الحسابات لاحقًا.

نموذج ذهني أفضل

لا تفكر في OIDC على أنه "تسجيل الدخول الاجتماعي".

فكر فيه على أنه نقل قدرة عالية المخاطر إلى برامج تم بناؤها وتدقيقها وتجهيزها خصيصًا للهويات.

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

متى يكون بناءه بنفسك منطقيًا

هناك حالات يكون فيها امتلاك المصادقة مبررًا:

• أنت تبني منتج هوية
• لديك قيود تنظيمية صارمة تستبعد المزودين الخارجيين
• تحتاج إلى نماذج مصادقة غير متصلة أو معزولة
• لديك نضج أمني داخلي للتعامل معها بشكل صحيح

توجد هذه الحالات. لكنها أقل شيوعًا مما يرغب المهندسون في التفكير فيه.

بالنسبة لمنتج SaaS نموذجي، السؤال الحقيقي ليس "هل يمكننا بناء المصادقة بأنفسنا؟" بل هو "لماذا نختار أن نمتلك هذه المسؤولية؟"

قراءة إضافية

• OpenID Connect Core 1.0
• OpenID Connect Discovery 1.0
• RFC 7636: Proof Key for Code Exchange by OAuth Public Clients