ما هو OAuth؟

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

"هل من الممكن السماح لتطبيق بالوصول إلى بياناتي دون الحاجة إلى إعطائه كلمة المرور الخاصة بي؟"

OAuth هو معيار يحاول حل هذه المشكلة من خلال توفير تفويض مركزي.

OAuth، الذي يعني "التفويض المفتوح"، هو معيار مفتوح لتفويض الوصول. يسمح لك (مالكو الموارد) بمشاركة المعلومات بين التطبيقات والمواقع دون الكشف عن كلمات المرور الخاصة بك. يتم استخدامه على نطاق واسع، وربما تستخدم خدمات OAuth يوميًا. على سبيل المثال، لتسجيل الدخول إلى GeeksforGeek، يمكنك اختيار تسجيل الدخول باستخدام حساب Google الخاص بك. من خلال القيام بذلك، فإنك تفوض GeeksforGeek للوصول إلى بعض المعلومات الموجودة في حساب Google الخاص بك، مثل اسم المستخدم وصورة الملف الشخصي، إلخ.

مثال تسجيل الدخول باستخدام OAuth

تاريخ OAuth

تم نشر بروتوكول OAuth 1.0 كـ RFC 5849، وهو طلب تعليقات إعلامي، في أبريل 2010.

تم نشر بروتوكول OAuth 2.0 كـ RFC 6749، وتم نشر استخدام رمز Bearer Token لـ OAuth 2.0 كـ RFC 6750، في أكتوبر 2012.

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

كيف يعمل OAuth 2.0

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

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

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

عملية التفويض في OAuth

الأدوار

يحدد OAuth أربعة أدوار:

العميل - التطبيق الذي يريد الوصول إلى بياناتك (مالك المورد) وإجراء طلبات الموارد المحمية نيابة عن مالك المورد وبموافقته.

مالك المورد - المستخدم الذي يمتلك البيانات في خادم المورد، ويريد استخدام خدمة العميل وله حساب على خادم التفويض. على سبيل المثال، أنا مالك المورد لملفي الشخصي على Facebook، وأريد استخدام خدمة GeeksforGeeks.

خادم التفويض - المحرك الرئيسي لـ OAuth. يصدر رموز الوصول إلى العميل بعد التحقق بنجاح من هوية مالك المورد والحصول على التفويض.

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

تدفق بروتوكول OAuth

تدفق بروتوكول oauth

الخطوة أ: يطلب التطبيق الخارجي التفويض من المستخدم

الخطوة ب: يتلقى التطبيق الخارجي منحة تفويض، وهي بيانات اعتماد تمثل تفويض مالك المورد

الخطوة ج: يطلب التطبيق الخارجي رمز وصول باستخدام منحة التفويض

الخطوة د: يتحقق خادم التفويض من العميل ويصادق على منحة التفويض، وإذا كانت صالحة، يصدر رمز وصول إلى التطبيق الخارجي

الخطوة هـ: يستخدم التطبيق الخارجي رمز الوصول لطلب الموارد المحمية من خادم المورد

الخطوة و: يتحقق خادم المورد من رمز الوصول ويخدم الطلب إذا كان صالحًا

رمز التفويض ورمز الوصول

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

تدفق oauth - طريقة رمز التفويض

الخطوة أ: يسمح التطبيق الخارجي للمستخدم باختيار طريقة تفويض، مثل GitHub، ثم يعيد توجيه المستخدم إلى خادم التفويض مع معلمات مثل client_id و redirect_uri

عينة طلب:

    GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
    Host: server.example.com

الخطوة ب: يسجل المستخدم دخوله ويوافق على التفويض

الخطوة ج: يعيد خادم التفويض توجيه المستخدم إلى الجزء الخلفي من التطبيق الخارجي وفقًا لـ redirect_uri، مع توفير رمز التفويض

عينة استجابة:

     HTTP/1.1 302 Found
     Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
               &state=xyz

الخطوة د: يستخدم التطبيق الخارجي رمز التفويض لاستبداله برمز الوصول من خادم التفويض

عينة طلب:

     POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

     grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
     &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

الخطوة هـ: يتحقق خادم التفويض ويعيد رمز الوصول

عينة استجابة من خادم التفويض:

     HTTP/1.1 200 OK
     Content-Type: application/json;charset=UTF-8
     Cache-Control: no-store
     Pragma: no-cache

     {
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"example",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
       "example_parameter":"example_value"
     }

مثال ملموس

يريد بوب طباعة طلباته على Amazon بشكل جميل باستخدام برنامج يسمى Rabbit.

مالك المورد -> بوب

العميل (التطبيق الخارجي) -> برنامج Rabbit

خادم التفويض -> خادم تفويض Amazon

خادم المورد -> قواعد بيانات Amazon لتخزين معلومات الطلبات

الموارد المحمية -> معلومات طلبات بوب على Amazon

مثال تدفق OAuth - طلبات Amazon

لماذا يجب الحصول على رمز التفويض ورمز الوصول بشكل منفصل؟

يتم الحصول على رمز التفويض ورمز الوصول بشكل منفصل لضمان إجراءات الأمان.

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

بمجرد تسجيل دخول المستخدم والموافقة بنجاح، يتم إعادة توجيهه إلى التطبيق مع رمز تفويض مؤقت في العنوان.

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

علاوة على ذلك، لاستبدال رمز الوصول، سيحتاج العميل إلى توفير client ID و client secret بالإضافة إلى رمز التفويض. يحتاج خادم التفويض إلى هذه المعلمات للتحقق من العميل والتأكد من أن الذي يطلب رمز الوصول موثوق به. إذا تم تسريب رمز التفويض بشكل غير محظوظ، ولكن المخترق لا يملك client ID و client secret، فلن يتمكن من الحصول على رمز الوصول. حتى إذا كان لديه client ID و client secret، سيظل بحاجة إلى التنافس مع خادم العميل، لأن رمز التفويض صالح لمرة واحدة فقط. تزيد هذه الآلية بشكل كبير من صعوبة الهجمات المحتملة. إذا تخطينا خطوة الحصول على رمز التفويض وأعدنا رمز الوصول مباشرة، فقد يستخدم المهاجم رمز الوصول لسرقة معلومات المستخدم بسهولة.

OIDC (OpenID Connect)

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

OIDC يقوم بهذا التوحيد.

كيف يقوم OIDC بذلك؟ ببساطة، يعيد JWT تنسيق id_token يحتوي على معلومات المستخدم الأساسية مع access token. يمكن للتطبيقات الخارجية الحصول على معلومات المستخدم عن طريق التحقق من خوارزمية التوقيع والتحقق من التوقيع على id_token باستخدام مفتاح عام.

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

ميزة أخرى لـ OIDC هي Single Sign On (SSO) و Single Log Out (SLO). يحسن SSO قابلية الاستخدام من خلال تمكين المستخدم من الحصول على جلسات مصادقة مع عملاء مختلفين دون الحاجة إلى تقديم بيانات الاعتماد في كل مرة. طالما أن المستخدم قد سجل دخوله بنجاح إلى تطبيق واحد، فلا داعي لإدخال كلمة المرور مرة أخرى عند تسجيل الدخول إلى التطبيقات الأخرى.

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

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

دعم APISIX لـ OAuth/OIDC

Apache APISIX هو بوابة API مفتوحة المصدر للسحابة الأصلية. إنها بوابة API ديناميكية وفعالة وعالية الأداء ويمكنك استخدامها للتعامل مع حركة المرور التقليدية من الشمال إلى الجنوب، وكذلك حركة المرور بين الخدمات من الشرق إلى الغرب. يمكن أيضًا استخدامها كوحدة تحكم دخول لـ k8s.

نظرًا لأن APISIX هو بوابة API تعمل كوسيط لعدة خوادم تطبيقات علوية، فإنه من الطبيعي وضع التفويض المركزي والمصادقة على بوابة API.

يدعم مكون OpenID Connect (OIDC) في APISIX بروتوكول OpenID Connect. يمكن للمستخدمين استخدام هذا المكون لتوصيل APISIX مع العديد من مزودي الهوية (IdP)، مثل Okta، Keycloak، Ory Hydra، Authing، إلخ، ونشره كبوابة مصادقة مركزية. OIDC هو مجموعة شاملة لـ OAuth، لذلك يدعم هذا المكون أيضًا OAuth.

رسم تخطيطي للنشر:

رسم تخطيطي لنشر apisix و oauth

نموذج التكوين: تكامل Keycloak للمصادقة مع Apache APISIX

تكوين Keycloak

المعلمة	القيمة
عنوان Keycloak	http://127.0.0.1:8080/
النطاق	myrealm
نوع العميل	OpenID Connect
معرف العميل	myclient
سر العميل	e91CKZQwhxyDqpkP0YFUJBxiXJ0ikJhq
عنوان URI لإعادة التوجيه	http://127.0.0.1:9080/anything/callback
الاكتشاف	http://127.0.0.1:8080/realms/myrealm/.well-known/openid-configuration
عنوان URI لتسجيل الخروج	/anything/logout
اسم المستخدم	myuser
كلمة المرور	myrealm
النطاق	mypassword

نموذج كود

curl -XPUT 127.0.0.1:9080/apisix/admin/routes/1 -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -d '{
    "uri":"/anything/*",
    "plugins": {
        "openid-connect": {
            "client_id": "myclient",
            "client_secret": "e91CKZQwhxyDqpkP0YFUJBxiXJ0ikJhq",
            "discovery": "http://127.0.0.1:8080/realms/myrealm/.well-known/openid-configuration",
            "scope": "openid profile",
            "bearer_only": false,
            "realm": "myrealm",
            "redirect_uri": "http://127.0.0.1:9080/anything/callback",
            "logout_path": "/anything/logout"
        }
    },
    "upstream":{
        "type":"roundrobin",
        "nodes":{
            "httpbin.org:80":1
        }
    }
}'

عند زيارة http://127.0.0.1:9080/anything/test بعد إنشاء API بنجاح، سيتم توجيهك إلى صفحة تسجيل الدخول في Keycloak لأنك لم تقم بتسجيل الدخول:

تسجيل الدخول إلى apisix keycloak

أدخل myuser كاسم مستخدم و mypassword ككلمة مرور، وسيتم توجيهك إلى الصفحة التالية.

تم التفويض في apisix keycloak

قم بزيارة http://127.0.0.1:9080/anything/logout لتسجيل الخروج:

تسجيل الخروج من apisix keycloak

ملخص

باختصار، معيار OAuth هو حل شائع لكل من التطبيقات والمستخدمين. يوفر الراحة والأمان من خلال السماح للمستخدمين باستخدام الخدمات عبر منصات متعددة دون مشاركة بيانات اعتمادهم. Apache APISIX هو بوابة API شائعة تدعم تكامل العديد من مزودي الهوية (Keycloak، Ory Hydra، Okta، Auth0، إلخ) لحماية واجهات برمجة التطبيقات الخاصة بك.

اقرأ المزيد من الجلسات: