IdentityServer4. مفاهيم أساسية. OpenID Connect و OAuth 2.0 و JWT

مع هذا المنشور أريد فتح سلسلة من المقالات المخصصة لـ IdentityServer4. لنبدأ بالمفاهيم الأساسية.

بروتوكول المصادقة الواعد في الوقت الحالي هو OpenID الاتصال، وبروتوكول التفويض (توفير الوصول) هو بروتوكول OAuth 2.0. خادم الهوية4 ينفذ هذين البروتوكولين. هو الأمثل لحلها مشاكل نموذجية الأمن.

OpenID الاتصال هو بروتوكول مصادقة ومعيار، ولا يوفر الوصول إلى الموارد (Web API)، ولكن منذ ذلك الحين تم تصميمه على رأس بروتوكول التفويض بروتوكول OAuth 2.0، فهو يسمح لك بالحصول على معلمات ملف تعريف المستخدم كما لو كان لديك حق الوصول إلى المورد معلومات المستخدم.

JWT (JSON Web Token) هو معيار ويب يحدد طريقة لنقل بيانات المستخدم بتنسيق JSON في نموذج مشفر.

أوث 2.0 (RFC 6749) هو بروتوكول ترخيص ومعيار. فهو يسمح للتطبيقات بالوصول إلى الموارد المحمية، مثل Web APIs.

دعونا نلقي نظرة على الرسم البياني للوصول إلى مورد محمي وفهم الخطوات الرئيسية والمصطلحات المقبولة:

1. يطلب العميل الإذن من المستخدم للمصادقة نيابة عنه. زبون هو تطبيق عميل يصل إلى الموارد المحمية نيابة عن مالك المورد. مورد - هذه جميع خدماتنا المحمية واجهة برمجة تطبيقات الويب.

2. يسمح المستخدم لتطبيق العميل بالمصادقة نيابة عنه، على سبيل المثال، عن طريق إدخال معلومات تسجيل الدخول وكلمة المرور. سيكون تسجيل الدخول وكلمة المرور بمثابة منحة ترخيص لتطبيق العميل. المستخدم (مالك المورد) — برنامج أو شخص يمكنه منح الوصول إلى الموارد المحمية، على سبيل المثال، عن طريق إدخال معلومات تسجيل الدخول (اسم المستخدم) وكلمة المرور (كلمة المرور)؛

3. يطلب تطبيق العميل رمز وصول من IdentityServer4 من خلال تقديم معلومات عن نفسك (client_id, client_secret)، منح إذن التفويض من المستخدم (username, password) وتقديم grant_type и scope. ثم يتحقق خادم الترخيص من صحة العميل وتفاصيل مالك المورد (تسجيل الدخول وكلمة المرور).

   لا يقوم بروتوكول OAuth 2.0 بمصادقة المستخدم فحسب، بل يقوم أيضًا بتطبيق العميل الذي يصل إلى الموارد. ولهذا الغرض، يوفر البروتوكول معلمات مثل CLIENT_ID и client_secret.
   معرف العميل هو معرف تطبيق العميل المستخدم IdentityServer4 للبحث عن معلومات حول العميل.
   client_secret يشبه كلمة المرور لتطبيق العميل ويستخدم لمصادقة تطبيق العميل عليه IdentityServer4. يجب أن يكون سر العميل معروفًا فقط للتطبيق وواجهة برمجة التطبيقات (API).. وبناء على ما سبق نستنتج ذلك يحتاج IdentityServer4 إلى معرفة عملائه.

4. إذا تمت مصادقة التطبيق وكان إذن التفويض صالحًا، IdentiryServer4 يخلق access-токен (رمز الوصول) للتطبيق ومفتاح التحديث الاختياري (refresh-токен). اكتملت عملية الترخيص. إذا كان الطلب غير صالح أو غير مصرح به، فسيقوم خادم التفويض بإرجاع رمز مع رسالة خطأ مناسبة.

5. يصل تطبيق العميل إلى واجهة برمجة تطبيقات الويب الآمنة للبيانات، مما يوفر رمز وصول للترخيص. إذا كان رمز استجابة خادم الموارد 401, 403 أو 498، فإن رمز الوصول المستخدم للمصادقة غير صالح أو منتهي الصلاحية.

6. إذا كان الرمز صالحًا، Web API يوفر البيانات للتطبيق.

أنواع التوكنات

مسجل في IdentityServer4 يُسمح للعملاء بالطلب IdentityServer4 identity-رمز مميز، access-رمز و refresh-رمز مميز.

• رمز الهوية — نتيجة عملية المصادقة. يحتوي على معرف المستخدم ومعلومات حول كيفية ووقت مصادقة المستخدم. يمكنك توسيعه باستخدام بياناتك الخاصة.
• رمز وصول - يتم إرساله إلى واجهة برمجة التطبيقات المحمية ويستخدمه للسماح (السماح بالوصول) إلى بياناته.
• رمز التحديث (رمز التحديث) هي معلمة اختيارية يمكن لخادم التفويض إرجاعها استجابةً لطلب رمز الوصول.

دعونا نقدم مفهومين آخرين:

عنوان URL لخادم المصادقة - نقطة النهاية للحصول على مفتاح الوصول. سنقوم بتوجيه جميع طلبات توفير وتجديد مفاتيح الوصول إلى عنوان URL هذا.

عنوان URL للمورد - عنوان URL للمورد المحمي الذي يجب الاتصال به للوصول إليه، وتمرير مفتاح الوصول إليه في رأس التفويض.

طلب مفتاح الوصول

لطلب مفتاح الوصول، يفعل العميل ذلك POST طلب إلى نقطة النهاية IdentityServer4 مع العنوان التالي

'Content-Type': 'application/x-www-form-urlencoded',
'Accept': 'application/json',
'Expect': '100-continue'

وتمرير المعلمات التالية:

'grant_type' : 'password',
'username' : login,
'password' : password,
'scope' : 'scope',
'client_id' : 'client_id',
'client_secret' : '{client_secret}'

username, password, client_id и client_secret تمت مناقشتها أعلاه. دعونا نلقي نظرة على المعلمات المتبقية:

نوع_المنحة - نوع المنحة أو نوع التفويض. يعتمد نوع إذن التفويض على طريقة طلب التفويض التي يستخدمها التطبيق، بالإضافة إلى أنواع الأذونات التي تدعمها واجهة برمجة التطبيقات. في حالتنا سيكون الأمر مهما password، وهو حسب المواصفات OAuth 2.0 يتوافق مع منح تفاصيل الوصول لمالك المورد (التفويض عن طريق تسجيل الدخول وكلمة المرور).

بروتوكول OAuth 2.0 يحدد الأنواع التالية من المنح المطلوبة التفاعل الإلزامي مع المستخدمين:

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

وأنواع المنح التي يمكن تنفيذها دون تدخل المستخدم:

• تفاصيل مالك الموارد. يجب استخدام هذا النوع من الأذونات فقط إذا كان المستخدم يثق في تطبيق العميل وكان المستخدم مرتاحًا لإدخال معلومات تسجيل الدخول وكلمة المرور الخاصة به. يجب استخدام نوع الإذن هذا فقط في حالة عدم توفر خيارات أخرى. يعد هذا النوع من الأذونات مناسبًا لعملاء الشركات الذين استخدموا بالفعل بيانات اعتماد المستخدم داخل نظامهم ويريدون التبديل إليه OAuth 2.0.
• بيانات اعتماد العميل. يُستخدم عندما يصل التطبيق إلى واجهة برمجة التطبيقات (API). يمكن أن يكون هذا مفيدًا، على سبيل المثال، عندما يريد أحد التطبيقات تحديث معلومات تسجيل الخدمة الخاصة به أو إعادة توجيه URI، أو الوصول إلى المعلومات الأخرى المخزنة في حساب خدمة التطبيق من خلال واجهة برمجة تطبيقات الخدمة.

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

المصدر: www.habr.com