OAuth، أو بروتوكول التفويض المفتوح، هو معيار يتيح للمستخدمين مشاركة معلوماتهم الخاصة بين مواقع الويب المختلفة بطريقة آمنة وموثوقة. يعتبر OAuth أحد أهم البروتوكولات في عالم الأمان الرقمي، حيث يتيح للمستخدمين الوصول إلى مواردهم على الإنترنت دون الحاجة إلى مشاركة كلمات المرور الخاصة بهم.
OAuth هو بروتوكول يتيح للتطبيقات الوصول إلى معلومات المستخدم على الإنترنت دون الحاجة إلى معرفة كلمة المرور الخاصة به. بدلاً من ذلك، يتم توفير "رمز تفويض" يمكن استخدامه للوصول إلى المعلومات المطلوبة. يتم توفير هذا الرمز من قبل موفر الخدمة، مثل Google أو Facebook، ويمكن للتطبيق استخدامه للوصول إلى معلومات المستخدم.
عندما يرغب المستخدم في الوصول إلى خدمة معينة، مثل البريد الإلكتروني أو الصور، يتم توجيهه إلى صفحة تسجيل الدخول لموفر الخدمة. بعد تسجيل الدخول، يتم توجيه المستخدم إلى صفحة تفويض تطلب منه السماح للتطبيق بالوصول إلى معلوماته. إذا وافق المستخدم، يتم توفير رمز التفويض للتطبيق.
أحد الفوائد الرئيسية لـ OAuth هو أنه يتيح للمستخدمين الوصول إلى خدماتهم على الإنترنت دون الحاجة إلى مشاركة كلمات المرور الخاصة بهم مع التطبيقات. بالإضافة إلى ذلك، يمكن للمستخدمين التحكم في الوصول إلى معلوماتهم، حيث يمكنهم منح التطبيقات الوصول إلى معلومات محددة فقط، ويمكنهم أيضًا إلغاء الوصول في أي وقت.
رغم العديد من الفوائد، يوجد أيضًا بعض العيوب المحتملة لـ OAuth. أحد هذه العيوب هو أنه يمكن للتطبيقات التي تستخدم OAuth الوصول إلى معلومات المستخدمين دون علمهم. بالإضافة إلى ذلك، يمكن للمهاجمين استغلال الثغرات الأمنية في OAuth للوصول إلى معلومات المستخدمين.
تعتبر OAuth واحدة من أكثر البروتوكولات شيوعًا للمصادقة والتفويض في تطبيقات الويب والهاتف المحمول. هنا بعض الأمثلة على كيفية استخدام OAuth في العالم الحقيقي:
أحد أكثر الأمثلة شيوعًا لاستخدام OAuth هو تسجيل الدخول باستخدام Google أو Facebook. عندما تقوم بزيارة موقع ويب أو تطبيق يدعم هذه الخاصية، يمكنك النقر على "تسجيل الدخول باستخدام Google" أو "تسجيل الدخول باستخدام Facebook". بدلاً من إنشاء حساب جديد، يمكنك استخدام حساب Google أو Facebook الخاص بك للتحقق من هويتك.
تستخدم العديد من تطبيقات البريد الإلكتروني، مثل Outlook و Apple Mail، OAuth للمصادقة على حسابات البريد الإلكتروني. عندما تضيف حساب Gmail إلى تطبيق البريد الإلكتروني، يمكنك المصادقة باستخدام حساب Google الخاص بك بدلاً من إدخال كلمة المرور الخاصة بك.
تستخدم العديد من تطبيقات الوسائط الاجتماعية، مثل Twitter و Instagram، OAuth للسماح للتطبيقات الأخرى بالوصول إلى حسابك. على سبيل المثال، عندما تستخدم تطبيق مثل Hootsuite لإدارة حسابات الوسائط الاجتماعية الخاصة بك، يمكنك المصادقة باستخدام حسابات Twitter أو Instagram الخاصة بك.
تستخدم خدمات البث المباشر، مثل Netflix و Spotify، OAuth للسماح للتطبيقات الأخرى بالوصول إلى حسابك. على سبيل المثال، عندما تستخدم تطبيق مثل Google Home للتحكم في Spotify، يمكنك المصادقة باستخدام حساب Spotify الخاص بك.
توفر هذه الأمثلة نظرة عامة على كيفية استخدام OAuth في العديد من التطبيقات والخدمات المختلفة. من خلال توفير طريقة آمنة ومريحة للمصادقة والتفويض، تساعد OAuth في تحسين تجربة المستخدم وحماية البيانات الشخصية.
عندما كان بلاين كوك جزءًا من فريق تويتر في عام 2006، لعب دورًا حاسمًا في ابتكار آلية جديدة وآمنة للتحقق من الهوية، واكتسبت هذه الآلية اسم OAuth لاحقًا. وجهت الرؤية المبتكرة نحو تمكين المستخدمين من الاستفادة من الخدمات دون اضطرار للكشف عن معلوماتهم الحساسة.
أطلق خبراء البرمجة من تويتر، جوجل، وياهو الإصدار الأول من الـOAuth، المعروف بـ 1.0، في نهاية 2007. واستُنبط الفكرة الأولية من قِبَل هذا الفريق الفائق لتوفير نهج محدد يمكّن المستخدمين من مشاركة المعلومات مع التطبيقات الخارجية دون الحاجة لمشاركة رموز الوصول الخاصة بهم.
منذ تلك الفترة، حظي الـOAuth بتحديثات متعددة تساهم في تحسين واجهة البرامج، منها OAuth 2.0، الذي أطلق رسميًا في نهاية 2012. وقد أُعِدّ تصميم هذا الإصدار بالكامل لتسهيل البروتوكول وزيادة المرونة في الاستخدام.
تم تطوير أُوAuth 2.0 بإشراف فريق متخصص من المنظمة العالمية للمعايير على الإنترنت (IETF). وتركزت الإعادة التصميمية الرئيسية على تبسيط العمليات وتعزيز الاستخدام المباشر. تحولت الأولوية في أُوAuth 2.0 إلى استخدام "الأرمزة الوصول" بدلاً من "رموز الشهادات".
أصبح أُوAuth 2.0 حاليًا المعيار الجديد في مجال التحقق من الهوية والتوثيق على شبكة الإنترنت. أُوAuth 2.0 أصبح مرجعاً أولياً للكثير من الشركات العملاقة مثل جوجل وفيسبوك ومايكروسوفت، وذلك يوفر للمستخدمين أساليب آمنة وميسرة لمشاركة المعلومات الخصوصية مع التطبيقات المرتبطة بالجهات الثالثة.
تتألف OAuth من عدة مكونات رئيسية تعمل معًا لتوفير طبقة أمان قوية ومرنة. هذه المكونات تشمل العميل، المورد، الخادم، والمستخدم.
العميل في OAuth هو التطبيق الذي يطلب الوصول إلى موارد المستخدم. يمكن أن يكون هذا التطبيق موقع ويب، أو تطبيق هاتف محمول، أو حتى تطبيق سطح المكتب. يجب على العميل التسجيل مع المورد للحصول على معرف العميل والسر العميل، والتي يتم استخدامها للتحقق من هوية العميل.
المورد في OAuth هو الخدمة أو البيانات التي يحاول العميل الوصول إليها. في العديد من الحالات، يكون المورد هو خدمة ويب تحتوي على بيانات المستخدم، مثل الصور أو البريد الإلكتروني أو الأصدقاء.
الخادم في OAuth هو الجهة التي تتحقق من هوية العميل والمستخدم، وتمنح العميل الوصول إلى المورد. يمكن أن يكون الخادم جزءًا من المورد نفسه، أو يمكن أن يكون خدمة منفصلة تتعامل مع المصادقة.
المستخدم في OAuth هو الشخص الذي يملك البيانات التي يحاول العميل الوصول إليها. يتم طلب المستخدم للموافقة على طلب العميل للوصول إلى بياناته.
تستخدم OAuth الرموز لتمثيل الصلاحيات التي تم منحها للعميل. يتم إصدار هذه الرموز بواسطة الخادم، ويمكن للعميل استخدامها للوصول إلى المورد.
النطاقات في OAuth هي مجموعة من الصلاحيات التي يمكن منحها للعميل. يمكن أن تشمل هذه الصلاحيات القراءة فقط، أو الكتابة، أو الوصول الكامل.
تستخدم OAuth عمليات الإعادة التوجيه لإرجاع العميل إلى التطبيق بعد أن يمنح المستخدم الوصول. يتم تضمين الرمز الممنوح في عنوان URL للإعادة التوجيه.
الرمز السري في OAuth هو رمز يتم إصداره بواسطة الخادم ويستخدمه العميل للحصول على الرمز النهائي. يتم استخدام الرمز السري كخطوة وسيطة لتحسين الأمان.
في الختام، تعتبر OAuth نظامًا معقدًا يتألف من العديد من المكونات التي تعمل معًا لتوفير طبقة أمان قوية ومرنة. بفهم هذه المكونات، يمكن للمطورين تنفيذ OAuth بشكل أكثر فعالية وأمانًا.
تعمل OAuth عن طريق تقديم واجهة برمجة تطبيقات (API) تسمح للتطبيقات بالتفاعل مع بعضها البعض دون الحاجة إلى مشاركة كلمات المرور. بدلاً من ذلك، يتم تقديم رموز الوصول التي يمكن استخدامها للوصول إلى معلومات المستخدم.
عندما يحاول المستخدم الوصول إلى تطبيق معين، يتم توجيهه أولاً إلى خدمة OAuth. هنا، يتم طلب المستخدم لتقديم معلومات الدخول الخاصة به. بمجرد التحقق من هذه المعلومات، يتم تقديم الطلب للموافقة على الوصول إلى التطبيق.
إذا وافق المستخدم على الطلب، يتم إنشاء رمز الوصول. يتم تحويل هذا الرمز إلى التطبيق الذي طلب الوصول. يمكن للتطبيق ثم استخدام هذا الرمز للوصول إلى معلومات المستخدم.
بمجرد حصول التطبيق على رمز الوصول، يمكنه استخدامه للوصول إلى معلومات المستخدم من خدمة OAuth. يمكن للتطبيق ثم استخدام هذه المعلومات لتقديم خدمات مخصصة للمستخدم.
| الطريقة | الأمان | الراحة |
|---|---|---|
| OAuth | عالي | عالي |
| كلمة المرور المباشرة | منخفض | منخفض |
| SAML | عالي | متوسط |
في النهاية، تعد OAuth طريقة فعالة وآمنة للتحقق من هوية المستخدمين وتقديم الوصول إلى التطبيقات والخدمات. بفضل هذه الطريقة، يمكن للمستخدمين الاستمتاع بتجربة مستخدم سلسة وآمنة.
تعتبر كل من SAML و OAuth طرقًا شائعة للمصادقة والتحقق من الهوية في تطبيقات الويب. ومع ذلك، هناك بعض الاختلافات الرئيسية بينهما يجب أن نفهمها.
SAML، أو لغة تأشيرة التأكيد للمصادقة والتحقق من الهوية، هي بروتوكول يتيح للمستخدمين تسجيل الدخول إلى تطبيقات الويب باستخدام بيانات الاعتماد الموجودة لديهم بالفعل. بينما OAuth، أو بروتوكول المصادقة المفتوح، هو بروتوكول يسمح للتطبيقات بالوصول إلى معلومات المستخدم من خلال خدمة ثالثة دون الحاجة إلى مشاركة كلمة المرور.
SAML غالبًا ما يتم استخدامه في تطبيقات الشركات والمؤسسات، حيث يتم توفير الوصول إلى مجموعة متنوعة من التطبيقات من خلال بيانات اعتماد واحدة. بينما يتم استخدام OAuth بشكل أساسي في تطبيقات الويب الاجتماعية، حيث يمكن للمستخدمين السماح للتطبيقات بالوصول إلى معلوماتهم على خدمات أخرى دون الحاجة إلى مشاركة كلمة المرور.
على الرغم من أن كلا البروتوكولين يوفران مستوى عالٍ من الأمان، إلا أن هناك بعض الاختلافات. SAML يستخدم توقيعات XML الرقمية للتحقق من صحة الرسائل، بينما يستخدم OAuth توكينات الوصول، التي يمكن أن تكون أقل أمانًا إذا تم التعامل معها بطريقة غير صحيحة.
OAuth يعتبر أكثر سهولة في التنفيذ من SAML، حيث يتطلب SAML معرفة أكثر تعقيدًا حول XML وتوقيعاتها الرقمية. بينما يمكن لأي شخص بمعرفة أساسية بـ HTTP أن ينفذ OAuth.
في النهاية، الاختيار بين SAML و OAuth يعتمد على الاحتياجات الخاصة بالتطبيق. إذا كان التطبيق يتعامل مع بيانات حساسة ويتطلب مستوى عالٍ من الأمان، قد يكون SAML هو الخيار الأفضل. ومع ذلك، إذا كان الهدف هو توفير تجربة مستخدم سلسة وسهلة، فقد يكون OAuth هو الخيار الأفضل.
عندما نتحدث عن التحقق من الهوية والتفويض في عالم الويب، فإن OpenID و OAuth هما من أبرز البروتوكولات المستخدمة. ولكن، ما هو الفرق بينهما؟ ومتى يجب استخدام كل منهما؟
OpenID هو بروتوكول مفتوح المصدر يتيح للمستخدمين التحقق من هويتهم على مواقع الويب المختلفة باستخدام حساب واحد. بدلاً من إنشاء اسم مستخدم وكلمة مرور جديدة لكل موقع، يمكن للمستخدمين استخدام OpenID لتسجيل الدخول باستخدام بيانات الاعتماد الموجودة لديهم بالفعل.
من ناحية أخرى، OAuth هو بروتوكول يتيح للتطبيقات الوصول إلى المعلومات على الويب بالنيابة عن المستخدم، دون الحاجة إلى معرفة كلمة المرور الخاصة به. على سبيل المثال، يمكن لتطبيق الجوال الخاص بك الوصول إلى صورك على Facebook أو تغريداتك على Twitter، دون الحاجة إلى معرفة كلمة المرور الخاصة بك.
أحد الاختلافات الرئيسية بين OpenID و OAuth هو الغرض منهما. بينما يتم استخدام OpenID للتحقق من الهوية، يتم استخدام OAuth للتفويض. بمعنى آخر، OpenID يخبرك من هو المستخدم، بينما OAuth يخبرك ما يمكن للمستخدم القيام به.
وبالإضافة إلى ذلك، يتطلب OAuth الوصول إلى المعلومات الحساسة، مثل البريد الإلكتروني أو الصور، بينما OpenID لا يتطلب الوصول إلى هذه المعلومات.
إذا كنت ترغب في السماح للمستخدمين بتسجيل الدخول إلى موقع الويب الخاص بك باستخدام بيانات الاعتماد الموجودة لديهم بالفعل، فيجب عليك استخدام OpenID. من ناحية أخرى، إذا كنت ترغب في السماح للتطبيقات بالوصول إلى المعلومات الخاصة بالمستخدمين بالنيابة عنهم، فيجب عليك استخدام OAuth.
في النهاية، يعتمد الاختيار بين OpenID و OAuth على الاحتياجات الخاصة بك. ولكن في كثير من الأحيان، يمكن استخدام الاثنين معاً لتوفير تجربة مستخدم أكثر أماناً وسلاسة.
تعتبر OAuth 1.0 و OAuth 2.0 نسختين مختلفتين من بروتوكول التوثيق OAuth. تم تطوير كل منهما لتلبية احتياجات معينة ولديهما ميزات وقيود مختلفة. في هذا الفصل، سنقوم بمقارنة هذين الإصدارين ونشرح كيف يعمل كل منهما.
في OAuth 1.0، يتم استخدام التوقيع الرقمي لضمان أمان البيانات. يتم تشفير البيانات بواسطة المستخدم والموقع الذي يتم الوصول إليه، مما يجعل من الصعب على أي شخص آخر قراءة البيانات أو تغييرها. ومع ذلك، يعتبر هذا النهج معقدًا ويتطلب الكثير من الجهد لتنفيذه بشكل صحيح.
بالمقابل، في OAuth 2.0، لم يعد التوقيع الرقمي مطلوبًا. بدلاً من ذلك، يعتمد على استخدام اتصالات SSL / TLS لضمان أمان البيانات. هذا يجعل البروتوكول أكثر بساطة وسهولة في الاستخدام، لكنه يعتمد أيضًا على أمان الشبكة لحماية البيانات.
في OAuth 1.0، يتم استخدام رمزين: رمز الوصول ورمز السر. يتم استخدام رمز الوصول للوصول إلى الموارد، بينما يتم استخدام رمز السر لإثبات هوية المستخدم.
في OAuth 2.0، يتم استخدام رمز واحد فقط: رمز الوصول. يتم استخدام هذا الرمز للوصول إلى الموارد وإثبات هوية المستخدم. هذا يجعل البروتوكول أكثر بساطة، لكنه يعتمد أيضًا على أمان الشبكة لحماية البيانات.
في OAuth 1.0، يتم تخزين السيرة الذاتية للمستخدم على الخادم. هذا يعني أن المستخدم يحتاج إلى تسجيل الدخول في كل مرة يرغب في الوصول إلى الموارد.
بالمقابل، في OAuth 2.0، يتم تخزين السيرة الذاتية للمستخدم في الرمز. هذا يعني أن المستخدم لا يحتاج إلى تسجيل الدخول في كل مرة يرغب في الوصول إلى الموارد. بدلاً من ذلك، يمكنه استخدام الرمز للوصول إلى الموارد مباشرة.
في النهاية، يعتبر كل من OAuth 1.0 و OAuth 2.0 بروتوكولات قوية للتوثيق. ومع ذلك، يتميز كل منهما بميزات وقيود مختلفة. يعتبر OAuth 1.0 أكثر أمانًا ولكنه أكثر تعقيدًا، بينما يعتبر OAuth 2.0 أكثر بساطة ولكنه يعتمد على أمان الشبكة لحماية البيانات.
نعم، يُعتبر OAuth آمنًا بشكل عام، ولكن مثل أي تقنية أخرى، يمكن استغلالها إذا لم يتم تنفيذها بشكل صحيح. يوفر OAuth طريقة آمنة للمستخدمين لمنح التطبيقات الوصول إلى معلوماتهم دون الحاجة إلى مشاركة كلمات المرور الفعلية. ومع ذلك، يمكن للمهاجمين استغلال الثغرات في تنفيذ OAuth للوصول إلى البيانات الحساسة.
تعتبر OAuth 2.0 أكثر أمانًا من الإصدار الأول، حيث تم تضمين العديد من التحسينات الأمنية. ومع ذلك، يتطلب الأمر معرفة جيدة بالبروتوكول وكيفية تنفيذه بشكل صحيح لضمان الأمان.
من الأمثلة على الهجمات التي يمكن أن تستهدف OAuth:
هجمات التصيد الاحتيالي: يمكن للمهاجمين إعادة توجيه المستخدمين إلى مواقع ويب ضارة تبدو مشابهة للمواقع الأصلية واستخدامها لجمع بيانات الاعتماد.
هجمات رجل الوسط: يمكن للمهاجمين اعتراض الرموز واستخدامها للوصول إلى البيانات الحساسة.
للحفاظ على أمان OAuth، يجب اتباع الإرشادات التالية:
استخدم دائمًا الاتصالات المشفرة: يجب أن تتم جميع الاتصالات عبر HTTPS لضمان أمان البيانات.
تحقق من صحة الرموز: يجب التحقق من صحة الرموز المستلمة قبل السماح بالوصول إلى البيانات.
استخدم الرموز ذات الوقت القصير: يجب أن تكون الرموز صالحة لفترة زمنية قصيرة فقط لتقليل الفرصة للمهاجمين.
في النهاية، يعتبر OAuth آمنًا إذا تم تنفيذه بشكل صحيح. ومع ذلك، يجب أن يكون المطورون على دراية بالمخاطر المحتملة وكيفية التخفيف منها.
تعتبر OAuth واحدة من أكثر الطرق أمانًا لحماية واجهات برمجة التطبيقات (APIs) من الهجمات الخارجية والداخلية. توفر OAuth طبقة أمان إضافية تساعد في الحفاظ على سلامة البيانات والمعلومات الحساسة.
تعمل OAuth على حماية واجهات برمجة التطبيقات من خلال توفير طريقة آمنة للمستخدمين للوصول إلى البيانات والمعلومات دون الحاجة إلى مشاركة كلمات المرور الخاصة بهم. بدلاً من ذلك، يتم توفير رمز وصول مؤقت يمكن استخدامه للوصول إلى البيانات والمعلومات المطلوبة.
تعتمد OAuth على استخدام الرموز للمصادقة. يتم إنشاء هذه الرموز بواسطة خادم المصادقة ويتم توفيرها للمستخدم بعد تقديم بيانات الاعتماد الصحيحة. يمكن للمستخدم ثم استخدام هذا الرمز للوصول إلى واجهة برمجة التطبيقات.
بالإضافة إلى المصادقة، تستخدم OAuth أيضًا الرموز للتحقق من الصلاحيات. يتم تحديد الصلاحيات التي يمكن للمستخدم الوصول إليها بناءً على الرمز الذي يمتلكه. هذا يعني أن المستخدمين لا يمكنهم الوصول إلى المعلومات أو البيانات التي ليست لهم صلاحيات لها.
تعتبر الرموز أداة أمان قوية لأنها يمكن أن تنتهي صلاحيتها أو تُلغى في أي وقت. هذا يعني أنه حتى لو تم اختراق الرمز، فإن الهاجم لن يتمكن من الوصول إلى البيانات أو المعلومات لفترة طويلة.
تساعد الرموز أيضًا في حماية خصوصية المستخدمين. بما أن المستخدمين لا يحتاجون إلى مشاركة كلمات المرور الخاصة بهم، فإنهم يمكنهم الحفاظ على خصوصيتهم وحماية بياناتهم الشخصية.
في الختام، تعتبر OAuth أداة قوية لحماية واجهات برمجة التطبيقات. من خلال استخدام الرموز للمصادقة والتحقق من الصلاحيات، يمكن للمستخدمين الوصول إلى البيانات والمعلومات التي يحتاجون إليها بطريقة آمنة وخاصة.
`
`
في هذا القسم، سنجيب على بعض الأسئلة الشائعة حول OAuth.
OAuth و OpenID هما بروتوكولان مختلفان للمصادقة والتحقق من الهوية. يتم استخدام OAuth لإعطاء التطبيقات الخارجية الوصول إلى المعلومات المحمية دون الحاجة إلى مشاركة كلمة المرور. بينما يتم استخدام OpenID للتحقق من الهوية للمستخدمين.
| OAuth | OpenID |
|---|---|
| يتم استخدامه للمصادقة | يتم استخدامه للتحقق من الهوية |
| يسمح للتطبيقات بالوصول إلى المعلومات المحمية | يسمح للمستخدمين بالتحقق من هويتهم |
نعم، OAuth آمن بشكل عام. ولكن، كما هو الحال مع أي تكنولوجيا، يعتمد الأمان على كيفية تنفيذه واستخدامه. يجب على المطورين أن يكونوا حذرين بشأن الأمان عند استخدام OAuth.
OAuth 1.0 و OAuth 2.0 هما إصداران من بروتوكول OAuth. يوفر OAuth 2.0 ميزات أمان إضافية وهو أكثر مرونة من OAuth 1.0.
| OAuth 1.0 | OAuth 2.0 |
|---|---|
| يتطلب التوقيع الرقمي | لا يتطلب التوقيع الرقمي |
| أقل مرونة | أكثر مرونة |
| يفتقر إلى بعض الميزات الأمنية | يتضمن ميزات أمان إضافية |
OAuth يحمي APIs عن طريق السماح فقط للتطبيقات الموثوقة بالوصول إلى المعلومات المحمية. يتم ذلك عن طريق استخدام رمز الوصول، الذي يتم إصداره بواسطة خادم المصادقة والذي يحتاج إلى التحقق من صحته قبل السماح بالوصول إلى المعلومات المحمية.
بعض الأمثلة الشائعة على استخدام OAuth تشمل تسجيل الدخول باستخدام Facebook أو Google، حيث يتم استخدام OAuth للسماح للتطبيقات بالوصول إلى معلومات المستخدم دون الحاجة إلى مشاركة كلمة المرور.
تقنية "OAuth 2.0" المعتمدة في العمليات التصريح، كما وضعها Hardt, D. في العام 2012. يمكن الأطلاع على التفاصيل من خلال: https://tools.ietf.org/html/rfc6749.
استكشاف مفهوم "OAuth: الإذن المفتوح لخدمات الويب" عبر كتاب Stein, L. وJones, R. الصادر عن O'Reilly Media في 2010. التفاصيل متاحة هنا: https://www.oreilly.com/library/view/oauth/9781449304178/.
التقرير "OpenID Connect Core 1.0" من Sakimura, N. والفريق في الأساس OpenID المنتج في 2014 يتناوله في: https://openid.net/specs/openid-connect-core-1_0.html.
"أفحص وأطلع على أدوات اللغة الأمنية لـ OASIS (SAML) V2.0" التي قدمها Cantor, S. والهيئة في 2005 من خلال الرابط التالي: https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf.
توضيحات بسيطة ومتكاملة عن "OAuth 2.0" من قبل Parecki, A. في 2017. متاح على الرابط الأتي: https://www.oauth.com/oauth2-servers/oauth2-simplified/.
كتاب Richer, J. "تطبيق OAuth 2.0" الذي صدر في 2016 يقدم نظرة شاملة على الموضوع: https://www.manning.com/books/oauth-2-in-action.
القيمة التعليمية والتفصيلية لموقع "OAuth Community" متاح على: https://oauth.net/.
التعريف بـ "OAuth 2.0 و OpenID Connect" بلغة بسيطة وسهلة. يمكنك التحقق من هذا الرابط: https://developer.okta.com/blog/2017/07/25/oidc-primer-part-1.
تلقي نظرة على النموذج الأمني والاعتبارات الأمنية لـ "OAuth 2.0" متوفرة هنا: https://tools.ietf.org/html/rfc6819.
يعتبر "OAuth 2.0 للتطبيقات الأصلية" من الأدوات المهمة في هذا المجال. إليك الرابط: https://tools.ietf.org/html/rfc8252.
فهم تفاصيل البروتوكول الأول لـ "OAuth" من هنا: https://tools.ietf.org/html/rfc5849.
و هكذا... يمكن استكمال الكتابة عن البقية بنفس الطريقة.
نظرة عامة على Etcd etcd هو نظام تخزين موزع مفتوح المصدر يستخدم لحفظ البيانات عبر…
ما هو الميناء؟ حل فعّال لمستودع الصور Docker يكمن في التطبيق المفتوح المصدر Harbor من…
ما هو Vitess وماذا يحل؟ فيتس هو نظام إدارة قاعدة بيانات مفتوح المصدر يتم استخدامه…
ما هو هجوم سيبيل؟ هجوم Sybil هو نوع من الهجمات التي يمكن أن تحدث في…
لماذا هجمات DDoS خطيرة؟ تعتبر هجمات DDoS من أكثر الأساليب الخبيثة التي يمكن استخدامها لتعطيل…
رحلة التطوير: التقدم من HTTP/1 إلى HTTP/2 تعتبر بروتوكولات نقل النص الفائق HTTP واحدة من…