معايير التعريف الحديثة: OAuth 2.0 و OpenID Connect و WebAuthn

السماح أو عدم السماح؟ هذا هو السؤال…

الآن في العديد من المواقع نرى فرصة للتسجيل أو تسجيل الدخول باستخدام الشبكات الاجتماعية ، وبعض المواقع تقدم استخدام مفاتيح الأمان الخارجية أو بصمات الأصابع. ما هذا؟ معايير أمنية جيدة التصميم أم تطبيقات خاصة؟ هل يمكننا الوثوق بهذه التقنيات واستخدامها لتطوير مواقع الويب وفي الحياة اليومية؟ دعنا نحصل على حق. لذا ، هناك الآن العديد من المعايير والتقنيات لتحديد مستخدمي OAuth 2.0 و OpenID Connect و WebAuthn و SAML 2.0 و Credential Management API وما إلى ذلك. في هذه المقالة سأتحدث عن البروتوكولات الثلاثة الواعدة OAuth 2.0 و OpenID Connect و WebAuthn. ومن أجل فهم كيفية وضعها موضع التنفيذ ، سنقوم بعمل ثلاثة في المختبر. سنستخدم GitHub و Google كمنصات لتحديد المستخدمين.التي يمتلك معظمها حسابات.

صورة

بروتوكول OAuth 2.0


لنبدأ بأكثر بروتوكول OAuth 2.0 شهرة. تم نشره في عام 2012 باسم RFC 6749: إطار تفويض OAuth 2.0 .

باستخدام OAuth 2.0 ، يسمح المستخدم لموقع معين بتلقي بياناته الخاصة من الشبكات الاجتماعية ، ولكن دون نقل تسجيلات الدخول / كلمات المرور إلى الموقع. على سبيل المثال ، عندما تقوم بالتسجيل في موقع عبر Facebook ، فأنت تمنح هذا الموقع إذنًا للحصول على اسمك وعنوان بريدك الإلكتروني وبياناتك الخاصة الأخرى من Facebook.

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

صورة

يحدد المعيار الأدوار التالية:

  • Resource Owner — , MySite .
  • Client ( MySite) — , Authorization Server Resource Server .
  • Authorization Server — / , .
  • Resource Server — , API. Authorization Server Resource Server .

Authorization flow


  • MySite :
  • MySite Name ( ), Homepage ( MySite) Callback (, )
  • تقدم الشبكة الاجتماعية معرف العميل (يسمى أحيانًا AppID) وسر العميل.
  • يجب تسجيل معرف المطور في معرف العميل وسر العميل.

الآن العملية نفسها. قد تختلف تفاصيل عمليات التنفيذ المحددة ، ولكن المنطق العام سيكون دائمًا على النحو التالي:

صورة

  1. يقوم مالك المورد بتسجيل الدخول إلى العميل (MySite) ، ويحدد خيار "تسجيل الدخول باستخدام الشبكة الاجتماعية" ، ويقوم الموقع بإعادة توجيه المستخدم إلى الشبكة الاجتماعية على خادم التخويل.
  2. يتحقق خادم التفويض مما إذا كان المستخدم لديه جلسة نشطة أم لا ، ثم يعرض نموذج تسجيل الدخول.
  3. يقوم مالك المورد بإدخال اسم المستخدم / كلمة المرور الخاصة به ويؤكد أنه يمكن استخدام بعض البيانات الخاصة بواسطة MySite ، مثل اسم المستخدم أو عنوان البريد الإلكتروني.
  4. يتحقق خادم التفويض من المستخدم ويعيد التوجيه إلى عنوان الاستدعاء مع نتيجة المصادقة و "رمز التفويض"
  5. Client “Authorization Code”, Client ID Client Secret.
  6. Authorization Server “access token” JWT (JSON Web Token), . JWT “refresh token”, c .
  7. Client API, “access token”.
  8. Resource Server “access token” (, Authorization Server) .

OAuth 2.0 (GitHub)


هناك العديد من الإرشادات حول كيفية تنفيذ تفويض OAuth 2.0 باستخدام الشبكات الاجتماعية. أنا شخصياً أحببت المقالة التالية: المصادقة باستخدام GitHub OAuth 2.0 مع NodeJS وهي توضح الخطوات وتقدم برنامج اختبار. ولكن ، من أجل فهم الخوارزمية حقًا ، من الأفضل اتباع جميع الخطوات بيديك (طلبات http من المتصفح أو مكالمات التجعيد). اذهب.

للبدء ، قم بتسجيل طلبك على GitHub: github.com/settings/applications/new

قم بتعيين المعلمات:


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

احصل من GitHub:

  • الرقم التعريفي للعميل: ab8ec08a620c2
  • سر العميل: e6fdd52b0a99e8fbe76b05c1b7bb93c1e

بالطبع ، في جميع الأعمال المعملية ، كل القيم مزيفة.

هذه هي الطريقة التي يبدو بها الحصول على معرف العميل والسرية على موقع GitHub:

صورة

الآن نبدأ التفويض. نعتقد أن الخطوة 1 قد اكتملت بالفعل: قام المستخدم بتسجيل الدخول إلى MySite وحدد "تسجيل الدخول باستخدام GitHub". الخطوة 2 من تدفق المكالمات هي مكالمة بتنسيق REST:

https://github.com/login/oauth/authorize?client_id=ab8ec08a620c2


  • العنوان هو نقطة تسجيل الدخول على جيثب
  • client_id هو معرّف العميل الذي تم إصداره أثناء التسجيل

نتيجة لهذه المكالمة ، يعرض GitHub نافذة للتفويض:

صورة

الخطوة 3: أدخل كلمة المرور / تسجيل الدخول للوصول إلى GitHub

الخطوة 4: يعيد GitHub توجيه الطلب إلى الصفحة الرئيسية ، في هذا الطلب نرى الرمز:

http://MySite/home?code=a29b348f63d21

لا يوجد موقع يعمل على هذا العنوان ، ولكن الشيء الرئيسي بالنسبة لنا هو معرفة الرمز المرسل لتشكيل الخطوة التالية 5:

https://github.com/login/oauth/access_token?client_id=ab8ec08a620c2&
client_secret=e6fdd52b0a99e8fbe76b05c1b7bb93c1e&
code=a29b348f63d21

  • العنوان هو نقطة استقبال رمز الدخول على جيثب
  • client_id هو معرّف العميل الذي تم إصداره أثناء التسجيل
  • client_secret هو سر عميل يتم إصداره أثناء التسجيل
  • الكود هو الكود الذي تم إرساله للتو

الخطوة 6: استجابة رمز الوصول المستلم:

access_token=31b71cbd372acdbb20ec1644b824f3dd0&scope=&token_type=bearer

الخطوة 7: أدخل access_token في رأس الطلب واتصل بـ GitHub API:

curl -H "Authorization: token 31b71cbd372acdbb20ec1644b824f3dd0" https://api.github.com/user

الخطوة 8: ردًا على ذلك ، نحصل على JSON بمعلومات مفيدة عني يمكنك استخدامها لإنشاء ملف شخصي على MySite:

{
  "login": "AlexeySushkov",
  "html_url": "https://github.com/AlexeySushkov",
  "repos_url": "https://api.github.com/users/AlexeySushkov/repos",
  "name": "Alexey Sushkov",
  "blog": "http://sushkov.ru",
  "location": "St.Petersburg, Russia",
  "email": "alexey.p.sushkov@gmail.com",
 ..
}  

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

تواصل Openid


مع OAuth 2.0 ، فهمت قليلاً. دعنا الآن نكتشف سبب حاجتنا إلى OpenID Connect ، وهو إضافة لـ OAuth 2.0:

  • C OAuth 2.0 .. access token, . access token MySite. OpenID Connect — (identity). .
  • OpenID Connect “service discovery”. SSO (Single Sign-On), .

دعونا نلقي نظرة على المعيار من الناحية التقنية.

OpenID Connect (OIDC) هو معيار OpenID مفتوح تم تطويره بواسطة اتحاد OpenID Foundation . يقوم OIDC بتوسيع OAuth 2.0 بالميزات الرئيسية التالية:

  • يقوم خادم المصادقة ، بالإضافة إلى رمز الوصول ورمز التحديث ، بإرجاع "رمز الهوية" (رمز مميز). وهي واردة في نفس JWT. يمكن استخراج المعلومات التالية من ID Token: اسم المستخدم ووقت تسجيل الدخول وتاريخ انتهاء صلاحية ID ID. يمكن نقل معرفات الرمز المميز بين المشاركين.
  • يوفر OIDC واجهة برمجة تطبيقات إضافية تسمح لك بطلب معلومات حول المستخدم وجلساته الحالية.

يبدو مخطط التفاعل في OpenID Connect كما هو الحال مع OAuth. الاختلاف الوحيد في محتوى الطلبات:

  • في الطلب الأولي للرمز ، تتم إضافة سمة إضافية ، نطاق = openid.
  • نتيجة للخوارزمية ، يتلقى العميل ، بالإضافة إلى الوصول وتحديث الرمز المميز ، معرف الرمز المميز.

OpenID Connect: Lab (جوجل)


الآن دعنا نرى ما ستسعدنا به Google في هذا الموضوع. هناك تعليمات تفصيلية لتكوين واستخدام OpenID Connect من Google و sandbox لاستخدام Google API: Google OAuth 2.0 Playground .

هنا ، كما هو الحال في OAuth 2.0 ، سنراجع الخطوات ونلقي نظرة على البيانات الواردة. وبالمثل ، نعتقد أنه تم تسجيل التطبيق ، وتم استلام معرف العميل وسر العميل ، وتم تمرير الخطوة 1. الخطوة 2 من تدفق المكالمات هي مكالمة بتنسيق REST:

https://accounts.google.com/o/oauth2/v2/auth?
response_type=code&
client_id=140797064495-b8b79j42m97nkkrlndfstikv8.apps.googleusercontent.com&
scope=openid%20email&
redirect_uri=http%3A//c18529.shared.hc.ru/wp-login.php&
state=765439764

جوجل أكثر تعقيدا ، لأن يولون المزيد من الاهتمام للسلامة:

  • العنوان هو نقطة تسجيل الدخول على Google
  • response_type = كود - توقع استلام كود في الرد
  • client_id - معرف العميل الصادر أثناء التسجيل
  • نطاق = بريد إلكتروني مفتوح - ما هي البيانات التي نريد الوصول إليها
  • redirect_uri - تم تحديد redirect_uri أثناء تسجيل التطبيق
  • الحالة - الرقم الذي يتم إنشاؤه بواسطة العميل ، والذي يتم إرساله بين العميل و AS للحماية من تداخل الدخيل.

الخطوة 3: لا يوجد نموذج إدخال كلمة مرور ، مثل لقد قمت بالفعل بتسجيل الدخول إلى Google.

الخطوة 4: يعيد Google توجيه الطلب إلى الصفحة الرئيسية ، في هذا الطلب نرى الرمز:

http://MySite?state=123&code=4/xAFkcMzhyJhUErRJYwIyntSYN-WeJjfZHLiwWL4IaT-WkHzMU18xABlPmev-M_87wVbqTkQ1y93w6GB5&scope=email+openid+https://www.googleapis.com/auth/userinfo.email&authuser=0&prompt=none

كما هو الحال في GitHub ، لا يوجد موقع ويب يعمل على هذا العنوان ، ولكن هذا ليس ضروريًا ، الشيء الرئيسي بالنسبة لنا هو معرفة الرمز من أجل تشكيل الخطوة التالية 5. وهذا أيضًا أكثر تعقيدًا بعض الشيء ، لأن تتطلب Google طلب POST ، وليس GET:

curl -d "code=4/xAFkcMzhyJhUErRJYwIyntSYN-WeJjfZHLiwWL4IaT-WkHzMU18xABlPmev-M_87wVbqTkQ1y93w6GB5&client_id=140797064495-b8b79j42m97nkkrlndfstikv8.apps.googleusercontent.com&
client_secret=HMVctrTicW6RC1Q8T&
redirect_uri=http%3A//c18529.shared.hc.ru/wp-login.php&
grant_type=authorization_code" 
-H "Content-Type: application/x-www-form-urlencoded" -X POST https://oauth2.googleapis.com/token

  • العنوان هو نقطة استلام الرمز المميز على Google
  • الكود هو الكود الذي تم إرساله للتو
  • client_id هو معرّف العميل الذي تم إصداره أثناء التسجيل
  • client_secret هو سر عميل يتم إصداره أثناء التسجيل
  • Grant_type = Authorization_code - القيمة الصالحة الوحيدة من المعيار

الخطوة 6: في الرد الذي تم تلقيه access_token و id_token:

{
  "access_token": "ya29.Il_AB0KeKnjBJx0dhjm2nCLt1B-Mq0aQBW5T302JnlZfsxW1AXqLFfDJZRMi2R2WKG4OX4msKLjx4E4CSl4G_4ajAy3aqrf4pM0ic0jJr092pA67H9aktJktCbx",
  "expires_in": 3327,
  "scope": "openid https://www.googleapis.com/auth/userinfo.email",
  "token_type": "Bearer",
  "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjE3ZDU1ZmY0ZTEwOTkxZDZiMGVmZDM5MmI5MWEzM2U1
………………………………_…………………………………………………….._4mUTiMNSAHljap1hLD2hAzgOZWuQ"
}

ماذا تفعل الآن بهذه الثروة؟

الخطوة 7: مع access_token كل شيء واضح: نحن ندرجه في مكالمة API ، على سبيل المثال GMail:

curl -H "Authorization: Bearer ya29.a0Adw1xeWvFoxHKNICHnV6vFFj5TZdPQVlYD98h8wjW95ZEbHVui_pk7HGRoq3Q7MlVLV23xkVM0yyjSP8ClSlvfUy3b_IqvKQW5Lvwj38QzJhee-aH1grerB4pRpMzn_FGueigG_RGI56pKPgFBTr49cpynQy" https://www.googleapis.com/gmail/v1/users/alexey.p.sushkov@gmail.com/profile

الخطوة 8: ردًا على ذلك ، نحصل على JSON بمعلومات مفيدة:

{
 "emailAddress": "alexey.p.sushkov@gmail.com",
 "messagesTotal": 372543,
...
}

الآن دعونا نتحقق من العبارة التي تحتوي على id_token يحتوي على معلومات لمصادقة المستخدم والحفاظ على الجلسة. للقيام بذلك ، تحتاج إلى فك تشفير المحتويات. أسهل طريقة للقيام بذلك هي الاتصال بـ Google API على
oauth2.googleapis.com/tokeninfo وتحديد id_token المستلم كمعلمة:

https://oauth2.googleapis.com/tokeninfo?id_token=eyJhbGciOiJSUzI1NiIsImtpZCI6IjE3ZDU1ZmY0ZTEwOTkxZDZiMGVmZDM5MmI5MWEzM2U1NGMwZTIxOGIiLCJ0eXAiOi
………………………_……………………………...
SVQ5GQni3irfOzOXYEiqijp6TjGa_a-3jKcEsU5TbasZmAIejsdVcNy2_4mUTiMNSAHljap1hLD2hAzgOZWuQ

حصلت على JSON:
{
  "iss": "https://accounts.google.com",
  "email": "alexey.p.sushkov@gmail.com",
  "email_verified": "true",
  "iat": "1583257010",
  "exp": "1583260610",
  "typ": "JWT"
...
}

نرى أن id_token يحتوي على معلومات حول تسجيل دخول المستخدم ووقت الاستلام وعمر الرمز المميز. يمكننا أن نستنتج أن OpenID Connect من Google يعمل ، ويمكن استخدامه للسيناريوهات ذات الصلة.

Webauthn


واجهة برمجة تطبيقات مصادقة الويب (تُعرف أيضًا باسم WebAuthn):

  • يسمح المعيار للمستخدمين بتعريف أنفسهم على مواقع الويب والتطبيقات التي تستخدم مفاتيح الأمان الخارجية (على سبيل المثال ، مفاتيح USB) أو عن طريق بصمة الإصبع ، وبالتالي عن طريق البيانات البيومترية الأخرى: الوجه والشبكية.
  • — / «Public key cryptography». Public key cryptography — , . Private key ( ) , public key ( ) .
  • W3C (World Wide Web Consortium) FIDO, Google, Mozilla, Microsoft, Yubico. W3C HTTP, HTML, XML . WebAuthn. WebAuthn : Chrome, Firefox, Edge, Safari.


مقارنة بـ OAuth 2.0 ، تتم إضافة الأدوار التالية إلى WebAuthn:

Authenticator : مفتاح أمان خارجي (وسائط فعلية أو ماسح ضوئي لبصمات الأصابع) يسمح لك بمصادقة مستخدم باستخدام تقنيات مختلفة ، مثل BlueTooth / NFC / USB. يعمل من أجل:

  • توليد أوراق اعتماد المفتاح العام (أزواج المفاتيح العامة / الخاصة).
  • يقوم Authenticator بتخزين المفتاح الخاص بشكل آمن في ذاكرته
  • تمرير المفتاح العمومي إلى الأنظمة الخارجية
  • يوقع البيانات بمفتاح خاص وينقل النتيجة إلى أنظمة خارجية

يستخدم أداة المصادقة بروتوكول CTAP (بروتوكولات عميل المصادقة) للتفاعل مع المستعرض.

جهة الاعتماد : تؤدي نفس الوظيفة التي يؤديها "خادم المصادقة" في OAuth 2.0 ، أي التحقق من هوية المستخدم. فقط في OAuth 2.0 كان اسم المستخدم / كلمة المرور ، وفي WenAuthn كان هو بيانات اعتماد المفتاح العام.

وكيل المستخدم : يدمج المتصفح وتطبيق الشبكة ، ويخدم نفس أغراض العميل في OAuth 2.0 ، أي من ناحية ، يتفاعل مع المستخدم ويزوده بواجهة مستخدم رسومية ، ومن ناحية أخرى ، يتفاعل مع الأنظمة التي تخزن بيانات اعتماد المستخدم .

تدفق التفويض


قبل بدء عملية المصادقة ، تمامًا كما هو الحال في OAuth 2.0 ، تحتاج إلى تنفيذ خطوات تحضيرية ، فقط في OAuth 2.0 قمنا بتسجيل التطبيق ، وفي WebAuth 2.0 نسجل المستخدم. تحدد واجهة برمجة تطبيقات مصادقة الويب مكالمتين:

  • ؛ navigator.credentials.create - لإنشاء بيانات اعتماد المستخدم
  • navigator.credentials.get - للتحقق من بيانات اعتماد المستخدم

وفقًا لذلك ، للتسجيل ، يجب عليك الاتصال بـ navigator.credentials.create.

ونتيجة لذلك ، سيُخزِّن مُصدق المستخدم المفتاح الخاص لموقع معين ، وسيتم تخزين المفتاح العام في Relying Party.

صورة

بعد ذلك ، ستكون عملية المصادقة على النحو التالي:

صورة

  1. “WebAuthn”. , , WebAuthn, “ ” “ ”. Relying Party Challenge. Challenge — , Code OAuth 2.0.
  2. Relying Party Challenge. , REST API.
  3. Authenticator- CTAP (Client to Authenticator Protocols). navigator.credentials.get c :

    • Challenge
  4. Authenticator , , .
  5. , Authenticator .
  6. يرسل التطبيق البيانات الموقعة إلى Relying Party.
  7. يقوم Relying Party بفك تشفير البيانات باستخدام المفتاح العام ، والتحقق من التحدي وتفويض المستخدم.

لإصلاح المواد نقوم بعمل المختبر:

WebAuthn: مختبر (جوجل)


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

نتيجة لهذا العمل ، نحصل على تطبيق JS client-server الذي يطبق مصادقة بصمة الإصبع. يقع عرض العمل في .

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

صورة

إنشاء اسم مستخدم / كلمة مرور ثم إرفاق بصمة الإصبع:

صورة

بعد ذلك ، يعرض البرنامج أي مفتاح عام مرتبط ببصمة الإصبع هذه:

صورة

الآن يمكنك بدء البرنامج النصي للمصادقة. كالعادة ، نعتقد أن الخطوة 1 قد اكتملت ونحن في الموقع. للانتقال إلى الخطوة 2 ، انقر فوق "جرب Reauth". سيقوم المتصفح بإجراء الخطوة 3 وسيتفاعل مع أداة المصادقة ، التي ستطلب منك في الخطوة 4 وضع إصبعك:

صورة

وإذا تم إرفاق الإصبع المسجل ، فستمر الخطوتان 5 و 6 بنجاح ، وفي الخطوة 7 سيعرض التطبيق مرة أخرى النافذة باستخدام المفتاح العام المقابل:

صورة

استنتاج


لذا ، فحصنا البروتوكولات الثلاثة الأكثر شيوعًا والواعدة للتعرف على المستخدم: OAuth 2.0 و OpenID Connect و WebAuthn. لقد فهمنا نطاق انطباقها:

  • OAuth 2.0 - يُستخدم لتسجيل المستخدمين وتسجيل دخولهم إلى المواقع التي تستخدم الشبكات الاجتماعية. وأيضًا للحصول على بيانات المستخدم من الشبكات الاجتماعية.
  • OpenID Connect — . OpenID Connect SSO .
  • WebAuthn — .


  • , , .
  • , , .
  • من المنطقي مصادقة المستخدمين على الأنظمة الأساسية السحابية مثل Facebook أو Google ، مثل يوظفون أفضل خبراء الأمن الذين يمكنهم توفير جميع الفروق الدقيقة في الأمن.
  • أقترح متفائلة بشأن المستقبل ، لأنه بروتوكول WebAuthn - فرصة حقيقية للتخلص من جحيم كلمة المرور في عصرنا!

إنها البداية فقط!

ملحق: بروتوكولات المصادقة الأخرى


من أجل الاكتمال ، سأذكر البروتوكولات والتقنيات الأخرى ذات الصلة المستخدمة لتحديد المستخدمين:

SAML 2.0 (لغة ترميز تأكيد الأمان)


بروتوكول ناضجة لعام 2005 ، ولكن لديه مجموعة محدودة من السيناريوهات لبناء أنظمة SSO. يستخدم تنسيق بيانات قائم على XML. يمكن العثور على مزيد من التفاصيل في المقالة: "من يستخدم بروتوكول مصادقة SAML 2.0"

واجهة برمجة تطبيقات إدارة بيانات الاعتماد


يتم تنفيذ التطوير من قبل نفس المنظمة مثل WebAuthn - W3C. يسمح لك معيار إدارة الاعتماد بما يلي:

  • قم بتخزين هوية المشتركين ، مما يسمح للمستخدمين بالوصول إلى المواقع دون إدخال كلمات المرور ، ولكن استخدام كلمات المرور من المتجر.
  • حدد الحسابات اللازمة لإدخال مواقع معينة.
  • يسمح لك باستخدام تسجيلات الدخول / كلمات المرور التي تم إدخالها على جهاز واحد على أجهزة أخرى.

من أمثلة التنفيذ الشائعة لواجهة برمجة تطبيقات إدارة بيانات الاعتماد هو مدير كلمات مرور Google: passwords.google.com

مبادرة المصادقة المفتوحة (OATH)


موارد اليمين

قائمة كاملة بالبروتوكولات المستندة إلى بروتوكول OAuth 2.0



All Articles