OAuth 2 এ অন্তর্ভুক্ত অনুদান অনুমোদনের ধরণের উদ্দেশ্য কী?


254

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

উভয় প্রবাহই একইরকম শুরু হয় (উত্স: http://tools.ietf.org/html/draft-ietf-oauth-v2-22 ):

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

এখানে যেখানে প্রবাহ বিভক্ত হয়। উভয় ক্ষেত্রেই পুনঃনির্দেশের ইউআরআই এই সময়ে ক্লায়েন্ট দ্বারা হোস্ট করা কিছু শেষ পয়েন্টে:

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

সুতরাং আমার প্রশ্ন: ক্লায়েন্ট প্রমাণীকরণের পদক্ষেপ এড়িয়ে এখানে কী অর্জন করা হয়েছে?


এটি দেখুন: আইবিএম
হাভার্ড

5
আগের মন্তব্যে লিঙ্কটি মারা গেছে। এখানে একটি আপডেট হয়েছে
অ্যান্ড্রুআর

3
আমি এখানে সমস্ত উত্তর পড়েছি, তবে আমি এখনও বুঝতে পারি না যে অ্যাক্সেস টোকেন পেতে কোনও ব্যক্তিগত ক্লায়েন্টের গোপনীয়তা কীভাবে সুরক্ষিত হতে পারে। আসুন আমরা বিশ্বাস করি যে বিশ্বাসযোগ্য অ্যাপ্লিকেশনটি বিশ্বাসযোগ্য গ্রান্ট ব্যবহার করে এটির অনুমতি দেয় (টুইটার ওআউথ ব্যবহার করে বলুন) এটি দেওয়া উচিত ট্রাস্টডপপুলার অ্যাপ্লিকেশনটি usted যদি আমি এভিল অ্যাপডোপলবার হয় তবে কোনও অ্যাপ্লিকেশন তৈরি করতে আমাকে কী থামাতে হবে যা কোনও ট্রান্সডপলপুলার অ্যাপ্লিকেশনকে একটি অন্তর্নিহিত অনুদানের অনুরোধে ক্লায়েন্ট_আইড হিসাবে পাস করে এবং তারপরে ব্যবহারকারীর পক্ষে ক্রিয়াকলাপ (যেমন একটি ফিড স্প্যামিংয়ের মতো) সম্পাদন করে, এখন দেখে মনে হচ্ছে তারা বিশ্বাসযোগ্যপোপুলার অ্যাপ্লিকেশন থেকে আসছে ?
অ্যাডওয়াইন

অ্যাডভাইন হিসাবে আমি একই জিনিস অবাক। তবে, সম্ভবত এমন অ্যাপ্লিকেশনগুলির জন্য যা অন্তর্নিহিত অনুদানের অনুরোধের প্রয়োজন, আরও সমস্ত প্রমাণীকরণের প্রয়োজন নেই, কারণ সেগুলি সবই পেয়েছে?
ম্যাভ

13
@ অ্যাডভাইন আপনার দৃশ্যে অ্যাভিল অ্যাপকে টুইটারে ট্রাষ্টডপপুলার অ্যাপ্লিকেশন হিসাবে অনুমোদন দেওয়া থেকে বিরত রাখবে তা হ'ল এটি টুইটার থেকে কলব্যাকগুলি গ্রহণ করতে পারে না, ক্লায়েন্ট আইডি নিবন্ধিত করার সময় তাদের সর্বদা সংজ্ঞায়িত ইউআরআইতে প্রেরণ করা হত
ইভান

উত্তর:


196

আমার মতামত এখানে:

অনুমোদনের কোড প্রবাহে প্রমাণীকরণের কোড + টোকেনের উদ্দেশ্য হ'ল টোকেন এবং ক্লায়েন্টের গোপনীয়তা কখনই উত্সের মালিকের কাছে প্রকাশিত হবে না কারণ তারা সার্ভার-টু-সার্ভার ভ্রমণ করে।

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

সুতরাং উত্তর "কি অর্জন করা হয়েছে?" "সরলতা"।


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

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

2
এটি কেবল অর্ধেক উত্তর দেয় এবং "কী হারিয়ে গেছে"?
এরালপবি

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

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

94

এটি সুরক্ষার কারণে, সরলতার জন্য নয়।

আপনার ব্যবহারকারী এজেন্ট এবং ক্লায়েন্টের মধ্যে পার্থক্যটি বিবেচনা করা উচিত :

ব্যবহারকারী-এজেন্ট এমন একটি সফ্টওয়্যার যার মাধ্যমে ব্যবহারকারী ("রিসোর্স মালিক") সিস্টেমের অন্যান্য অংশগুলির সাথে যোগাযোগ করে (প্রমাণীকরণের সার্ভার এবং সংস্থান সার্ভার)।

ক্লায়েন্টটি এমন সফ্টওয়্যার যা ব্যবহারকারীর সংস্থানগুলি সার্ভারে অ্যাক্সেস করতে চায়।

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

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


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

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

আপনার ব্যাখ্যার জন্য ধন্যবাদ তবে আমার আরও একটি বিভ্রান্তি আছে। আমাদের "অনুমোদন কোড" প্রবাহ কেন দরকার তা আমি বুঝতে পারি না। অন্তর্নিহিত প্রবাহ (অ্যাক্সেস_ টোকেন) এবং একটি রিফ্রেশ টোকেন দিয়ে আমরা সার্ভারে একই ফলাফলটিতে পৌঁছাতে পারি। অন্তর্নিহিত প্রবাহের একমাত্র সুরক্ষার বিবেচনাটি হ'ল অ্যাক্সেস_কোডের স্বল্প জীবন হওয়া উচিত যাতে এটি সার্ভারে সার্ভারে ব্যবহার করা যায় না। ঠিক আছে, তবে রিফ্রেশ টোকেন এই সমস্যার সমাধান করে। কেন আমরা একটি auth_code প্রবাহ ব্যবহার করব এবং অ্যাক্সেস_কোড পাওয়ার জন্য সার্ভারে সেই টোকেনের মাধ্যমে অ্যাক্সেস_ টোকেনের অনুরোধ করা উচিত আমরা রিফ্রেশ_ টোকেন দিয়ে একই ফলাফলটি অর্জন করতে পারি?
মোহাম্মদ নিকরওয়ান

"অন্যান্য অ্যাপ্লিকেশন দ্বারা টোকেন সহজেই নেওয়া যেতে পারে" কীভাবে?
এমভিএমএন

উত্তর জন্য চেহারা @MohammadNikravan stackoverflow.com/q/13387698/355438
Lu55

60

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

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

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

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

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

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


21

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

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

সুরক্ষা সংক্রান্ত প্রভাবগুলি অবশ্য তাৎপর্যপূর্ণ। Http://tools.ietf.org/html/rfc6749#section-10.3 থেকে :

অন্তর্নিহিত অনুদান প্রকারটি ব্যবহার করার সময়, অ্যাক্সেস টোকেনটি ইউআরআই খণ্ডে প্রেরণ করা হয়, যা এটি অননুমোদিত পক্ষগুলিতে প্রকাশ করতে পারে।

Http://tools.ietf.org/html/rfc6749#section-10.16 থেকে :

কোনও রিসোর্স মালিক কোনও আক্রমণকারীর দূষিত ক্লায়েন্টকে অ্যাক্সেস টোকন প্রদান করে স্বেচ্ছায় একটি সংস্থার অ্যাক্সেসের প্রতিনিধি দিতে পারেন। এটি ফিশিং বা অন্য কোনও অজুহাতে হতে পারে ...


"সার্বজনীন", (জাভাস্ক্রিপ্ট) ওয়েব অ্যাপ্লিকেশনটি কোনও সার্ভার সাইড উপাদান ছাড়াই আপনার অর্থ কী? সার্ভার ছাড়া ওয়েব অ্যাপ্লিকেশন কীভাবে থাকতে পারে?
জম্মি পৃষ্ঠা

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

13

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

ড্যান তাফলিন বলেছেন:

... অনুমোদনের কোড প্রবাহে রিসোর্স মালিককে অ্যাক্সেস টোকেন কখনই দেখার দরকার হয় না, যেখানে জাভাস্ক্রিপ্ট ক্লায়েন্টগুলিতে যেটি অনিবার্য। অনুমোদনের কোড প্রবাহটি ব্যবহার করে জাভাস্ক্রিপ্ট ক্লায়েন্টদের কাছ থেকে ক্লায়েন্টের গোপনীয়তা এখনও রাখা যেতে পারে ..

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


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

প্রকৃতপক্ষে গৃহীত উত্তর আমাকে বিভ্রান্ত করেছে। আমাকে ক্লায়েন্ট_সেক্রেট কী বলে ভুল বুঝে ফেলেছে! এই উত্তর এবং উপরের মন্তব্য স্পট হয়।
সারস্পারিলা

9

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

আইইটিএফ ওআউথ মেলিং তালিকায় 2017 আলোচনা এই প্রয়োগকারীদের থেকে উপলভ্য:

এখানে আরও পড়ুন:

অন্তর্ভুক্তটি আগে কোনও গোপন ব্যতীত ক্লায়েন্টদের জন্য সুপারিশ করা হয়েছিল, তবে কোনও গোপনীয়তা ছাড়াই অনুমোদন কোড অনুদান ব্যবহার করে বরখাস্ত করা হয়েছে।

...

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

অন্তর্ভুক্ত গ্রান্ট থেকে ক্লায়েন্ট সিক্রেট ছাড়াই আথ কোডে সরানো এখানে মোবাইল অ্যাপ্লিকেশনের জন্যও উল্লেখ করা হয়েছে:


আমি মনে করি আপনি এই সুপারিশটি যত্নবান হতে চান। স্পা না দিয়ে নেটিভ অ্যাপ্লিকেশনগুলির জন্য গাইডেন্সে এটি প্রস্তাবিত হয়েছিল। দুর্ভাগ্যক্রমে এসপিএগুলিতে অনেকগুলি অনলাইন আলোচনা, ফোরাম এবং এমনকি oauth-wg মেলিং তালিকায় দলিল হিসাবে ভাল গাইডেন্স নেই।
টম

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

মোটামুটি সাম্প্রতিক (2018) oauth-wg আলোচনা এখানে পাওয়া যাবে ietf.org/mail-archive/web/oauth/current/msg18020.html । আরএফসি 8252 নেটিভ অ্যাপ্লিকেশনগুলির জন্য যেমন শিরোনামটি "নেটিভ অ্যাপ্লিকেশনগুলির জন্য ওআউথ 2.0" পরামর্শ দেয় sugges রেডহাট, ডিটি, স্মার্ট হেলথ আইটির উল্লেখগুলি একটি মেলিং তালিকার আলোচনার প্রতিক্রিয়া, একটি আরএফসি নয়, কার্য খসড়া ইত্যাদি ...
টম

3

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


3

অন্তর্নিহিত প্রবাহে যদি ব্যবহারকারীর ব্রাউজারটি দূষিত হয় (মন্দ প্রসারণ / ভাইরাস) তবে দুর্নীতিটি ব্যবহারকারীর সংস্থানগুলিতে অ্যাক্সেস পেতে পারে এবং খারাপ জিনিসগুলি করতে পারে।

প্রমাণ প্রবাহে দুর্নীতি করতে পারে না কারণ এটি ক্লায়েন্টের গোপনীয়তা জানে না।


2

https://tools.ietf.org/html/rfc6749#page-8

অন্তর্নিহিত

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

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

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


1

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


1

অন্তর্ভুক্ত অনুদান অনুমোদনের শেষ পয়েন্ট থেকে টোকেন প্রাপ্ত করার অনুমতি দেয় একটি সহGET । এর অর্থ অনুমোদনের সার্ভারকে CORS সমর্থন করতে হবে না।

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

Icallyতিহাসিকভাবে অন্তর্ভুক্ত প্রবাহটি প্রয়োগ করার অন্যান্য কারণ ছিল তবে মনে হয় অনুমোদনের কোড অনুদান প্রদানের সুরক্ষার সুবিধাগুলির দ্বারা তারা বর্তমানে ছাড়িয়ে গেছে:

  • গোপনীয় ক্লায়েন্টদের জন্য ব্যাক-চ্যানেলে টোকেনগুলি সরবরাহ ও ব্যবহারের বিকল্প
  • জনসাধারণের ক্লায়েন্টদের জন্য ব্রাউজারের ইতিহাসে টোকেনগুলি প্রকাশ করা নয়
  • টোকেন জারি করার আগে অননুমোদিত প্রবাহকে বাধা দেওয়া - "সকল ধরণের OAuth ক্লায়েন্ট" এর জন্য PKCE সহ

0

আমি স্রেফ OAuth 2.0 সম্পর্কে কিছু নিবন্ধের মুখোমুখি হয়েছি। লেখক বলেছেন যে অন্তর্নিহিত প্রবাহের পিছনে কারণ হ'ল জেএস অ্যাপ্লিকেশনগুলি সেখানে অনুরোধে খুব সীমাবদ্ধ ছিল:

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

https://medium.com/securing/what-is-going-on-with-oauth-2-0-and-why-you-should-not-use-it-for-authentication-5f47597b2611

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.