একটি RESTful API এ API কীগুলি বনাম HTTP প্রমাণীকরণ বনাম OAuth

Question

আমি যে অ্যাপ্লিকেশন বজায় রাখি তার মধ্যে একটির জন্য একটি RESTful API তৈরির জন্য কাজ করছি। আমরা বর্তমানে এটিতে বিভিন্ন জিনিস তৈরি করতে চাইছি যার জন্য আরও নিয়ন্ত্রিত অ্যাক্সেস এবং সুরক্ষা প্রয়োজন। কীভাবে এপিআই সুরক্ষিত করা যায় সে সম্পর্কে গবেষণা করার সময়, কী ফর্মটি ব্যবহার করতে হবে সে সম্পর্কে আমি কয়েকটি ভিন্ন মতামত পেয়েছি। আমি কিছু সংস্থান দেখেছি বলেছি যে এইচটিটিপি-অউথ যাবার উপায়, অন্যরা এপিআই কীগুলি পছন্দ করে এবং অন্যরাও (এসওতে আমি এখানে যে প্রশ্নগুলি পেয়েছি সেগুলি সহ) ওআথের শপথ করে।

তারপরে অবশ্যই, যেগুলি এপিআই কীগুলি পছন্দ করে, বলে যে ওএউথটি ব্যবহারকারীর পক্ষে অ্যাক্সেস পাওয়ার জন্য অ্যাপ্লিকেশনগুলির জন্য ডিজাইন করা হয়েছে (যেমন আমি এটি বুঝতে পারি, যেমন আপনার ফেসবুক অ্যাকাউন্ট ব্যবহার করে কোনও নন-ফেসবুক সাইটে সাইন ইন করা), এবং কোনও ব্যবহারকারীর পক্ষে নির্দিষ্টভাবে সাইন আপ করেছেন এমন কোনও সাইটে সরাসরি সংস্থান অ্যাক্সেস করার জন্য নয় (যেমন সরকারী টুইটার ক্লায়েন্ট টুইটার সার্ভারগুলিতে অ্যাক্সেস করা)। যাইহোক, OAuth- র প্রস্তাবনাগুলি প্রমাণীকরণের প্রয়োজনীয়তার সর্বাধিক প্রাথমিকের জন্যও বলে মনে হয়।

আমার প্রশ্ন, তাহলে, - এইচটিটিপিএস-এ সমস্ত সম্পন্ন হয়েছে ধরেই নেওয়া হচ্ছে, এই তিনটির মধ্যে কিছু ব্যবহারিক পার্থক্য কী? অন্যকে কখন বিবেচনা করা উচিত?

Comments

আপনি কি দিয়ে শেষ করেছেন?

— ইরভিন

@ ইরউইন - আমি বেশ কিছু সময় আগে এই প্রশ্নটি জিজ্ঞাসা করেছি এবং তখন থেকে এটির প্রয়োজনীয় প্রকল্পটি থেকে এগিয়ে চলেছি, তবে আমি এপিআই কী এবং উত্পন্ন পাসওয়ার্ডের সংমিশ্রণটি ব্যবহার করে শেষ করেছি (যা ব্যবহারকারীরা কখনই দেখতে পায় না), যা এইচটিটিপি প্রমাণীকরণ ব্যবহার করে প্রেরণ করা হয়েছিল।

— শওনা

Answer 1

এটি আপনার প্রয়োজনের উপর নির্ভর করে। তোমার দরকার আছে:

• পরিচয় - কে এপিআই অনুরোধ করছে বলে দাবি করেছে?
• প্রমাণীকরণ - তারা সত্যই তারা বলে যে তারা?
• অনুমোদন - তারা যা করার চেষ্টা করছে তা করার অনুমতি দেওয়া হচ্ছে?

নাকি তিনটি?

ভলিউম বা এপিআই কলগুলির সংখ্যার খোঁজ রাখার জন্য যদি আপনাকে কেবল কলার সনাক্ত করতে হয় তবে একটি সাধারণ এপিআই কী ব্যবহার করুন। মনে রাখবেন যে আপনি যদি এপিআই কীটি জারি করেছেন ব্যবহারকারী যদি তা অন্য কারও সাথে ভাগ করে নেন তবে তারা আপনার এপিআইতেও কল করতে সক্ষম হবে।

তবে, আপনার যদি পাশাপাশি অনুমোদনেরও প্রয়োজন হয় তবে তা হল আপনার এপিআই'র কলারের উপর ভিত্তি করে নির্দিষ্ট কিছু সংস্থানগুলিতে অ্যাক্সেস সরবরাহ করা দরকার, তবে oAuth ব্যবহার করুন।

এখানে একটি ভাল বিবরণ দেওয়া হয়েছে: http://www.srimax.com/index.php/do-you-need-api-keys-api-identity-vs-authorization/

Comments

"নির্দিষ্ট সংস্থানগুলি" দিয়ে আপনার অর্থ "নির্দিষ্ট এপিআই কল" বা "নির্দিষ্ট ডাটাবেস রেকর্ডস", বা উভয়ই?

— ম্যাগনে 12

বেশিরভাগ ডিবি রেকর্ডস (বা এমন কিছু যা সুরক্ষিত রাষ্ট্র প্রকাশ করে বা রাষ্ট্রকে পরিবর্তন করে)। তবে এটি প্রিমিয়াম বৈশিষ্ট্যের মতোও কিছু হতে পারে (যেমন একটি মেঘের উপর একটি অ্যালগরিদম চালানো) যা ডিবের উপর সত্যিকার অর্থে কোনও পরিবর্তন করে না তবে সিস্টেম সংস্থান ব্যবহার করে এবং কেবল অনুমোদিত ব্যক্তিদের জন্যই উপলভ্য হওয়া উচিত।

— সিড

@ সিড আমি এমন একটি অ্যাপে কাজ করছি যা ফেসবুক বা লিংকডইন দিয়ে সাইন আপ করা ব্যবহারকারীদের নিবন্ধনের জন্য OAuth ব্যবহার করে। অতিরিক্তভাবে আমরা ডেটা পরিচালনা করার জন্য অন্যান্য পরিষেবাগুলির জন্য আমাদের API খুলছি। সেক্ষেত্রে, আপনি কী ইউটিউথের পক্ষে ওআউথ, এবং একটি এপিআই কী বা ব্যবহারকারীর নাম এবং পাসওয়ার্ডের সংমিশ্রণ (যেমন নিবন্ধটি আপনি লিঙ্ক করেছেন তাতে API) অ্যাক্সেসের জন্য প্রস্তাব করবেন? OAuth এবং api কী উভয়ই বিভিন্ন উদ্দেশ্যে ব্যবহৃত হয়, তাই না?

— টম ডো

@ টমডো হাই টম - হ্যাঁ তা উপলব্ধি করে। আপনি সম্ভবত এখন OAuth2 ব্যবহার করতে চান। যদি আপনার সার্ভার পাইথনে থাকে (জ্যাঙ্গো বা ফ্লাস্ক) github.com/omab/python-social-auth

— সিড

আমি বুঝতে পারছি না কীভাবে একটি API কী এই তিনটি জিনিস সরবরাহ করতে পারে না। পরিচয় এবং প্রমাণীকরণ উভয়ই "আপনি কোনও নির্দিষ্ট গোপনীয়তা জানেন?" এর উপর ভিত্তি করে (যদি না আপনি 2 এফএ পরিচয় করেন তবে এটি একটি পৃথক বিষয়)। যদি আমি ব্যবহারকারীর 5-এর খুব দীর্ঘ এপিআই কী দিই, যা আমি ব্যবহারকারী 5 হিসাবে দাবি করে এবং প্রমাণ করে, অন্তত সেইসাথে একটি ব্যবহারকারীর নাম / পাসওয়ার্ডও দেয়। এবং কোনও এপিআই কীগুলিতে আলাদা আলাদা অনুমতি বরাদ্দ করতে পারে না এমন কোনও কারণ নেই। রাইট? আমি এখানে কি মিস করছি?

— নাথান লং

Answer 2

এপিআই কী বা এমনকি টোকেনগুলি সরাসরি প্রমাণীকরণ এবং অনুমোদনের প্রক্রিয়াগুলির বিভাগে আসে কারণ তারা আরএসটি API এর উন্মুক্ত সংস্থানগুলিতে অ্যাক্সেস দেয়। প্রতিনিধিদের ব্যবহারের ক্ষেত্রে এ জাতীয় প্রত্যক্ষ প্রক্রিয়া ব্যবহার করা যেতে পারে।

আরইএসটি শেষ পয়েন্টগুলি দ্বারা উদ্ভাসিত কোনও সংস্থান বা সংস্থার সংস্থার অ্যাক্সেস পাওয়ার জন্য, এটির পরিচয় অনুসারে অনুরোধকারীর সুবিধাগুলি পরীক্ষা করা প্রয়োজন। কর্মপ্রবাহের প্রথম ধাপটি তারপরে অনুরোধটি প্রমাণীকরণ করে পরিচয় যাচাই করা হয় ; ধারাবাহিক পদক্ষেপটি অ্যাক্সেসের মাত্রা অনুমোদিত করার জন্য নির্ধারিত নিয়মের একটি সেটের বিরুদ্ধে পরিচয় যাচাই করে (যেমন পড়ুন, লিখুন বা পড়ুন / লিখুন)। একবার বলা পদক্ষেপগুলি সম্পন্ন হওয়ার পরে, একটি সাধারণ আরও উদ্বেগ হ'ল অনুরোধের অনুমোদিত হার , যার অর্থ অনুরোধকারীকে প্রদত্ত সংস্থান (গুলি) এর দিকে প্রতি সেকেন্ডে কতগুলি অনুরোধ সম্পাদনের অনুমতি দেওয়া হয়।

ওএথ (ওপেন অথরাইজেশন) প্রতিনিধি অ্যাক্সেসের জন্য একটি প্রমিত প্রোটোকল প্রায়শই বড় ইন্টারনেট সংস্থাগুলি পাসওয়ার্ড সরবরাহ না করেই অ্যাক্সেস দেওয়ার জন্য ব্যবহৃত হয়। পরিষ্কার হিসাবে, ওআউথ হ'ল প্রোটোকল যা উপরোক্ত উল্লিখিত উদ্বেগগুলি পূরণ করে: উত্সের মালিকের পক্ষে সার্ভার রিসোর্সে সুরক্ষিত প্রতিনিধি অ্যাক্সেস সরবরাহ করে প্রমাণীকরণ এবং অনুমোদন। এটি অ্যাক্সেস টোকেন্স প্রক্রিয়া ভিত্তিক যা তৃতীয় পক্ষকে সংস্থার মালিকের পক্ষে সার্ভার দ্বারা পরিচালিত সংস্থানটিতে অ্যাক্সেস পেতে দেয়। উদাহরণস্বরূপ, সার্ভিসএক্স জন এর পক্ষে জন স্মিথের গুগল অ্যাকাউন্টটি অ্যাক্সেস করতে চায়, একবার জন প্রতিনিধিদলের অনুমোদন দিলে; সার্ভিসএক্সকে গুগল অ্যাকাউন্টের বিশদটি অ্যাক্সেস করার জন্য একটি সময় ভিত্তিক টোকেন জারি করা হবে, সম্ভবত কেবল পঠনের অ্যাক্সেসেই।

এপিআই কী ধারণাটি উপরে বর্ণিত OAuth টোকেনের সাথে খুব মিল। প্রধান পার্থক্য প্রতিনিধিদের অনুপস্থিতিতে অন্তর্ভুক্ত: ব্যবহারকারী ক্রমাগত প্রোগ্রাম্যাটিক ইন্টারঅ্যাকশনগুলির জন্য সরাসরি পরিষেবা সরবরাহকারীর চাবিটি অনুরোধ করে। এপিআই কী এর ক্ষেত্রে সময় ভিত্তিক পাশাপাশি রয়েছে: ওআউথ টোকেন হিসাবে কীটি কোনও সময় ইজারা বা মেয়াদোত্তীর্ণ সময়কাল সাপেক্ষে। অতিরিক্ত দিক হিসাবে, কী এবং টোকেন পরিষেবা চুক্তি দ্বারা রেট সীমাবদ্ধ হতে পারে, অর্থাত প্রতি সেকেন্ডে কেবলমাত্র একটি নির্দিষ্ট সংখ্যক অনুরোধ দেওয়া যেতে পারে।

পুনরুদ্ধার করার জন্য, বাস্তবে সনাতন প্রমাণীকরণ এবং অনুমোদনের প্রক্রিয়া এবং কী / টোকেন-ভিত্তিক সংস্করণগুলির মধ্যে কোনও আসল পার্থক্য নেই। দৃষ্টান্তটি কিছুটা আলাদা যদিও: ক্লায়েন্ট এবং সার্ভারের মধ্যে প্রতিটি এবং প্রতিটি মিথস্ক্রিয়ায় শংসাপত্রগুলির পুনরায় ব্যবহার করার পরিবর্তে, একটি সমর্থন কী / টোকেন ব্যবহৃত হয় যা সামগ্রিক মিথস্ক্রিয়া অভিজ্ঞতাটিকে মসৃণ এবং সম্ভবত আরও সুরক্ষিত করে তোলে (প্রায়শই, জেডাব্লুটি মান অনুসরণ করে , কী এবং কারুকাজ এড়ানোর জন্য টোকনগুলি সার্ভার দ্বারা ডিজিটালি স্বাক্ষরিত হয়)।

• প্রত্যক্ষ প্রমাণীকরণ এবং অনুমোদন : প্রচলিত শংসাপত্রাদি-ভিত্তিক সংস্করণগুলির বৈকল্পিক হিসাবে কী-ভিত্তিক প্রোটোকল।
• প্রদত্ত প্রমাণীকরণ এবং অনুমোদন : ওএউথ-ভিত্তিক প্রোটোকলগুলির মতো, যা আবার টোকেনকে শংসাপত্র ভিত্তিক সংস্করণের রূপ হিসাবে ব্যবহার করে (সামগ্রিক লক্ষ্য কোনও তৃতীয় পক্ষের কাছে পাসওয়ার্ড প্রকাশ করছে না)।

উভয় বিভাগই আগ্রহী সংস্থান (গুলি) এর মালিকানাধীন সার্ভারের সাথে প্রথম আলাপচারিতার জন্য একটি traditionalতিহ্যবাহী পরিচয় যাচাইকরণের কার্যপ্রবাহ ব্যবহার করে।