ওপেনআইডি ও ওউথের মধ্যে পার্থক্য কী?

Question

আমি সত্যিই ওপেনআইডিআইডি এবং ওআউথের মধ্যে পার্থক্যটি বোঝার চেষ্টা করছি? তারা দুটি সম্পূর্ণ পৃথক জিনিস হতে পারে?

Comments

এই বুঝতে পেরেছিল যে OAuth এর একটি প্রমাণীকরণ ফ্রেমওয়ার্ক নয় সহায়ক হতে পারে - যখন কোন OpenID এবং থেকে OpenID হয় .. blog.api-security.org/2013/02/...

— Prabath Siriwardena

ওপেনআইডি কানেক্ট (২০১৪) একটি একক প্রোটোকলে ওপেনআইডি ২.০, ওপেনআইডি অ্যাট্রিবিউট এক্সচেঞ্জ 1.0 এবং ওআউথ 2.0 এর বৈশিষ্ট্যগুলি একত্রিত করে। সিকিউরিটি.স্ট্যাকেক্সচেঞ্জ

— প্রশ্নগুলি / ques৪611/…

এটি প্রতিটি স্ট্যান্ডার্ডের উদ্দেশ্যটির দুর্দান্ত ব্যাখ্যা: stackoverflow.com/a/33704657/557406

— চার্লস এল।

Answer 1

ওপেনআইডিটি প্রমাণীকরণ সম্পর্কিত (যেমন আপনি প্রমাণ করছেন), ওআউথ অনুমোদনের বিষয়ে (অর্থাত্ মূল প্রমাণীকরণের সাথে ডিল না করে কার্যকারিতা / ডেটা / ইত্যাদিতে অ্যাক্সেস দেওয়ার জন্য)।

বাহ্যিক অংশীদার সাইটগুলিতে কোনও ব্যবহারকারীকে পুনরায় প্রমাণীকরণ না করে সুরক্ষিত ডেটা অ্যাক্সেসের অনুমতি দেওয়ার জন্য OAuth ব্যবহার করা যেতে পারে।

" ব্যবহারকারীর দৃষ্টিকোণ থেকে ওপেনআইডি বনাম ওআউথ " ব্লগ পোস্টটির ব্যবহারকারীর দৃষ্টিকোণ থেকে দু'জনের একটি সহজ তুলনা রয়েছে এবং " ওআউথ-ওপেনআইডি: আপনি যদি একইরকম জিনিস মনে করেন তবে আপনি ভুল গাছটিকে বার্ক আপ করছেন " আরও তথ্য রয়েছে এটি সম্পর্কে।

Comments

সবেমাত্র সমস্ত তথ্য পেয়েছে। আশা করি এই ওপেনআইডি এবং ওআউথ তুলনাটি দরকারী।

— রাক্সা

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

— টিএমএমএম

"ওপেনআইডি কানেক্ট" আরও বিভ্রান্তি নিশ্চিত করে কারণ এটি একটি ছোট এক্সটেনশান সহ আসলে একটি OAuth ভি 2।

— ভিলমন্টাস বড়ানউস্কাস

একক সাইন অন (এসএসও)

— রিচার্ড

@ টিম্মম্ম, "OAuth 2.0 কোনও প্রমাণীকরণ প্রোটোকল নয়" যেমন তারা এখানে উল্লেখ করেছে । এখানে আরও একটি সহায়ক ভিডিও রয়েছে

— রায়লয়েভলেস

Answer 2

ওআউথ এবং ওপেনআইডিটির তুলনা করার জন্য তিনটি উপায় রয়েছে:

1. উদ্দেশ্য

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

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

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

2. বৈশিষ্ট্য

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

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

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

3. প্রযুক্তিগত বাস্তবায়ন

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

প্রতিটি প্রোটোকলের অনুরোধ বা প্রতিক্রিয়াটির সত্যতা যাচাই করতে ব্যবহৃত স্বাক্ষর গণনা করার আলাদা পদ্ধতি রয়েছে এবং প্রত্যেকটির নিবন্ধের বিভিন্ন প্রয়োজন রয়েছে।

Comments

ধন্যবাদ, আমি এই প্রসঙ্গে 'ফেডারেটেড' এবং 'আবিষ্কার' শব্দটি নিয়ে প্রচুর সমস্যায় পড়ছিলাম এবং উত্তরটি একেবারে পরিষ্কার করে দিয়েছে।

— আদিত্য এমপি

একটি ভাল উত্তর, তবে আমি "সাদা-তালিকার ব্যতিক্রম" নিয়ে কিছুটা বিভ্রান্ত। আপনি বাদ সাদা তালিকা?

— ক্রিপথ

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

— ইউজিন ইয়ার্মাশ

Answer 3

ওপেনআইডিআইডি (প্রধানত) সনাক্তকরণ / প্রমাণীকরণের জন্য, যাতে এটি stackoverflow.comজানে যে আমি নিজের chris.boyle.name(বা যেখানেই থাকি) মালিক এবং তাই সম্ভবত আমি একই ব্যক্তি যিনি chris.boyle.nameগতকাল মালিকানা পেয়েছিলেন এবং কিছু খ্যাতি অর্জন করেছিলেন।

OAuth আপনার পক্ষ থেকে পদক্ষেপ নেওয়ার অনুমোদনের জন্য ডিজাইন করা হয়েছে, যাতে stackoverflow.com(বা যেখানেই হোক) আপনার টুইটারের পাসওয়ার্ড না জেনে নিজের পক্ষ থেকে স্বয়ংক্রিয়ভাবে টুইট করার অনুমতি চাইতে পারেন।

Comments

তবে যদি আপনি আপনার পক্ষ থেকে পদক্ষেপ নেওয়ার জন্য টুইটারকে অনুমোদিত করেন তবে এর দ্বারা বোঝা যায় যে আপনি সেই ব্যক্তি যাকে আপনি বলেছিলেন যে আপনি - তাই এটি উভয়কেই একত্রিত করে?

— ডেভিড ডি সি ই ফ্রেইটাস

ডেভিড, আপনি ঠিক বলেছেন। গুগল এটি এভাবে করে।

— টিএমএমএম

এটি ওউথের সাথে মনে হচ্ছে, তৃতীয় পক্ষের সাইটটি একটি টোকেন পাবে যা এটি ওউথ সরবরাহকারীর সাইটে ক্রিয়া সম্পাদন করতে ব্যবহার করতে পারে (বলুন, আপনার পক্ষ থেকে টুইট করুন), তবে ব্যবহারকারীর পরিচয় (ব্যবহারকারীর নাম) পাওয়া যায়নি প্রোটোকল যাতে সরবরাহকারীদের এটি কাস্টম সংস্থান হিসাবে যুক্ত করতে হয়।

— একমাত্র

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

— রেভন্ত কুমার

@ jlo-gmail OAuth 2.0 এ এই উদ্দেশ্যে রিফ্রেশ টোকেন অন্তর্ভুক্ত রয়েছে: আপনি মাঝে মাঝে একটি নতুন অ্যাক্সেস টোকেন পেতে রিফ্রেশ টোকেন ব্যবহার করেন। আরও তথ্য: সরঞ্জাম. ietf.org/html/rfc6749#section-1.5

— ক্রিস

Answer 4

অনেক লোক এখনও এটি দেখতে যান তাই এটি ব্যাখ্যা করার জন্য এখানে একটি খুব সাধারণ চিত্র রয়েছে g

সৌজন্য উইকিপিডিয়া

Comments

ওআউথ উদাহরণে আরও একটি পদক্ষেপ থাকা উচিত নয় যেখানে অ্যান্ড্রয়েড অ্যাপ্লিকেশন ব্যবহারকারীদের পরিচয় জানতে গুগলের সাথে যোগাযোগের জন্য ভ্যালেট কীটি ব্যবহার করে?

— একমাত্র 18

আমি মনে করি অনুপস্থিত পদক্ষেপটি আরও জেনারেল হওয়া উচিত। অর্থাৎ এটি পরিচয়ের বিষয়ে এতটা নয় যেমন এটি API এর মাধ্যমে সরবরাহ করা যেতে পারে এমন ডেটা সম্পর্কে। অর্থাত আপনার গুগল ফটো বা আপনার জি-মেল ইমেলগুলি যে অ্যান্ড্রয়েড অ্যাপটি যে কোনও উদ্দেশ্যেই ব্যবহার করতে পারে। অবশ্যই, পরিচয়টি API এর মাধ্যমে অ্যাক্সেসযোগ্য হতে পারে।

— স্যাটেলাইট

ওআউথের জন্য, এটি কি "আপনার বাড়ির ভ্যালেট কীটি আমাকে দিয়ে দিন যাতে আমি আপনার বাড়িতে অ্যাক্সেস / সংশোধন করতে পারি"?

— hendryanw

Answer 5

OAuth এর

authorizationশুধুমাত্র ডেলিগ্রেটেডের জন্য ব্যবহৃত হয় - এর অর্থ আপনি কোনও পাসওয়ার্ড না দিয়ে তৃতীয় পক্ষের পরিষেবা অ্যাক্সেসের ব্যক্তিগত ডেটা ব্যবহার করার অনুমতি দিচ্ছেন। এছাড়াও ওআউথ "সেশনগুলি" সাধারণত ব্যবহারকারী সেশনের চেয়ে দীর্ঘকাল বেঁচে থাকে। মানে OAuth অনুমোদনের অনুমতি দেওয়ার জন্য ডিজাইন করা হয়েছে

অর্থাত্ ফ্লিকার তাদের ফ্লিকার ব্যবহারকারী নাম এবং পাসওয়ার্ড না দিয়েই তৃতীয় পক্ষের পরিষেবাগুলি তাদের পক্ষে কোনও ব্যক্তির ছবি পোস্ট এবং সম্পাদনা করার অনুমতি দেওয়ার জন্য OAuth ব্যবহার করে।

ঝাঁপ দাও

ব্যবহৃত authenticateএকক সাইন-অন পরিচয়। সমস্ত ওপেনআইডিআইডি করার কথা একটি ওপেনআইডি সরবরাহকারীকে প্রমাণ করার অনুমতি দেওয়া হয় যে আপনি বলেছিলেন যে তিনি। তবে অনেকগুলি সাইট অনুমোদনের জন্য পরিচয় প্রমাণীকরণ ব্যবহার করে (তবে দুটি আলাদা করা যায়)

উদাহরণস্বরূপ, বিমানবন্দরে একজন যার পাসপোর্টটি ব্যবহার করছেন তার টিকিটে যার নাম রয়েছে তার প্রমাণীকরণ করতে (বা প্রমাণ করতে) shows

Comments

আপনি অবশ্যই একক সাইন-অনকে অনুমোদনের জন্য OAuth ব্যবহার করতে পারেন?

— টিএমএমএম

Answer 6

যদি আপনার ব্যবহারকারীরা কেবল ফেসবুক বা টুইটারের সাহায্যে লগইন করতে চান তবে OAuth ব্যবহার করুন। যদি আপনার ব্যবহারকারীরা তাদের ওপেনআইডিআইডি সরবরাহকারীদের ঘাড় ঘুরিয়ে রাখেন তারা ওপেনআইডি ব্যবহার করুন কারণ তারা "তাদের পরিচয়ের মালিক অন্য কেউ চান না"।

Comments

আমি এই ব্যাখ্যাটি সত্যই পছন্দ করি। যদিও আমি লগইনের শীর্ষে বসে তাদের ওটিপি বাস্তবায়ন দিয়ে আমার শংসাপত্রগুলিকে Google পরিচালনা করতে দিলে আমি বেশি খুশি।

— নাটালি অ্যাডামস 21

Answer 7

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

OpenID একটি অনন্য রূপ নিতে কোনো URI কিছু "OpenID সরবরাহকারী" অর্থাত্ পরিচয় প্রদানকারী (আইডিপি) দ্বারা পরিচালিত।

OAuth XACML এর সাথে একত্রে ব্যবহার করা যেতে পারে যেখানে OAuth মালিকানা অনুমোদনের জন্য এবং প্রতিনিধিদের অ্যাক্সেসের জন্য ব্যবহার করা হয় যেখানে XACML অনুমোদনের নীতিগুলি সংজ্ঞায়িত করতে ব্যবহৃত হয়।

ওআইডিসি সাধারণ জেএসওএন ওয়েব টোকেনস ( জেডাব্লুটি ) ব্যবহার করে, যা আপনি OAuth 2.0 স্পেসিফিকেশন অনুসারে প্রবাহগুলি ব্যবহার করে পেতে পারেন । OAuth এর সরাসরি সম্পর্কিত হয় OIDC যেহেতু OIDC একটি প্রমাণীকরণ স্তর উপরে নির্মিত OAuth এর 2.0 ।

উদাহরণস্বরূপ , আপনি যদি নিজের গুগল অ্যাকাউন্টটি ব্যবহার করে আথ0-এ সাইন ইন করতে পছন্দ করেন তবে আপনি ওআইডিসি ব্যবহার করেন । একবার আপনি সফলভাবে Google সহ প্রমাণীকরণ এবং অনুমোদন Auth0 আপনার তথ্য অ্যাক্সেস করতে, Google এ পাঠাবে Auth0 ব্যবহারকারী সম্পর্কে তথ্য এবং প্রমাণীকরণ সঞ্চালিত। এই তথ্যটি একটি জেএসএন ওয়েব টোকেন (জেডব্লিউটি) এ ফিরে এসেছে । আপনি একটি অ্যাক্সেস টোকেন পাবেন এবং, যদি অনুরোধ করা হয়, একটি আইডি টোকেন পাবেন। টোকেনের প্রকার : উত্স: ওপেনআইডি কানেক্ট

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

Answer 8

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

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

OAuth প্রতিনিধিত্বপ্রাপ্ত অনুমোদনের উদ্দেশ্যে। একটি ক্লায়েন্ট কোনও সরবরাহকারীর সাথে নিবন্ধন করে, যা অনুমোদনের টোকেন সরবরাহ করে যা এটি ব্যবহারকারীর পক্ষ থেকে ক্রিয়া সম্পাদন করতে গ্রহণ করবে।

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

Answer 9

আমি বিশ্বাস করি যে এটি এই প্রশ্নের পুনর্বিবেচনাটি বোধগম্য করে পাশাপাশি মন্তব্যগুলিতেও উল্লেখ করেছে, ওপেনআইডি কানেক্টের প্রবর্তনটি আরও বিভ্রান্তি এনে দিয়েছে।

ওপেনআইডি কানেক্টটি ওপেনআইডি ১.০ / ২.০ এর মতো একটি প্রমাণীকরণ প্রোটোকল তবে এটি আসলে ওআউথ ২.০ এর শীর্ষে নির্মিত, সুতরাং আপনি প্রমাণীকরণ বৈশিষ্ট্য সহ অনুমোদনের বৈশিষ্ট্যগুলি পাবেন। এই (অপেক্ষাকৃত সাম্প্রতিক, তবে গুরুত্বপূর্ণ) নিবন্ধে দুজনের মধ্যে পার্থক্যটি বেশ ভালভাবে ব্যাখ্যা করা হয়েছে: http://oauth.net/articles/authentication/

Answer 10

ওপেনআইডিআইডি, ওআউথ, ওপেনআইডি কানেক্টের মধ্যে পার্থক্যের ব্যাখ্যা:

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

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

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

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

(সূত্র)

ওপেনআইডি কানেক্ট ওপেনআইডি ২.০ এর চেয়ে আলাদা কীভাবে?

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

(সূত্র)

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

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

এটি কোড লিখতে সহজ করে যা ব্যবহারকারীকে একাধিক পরিচয় সরবরাহকারীদের মধ্যে চয়ন করতে দেয়।

(সূত্র)

গুগলের OAuth 2.0

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

(সূত্র)

Comments

সুন্দর ব্যাখ্যা। তার জন্য +1।

— আতাউর রহমান মুন্না

Answer 11

উত্তরের চেয়ে প্রশ্নের আরও প্রসারণ, তবে এটি উপরের দুর্দান্ত প্রযুক্তিগত উত্তরগুলির সাথে কিছু দৃষ্টিকোণ যুক্ত করতে পারে। আমি বেশিরভাগ ক্ষেত্রে অভিজ্ঞ প্রোগ্রামার, তবে ওয়েবের জন্য প্রোগ্রামিংয়ে মোট oo এখন জেন্ড ফ্রেমওয়ার্ক ব্যবহার করে একটি ওয়েব-ভিত্তিক অ্যাপ্লিকেশন তৈরি করার চেষ্টা করছি।

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

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

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

সত্যিই দুর্দান্ত হবে যদি কেউ এই জাতীয় একাধিক তৃতীয়-অংশ অনুমোদনের সেটআপটিকে সমর্থন করার বিষয়ে তথ্য বা পয়েন্টার পোস্ট করতে পারে এবং আপনি যে ব্যবহারকারীদের দ্বারা অনুমোদন প্রত্যাহার করেন বা তাদের তৃতীয় পক্ষের সাইটে অ্যাক্সেস হারিয়ে ফেলেন তাদের সাথে আপনি কীভাবে व्यवहार করেন। আমি এই ধারণাটিও পেয়েছি যে এখানে আমার ব্যবহারকারীর নামটি একটি অনন্য স্ট্যাকওভারফ্লো অ্যাকাউন্ট সনাক্ত করে যা আমি যদি সেট আপ করতে চাইতাম তবে আমি বেসিক প্রমাণীকরণের সাথে অ্যাক্সেস করতে পারি এবং অন্যান্য তৃতীয় পক্ষের প্রমাণীকরণকারীর মাধ্যমেও এই একই অ্যাকাউন্টটি অ্যাক্সেস করতে পারি (উদাহরণস্বরূপ যাতে আমি লগড হিসাবে বিবেচিত হব আমি যদি কোনও গুগল, ফেসবুক বা টুইটার ...) এ লগ ইন করে থাকি তবে স্ট্যাকওভারফ্লোতে প্রবেশ করুন। যেহেতু এই সাইটটি এটি করছে, তাই এখানে কারোরই সম্ভবত এই বিষয়ে কিছুটা ভাল অন্তর্দৃষ্টি রয়েছে। :-)

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

Answer 12

ওপেনআইডি প্রমাণ করে যে আপনি কে।

OAuth অনুমোদনকারী পক্ষের সরবরাহিত বৈশিষ্ট্যগুলিতে অ্যাক্সেসের অনুমতি দেয়।

Comments

OAuth: কিছু বৈশিষ্ট্যে অ্যাক্সেস দেওয়ার আগে, প্রমাণীকরণ করা উচিত, তাই না? সুতরাং ওআউথ = ওপেনআইডি + কিছু বৈশিষ্ট্যে অ্যাক্সেস দেয়?

— হাসান তারেক

Answer 13

আমি বর্তমানে OAuth 2.0 এবং ওপেনআইডি কানেক্ট স্পেকে কাজ করছি। সুতরাং এখানে আমার বোঝার বিষয়: আগে তারা ছিল:

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

2. ওআউথ: ওআউথ এই সমস্ত ধরণের মালিকানাধীন পদ্ধতির দিকে তাকিয়ে একটি স্ট্যান্ডার্ড হিসাবে এটির উত্থান দেখেছিল এবং তাই আমাদের কাছে OAuth 1.o মান হিসাবে ছিল তবে কেবল অনুমোদনের উদ্দেশ্যে addressing অনেক লোক লক্ষ্য করেনি তবে এটি একরকম বাছাই শুরু করেছিল। তারপরে ২০১২ সালে আমাদের OAuth 2.0 ছিল C সিটিওস, আর্কিটেক্টসরা সত্যিই মনোযোগ দেওয়া শুরু করেছিল যেহেতু বিশ্ব ক্লাউড কম্পিউটিংয়ের দিকে এবং কম্পিউটার এবং অন্যান্য ডিভাইসগুলির দিকে কম্পিউটারের ডিভাইসগুলির দিকে এগিয়ে চলেছে। ওআউথ ধরণের একটি বড় সমস্যা সমাধানের দিকে লক্ষ্য করা হয়েছে যেখানে সফ্টওয়্যার গ্রাহকরা কোনও সংস্থাকে আইডিপি পরিষেবা দিতে পারেন এবং বিক্রয় বিক্রেতাদের, এসএপি ইত্যাদির মতো বিভিন্ন বিক্রেতাদের অনেকগুলি পরিষেবা থাকতে পারে, সুতরাং এখানে সংহতকরণ সত্যই ফেডারেশনের দৃশ্যের মতো দেখায়, একটি বড় সমস্যা, এসএএমএল ব্যবহার ব্যয়বহুল is সুতরাং আসুন OAuth 2.o অন্বেষণ করা যাক। ওহ, এই সময়ের মধ্যে একটি গুরুত্বপূর্ণ বিষয়টি মিস করেছেন যে গুগল অনুভূত হয়েছিল যে ওআউথ আসলে 'না'

   ক। OAuth 2.o পরিষ্কারভাবে বলে না, ক্লায়েন্টের নিবন্ধকরণ কীভাবে ঘটবে খ। এটি এসপি (রিসোর্স সার্ভার) এবং ক্লায়েন্ট অ্যাপ্লিকেশন (যেমন বিশ্লেষণ সার্ভার ডেটা সরবরাহকারী যেমন ডেটা ক্লায়েন্ট হিসাবে প্রদর্শিত অ্যাপ্লিকেশন) এর মধ্যে মিথস্ক্রিয়া সম্পর্কে কিছুই উল্লেখ করে না)

প্রযুক্তিগতভাবে এখানে ইতিমধ্যে দুর্দান্ত উত্তর দেওয়া হয়েছে, আমি সংক্ষিপ্ত বিবর্তন দৃষ্টিভঙ্গি দেওয়ার কথা ভেবেছিলাম

Answer 14

ওপেনআইডি প্রমাণীকরণের সাথে ডিল করতে OAuth ব্যবহার করে।

উপমা অনুসারে, এটি নেট। উইন্ডোজ এপিআইয়ের উপর নির্ভর করে। আপনি সরাসরি উইন্ডোজ এপিআই কল করতে পারেন তবে এটি এত বিস্তৃত, জটিল এবং পদ্ধতি যুক্তি এত বিশাল, আপনি সহজেই ভুল / বাগ / সুরক্ষা সমস্যা করতে পারেন।

ওপেনআইডি / ওআউথের সাথে একই। ওপেনআইডি প্রমাণীকরণ পরিচালনা করার জন্য ওআউথের উপর নির্ভর করে তবে একটি নির্দিষ্ট টোকেন (আইডি_ টোকেন), ডিজিটাল স্বাক্ষর এবং নির্দিষ্ট প্রবাহকে সংজ্ঞায়িত করে।

Answer 15

আমি এই প্রশ্নের একটি বিশেষ দিকটি সম্বোধন করতে চাই, যেমনটি এই মন্তব্যে ধরা পড়ে:

OAuth: কিছু বৈশিষ্ট্যে অ্যাক্সেস দেওয়ার আগে, প্রমাণীকরণ করা উচিত, তাই না? সুতরাং ওআউথ = ওপেনআইডি + কিছু বৈশিষ্ট্যে অ্যাক্সেস দেয়? - হাসান মাকারভ 21 জুন 1:57 এ

হ্যা এবং না. উত্তরটি সূক্ষ্ম, তাই আমাকে সহ্য করুন।

OAuth এর প্রবাহ লক্ষ্য সার্ভিস (OAuth এর প্রদানকারী যে) আপনার পুননির্দেশনা, তখন তা হয় সম্ভবত আপনি যে সেবা সহ প্রমাণীকরণ আগে একটি টোকেন ক্লায়েন্ট অ্যাপ্লিকেশন / সেবার হাতি ফিরে আসবে প্রয়োজন হবে। ফলস্বরূপ টোকেন ক্লায়েন্ট অ্যাপ্লিকেশনটিকে প্রদত্ত ব্যবহারকারীর পক্ষ থেকে অনুরোধ করার অনুমতি দেয়।

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

এই ভুল করবেন না।

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

প্রমাণীকরণ হ্যান্ডেল করতে, আপনি সম্ভবত ওপেনআইডি সংযোগটি দেখতে চান যা মূলত OAuth 2.0 দ্বারা সেট করা ফাউন্ডেশনের উপরে থাকা অন্য স্তর another এখানে একটি উদ্ধৃতি যা (আমার মতে) ওপেনআইডি সংযোগ সম্পর্কিত সবচেয়ে গুরুত্বপূর্ণ পয়েন্টগুলি ক্যাপচার করে ( https://oauth.net/articles/authentication/ থেকে ):

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

ওপেনআইডি কানেক্টটি সরাসরি ওআউথ ২.০ এ নির্মিত এবং বেশিরভাগ ক্ষেত্রেই ওআউথ অবকাঠামো বরাবর (বা উপরে) স্থাপন করা হয়। ওপেনআইডি কানেক্টটি বিভিন্ন জায়গায় সাইন ইন এবং এনক্রিপ্ট করা তথ্য বহন করার জন্য নির্দিষ্টকরণের জেএসএন অবজেক্ট সাইনিং অ্যান্ড এনক্রিপশন (জসো) ব্যবহার করে। প্রকৃতপক্ষে, JOSE ক্ষমতা সহ একটি OAuth 2.0 স্থাপনা সম্পূর্ণরূপে সম্মতিযুক্ত ওপেনআইডি সংযোগ সিস্টেমটি সংজ্ঞায়িত করার জন্য একটি দীর্ঘ পথ এবং উভয়ের মধ্যে ব-দ্বীপটি তুলনামূলকভাবে ছোট। তবে এই বদ্বীপটি একটি বড় পার্থক্য করে এবং ওপেনআইডি কানেক্ট ওউথ বেসে কয়েকটি মূল উপাদান যুক্ত করে উপরের আলোচিত অনেকগুলি সমস্যাগুলি এড়াতে পরিচালনা করে: [...]

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

Answer 16

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

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

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

Answer 17

ওপেনআইডি কানেক্টটি প্রমাণীকরণ প্রোটোকল হিসাবে OAuth 2.0 অনুমোদন প্রোটোকলকে প্রসারিত করে, যাতে আপনি OAuth ব্যবহার করে একক সাইন-অন করতে পারেন। ওপেনআইডি কানেক্টটি আইডি টোকেনের ধারণাটি উপস্থাপন করে যা একটি সুরক্ষা টোকেন যা ক্লায়েন্টকে ব্যবহারকারীর পরিচয় যাচাই করতে দেয়

Answer 18

OAuth 2.0 একটি সুরক্ষা প্রোটোকল। এটি একটি অনুমোদনের নিকটবর্তী কোনও অনুমোদন প্রোটোকল।

সংজ্ঞা দ্বারা প্রমাণীকরণ উত্তর দুটি প্রশ্নের উত্তর।

1. ব্যবহারকারী কে?
2. ব্যবহারকারী বর্তমানে সিস্টেমে উপস্থিত আছেন?

OAuth 2.0 এর নিম্নলিখিত অনুদানের ধরণ রয়েছে

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

সমস্ত 4 টির মধ্যে একটি জিনিস সাধারণ, অ্যাক্সেস_ টোকেন, একটি নিদর্শন যা সুরক্ষিত সংস্থান অ্যাক্সেস করতে ব্যবহার করা যেতে পারে।

অ্যাক্সেস টোকেন 2 টি প্রশ্নের উত্তর সরবরাহ করে না যা একটি "প্রমাণীকরণ" প্রোটোকলের অবশ্যই উত্তর দিতে হবে।

ওউথ ২.০ ব্যাখ্যা করার জন্য একটি উদাহরণ (ক্রেডিট: অ্যাকশনে OAuth 2, প্রকাশনা পরিচালনা করা)

চকোলেট সম্পর্কে কথা বলা যাক। আমরা চকোলেট থেকে অনেকগুলি মিষ্টান্ন তৈরি করতে পারি, ফজ, আইসক্রিম এবং কেক সহ। তবে, এগুলির কোনওটিকেই চকোলেটের সমতুল্য করা যায় না কারণ মিষ্টান্ন তৈরি করতে ক্রিম এবং রুটির মতো একাধিক অন্যান্য উপাদানের প্রয়োজন হয়, যদিও চকোলেটটি মূল উপাদানগুলির মতো মনে হয়। একইভাবে, ওআউথ ২.০ হ'ল চকোলেট, এবং কুকিজ, টিএলএস অবকাঠামো, পরিচয় সরবরাহকারী এমন অন্যান্য উপাদান যা "প্রমাণীকরণ" কার্যকারিতা সরবরাহ করার জন্য প্রয়োজনীয়।

আপনি যদি প্রমাণীকরণ চান, আপনি ওপেনআইডি কানেক্টের জন্য যেতে পারেন, যা একটি "আইডি_ টোকেন" সরবরাহ করে, একটি অ্যাক্সেস টোকন ছাড়াও, যা প্রতিটি প্রমাণীকরণ প্রোটোকলের অবশ্যই উত্তর দিতে পারে এমন প্রশ্নের উত্তর দেয়।

Answer 19

OAuth অনুমোদনের শীর্ষে প্রমাণীকরণ তৈরি করে: ব্যবহারকারী তাদের পরিচয়টি অ্যাপ্লিকেশনটিতে অ্যাক্সেস প্রেরণ করে, যা পরে, পরিচয় API এর গ্রাহক হয়ে যায় এবং তারপরে ক্লায়েন্টকে প্রথম স্থানে কতৃত্বীকৃত হয়েছিল তা খুঁজে বের করে http://oauth.net/ প্রবন্ধ / প্রমাণীকরণ /