معلومات مبسطة حول ال API و ال OAuth

تعريف ال API :

هو وسيلة للتواصل مع نظام ما دون الحاجة للتدخل فى هذا النظام.

 

لماذا ال API ضرورى :

  • ال API يعزل الأنظمة و يحميها عن طريق توفير بوابة تسمح بالتعامل مع النظام دون الإطلاع على شفراته البرمجية.
  • ال API لا يرغم المطورين الراغبين فى التعامل مع الأنظمة على دراسة لغة برمجة معينة .. حيث يقدم مخرجاته فى صيغة عالمية متفق عليها و تعمل بها كافة لغات البرمجة مثل صيغة ال XML أو  ال JSON أو ال Text.

 

كيف يعمل ال API :

يتم برمجة ال API بإستخدام أى لغة على أن يكون المعلومات التى يخرجها بصيغة عالمية متفق عليها تفهمها جميع الأنظمة.

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

يحدد ال API للراغبين فى التواصل مع النظام طرق التواصل المتاحة و التى لا يمكن التواصل إلا من خلالها .. أى أنك لن تأخذ من ال API معلومات أو بيانات إلا التى صمم من أجل أن يعطيك إياها .

 

ماهى عملية المصادقة authentication ؟

هى عملية تشبه عملية تسجيل الدخول login و لكنها تتم عبر وسائل آمنة و بروتوكولات محددة توضح كيفية القيام بها .

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

 

متى تكون عملية المصادقة هامة ؟

إذا كان ال API بسيطاً ولا يعطى معلومات حساسة وليس هناك خوف من سوء الإستخدام فقد لا نضطر إلى استخدام عملية المصادقة .. كال API المستخدم للحصول على بيانات الطقس مثلاً  .

أما ال API المستخدم لإضافة محتوى مخصص أو الإطلاع على بيانات حساسة أو تعديلها فيجب أن تتم عملية المصادقة و نكون فى هذه الحالة Authenticated و مخول لنا التعامل مع النظام الآخر Authorized و يمكنا بعمل ال Requests وفقاً للطريق التى يحددها ال API نفسه.

 

ماهو البروتوكول Protocol ؟

هو عبارة تعليمات نسير عليها بعض النظر عن اللغات المستخدمة أو بيئات العمل المتاحة .. و فى حالة التزامنا بهذه التعليمات سنصل إلى النتيجة المرجوه منه .

من أمثلة البروتوكولات بروتوكول ال TCP/IP و أحد هو البروتوكولات التى توضح خطوات عمل اتصال ناجح وآمن بين الأجهزة الإلكترونية التى تعمل على الشبكات وبعضها البعض و الخطأ فى تنفيذ البروتوكول قد ينتج عنه إما ثغرة تسهل إختراق هذه الأجهزة أو مشكلة لا تسمح بالإتصال … وللعلم فإن هناك العديد من البروتوكولات غير هذه البروتوكول التى تستخدم لنفس هذا الغرض و للمصنع أو المستخدم حرية استخدام أى منها .

 

ماهو ال OAuth ؟

هو بروتوكول عالمى معروف يوضح طريقة وخطوات عمل مصادقة بين الأنظمة و يعطينا أكثر من طريقة لإتمام هذه المصادقة

http://oauth.net

 

ماهى ال Grant ؟

هى الوسيلة التى تستخدم فى عملية المصادقة … فمثلاً عند عمل مصادقة بين جهازين يعملان بالبلوتوث يتم طلب Pincode عند إدخاله يتم عمل pairing … و من ثم يمكننا تسمية هذه العملية Pincode grant

 

ماهى طرق ال Grants التى يوفرها ال OAuth ؟

  • Authorisation code grant .. المصادقة عبر نظام الكود .
  • Resource owner credentials grant … المصادقة عبر بيانات المستخدم النهائي .
  • Client credentials grant .. المصادقة عبر بيانات التطبيق .

 

و لكى نفهم الفرق بين الأنواع الثلاثة علينا أن نفرق بين 3 أشياء :

ال Sever :

هو النظام الذى يحتوى على الاكواد البرمجية الخاصة بالنظام و الخاصة بال API و الخاصة بعملية التوثيق من جهة الخادم و قاعدة البيانات و الذى يتم إرسال ال Requests إليه .

إذا كانت مهمتك تصميم و إنشاء API لنظام ما فإنك دورك الآن هو أن تنشئ ال Server .

مثال : إنشاء API لموقع ما لإستخدامة فيما بعد فى

 

ال Client :

هو النظام الآخر الذى يريد عمل مصادقة كتطبيق الجوال مثلاً أو تطبيق ويب أو سطح مكتب يريد التعامل مع النظام الخاص بال server .

إذا كانت مهمتك إنشاء تطبيق يتعامل مع API معين فإن دورك الآن هو أن تنشئ ال Client .

مثال : إنشاء تطبيق يتعامل مع API الفيسبوك … هذا التطبيق هو ال Client .

 

ال Resource owner :

هو المستخدم صاحب البيانات الموجودة على النظام .

 

من يحدد ال Grant ؟

يتم تحديد طريقة ال Grant المناسبة عن طريق الخادم Server و يلتزم بها ال Client و ال Resource owner

 

ما هى طريقة ال Grant المناسبة لنظامك عند إنشاء server  :

  • Authorisation code grant .. المصادقة عبر نظام الكود :

فى حالة كان نظامك يعتمد على تسجيل دخول ال Resource owners و أنت لا تثق فى ال clients الذين سيستخدمون ال API لإنشاء تطبيقات لهؤلاء ال Resource owners … فبالتالى أنت لا تريدهم أن يحصلوا على إسم المستخدم و كلمة المرور الخاصين بال Resource owners … فتجعل عملية تسجيل الدخول لل Resource owners تتم من خلال نظامك أنت ( موقعك ) وبعد نجاح تسجيل الدخول تحيلهم إلى ال Client ب Code ليستخدمه فى إتمام عملية المصادقة و الحصول على ال Token .

 

  • Resource owner credentials grant … المصادقة عبر بيانات المستخدم النهائي .

هذه الحالة أكثر سهولة فى تطبيقها و لكنها تعتمد على مدى ثقتك فى ال Client … ففى هذه الحالة سيحتوى تطبيق ال Client على فورم لإدخال إسم المستخدم و كلمة المرور لل Resource owner مباشرة .. ثم يقوم ال client بعملية تسجيل الدخول عوضاً عن المستخدم فى النظام الخاص بك ( موقعك ) و الحصول على ال Token عند نجاح العملية .

و لكن إن لم يكن ال Client أمينا فقد يقوم بسوء إستغلال بيانات تسجيل دخول المستخدمين لديك .

و يمكن الإعتماد على هذه الحالة فقط فى حالة أنك أنت صاحب ال Client المتسخدم .. مثل تطبيق Facebook على Android أو IOS فإنك تسجل دخولك مباشرة لأن هذا التطبيق Facebook هى من نشرته و برمجته .

 

  • Client credentials grant .. المصادقة عبر بيانات التطبيق .

فى كل حالة من الحالات السابقة كان ال Client يهمة أن ال Resource owner يقوم بتسجيل الدخول و لكن فى هذه الحالة لا يوجد Resource owner .

ال Client يقوم بالتواصل مع النظام لعرض بيانات أو جلب إحصائيات أو أخبار فقط .

هذه المصادقة يطلق عليها machine-to-machine .

 

  • Refresh token grant  .. تخديث التذكرة ..

التذكرة أو ال Token التى يحصل على ال Client من ال Server عن إتمام عملية المصادقة لها فترة صلاحية و لذلك نشأ هذا ال Grant ليتم من خلاله تجديد التذكرة قبل إنتهائها و الحصول على تذكرة جديدة بدلاً من تركها حتى الإنتهاء و بالتالى يضطر ال client لبدأ عميلة مصادقة جديدة سواء بنفسه أو بتوجيه ال Resource owner لذلك .

 

فى كل حالة من الحالات السابقة …. ال Client يقوم بإرسال ال Client_id و ال Client_secret الخاصين بتطبيقة مع ال requests التى يقوم بها .. ليحدد النظام ما هو التطبيق الذى يحاول استخدامه .. بحيث يمكن حظره أو الحصول على احصائيات تخص بعض التطبيقات .

 

أتمنى أن أكود قد أفدتكم ولو قليلاً حول هذا الموضوع .. ولا تنسونا بالدعاء