পটভূমি: আমি OAuth 1.0a এবং 2.0 এর জন্য ক্লায়েন্ট এবং সার্ভার স্ট্যাক লিখেছি।
OAuth 1.0a & 2.0 উভয়ই দ্বি-পাদী প্রমাণীকরণকে সমর্থন করে , যেখানে কোনও সার্ভার ব্যবহারকারীর পরিচয় এবং তিন-পাদিত প্রমাণীকরণের বিষয়ে নিশ্চিত, যেখানে একটি সার্ভার ব্যবহারকারীর পরিচয়ের কোনও সামগ্রী সরবরাহকারী দ্বারা আশ্বাসপ্রাপ্ত। থ্রি-লেগড প্রমাণীকরণ হ'ল যেখানে অনুমোদনের অনুরোধ এবং অ্যাক্সেস টোকেনগুলি খেলতে আসে এবং এটি লক্ষণীয় গুরুত্বপূর্ণ যে OAuth 1 এরও রয়েছে।
জটিলটি: তিন-পাদিত প্রমাণীকরণ
OAuth চশমাগুলির একটি প্রধান বিষয় হ'ল কোনও সামগ্রী সরবরাহকারী (যেমন ফেসবুক, টুইটার ইত্যাদি) কোনও সার্ভারকে (যেমন ক্লায়েন্টের পক্ষে কনটেন্ট সরবরাহকারীর সাথে কথা বলতে ইচ্ছুক এমন একটি ওয়েব অ্যাপ্লিকেশন) নিশ্চিত করা যে ক্লায়েন্টের কিছু পরিচয় রয়েছে । থ্রি-লেগড প্রমাণীকরণ কী অফার করে তা হ'ল ক্লায়েন্ট বা সার্ভার ব্যতীত সেই পরিচয়ের বিশদ জানতে (যেমন ব্যবহারকারীর নাম এবং পাসওয়ার্ড) জেনে রাখার প্রয়োজন নেই ।
(?) ছাড়াই ওআউথের বিশদটির গভীরতা না পেয়ে:
- ক্লায়েন্ট সার্ভারে একটি অনুমোদনের অনুরোধ জমা দেয়, যা ক্লায়েন্টকে তার পরিষেবার বৈধ ক্লায়েন্ট বলে যাচাই করে।
- সার্ভারটি তার সংস্থাগুলিতে অ্যাক্সেসের জন্য অনুরোধ করতে সামগ্রীটিকে সরবরাহকারীর কাছে ক্লায়েন্টকে পুনর্নির্দেশ করে।
- সামগ্রী সরবরাহকারী ব্যবহারকারীর পরিচয় যাচাই করে এবং প্রায়শই সংস্থানগুলি অ্যাক্সেস করার জন্য তাদের অনুমতি প্রার্থনা করে।
- সামগ্রী সরবরাহকারী সাফল্য বা ব্যর্থতার বিষয়টি অবহিত করে ক্লায়েন্টকে আবার সার্ভারে পুনঃনির্দেশ করে। এই অনুরোধ সাফল্যের একটি অনুমোদন কোড অন্তর্ভুক্ত।
- সার্ভার সামগ্রী সরবরাহকারীকে একটি আউট-ব্যান্ড অনুরোধ করে এবং অ্যাক্সেস টোকেনের জন্য অনুমোদনের কোডটি বিনিময় করে।
সার্ভারটি এখন অ্যাক্সেস টোকেনটি পাস করে সামগ্রীর সরবরাহকারীর কাছে অনুরোধ করতে পারে।
প্রতিটি এক্সচেঞ্জ (ক্লায়েন্ট-> সার্ভার, সার্ভার-> সামগ্রী সরবরাহকারী) একটি ভাগ করা গোপনীয়তার বৈধতা অন্তর্ভুক্ত করে, তবে যেহেতু OAuth 1 একটি এনক্রিপ্ট না করা সংযোগের উপর চালিয়ে যেতে পারে, তাই প্রতিটি বৈধতা তারের মাধ্যমে গোপনটি পাস করতে পারে না।
এটি ঠিক হয়ে গেছে, যেমনটি আপনি উল্লেখ করেছেন, এইচএমএসি দিয়ে। ক্লায়েন্ট তার অনুমোদনের অনুরোধের জন্য আর্গুমেন্টগুলিতে স্বাক্ষর করতে সার্ভারের সাথে ভাগ করা গোপনীয়তা ব্যবহার করে। সার্ভার আর্গুমেন্ট গ্রহণ করে, সেগুলিকে নিজেরাই ক্লায়েন্টের কী দিয়ে স্বাক্ষর করে এবং এটি বৈধ ক্লায়েন্ট কিনা তা দেখতে সক্ষম হয় (উপরের 1 ধাপে)।
এই স্বাক্ষরটির জন্য ক্লায়েন্ট এবং সার্ভার উভয়কেই আর্গুমেন্টের ক্রমে সম্মতি জানাতে হবে (সুতরাং তারা ঠিক একই স্ট্রিংয়ে স্বাক্ষর করছে) এবং OAuth 1 সম্পর্কে একটি প্রধান অভিযোগ হ'ল এটির জন্য সার্ভার এবং ক্লায়েন্ট উভয়ই বাছাই করে এবং স্বাক্ষর করুন এটি বেআইনীভাবে কোড এবং হয় এটি সঠিক বা আপনি খুব 401 Unauthorizedসামান্য সাহায্য পান। এটি ক্লায়েন্ট লেখার ক্ষেত্রে বাধা বাড়িয়ে তোলে।
এসএসএল দিয়ে চালানোর অনুমোদনের অনুরোধের প্রয়োজনীয়তার মাধ্যমে, OAuth 2.0 আর্গুমেন্ট বাছাই এবং সম্পূর্ণরূপে সাইন ইন করার প্রয়োজনটিকে সরিয়ে দেয়। ক্লায়েন্টটি তার গোপনীয়তা সার্ভারে দেয় যা এটি সরাসরি বৈধ করে।
একই প্রয়োজনীয়তাগুলি সার্ভার-> সামগ্রী সরবরাহকারী সংযোগে উপস্থিত রয়েছে এবং যেহেতু এটি এসএসএল যা OAuth পরিষেবাদি অ্যাক্সেস করে এমন একটি সার্ভার লেখার ক্ষেত্রে একটি বাধা সরিয়ে দেয়।
এটি উপরের 1, 2 এবং 5 ধাপে জিনিসগুলিকে অনেক সহজ করে তোলে।
সুতরাং এই মুহুর্তে আমাদের সার্ভারের একটি স্থায়ী অ্যাক্সেস টোকেন রয়েছে যা ব্যবহারকারীর জন্য ব্যবহারকারীর নাম / পাসওয়ার্ড সমতুল্য। এটি অনুরোধের অংশ হিসাবে (অ্যাক্সেস আর্গুমেন্ট, HTTP শিরোনাম, বা POST ফর্ম ডেটা হিসাবে) সেই অ্যাক্সেস টোকনটি ব্যবহার করে ব্যবহারকারীর পক্ষে সামগ্রী সরবরাহকারীর কাছে অনুরোধ জানাতে পারে।
যদি বিষয়বস্তু পরিষেবাটি কেবলমাত্র এসএসএল-এর মাধ্যমে অ্যাক্সেস করা হয়, আমরা সম্পন্ন করেছি। যদি এটি সরল এইচটিটিপি-র মাধ্যমে পাওয়া যায় তবে আমরা সেই স্থায়ী অ্যাক্সেস টোকনকে কোনও উপায়ে রক্ষা করতে চাই। সংযোগ স্নিগ্ধ করা যে কেউ চিরকালের জন্য ব্যবহারকারীর সামগ্রীতে অ্যাক্সেস পেতে সক্ষম হবেন।
OAuth 2 এ যেভাবে সমাধান হয়েছে তা রিফ্রেশ টোকেন সহ । রিফ্রেশ টোকেন স্থায়ী পাসওয়ার্ডের সমতুল্য হয়ে ওঠে এবং এটি কেবল কখনও এসএসএলে স্থানান্তরিত হয় । সার্ভারের যখন সামগ্রী পরিষেবায় অ্যাক্সেসের প্রয়োজন হয় তখন এটি স্বল্প-স্থায়ী অ্যাক্সেস টোকেনের জন্য রিফ্রেশ টোকেনের আদান প্রদান করে। এইভাবে সমস্ত স্মিফযোগ্য HTTP অ্যাক্সেসগুলি একটি টোকেন দিয়ে তৈরি করা হবে যা শেষ হবে that গুগল তাদের ওআউথ 2 এপিআইগুলিতে 5 মিনিটের মেয়াদোত্তীর্ণতা ব্যবহার করছে।
তাই রিফ্রেশ টোকেনগুলি বাদ দিয়ে OAuth 2 ক্লায়েন্ট, সার্ভার এবং সামগ্রী সরবরাহকারীর মধ্যে সমস্ত যোগাযোগকে সহজ করে if এবং রিফ্রেশ টোকেনগুলি কেবল তখন সুরক্ষা প্রদানের জন্য উপস্থিত থাকে যখন সামগ্রীটি এনক্রিপ্ট না করা থাকে।
দ্বি-পাদিত প্রমাণীকরণ
যদিও কখনও কখনও কোনও সার্ভারকে তার নিজস্ব সামগ্রীতে অ্যাক্সেস নিয়ন্ত্রণ করতে হয়। দ্বি-পাদিত প্রমাণীকরণ ক্লায়েন্টকে সরাসরি সার্ভারের মাধ্যমে ব্যবহারকারীকে প্রমাণীকরণ করতে দেয়।
OAuth 2 OAuth 1 এর কিছু এক্সটেনশানকে মানক করে যা বিস্তৃত ব্যবহারে ছিল। আমি যেটাকে সবচেয়ে ভাল জানি তা টুইটার দ্বারা xAuth হিসাবে প্রবর্তিত হয়েছিল । আপনি এটি OAuth 2 এ রিসোর্স মালিকের পাসওয়ার্ড শংসাপত্র হিসাবে দেখতে পারেন ।
মূলত, যদি আপনি ব্যবহারকারীর শংসাপত্রগুলি (ব্যবহারকারীর নাম এবং পাসওয়ার্ড) দিয়ে ক্লায়েন্টকে বিশ্বাস করতে পারেন তবে তারা এগুলি অ্যাক্সেস টোকেনের জন্য সরাসরি বিষয়বস্তু সরবরাহকারীর সাথে বিনিময় করতে পারে। এটি মোবাইল অ্যাপ্লিকেশনগুলিতে ওআউথকে অনেক বেশি দরকারী করে তোলে - থ্রি-লেগড প্রমাণীকরণের সাহায্যে সামগ্রী সামগ্রীর সার্ভারের সাথে অনুমোদনের প্রক্রিয়াটি পরিচালনা করতে আপনাকে এইচটিটিপি ভিউ এম্বেড করতে হবে।
OAuth 1 এর সাথে, এটি অফিসিয়াল স্ট্যান্ডার্ডের অংশ ছিল না, এবং অন্যান্য সমস্ত অনুরোধগুলির মতো একই স্বাক্ষরকরণ পদ্ধতিটি প্রয়োজন।
আমি রিসোর্স মালিকের পাসওয়ার্ড শংসাপত্রগুলির সাথে OAuth 2 এর সার্ভার সাইডটি কেবল প্রয়োগ করেছি এবং ক্লায়েন্টের দৃষ্টিকোণ থেকে অ্যাক্সেস টোকেন পাওয়া সহজ হয়ে গেছে: এইচটিটিপি অনুমোদনের শিরোনাম হিসাবে ক্লায়েন্টের আইডি / গোপন পাস করে সার্ভার থেকে একটি অ্যাক্সেস টোকেনের অনুরোধ করুন ফর্ম ডেটা হিসাবে ব্যবহারকারীর লগইন / পাসওয়ার্ড।
সুবিধা: সরলতা
সুতরাং কোনও প্রয়োগকারীর দৃষ্টিকোণ থেকে, OAuth 2 এ আমি যে প্রধান সুবিধা দেখছি তা হ্রাস জটিলতা। এটির জন্য অনুরোধ স্বাক্ষরকরণের প্রক্রিয়াটির প্রয়োজন হয় না, যা হুবহু কঠিন নয় তবে অবশ্যই স্পষ্টভাবে। এটি কোনও পরিষেবার ক্লায়েন্ট হিসাবে কাজ করার জন্য প্রয়োজনীয় কাজকে হ্রাস করে, যা আপনি যেখানে সবচেয়ে বেশি ব্যথা কমাতে চান (আধুনিক, মোবাইল বিশ্বে)। সার্ভার-> সামগ্রী সরবরাহকারীর শেষের জটিলতা হ্রাস করে ডেটাসেন্টারে এটি আরও স্কেলযোগ্য makes
এবং এটি স্ট্যান্ডার্ডটিতে ওউথ 1.0a (এক্সআউথের মতো) এর কিছু এক্সটেনশানগুলির কোড করে যা এখন ব্যাপক ব্যবহারে রয়েছে।