ما هو التصديق في WebAuthn؟

التصديق يمكن أن يشير إلى ثلاثة أشياء (غالبًا ما تُستخدم بشكل متبادل في اللغة المحكية على الرغم من أنها تعني شيئًا مختلفًا إذا تم أخذها بدقة):

1. أولاً وبشكل أعم، التصديق في مجال التشفير هو مصطلح حيث يقوم طرف ما "بالتصديق" بشكل مشفر على بيان لطرف آخر.

2. ثانيًا، خلال مرحلة التسجيل في WebAuthn، يتم إنشاء كائن تصديق بواسطة المُصادِق وإعادته إلى الطرف المعتمد. وهو كائن حاوٍ يحتوي على المعلومات التالية:

   • تنسيق بيان التصديق (fmt)
   • بيان التصديق (attStmt - انظر أدناه)
   • بيانات المُصادِق (authData)

Become part of our Passkeys Community for updates & support.

Join

3. ثالثًا، في WebAuthn، يعد بيان التصديق عنصرًا اختياريًا في كائن التصديق. هذا البيان، عند تضمينه، يتحقق من خصائص معينة لـالمُصادِق (الجهاز) المشارك في عملية التصديق. ومع ذلك، لا يقدم بعض مصنعي الأجهزة (مثل Apple) بيان تصديق لأن هذا الجانب من المواصفات لم يكن مخصصًا لمزامنة مفاتيح المرور ويفشل في التحقق بفعالية من سمات الأمان عندما يمكن مزامنة بيانات الاعتماد عبر أجهزة مختلفة (على سبيل المثال، يتم إنشاء مفتاح مرور على iPhone ولكنه يُستخدم أيضًا على MacBook لأنه تتم مزامنته عبر نفس سلسلة مفاتيح iCloud). الخصائص التي يمكن تقديمها عند توفير بيان التصديق:
   • تقديم دليل على استخدام جهاز أصلي وموثوق به أثناء المصادقة.
   • توفير تفاصيل حول أصل الجهاز وطرازه ومعلومات أخرى ذات صلة.
   • تعزيز التدابير الأمنية، خاصة في السيناريوهات التي تكون فيها موثوقية الجهاز حاسمة (مثل بعض الصناعات المنظمة مثل الرعاية الصحية).

يوضح تدفق عملية التسجيل التالي دور التصديق (الكائن) في WebAuthn:

{
    "root": {
        "id": "QFPlQVypLmmx71e0tmS3IfCFky0",
        "rawId": "QFPlQVypLmmx71e0tmS3IfCFky0",
        "response": {
            "attestationObject": {
                "fmt": "none",
                "attStmt": {},
                "authData": {
                    "rpIdHash": "t8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADc",
                    "flags": {
                        "userPresent": true,
                        "userVerified": true,
                        "backupEligible": true,
                        "backupStatus": true,
                        "attestedData": true,
                        "extensionData": false
                    },
                    "counter": 0,
                    "aaguid": "00000000-0000-0000-0000-000000000000",
                    "credentialID": "QFPlQVypLmmx71eOtmS3IfCFky0",
                    "credentialPublicKey": "pQECAyYgASFYIEa-lpSiQ4P...",
                    "parsedCredentialPublicKey": {
                        "keyType": "EC2 (2)",
                        "algorithm": "ES256 (-7)",
                        "curve": 1,
                        "x": "Rr6WlKJDg8MlbIq9mmHQzk2p2c_s7QoNKr7yMa7I8pM",
                        "y": "tAELYp7h3sYNjZZIZgHPYiaSzF×QVT18cgZ_7wm13Vw"
                    }
                }
            },
            "clientDataJSON": {
                "type": "webauthn.create",
                "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp",
                "origin": "https://passkeys.eu",
                "crossOrigin": false
            },
            "transports": ["hybrid", "internal"],
            "publicKeyAlgorithm": -7
        },
        "authenticatorAttachment": "cross-platform"
    }
}

في لقطة الشاشة أعلاه، لم يتم توفير AAGUID ولا بيان تصديق.

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

تابع القراءة للحصول على تحليل فني لأهم السمات.

في WebAuthn، يضمن التصديق أن مصادقة المستخدم آمنة وشفافة. باستخدام بيان التصديق، يمكنك التأكد من أن بيانات الاعتماد قد تم إنشاؤها على مُصادِق / جهاز معين.

تشير هذه الأنواع من التصديق إلى بيان التصديق (وليس كائن التصديق). وتعتبر تفضيلاً من قبل الطرف المعتمد (لذلك يمكن لـالمُصادِق أن يتصرف بشكل مختلف لأنه مجرد تفضيل).

• بدون تصديق (none): للحالات التي تكون فيها الخصوصية ذات أهمية قصوى أو عند استخدام أجهزة متزامنة، لا يقدم هذا النوع أي معلومات حول الجهاز، مما يضمن الحفاظ على خصوصية المستخدم. قد يكون سبب آخر لاستخدام هذه القيمة هو توفير رحلة ذهاب وإياب إلى هيئة إصدار الشهادات (CA). none هو أيضًا القيمة الافتراضية.
• تصديق غير مباشر (indirect): يفضل الطرف المعتمد الحصول على تصديق ولكنه يسمح للعميل بتحديد كيفية الحصول على بيانات التصديق. قد يستبدل العميل بيانات التصديق التي أنشأها المُصادِق ببيانات تصديق مجهولة لحماية خصوصية المستخدم.
• تصديق مباشر (direct): هذا هو الشكل الأكثر شفافية. هنا، يخبر الطرف المعتمد المُصادِق بأنه يريد بيان تصديق، بحيث يحصل الطرف المعتمد على معلومات مفصلة حول الجهاز، بما في ذلك علامته التجارية وطرازه وتفاصيل أخرى. على الرغم من أنه يوفر أعلى درجات الشفافية، إلا أنه قد يثير مخاوف تتعلق بالخصوصية في سيناريوهات معينة أو قد لا يكون قابلاً للاستخدام حقًا لبيانات الاعتماد المتزامنة.
• تصديق المؤسسات (enterprise): يرغب الطرف المعتمد في تلقي بيان تصديق يمكن أن يتضمن معلومات تعريف فريدة. يُستخدم هذا النوع من التصديق عادةً في الشركات أو المؤسسات التي ترغب في تتبع أجهزة / مُصادِقات معينة. يجب ألا توفر متصفحات الويب (وكلاء المستخدم) هذا التصديق المفصل ما لم تسمح إعداداتها بذلك خصيصًا للطرف الطالب. إذا سمحت الإعدادات بذلك، يجب على المتصفح إخبار الجهاز عند الحاجة (في بداية العملية) بأنه يتم طلب هذا النوع المحدد من التصديق. يجب على المتصفح بعد ذلك تمرير المعرف الفريد للجهاز وإثبات التصديق تمامًا كما يتلقاهما إلى الطرف المعتمد.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

يحتوي كائن التصديق على العديد من السمات، وفيما يلي شرح سريع لبعض السمات المختارة:

"attestationObject": {
        "fmt": "none",
        "attStmt": {},
        "authData": {
          "rpIdHash": "t8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADc",
          "flags": {
            "userPresent": true,
            "userVerified": true,
            "backupEligible": true,
            "backupStatus": true,
            "attestedData": true,
            "extensionData": false
          },
          "counter": 0,
          "aaguid": "00000000-0000-0000-0000-000000000000",
          "credentialID": "QFPlQVypLmmx71eOtmS3IfCFky0",
          "credentialPublicKey": "pQECAyYgASFYIEa-lpSiQ4P...",
          "parsedCredentialPublicKey": {
            "keyType": "EC2 (2)",
            "algorithm": "ES256 (-7)",
            "curve": 1,
            "x": "Rr6WlKJDg8MlbIq9mmHQzk2p2c_s7QoNKr7yMa7I8pM",
            "y": "tAELYp7h3sYNjZZIZgHPYiaSzF×QVT18cgZ_7wm13Vw"
          }
        }

attestationObject هو كائن مشفر بـ CBOR، يحتوي على معلومات حول بيانات الاعتماد التي تم إنشاؤها حديثًا، والمفتاح العام وبيانات أخرى ذات صلة:

• fmt يمثل تنسيق التصديق، حيث يمكن لـالمُصادِقات توفير بيانات التصديق بطرق مختلفة. يخبر الخادم كيف يجب عليه التحقق من صحة بيانات التصديق. القيم المسموح بها هي "packed"، "tpm"، "android-key"، "android-safetynet"، "fido-u2f"، "apple" أو "none". انظر التفاصيل هنا
• attStmt هو بيان التصديق. بالنسبة لمفاتيح المرور، على سبيل المثال على أجهزة iOS أو Android، يُترك فارغًا حيث يمكن مزامنة مفاتيح المرور على iOS أو Android، ويتم ملؤه للأجهزة الأخرى مثل Windows أو مفاتيح الأمان المادية.
• authData هو مخزن مؤقت للقيم يحتوي على البيانات التالية:
  
  تلعب بيانات الاعتماد المصدق عليها دورًا مهمًا هنا. وهي تحتوي على:
  • AAGUID،
  • طول معرف بيانات الاعتماد،
  • معرف بيانات الاعتماد و
  • المفتاح العام لبيانات الاعتماد.

على عكس كائن التصديق أعلاه حيث تم ترك attStmt فارغًا لأسباب تتعلق بالقراءة، هكذا سيبدو بيان التصديق المعبأ.

{
    "alg": -65535,
    "sig": "MBHX7qov53SWqqPYCrxE5fcoAeDI83a0DzVJ2-N1KI6IAaCGGvINAIFzTEn44F6giANKte-8yEMDZbvbgDG1weaRj7SqsVaTty-TEQ",
    "ver": "2.0",
    "x5c": [
        "MIIFwDCCA6oIaK6tZ7M",
        "MIIG6zCCBNpG18-MCJrHyrpMT-ul7RgxE4dFxqcG59ftTXqJ1f-X_Lpo7K-d7OgKoQrUgzxgATz8YXtFAk3rE1cHXvW9W52V637eAihKn9-UKC0ijzVXrBGX4Iq1o1M0ZfR-tFoOn498xasMCTnharKiM562GBLVJtlvV3DMSLEBl5SfuGM-qYjQgTQknXccks9guCmNaN_b2fo1DisbufXfjM3DVaMqx7IJpSc3wAnxooMrAYGpPM"
    ],
    "pubArea": "AAEACwAw_c3Ousz865mUPx8O3w",
    "certInfo": "_1RDR4AXAniCekfsiDI"
}

• alg: تشير خاصية alg إلى معرف الخوارزمية المشفرة التي يستخدمها المُصادِق لتوقيع بيان التصديق.
• sig: تحتوي خاصية sig على التوقيع الرقمي الذي أنشأه المُصادِق. يُستخدم هذا التوقيع للتحقق من أصالة بيان التصديق.
• ver: تحدد خاصية ver إصدار تنسيق بيان التصديق.
• x5c: تحتوي مصفوفة x5c على شهادة X.509 واحدة أو أكثر تشكل مسار شهادة، مما يساعد في التحقق من صحة التصديق.
• pubArea: تحتوي خاصية pubArea على معلومات مفصلة حول المفتاح العام وخصائص المُصادِق.
• certInfo: تتضمن خاصية certInfo عادةً معلومات حول شهادة المُصادِق من قبل طرف موثوق.

"clientDataJSON": {
        "type": "webauthn.create",
        "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp",
        "origin": "https://www.passkeys-debugger.io",
        "crossOrigin": false
      }

اقرأ المزيد عن clientDataJSON في مقالة القاموس الخاصة به.

"transports": [
        "hybrid",
        "internal"
      ]

تشير خاصية transports إلى الآليات التي يمكن من خلالها للمُصادِق التواصل مع العميل. بعض تركيبات القيم الشائعة والعينة هي:

• "transports": ["internal","hybrid"]: يمكن استخدام مفاتيح المرور من المُصادِق المدمج في المنصة (مثل Face ID، Touch ID، Windows Hello) أو عبر المصادقة عبر الأجهزة (باستخدام رمز الاستجابة السريعة والبلوتوث).
• "transports": ["internal"]: يمكن استخدام مفاتيح المرور من المُصادِق المدمج في المنصة (مثل Face ID، Touch ID، Windows Hello)
• لم يتم تعيين خاصية transports: السلوك الافتراضي الذي لا يعطي أي مؤشرات.

التصديق (بيان التصديق) في WebAuthn مهم لأنه يقدم دليلاً على أصالة المُصادِق. ويضمن أن عملية المصادقة تتم بواسطة جهاز موثوق به، وبالتالي الحماية من التهديدات الأمنية المحتملة.

Ben Gould

Head of Engineering

I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.

3,000+ devs trust Corbado & make the Internet safer with passkeys. Got questions? We’ve written 150+ blog posts on passkeys.

Join Passkeys Community

نعم، نظرًا لأنه يمكن مزامنة مفاتيح المرور عبر الأجهزة (على سبيل المثال، من iPhone إلى MacBook عبر Keychain)، لم يعد بإمكان الأطراف المعتمدة تحديد الجهاز المصدق عليه الذي يقوم بتسجيل الدخول فعليًا إلى تطبيق أو موقع ويب. لذلك، قررت Apple و Google أنهما لن يقدما بيانات تصديق لمفاتيح المرور المتزامنة. ومع ذلك، لتحسين تجربة المستخدم للأطراف المعتمدة ومنحهم الفرصة للتعرف على مفاتيح المرور وعرضها من نظامي Apple و Google البيئيين (سلسلة مفاتيح iCloud ومدير كلمات مرور Google)، سيظل AAGUID متوفرًا (طالما تم تعيين التصديق على direct أو indirect في إعدادات خادم WebAuthn لـ PublicKeyCredentialCreationOptions. انظر هذه المشكلة على GitHub للحصول على التفاصيل.

إذا كنت ترغب في دمج مصادقة مفتاح المرور في موقعك الإلكتروني وتطبيقك، وترغب في تقديم تجربة مستخدم رائعة لمفاتيح المرور لمستخدميك، فيجب أن تفكر في ما يلي. نفترض أنك تبني حلك بشكل أساسي لسيناريو يستخدم فيه معظم المستخدمين نظام تشغيل Windows أو iOS أو macOS أو Android. علاوة على ذلك، نفترض أن معظم مفاتيح المرور (بصرف النظر عن Windows) هي مفاتيح مرور متزامنة. نظرًا لأن أنظمة iOS و macOS و Android لم تعد ترسل بيان تصديق، لم يعد التحقق الحقيقي من المُصادِق مستخدمًا (لا يزال هذا يعمل مع Windows، ربما لأن Windows لا يقدم مفاتيح مرور متزامنة عبر Windows Hello حتى الآن). ومع ذلك، للحصول على AAGUID، على سبيل المثال لإدارة أفضل لمفاتيح المرور في إعدادات الحساب، نوصي بتعيين تفضيل التصديق على indirect، حيث سيسمح ذلك بالحصول على AAGUID بينما يتم إرسال بيان التصديق (Windows) أو عدم إرساله (iOS، macOS، Android).

توفر خدمة بيانات FIDO الوصفية مستودعًا للبيانات الوصفية لمختلف المُصادِقات. أثناء التصديق، يمكن الاستعلام عن هذه الخدمة لجلب تفاصيل حول المُصادِق والتحقق من صحتها، مما يضمن الدقة ويعزز موثوقية العملية. تتحقق خدمة بيانات FIDO الوصفية من بيان التصديق (وليس كائن التصديق).

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

يقدم WebAuthn أنواعًا مختلفة من تفضيلات التصديق - لا شيء، وغير مباشر، ومباشر، وللمؤسسات. بالنسبة للسيناريوهات التي تكون فيها خصوصية المستخدم مهمة، يمكن استخدام attestation=none، والذي لا يقدم أي تفاصيل حول الجهاز، مما يضمن حماية خصوصية المستخدم.