আপনার প্রশ্নের উত্তর কোড স্তর, প্রোটোকল স্তর বা আর্কিটেকচার স্তরে হতে পারে। আমি এখানে বেশিরভাগ প্রোটোকল স্তরের ইস্যু সংক্ষিপ্ত করার চেষ্টা করব যেহেতু এটি পেশাদার ও কনস বিশ্লেষণে সাধারণত সমালোচিত হয়। মনে রাখবেন যে OAuth2 রিসোর্স মালিকের পাসওয়ার্ড শংসাপত্রগুলির তুলনায় অনেক বেশি যা স্পেসিফিকেশন অনুসারে "উত্তরাধিকার বা স্থানান্তরের কারণে" উপস্থিত থাকে, "অন্যান্য অনুদানের ধরণের চেয়ে উচ্চতর ঝুঁকি" হিসাবে বিবেচিত হয় এবং স্পেসিফিকেশনটি স্পষ্টভাবে বলে যে ক্লায়েন্ট এবং অনুমোদন সার্ভারগুলি "এই অনুদানের ধরণের ব্যবহার হ্রাস করা উচিত এবং যখনই সম্ভব অন্য অনুদানের প্রকারগুলি ব্যবহার করা উচিত"।
বেসিক প্রমাণীকরণের তুলনায় আরওপিসি ব্যবহারের আরও অনেক সুবিধা রয়েছে তবে এটির আগে আমরা আসুন OAuth2 এবং বেসিক প্রমাণীকরণের মধ্যে বুনিয়াদি প্রোটোকল পার্থক্যটি। আমি এগুলি ব্যাখ্যা করার সাথে সাথে দয়া করে আমার সাথে সহ্য করুন এবং পরে আরওপিসিতে আসবেন।
ব্যবহারকারীর প্রমাণীকরণ প্রবাহিত হয়
OAuth2 নির্দিষ্টকরণে এখানে চারটি ভূমিকা সংজ্ঞায়িত করা হয়েছে। উদাহরণ সহ, তারা হ'ল:
- রিসোর্সের মালিক: যে ব্যবহারকারীর কিছু সংস্থান থেকে অ্যাক্সেস রয়েছে, যেমন আপনার ক্ষেত্রে, বিভিন্ন ব্যবহারকারীর আরইএসটি এপিআইতে বিভিন্ন অ্যাক্সেস স্তর থাকতে পারে;
- ক্লায়েন্ট: সাধারণত ব্যবহারকারী যে অ্যাপ্লিকেশনটি ব্যবহার করছেন তা ব্যবহারকারীর পরিষেবাগুলি সরবরাহ করতে সংস্থানটিতে অ্যাক্সেসের প্রয়োজন;
- রিসোর্স সার্ভার: আপনার ক্ষেত্রে REST এপিআই; এবং
- অনুমোদনের সার্ভার: এমন সার্ভার যা ব্যবহারকারীর শংসাপত্রগুলি উপস্থাপিত হয় এবং যা ব্যবহারকারীকে প্রমাণীকরণ করে।
যখন কোনও ক্লায়েন্ট অ্যাপ্লিকেশন চলে তখন এটি ব্যবহারকারীর উপর ভিত্তি করে সংস্থানগুলিতে অ্যাক্সেস পেয়ে যায়। যদি কোনও ব্যবহারকারীর প্রশাসকের অধিকার থাকে, তবে REST এপিআইতে ব্যবহারকারীর কাছে উপলব্ধ সংস্থান এবং ক্রিয়াকলাপ প্রশাসকের সুযোগ-সুবিধা ছাড়াই ব্যবহারকারীর চেয়ে অনেক বেশি হতে পারে।
OAuth2 একাধিক ক্লায়েন্ট এবং একাধিক সংস্থার জন্য একটি একক অনুমোদন সার্ভার ব্যবহার করার সম্ভাবনাটিকেও মঞ্জুরি দেয়। উদাহরণস্বরূপ, একটি রিসোর্স সার্ভার ফেসবুকের সাথে ব্যবহারকারীর প্রমাণীকরণ গ্রহণ করতে পারে (যা এই ক্ষেত্রে অনুমোদনের সার্ভার হিসাবে কাজ করতে পারে)। সুতরাং যখন ব্যবহারকারী কোনও অ্যাপ্লিকেশন চালায় (অর্থাৎ ক্লায়েন্ট), এটি ব্যবহারকারীকে ফেসবুকে প্রেরণ করে। ব্যবহারকারীরা তাদের শংসাপত্রগুলি ফেসবুকে টাইপ করেন এবং ক্লায়েন্টটি "টোকেন" ফিরিয়ে দেয় যা এটি সংস্থান সার্ভারে উপস্থাপন করতে পারে। রিসোর্স সার্ভার টোকেনটি দেখে এবং ফেসবুক আসলে এটি ইস্যু করে এবং ব্যবহারকারীকে সংস্থানটিতে অ্যাক্সেসের অনুমতি দেয় তা যাচাই করার পরে এটি গ্রহণ করে। এই ক্ষেত্রে, ক্লায়েন্ট কখনও ব্যবহারকারীর শংসাপত্রগুলি (যেমন তাদের ফেসবুক শংসাপত্রগুলি) দেখতে পায় না।
তবে আসুন আমরা ফেসবুকের পরিবর্তে আপনার ব্যবহারকারীর পরিচয় (এবং একটি অনুমোদন সার্ভার রয়েছে) পরিচালনা করছি যা ইতিমধ্যে আপনার ক্লায়েন্টকে টোকেন দেয়। এখন, আসুন আমরা বলি যে আপনারও একটি অংশীদার রয়েছে এবং আপনি তাদের অ্যাপ্লিকেশনটিকে (অর্থাত্ ক্লায়েন্টকে) আপনার REST এপিআইতে অ্যাক্সেসের অনুমতি দিতে চান। প্রাথমিক প্রমাণীকরণের (বা এমনকি আরওপিসি) ব্যবহার করে ব্যবহারকারী সেই ক্লায়েন্টকে শংসাপত্র সরবরাহ করবে যা অনুমোদনের সার্ভারে এটি প্রেরণ করবে। অনুমোদনের সার্ভারটি তখন একটি টোকেন সরবরাহ করবে যা ক্লায়েন্ট দ্বারা সংস্থানগুলি ব্যবহার করতে ব্যবহার করা যেতে পারে। দুর্ভাগ্যক্রমে, এর অর্থ হল যে ব্যবহারকারীর শংসাপত্রগুলি এখন সেই ক্লায়েন্টের কাছেও দৃশ্যমান। তবে, আপনি কোনও অংশীদারের অ্যাপ্লিকেশনটি (যারা আপনার সংস্থার বাহ্যিক হতে পারে) এমনকি কোনও ব্যবহারকারীর পাসওয়ার্ডও জানতে চাইবেন না। এটি এখন একটি সুরক্ষার সমস্যা এই লক্ষ্য অর্জনের জন্য,
সুতরাং, OAuth2 এর সাথে, কেউ আদর্শ ক্ষেত্রে আরওপিসি ব্যবহার করবেন না বরং অনুমোদনের কোড প্রবাহের মতো একটি আলাদা ব্যবহার করবে। এটি ব্যবহারকারীর শংসাপত্রগুলি যা কেবল অনুমোদনের সার্ভারে উপস্থাপন করা হয় তা জানার থেকে কোনও অ্যাপ্লিকেশনকে সুরক্ষা দেয়। সুতরাং, কোনও ব্যবহারকারীর শংসাপত্রগুলি ফাঁস হয় না। একই সমস্যাগুলি মৌলিক প্রমাণীকরণের সাথে প্রযোজ্য, তবে পরবর্তী বিভাগে, আমি ব্যাখ্যা করব যে কীভাবে আরওপিসি এখনও আরও ভাল, কারণ ক্লায়েন্টদের অবিচ্ছিন্ন অ্যাক্সেসের জন্য ব্যবহারকারীর শংসাপত্রগুলি আরওপিসিতে ক্লায়েন্টের দ্বারা সংরক্ষণের প্রয়োজন নেই।
নোট করুন যে ব্যবহারকারী যখন অনুমোদনের সার্ভারে যান, অনুমোদনের সার্ভারটি ব্যবহারকারীকে নিশ্চিত করতে অনুরোধ করতে পারে যে তারা ক্লায়েন্টকে তাদের পক্ষে সংস্থানগুলি অ্যাক্সেস করার অনুমতি দিতে চায় কিনা। সে কারণেই এটিকে অনুমোদন সার্ভার বলা হয় কারণ ক্লায়েন্টকে সংস্থানগুলি অ্যাক্সেস করার অনুমতি দেওয়ার প্রক্রিয়াটি প্রক্রিয়ায় অন্তর্ভুক্ত থাকে। যদি ব্যবহারকারী ক্লায়েন্টকে অনুমোদন না দেয় তবে এটি সংস্থানগুলিতে অ্যাক্সেস পাবে না। তেমনিভাবে, যদি ব্যবহারকারী নিজেরাই সংস্থানগুলিতে অ্যাক্সেস না রাখে তবে অনুমোদন সার্ভারটি অ্যাক্সেসটিকে অস্বীকার করতে পারে এবং একটি টোকেন ইস্যু করতে পারে না।
প্রাথমিক প্রমাণীকরণে, এমনকি অনুমোদন সার্ভার এবং সংস্থান সার্ভার একক সত্তায় একত্রিত হয়। সুতরাং, সংস্থান সার্ভারটি ব্যবহারকারীকে অনুমোদন দিতে চায়, তাই ক্লায়েন্টের কাছ থেকে শংসাপত্রগুলি জিজ্ঞাসা করে। ক্লায়েন্ট সেই শংসাপত্রগুলি সরবরাহ করে যা ব্যবহারকারীর অনুমোদনের জন্য রিসোর্স সার্ভার দ্বারা ব্যবহৃত হয়। এর অর্থ হ'ল একাধিক সংস্থান সার্ভারগুলি অবশ্যই ব্যবহারকারীর কাছ থেকে শংসাপত্রের প্রয়োজন হবে।
টোকেন জারি
ক্লায়েন্টরা অনুমোদনের সার্ভার থেকে টোকেন পান, তাদের চারপাশে রাখুন এবং সংস্থানগুলিতে অ্যাক্সেস করতে সেগুলি ব্যবহার করুন (টোকেনের নীচে নিজেরাই আরও বিশদ বিবরণ)। ক্লায়েন্টরা কখনই ব্যবহারকারীর পাসওয়ার্ড জানতে পারে না (আরওপিসি ব্যতীত অন্য প্রবাহে) এবং এটি সংরক্ষণ করার প্রয়োজন হয় না। আরওপিসিতে, যদিও ক্লায়েন্টগুলি ব্যবহারকারীর পাসওয়ার্ডটি জানে, তবুও তাদের এটি সংরক্ষণের দরকার নেই কারণ তারা এই টোকেনগুলিকে সংস্থানগুলি অ্যাক্সেস করতে ব্যবহার করে। বিপরীতে, মৌলিক প্রমাণীকরণের ক্ষেত্রে, যদি কোনও ক্লায়েন্ট প্রতিটি সেশনে ব্যবহারকারীর কাছে শংসাপত্র সরবরাহ করতে না চান, তবে ক্লায়েন্টটির ব্যবহারকারীর পাসওয়ার্ড সংরক্ষণ করতে হবে যাতে তারা পরের বারের মতো এটি সরবরাহ করতে পারে। এটি ক্লায়েন্ট শুধুমাত্র ওয়েব অ্যাপ্লিকেশন না হলে মৌলিক প্রমাণীকরণ ব্যবহারে এটি একটি প্রধান ত্রুটি, কুকিজ এই উদ্বেগগুলির কয়েকটি সমাধান করতে পারে। নেটিভ অ্যাপ্লিকেশন সহ, এটি সাধারণত কোনও বিকল্প নয়।
OAuth2 এর আরেকটি দিক রয়েছে যা টোকেন কীভাবে জারি করা হয় এবং সেগুলি কীভাবে কাজ করে তা অন্তর্ভুক্ত রয়েছে। যখন কোনও ব্যবহারকারী অনুমোদনের সার্ভারে (এমনকি আরওপিসিতেও) শংসাপত্রগুলি সরবরাহ করে, অনুমোদন সার্ভারটি দুটি ধরণের টোকেনগুলির মধ্যে এক বা একাধিক দিতে পারে: 1) অ্যাক্সেস টোকেন এবং 2) রিফ্রেশ টোকেন।
অ্যাক্সেস টোকেনগুলি রিসোর্স সার্ভারে প্রেরণ করা হয় যা এটি যাচাই করার পরে সংস্থানগুলিতে অ্যাক্সেস প্রদান করবে এবং সাধারণত তাদের একটি স্বল্পকালীন জীবনকাল থাকে, যেমন 1 ঘন্টা r রিফ্রেশ টোকেন ক্লায়েন্ট কর্তৃক শেষ হওয়ার পরে অন্য অ্যাক্সেস টোকেন পাওয়ার জন্য অনুমোদনের সার্ভারে প্রেরণ করা হয় এবং সাধারণত একটি দীর্ঘকালীন জীবনকাল থাকে (যেমন কয়েক মাস থেকে কয়েক মাস এমনকি কয়েক বছর পর্যন্ত)।
যখন ক্লায়েন্টটি রিসোর্স সার্ভারে অ্যাক্সেস টোকেন সরবরাহ করে, তখন এটি টোকেনটি দেখে এবং যাচাই করার পরে, অ্যাক্সেসের অনুমতি দেয় কিনা তা নির্ধারণ করার জন্য টোকেনের ভিতরে দেখে looks যতক্ষণ অ্যাক্সেস টোকেন বৈধ, ক্লায়েন্ট এটি ব্যবহার চালিয়ে যেতে পারে। আসুন আমরা ব্যবহারকারী অ্যাপ্লিকেশনটি বন্ধ করে এবং পরের দিন এটি শুরু করি এবং অ্যাক্সেস টোকেনটির মেয়াদ শেষ হয়ে গেছে। এখন ক্লায়েন্ট অনুমোদনের সার্ভারে একটি কল করবে এবং এটি মেয়াদ উত্তীর্ণ হয়নি তা ধরে নিয়ে রিফ্রেশ টোকন উপস্থাপন করবে। অনুমোদন সার্ভার, যেহেতু এটি ইতিমধ্যে টোকেন জারি করেছে, এটি যাচাই করে এবং এটি নির্ধারণ করতে পারে যে ব্যবহারকারীর আবার শংসাপত্র সরবরাহ করার প্রয়োজন নেই এবং এইভাবে ক্লায়েন্টকে অন্য অ্যাক্সেস টোকেন দেয়। ক্লায়েন্টের এখন আবার রিসোর্স সার্ভারে অ্যাক্সেস রয়েছে। এইভাবে সাধারণত ফেসবুক এবং টুইটারের ক্লায়েন্ট অ্যাপ্লিকেশনগুলি একবার একবার শংসাপত্রের জন্য জিজ্ঞাসা করে এবং তারপরে আবার ব্যবহারকারীর শংসাপত্র সরবরাহ করার প্রয়োজন হয় না। এই অ্যাপ্লিকেশনগুলির কখনই ব্যবহারকারীর শংসাপত্রগুলি জানার প্রয়োজন হয় না এবং ততবার ব্যবহারকারী যখনই অ্যাপ্লিকেশনটি শুরু করে তত সংস্থানগুলি অ্যাক্সেস করতে পারে।
এখন ব্যবহারকারী অনুমোদনের সার্ভারে যেতে পারেন (যেমন তাদের ফেসবুক ব্যবহারকারী প্রোফাইলে), কোনও ক্লায়েন্ট অ্যাপ্লিকেশনকে প্রভাবিত না করে পাসওয়ার্ড পরিবর্তন করতে পারেন। তারা সবাই সঠিকভাবে কাজ করতে থাকবে। যদি ব্যবহারকারী কোনও ডিভাইস হারিয়ে ফেলে যার উপর তারা ইতিমধ্যে রিফ্রেশ টোকেন সহ একটি অ্যাপ্লিকেশন পেয়েছিল, তবে তারা অনুমোদন সার্ভারকে (যেমন ফেসবুক) যে অ্যাপ্লিকেশনগুলির কোনও উপস্থিতি সম্মান না করে যে অ্যাপ্লিকেশনটি (যেমন ফেসবুক) সম্পন্ন করবে তাদের "লগ আউট" করতে বলতে পারে টোকেনগুলি রিফ্রেশ করুন এবং ব্যবহারকারীরা যখন এই অ্যাপ্লিকেশনগুলির মাধ্যমে সংস্থান অ্যাক্সেস করার চেষ্টা করবেন তখন তাদের শংসাপত্রগুলি সরবরাহ করতে বাধ্য করুন।
জেডাব্লুটিটি হ'ল টোকেন বিন্যাস যা সাধারণত OAuth2 এবং ওপেনআইডি কানেক্টের সাথে ব্যবহৃত হয়। টোকেনটি স্বাক্ষর করার এবং এটি যাচাই করার পদ্ধতিগুলি প্রতিটি সংস্থান সার্ভারের পরিবর্তে অন্য একটি সমাধান কার্যকর করার পরিবর্তে লাইব্রেরিগুলির সাথে উপলব্ধ রয়েছে। সুতরাং, সুবিধাটি কোডটির পুনরায় ব্যবহারযোগ্যতার মধ্যে রয়েছে যা পরীক্ষা করা হয়েছে এবং সমর্থন অব্যাহত রয়েছে।
সুরক্ষা জড়িত
উপরের যে কোনও পরিস্থিতিতে ছবিতে থাকলে বুনিয়াদি প্রমাণীকরণ দুর্বল হবে। বিকাশকারীদের জন্য OAuth2 এর জন্য একটি বিস্তৃত হুমকি মডেলও রয়েছে যা তাদের প্রয়োগগুলিতে সাধারণ দুর্বলতা এড়াতে এতে পরামর্শগুলি ব্যবহার করতে পারে। আপনি যদি হুমকির মডেলটি দেখতে পান তবে দেখতে পাবেন অনেকগুলি বাস্তবায়ন সম্পর্কিত দুর্বলতা (যেমন ওপেন রিডাইরেক্টর এবং সিএসআরএফ) এর মধ্যেও আচ্ছাদিত। আমি এই প্রতিক্রিয়াটিতে মৌলিক প্রমাণীকরণের বিপরীতে তুলনা করে যাই নি।
OAuth2 এর শেষ বড় সুবিধাটি হ'ল প্রোটোকলটি মানকযুক্ত এবং একাধিক অনুমোদন সার্ভার, ক্লায়েন্ট এবং সংস্থানকারী সার্ভার এটি সম্মান করে। বিকাশকারীদের জন্য প্রচুর লাইব্রেরি উপলব্ধ, যা রক্ষণাবেক্ষণ করা হয় যাতে সুরক্ষার সমস্যাগুলি বাস্তবায়নের ক্ষেত্রে পাওয়া যায়, আন্তঃব্যবহারযোগ্যতার অনুমতি দেওয়ার সময় গ্রন্থাগারগুলি আপডেট করা হয়।
উপসংহার
যদি আপনি একটি নতুন অ্যাপ্লিকেশন, আইএমও লিখছেন, তবে আদর্শ বিষয়টি হ'ল অন্তর্নিহিত সমস্যাগুলির কারণে বুনিয়াদি প্রমাণীকরণ এবং আরওপিসি উভয়ই এড়ানো উচিত। তবে প্রতিটি আবেদনের বিভিন্ন চাহিদা, সময়সীমা, বিকাশকারী দক্ষতা ইত্যাদি থাকে তাই সিদ্ধান্তটি কেস বাই কেস। তবে আপনার যদি বেসিক প্রমাণীকরণের চেয়ে আরও কিছু প্রয়োজন না থাকে তবে এটি বেছে নেওয়ার মাধ্যমে আপনি নিজেকে এমন একটি আর্কিটেকচারে লক করতে পারেন যা প্রসারিত করা সহজ নয় (যেমন ভবিষ্যতে যদি আপনার একাধিক সার্ভার থাকে তবে আপনার প্রয়োজন হবে না) ব্যবহারকারী তাদের প্রত্যেককে শংসাপত্র সরবরাহ করে বরং কেবল একবার অনুমোদনের সার্ভারে সরবরাহ করে, যা টোকেন ইত্যাদি সরবরাহ করতে পারে) can
নোট করুন যে তারের মাধ্যমে শংসাপত্রগুলি কীভাবে প্রেরণ করা হয় সে সম্পর্কে আমি আপনার মন্তব্যে সম্বোধন করি নি কারণ সেগুলি টিএলএস বা অনুরূপ প্রোটোকল ব্যবহার করে সুরক্ষিত করা যায়, বা অধিকারের প্রমাণ ইত্যাদি someone যে দ্বারা বিভ্রান্ত করা। উপরে বর্ণিত পার্থক্যগুলি সাধারণত স্থাপত্য স্তরে হয় এবং এইভাবেই আমি মনোনিবেশ করেছি কারণ একবার বাস্তবায়িত হলে আর্কিটেকচার পরিবর্তন করা সবচেয়ে কঠিন est
আজুর অ্যাক্টিভ ডিরেক্টরি বি 2 সি বেসিক , আমি যে পরিষেবাতে কাজ করি এবং সম্প্রতি জনসাধারণের পূর্বরূপের জন্য প্রকাশিত হয়েছিল, তৃতীয় পক্ষের অ্যাপ্লিকেশনটিকে সামাজিক আইডিপি (যেমন ফেসবুক, গুগল ইত্যাদির) সাথে আন্তঃব্যবহারযোগ্যতা সহ অনুমোদনের সার্ভার হিসাবে এএডি ব্যবহার করার অনুমতি দেয়। এটি ব্যবহারকারীদের সামাজিক আইডিপি ব্যবহার না করে তাদের নিজস্ব অ্যাকাউন্ট তৈরি করার অনুমতি দেয় এবং সেগুলি পরে প্রমাণীকরণের উদ্দেশ্যে ব্যবহার করা যেতে পারে। এর মতো আরও কয়েকটি পরিষেবা রয়েছে (যেমন আমি জানি অন্য একটি হ'ল auth0) যা বিকাশকারীরা তাদের অ্যাপ্লিকেশন এবং সংস্থানগুলির জন্য প্রমাণীকরণ এবং ব্যবহারকারী পরিচালনকে সম্পূর্ণ আউটসোর্স করতে ব্যবহার করতে পারেন। উপরে উল্লিখিত একই প্রোটোকল বৈশিষ্ট্যগুলি বিকাশকারীরা অনুমোদন সার্ভার (এএডি), একটি সংস্থান (যেমন তাদের আরএসটি এপিআই), ক্লায়েন্ট (যেমন তাদের মোবাইল অ্যাপ্লিকেশন) এবং ব্যবহারকারীদের ডিকুয়াল করতে ব্যবহৃত হয়। আমি আশা করি এই ব্যাখ্যা কিছুটা সাহায্য করবে।