ওআউথ 2 কীভাবে ওআউথ 1 থেকে আলাদা?

Question

খুব সাধারণ ভাষায়, কেউ OAuth 2 এবং OAuth 1 এর মধ্যে পার্থক্যটি ব্যাখ্যা করতে পারেন?

OAuth 1 কি এখন অচল? আমাদের কি OAuth 2 বাস্তবায়ন করা উচিত? আমি OAuth 2 এর অনেকগুলি বাস্তবায়ন দেখতে পাচ্ছি না; বেশিরভাগ এখনও OAuth 1 ব্যবহার করছেন, যা আমার সন্দেহ করে যে OAuth 2 ব্যবহারের জন্য প্রস্তুত। তাই কি?

Comments

পরিষ্কার করে বলো; stackoverflow.com/questions/9565744/…

— শিক্ষার্থী

যদি আপনি ওআউথের

— ক্রিস ইসমাইল

আপনি এখানে আপনার উত্তর খুঁজে পেতে পারেন OAuth 2.0 - ওভারভিউ

— জন জো

Answer 1

ইরান হ্যামার-লাহাভ তাঁর প্রবন্ধের OAuth 2.0 প্রবন্ধের সর্বাধিক পার্থক্য ব্যাখ্যা করার জন্য একটি দুর্দান্ত কাজ করেছেন । সংক্ষিপ্তসার হিসাবে, এখানে মূল পার্থক্য রয়েছে:

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

OAuth 2.0 এর আর ক্রেডিটোগ্রাফি থাকার জন্য ক্লায়েন্ট অ্যাপ্লিকেশনগুলির আর প্রয়োজন নেই। এটি পুরাতন টুইটার এথ এপিআই-এ ফিরে আসে, যার HMAC হ্যাশ টোকেন এবং অনুরোধ স্ট্রিংগুলিতে অ্যাপ্লিকেশনটির প্রয়োজন হয় না। OAuth 2.0 এর সাথে, অ্যাপ্লিকেশনটি কেবল জারি করা টোকেনটি এইচটিটিপিএস ব্যবহার করে একটি অনুরোধ করতে পারে।

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

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

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

Comments

কেউ কি স্পষ্ট করতে পারেন যে কীভাবে কলব্যাক url গুলি ওউথ 1 এবং 2 এর মধ্যে আলাদা?

— ব্রায়ান আর্মস্ট্রং

এটি যদি আরএফসি হিসাবে অনুমোদিত হয় তবে OAuth 2.0 কেবলমাত্র অউথিউটকেই বাতিল করবে। বর্তমানে এটি একটি ইন্টারনেট খসড়া, তবে এটি একটি ইন্টারনেট স্ট্যান্ডার্ড হওয়ার পরিকল্পনা করা হয়েছে (যতদূর এই বিষয়গুলি পরিকল্পনা করা যায়)। তবে, এটি বেশ কয়েক বছর সময় নেবে, যেহেতু কাঠামোর বড় অংশগুলি এখনও নির্দিষ্ট করা হয়নি। আমরা সম্ভবত আসন্ন বছরগুলিতে ইন্টারনেট ড্রাফ্টগুলির একটি পুরো পরিবার প্রকাশিত হতে দেখব, প্রতিটি প্রত্যেকে OAuth 2.0 অনুমোদনের কাঠামোর বিভিন্ন দিক সম্পর্কিত। কেন এই সত্য সফর দেখার জন্য tools.ietf.org/html/draft-ietf-oauth-v2 "এই স্পেসিফিকেশন পরিধি বহির্ভূত", এবং অনুসন্ধান;)

— Håvard Geithus,

নিবন্ধটির লেখক গত বছর "ওআউথ ২.০ এবং দ্য রোড টু হেল" নামে একটি ফলোআপ লিখেছিলেন, যা এখানে পড়তে পারেন: web.archive.org/web/20120731155632/http://hueniverse.com/2012/… দুটির মধ্যে একটি উল্লেখযোগ্য পার্থক্য হ'ল সুরক্ষা - যেমনটি 2.0 তে ক্রিপ্টোগ্রাফির অভাব দ্বারা পূর্বনির্ধারিত।

— kdazzle

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

— টাকাহিকো কাওয়াসাকি

@ কেডাজল, সেই লিঙ্কটি এখন এখানে চলে গেছে: hueniverse.com/oauth-2-0-

— এবং-

Answer 2

আমি এখানে দুর্দান্ত উত্তরগুলি দেখতে পাচ্ছি তবে যা আমি মিস করছি সেগুলি কয়েকটি চিত্র ছিল এবং যেহেতু স্প্রিং ফ্রেমওয়ার্কের সাথে আমাকে কাজ করতে হয়েছিল আমি তাদের ব্যাখ্যাটি পেরিয়ে এসেছি ।

আমি নিম্নলিখিত চিত্রগুলি খুব দরকারী বলে মনে করি। তারা OAuth2 এবং OAuth1 এর সাথে দলগুলির মধ্যে যোগাযোগের পার্থক্যের চিত্রিত করে।

---

ওআউথ 2

---

ওআউথ ঘ

Comments

এই প্রবাহে "ক্লায়েন্ট_সেক্রেট" কোথায় ব্যবহৃত হয় ??

— অশ্বতান্ত্রিক

যদি আপনি বোঝাতে চান যে ব্যবহারকারী যখন সরবরাহকারীর দিকে পুনঃনির্দেশিত হয় তখন ব্যবহারকারীরা প্রবেশ করান (তবে ফেসবুক, টুইটার, গুগল ইত্যাদি বলুন) তবে এটি পদক্ষেপ 2 OAuth 2এবং এর জন্য পদক্ষেপ 4 হবে OAuth 1।

— nyxz

উভয় চিত্রের কেন "সরবরাহকারীর অনুমোদন অনুমোদন" নামে একটি পরিষেবা সরবরাহকারী পদক্ষেপ রয়েছে? এটি পিছনে বা ভুল বলে মনে হচ্ছে। অনুমোদনের সন্ধানকারী "ব্যবহারকারী" নয় কি?

— ফোর্বিন

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

— nyxz

Answer 3

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

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

Comments

সুতরাং মূলত ওআউথ 2 এইচটিটিপিএসের সাথে কাজ করে এবং তাই ওআউথ 1 এর চেয়ে সহজ যা এইচটিটিপিএস ছাড়াই কাজ করতে পারে তার জন্য আরও জটিল হওয়া দরকার?

— মাইক্রো

@ মাইক্রোআর এটি একটি ব্যবহারিক সংজ্ঞা যা আপনি সেখানে এসেছেন! ;)

— এরালপবি

Answer 4

নোট করুন Oauth 2 ব্যবহারের বিরুদ্ধে গুরুতর সুরক্ষা যুক্তি রয়েছে:

একটি বিরক্তিকর নিবন্ধ

এবং আরও প্রযুক্তিগত এক

নোট করুন এগুলি Oauth 2 এর প্রধান লেখক থেকে আসছে।

গুরুত্বপূর্ণ দিক:

• Oauth 2 এসএসএলের শীর্ষে কোনও সুরক্ষা দেয় না যখন Oauth 1 পরিবহন-স্বাধীন।

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

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

• আপনি আপনার সমস্ত সুরক্ষা মুছে ফেলতে পারেন, যা OAuth 1.0 এ করা খুব কঠিন:

  দ্বিতীয় সাধারণ সম্ভাব্য সমস্যাটি টাইপস। কোনও অক্ষর ('https' তে 's') বাদ দিলে আপনি কি এটিকে একটি উপযুক্ত নকশা হিসাবে বিবেচনা করবেন? অথবা সম্ভবত অনুরোধটি (একটি বৈধ ও যাচাইকৃত এসএসএল / টিএলএস সংযোগের মাধ্যমে) ভুল গন্তব্যে প্রেরণ করা হয়েছে (' http://gacebook.com ' বলুন?)। মনে রাখবেন, কমান্ড লাইন থেকে OAuth বহনকারী টোকেন ব্যবহার করতে সক্ষম হলেন স্পষ্টতই ব্যবহারের ক্ষেত্রে বহনকারী টোকেনের পক্ষে ছিলেন।

Comments

"টাইপো" যুক্তিটি খুব বৈধ নয় - এটি HTTP থেকে https এ পুনঃনির্দেশ করা সাধারণ অনুশীলন

— ওলেগ মিখিভ

@ ওলেগমিখিভ হ্যাঁ, তবে কোনও এমআইটিএমকে আপনার শিরোনামগুলি স্নিগ্ধ করার অনুমতি দেওয়ার জন্য এটি কেবলমাত্র একটি http (নো-এস) অনুরোধ করে এবং আপনার টোকেনটি এখন অন্য কেউ ব্যবহার করছেন!

— প্যাট্রিক জেমস ম্যাকডুগল

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

— ওলেগ মিখিভ

"টাইপো" যুক্তিটির বিপরীতে অতিরিক্ত পয়েন্ট হিসাবে, কোনও পরিষেবা সরবরাহকারী যে কোনও ওআউথ 2.0 অনুরোধগুলি https এর মাধ্যমে নয় এবং সেই অনুরোধে অ্যাক্সেস টোকেনটি প্রত্যাহার করতে পারে।

— skeller88

Answer 5

OAuth 1.0 প্রোটোকলের সুরক্ষা ( আরএফসি 5849 ) একটি ক্লায়েন্ট অ্যাপ্লিকেশনটিতে এম্বেড করা একটি গোপন কী গোপনীয় রাখা যেতে পারে এই ধারণার উপর নির্ভর করে। তবে অনুমান নিরীহ।

ওআউথ ২.০ ( আরএফসি 6749 ) এ, এই ধরণের নিষ্পাপ ক্লায়েন্ট অ্যাপ্লিকেশনকে একটি গোপনীয় ক্লায়েন্ট বলা হয় । অন্যদিকে, এমন একটি পরিবেশে ক্লায়েন্ট অ্যাপ্লিকেশন যেখানে গোপনীয় কী গোপনীয় রাখা কঠিন, তাকে পাবলিক ক্লায়েন্ট বলা হয় । ২.১ দেখুন । বিশদ জন্য ক্লায়েন্ট প্রকার ।

সেই অর্থে, OAuth 1.0 শুধুমাত্র গোপনীয় ক্লায়েন্টদের জন্য একটি স্পেসিফিকেশন।

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

এছাড়াও, আরএফসি 5849 (OAuth 1.0) ওপেন পুনর্নির্দেশকারীদের সম্পর্কে কিছুই উল্লেখ করে না যখন আরএফসি 6749 (OAuth 2.0) করে। অর্থাৎ, oauth_callbackOAuth 1.0 এর প্যারামিটারটি সুরক্ষা গর্তে পরিণত হতে পারে।

অতএব, আমি মনে করি না যে OAuth 1.0 OAuth 2.0 এর চেয়ে বেশি সুরক্ষিত।

---

^{[এপ্রিল 14, 2016] আমার বক্তব্য স্পষ্ট করার জন্য সংযোজন}

OAuth 1.0 সুরক্ষা স্বাক্ষর গণনার উপর নির্ভর করে। একটি স্বাক্ষর একটি গোপন কী ব্যবহার করে গণনা করা হয় যেখানে একটি গোপন কীটি এইচএমএসি-এসএএএ 1 ( আরএফসি 5849, 3.4.2 ) বা আরএসএ-এসএএএএ 1 ( আরএফসি 5849, 3.4.3 ) এর জন্য একটি ব্যক্তিগত কী রয়েছে shared যে কেউ গোপন কী জানে সে স্বাক্ষর গণনা করতে পারে। সুতরাং, যদি গোপন কীটি আপোস করা হয় তবে স্বাক্ষর গণনার জটিলতা অর্থহীন তবে তা জটিল।

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

তেমনি, OAuth 2.0 গোপনীয় ক্লায়েন্টরা একই শর্তের উপর নির্ভর করে। শর্তটি ইতিমধ্যে সন্তুষ্ট থাকলে, সুরক্ষিত সংযোগের মাধ্যমে টিএলএস ব্যবহার করে কোনও সুরক্ষিত সংযোগ তৈরি client_idএবং client_secretকোনও অনুমোদনের সার্ভারে কোনও সমস্যা আছে কি? যদি উভয়ই একই শর্তে নির্ভর করে তবে OAuth 1.0 এবং OAuth 2.0 গোপনীয় ক্লায়েন্টের মধ্যে সুরক্ষা স্তরের কোনও বড় পার্থক্য রয়েছে?

আমি OAuth 2.0 এর জন্য OAuth 2.0 কে দোষ দেওয়ার জন্য কোনও ভাল কারণ খুঁজে পাচ্ছি না। আসল কথাটি হ'ল (১) OAuth 1.0 শুধুমাত্র গোপনীয় ক্লায়েন্টদের জন্য একটি স্পেসিফিকেশন এবং (২) OAuth 2.0 গোপনীয় ক্লায়েন্ট এবং সমর্থিত পাবলিক ক্লায়েন্টগুলির জন্য প্রোটোকলটিও সহজ করেছে । এটি সুপরিচিত বা না জানা যাই হোক না কেন, স্মার্টফোন অ্যাপ্লিকেশনগুলি সর্বজনীন ক্লায়েন্ট ( আরএফসি 6749, 9 ) হিসাবে শ্রেণীবদ্ধ করা হয় , যা OAuth 2.0 থেকে উপকৃত হয়।

Comments

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

— মার্ক জি।

Answer 6

টোকনটি তৈরি হওয়ার পরে আসল এপিআই কলগুলির জন্য OAuth 2.0 স্বাক্ষর প্রয়োজন হয় না। এটিতে কেবল একটি সুরক্ষা টোকেন রয়েছে।

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

এখানে OAuth 1.0 এবং 2.0 এর মধ্যে পার্থক্য এবং উভয় কীভাবে কাজ করে তা বর্ণনা করে।

Answer 7

OAuth 2 স্পষ্টতই সময় নষ্ট করা (এমন কারও মুখ থেকে যে এতে জড়িত ছিল):

https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529

তিনি বলেছেন (ব্রিভিটির জন্য সম্পাদিত এবং জোরের জন্য সাহসী):

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

... শেষে, আমি এই সিদ্ধান্তে পৌঁছেছি যে OAuth 2.0 একটি খারাপ প্রোটোকল। ডাব্লুএস- * খারাপ। এটি যথেষ্ট খারাপ যে আমি এর সাথে আর যুক্ত হতে চাই না। ... OAuth 1.0 এর সাথে তুলনা করা হলে, 2.0 স্পেসিফিকেশনটি আরও জটিল, কম ইন্টারঅ্যাপেবল, কম দরকারী, আরও অসম্পূর্ণ এবং সবচেয়ে গুরুত্বপূর্ণ, কম সুরক্ষিত।

স্পষ্টতই, ওয়েব সুরক্ষার গভীর উপলব্ধি সহ কোনও বিকাশকারীর হাতের OAuth 2.0 সম্ভবত একটি নিরাপদ বাস্তবায়ন ফলাফল। তবে, বেশিরভাগ বিকাশকারীদের হাতে - যেমন গত দুই বছর থেকে অভিজ্ঞতা হয়েছে - ২.০ অসুরক্ষিত বাস্তবায়ন তৈরি করার সম্ভাবনা রয়েছে।

Comments

মনে রাখবেন যে লিঙ্ক-কেবল উত্তর নিরুৎসাহিত করা হয়, উল্লেখগুলি সময়ের সাথে সাথে বাসি হয়ে যায়। রেফারেন্স হিসাবে লিঙ্কটি রেখে এখানে দয়া করে এখানে একা একা সংক্ষিপ্তসার বিবেচনা করুন।

— ক্লিওপাত্র

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

— তাকাহিকো কাওয়াসাকি

Answer 8

আপনার যদি কিছু উন্নত ব্যাখ্যা প্রয়োজন হয় তবে আপনার উভয় স্পেসিফিকেশন পড়তে হবে:

https://oauth.net/core/1.0a/

https://oauth.net/2/

আপনার যদি প্রবাহের পার্থক্যগুলির স্পষ্ট ব্যাখ্যা প্রয়োজন হয় তবে এটি আপনাকে সহায়তা করতে পারে:

OAuth 1.0 প্রবাহ

1. ক্লায়েন্ট অ্যাপ্লিকেশন যেমন সরবরাহকারীর সাথে নিবন্ধন করে।
2. টুইটার ক্লায়েন্টকে সেই "অ্যাপ্লিকেশনটির জন্য অনন্য" গ্রাহক গোপনীয়তা সরবরাহ করে।
3. ক্লায়েন্ট অ্যাপ্লিকেশন তার অনন্য "গ্রাহক গোপন" দিয়ে টুইটারে সমস্ত OAuth অনুরোধগুলিতে স্বাক্ষর করে ।
4. যদি ওএউথের অনুরোধটি কোনও ত্রুটিযুক্ত, ডেটা হারিয়ে যাওয়া বা ভুলভাবে স্বাক্ষরিত হয়, তবে অনুরোধটি প্রত্যাখাত হবে।

OAuth 2.0 প্রবাহ

1. ক্লায়েন্ট অ্যাপ্লিকেশন যেমন সরবরাহকারীর সাথে নিবন্ধন করে।
2. টুইটার ক্লায়েন্টকে সেই "ক্লায়েন্ট সিক্রেট" সরবরাহ করে যা এই অ্যাপ্লিকেশনটির কাছে অনন্য।
3. ক্লায়েন্ট অ্যাপ্লিকেশনটিতে "ক্লায়েন্ট সিক্রেট" অন্তর্ভুক্ত থাকে প্রতিটি অনুরোধের সাথে সাধারণত http শিরোনাম হিসাবে।
4. যদি ওএউথের অনুরোধের কোনওটি ত্রুটিযুক্ত, ডেটা অনুপস্থিত বা ভুল গোপন থাকে তবে অনুরোধটি প্রত্যাখাত হবে।

সূত্র: https://codiscope.com/oauth-2-0-vs-oauth-1-0/

Comments

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

— JRichardsz

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

— saran3h

12 বিকাশকারী এটি পেয়েছেন। oauth1 এবং oauth2 এর অনেক পার্থক্য রয়েছে। পূর্ববর্তী উত্তরগুলি তাদের কভার করে এবং যেমনটি আমি বলেছিলাম , নিজের উত্তর তৈরি করতে আপনি এই oauth.net/core/1.0a বা এই oauth.net/2 পড়তে পারেন । যখন কোনও বিকাশকারীকে বিশ্রাম ক্লায়েন্ট বিকাশ করা দরকার তখন আমার লক্ষ্যটি সবচেয়ে কুখ্যাত প্রযুক্তিগত পার্থক্যগুলির মধ্যে একটি দেখাচ্ছে ।

— জে রিচার্ডস্

Answer 9

OAuth 2.0 নিম্নলিখিত পদ্ধতিতে জিনিসগুলিকে সহজ করার প্রতিশ্রুতি দিয়েছে:

1. টোকেন তৈরির জন্য প্রয়োজনীয় সমস্ত যোগাযোগের জন্য এসএসএল প্রয়োজনীয়। জটিলতায় এটি একটি বিশাল হ্রাস কারণ এই জটিল স্বাক্ষরগুলির আর প্রয়োজন নেই।
2. টোকেনটি তৈরি হয়ে গেলে আসল এপিআই কলগুলির জন্য স্বাক্ষর প্রয়োজন হয় না - এসএসএলকেও এখানে দৃ strongly়ভাবে সুপারিশ করা হয়।
3. টোকেনটি তৈরি হওয়ার পরে, ওআউথ ১.০ প্রয়োজনীয় ছিল যে ক্লায়েন্টটি প্রতিটি এপিআই কলগুলিতে দুটি সুরক্ষা টোকেন প্রেরণ করে এবং স্বাক্ষর উত্পন্ন করতে উভয়ই ব্যবহার করে। OAuth 2.0 এর একটি মাত্র সুরক্ষা টোকেন রয়েছে এবং কোনও স্বাক্ষরের প্রয়োজন নেই।
4. প্রোটোকলের কোন অংশগুলি "রিসোর্স মালিক" দ্বারা প্রয়োগ করা হয় তা স্পষ্টভাবে নির্দিষ্ট করা হয়েছে যা প্রকৃত সার্ভার যা এপিআই প্রয়োগ করে এবং কোন অংশগুলি পৃথক "অনুমোদন সার্ভার" দ্বারা প্রয়োগ করা যেতে পারে। এটি অ্যাপিগির মতো পণ্যগুলির জন্য বিদ্যমান এপিআইগুলিতে OAuth 2.0 সমর্থন সরবরাহ করা সহজ করবে।

সূত্র: http://blog.apigee.com/detail/oauth_differences

Answer 10

সুরক্ষার দৃষ্টিকোণ থেকে, আমি OAuth 1 এ যাব See OAuth 2.0 এবং জাহান্নামের রাস্তা

এই লিঙ্কটি থেকে উদ্ধৃতি: "আপনি যদি বর্তমানে সফলভাবে 1.0 ব্যবহার করছেন, 2.0 কে উপেক্ষা করুন। এটি 1.0 এর চেয়ে বেশি কোনও মূল্য দেয় না (আমি অনুমান করছি যে আপনার ক্লায়েন্ট বিকাশকারীরা ইতিমধ্যে ইতিমধ্যে 1.0 স্বাক্ষরগুলি বের করে ফেলেছেন)।

আপনি যদি এই স্থানটিতে নতুন হন এবং নিজেকে সুরক্ষা বিশেষজ্ঞ হিসাবে বিবেচনা করেন তবে এর বৈশিষ্ট্যগুলি যত্ন সহকারে পরীক্ষা করার পরে 2.0 ব্যবহার করুন। আপনি যদি বিশেষজ্ঞ না হন তবে হয় 1.0 ব্যবহার করুন বা এটি ঠিক করার জন্য আপনার বিশ্বাসী কোনও সরবরাহকারীর 2.0 বাস্তবায়ন অনুলিপি করুন (ফেসবুকের এপিআই ডকুমেন্টগুলি শুরু করার জন্য ভাল জায়গা)। ২.০ বড় আকারের জন্য ভাল তবে আপনি যদি কোনও বড় অপারেশন চালাচ্ছেন তবে আপনার পক্ষে এটি সন্ধান করার জন্য আপনার কাছে সম্ভবত কিছু নিরাপত্তা বিশেষজ্ঞ রয়েছে ""