OAuth অনুমোদন কোড এবং অন্তর্নিহিত কর্মপ্রবাহের মধ্যে পার্থক্য কী? প্রত্যেকটি কখন ব্যবহার করবেন?

Question

OAuth 2.0 এর একাধিক কর্মপ্রবাহ রয়েছে। দুটো সম্পর্কে আমার কয়েকটি প্রশ্ন রয়েছে।

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

সুরক্ষার ক্ষেত্রে দুটি পদ্ধতির মধ্যে পার্থক্য কী? কোনটি আরও সুরক্ষিত এবং কেন?

যখন সার্ভার সরাসরি অ্যাক্সেস টোকেন জারি করতে পারে তখন একটি কাজের প্রবাহে অতিরিক্ত পদক্ষেপ (টোকেনের জন্য বিনিময় অনুমোদনের কোড) যুক্ত করার কারণ আমি দেখছি না।

বিভিন্ন ওয়েবসাইট বলছে যে ক্লায়েন্ট অ্যাপ্লিকেশন শংসাপত্রগুলি সুরক্ষিত রাখতে পারলে অনুমোদনের কোড প্রবাহ ব্যবহৃত হয়। কেন?

Comments

— ওআউথ

Answer 1

access_tokenকি আপনি সুরক্ষিত রিসোর্স (একটি API এর) কল করতে প্রয়োজন হয়। অনুমোদনের কোড প্রবাহে এটি পাওয়ার জন্য দুটি পদক্ষেপ রয়েছে:

1. ব্যবহারকারীর অবশ্যই প্রযোজ্য এবং codeএপিআই গ্রাহককে ("ক্লায়েন্ট" নামে পরিচিত) ফেরত দিতে হবে ।
2. এপিআইয়ের "ক্লায়েন্ট" (সাধারণত আপনার ওয়েব সার্ভার) codeএকটি জন্য প্রাপ্ত 1 টির বিনিময় করে এবং access_tokenনিজেকে client_idএবং এর সাথে প্রমাণীকরণ করেclient_secret
3. তখনই সহ API কল করতে পারেন access_token।

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

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

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

Comments

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

— মোহাম্মদ নিকরওয়ান

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

— ইউজিনিও পেস

আমি জানি যে মূল উত্তরটি 5 বছরেরও বেশি পুরানো, তবে এটি আমি সবচেয়ে সহজ এবং পরিষ্কার ব্যাখ্যাটি পড়েছি। আপনাকে @ ইউজিনিওপেস ধন্যবাদ

— তাহা আহমদ

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

— ড্যানিয়েল ল্যাংডন

ধন্যবাদ! হ্যাঁ, এখানে 3 টি যোগাযোগ চলছে: ব্রাউজার এবং এএস 9 .g উদাঃ ফেসবুক)। এই /authorizeঅনুরোধ। ব্রাউজার এবং ওয়েব সাইট API (কল ক্লায়েন্ট) কে কল করার চেষ্টা করছে। যে redirect_uri+ + codeসফল প্রমাণীকরণ পরে দ্বারা ফিরে আসেন। অবশেষে, ক্লায়েন্ট লোকচক্ষুর অন্তরালে আঃ কলিং, বিনিময় করা codeএকটি জন্য access_token। এই token endpointসাহিত্যে। সাধারণভাবে এএস কখনই কাউকে ডাকে না। এটি সর্বদা জবাব দেয়।

— ইউজিনিও পেস

Answer 2

আমি এখানে এমন কিছু যুক্ত করব যা আমি মনে করি না যে উপরের উত্তরগুলিতে পরিষ্কার হয়ে গেছে:

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

TL; ড আপনি হোল্ড টোকেন ব্যবহারকারীদের মেশিন বিশ্বাস করতে পারি না অন্তর্নিহিত প্রবাহ ব্যবহার করবেন না কিন্তু আপনি কি আপনার নিজের সার্ভার আমাদের বিশ্বাস করেন।

Comments

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

— চিজো

হ্যাঁ, একটি কুকি সুতরাং, ক্রস-সাইট অনুরোধ জালিয়াতির বিরুদ্ধে সুরক্ষিত রাখতে আপনার সার্ভার এবং ব্রাউজার ক্লায়েন্ট সেট আপ করা উচিত।

— মার্সেল

@Marcel আমি জানতে চাই যে একবার আমরা কোড, কিভাবে এবং কোথায় বিনিময় প্রকৃত পেতে ঘটে পেতে access_tokenসাহায্যে authorization code।

— চিরাগ সোনি

Answer 3

উভয়ের মধ্যে পার্থক্য হ'ল:

1. অন্তর্নিহিত প্রবাহে, টোকন সরাসরি "#" চিহ্নের মাধ্যমে ইউআরএল পুনর্নির্দেশের মাধ্যমে ফিরে আসে এবং এটি বেশিরভাগ জাভাস্ক্রিপ্ট ক্লায়েন্ট বা মোবাইল অ্যাপ্লিকেশনগুলিতে ব্যবহৃত হয় যার নিজস্ব সার্ভার সাইড নেই এবং ক্লায়েন্টকে কিছু বাস্তবায়নে তার গোপনীয়তা সরবরাহ করার প্রয়োজন হয় না ।

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

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

Comments

অনুমোদনের কোডটি ফেসবুকের জন্য 10 মিনিটের জন্য সার্ভারের পাশে সংরক্ষণ করা হয়। এটি তাদের ডিসেম্বর 5,2012 পরিবর্তনে প্রকাশিত হয়েছিল। আমার প্রশ্নটি মূলত, সুরক্ষা / পারফরম্যান্সের ক্ষেত্রে 2 এর মধ্যে পার্থক্য কী। উভয় প্রবাহ কী করে তা আমি জানি - তবে অনুমোদনের কোডটি ব্যবহার করার সুবিধা কী - কর্মপ্রবাহে আরও একটি পদক্ষেপ যুক্ত করে।

— Divyanshm

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

— বাসেম রেদা জোহদি

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

— বাসেম রেদা জোহদি

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

— Divyanshm

অ্যাক্সেস টোকেন কখনই শেষ ব্যবহারকারীর মেশিনে পৌঁছায় না? হ্যাঁ, এটি ক্লায়েন্ট অ্যাপ্লিকেশন সার্ভারের সাথে আপনার প্রোফাইলের সাথে যুক্ত।

— বাসেম রেদা জোহদি

Answer 4

অন্তর্ভুক্ত অনুদান দুটি স্বতন্ত্র পার্থক্য সহ অনুমোদনের কোড অনুদানের অনুরূপ।

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

দ্বিতীয়ত অনুমোদনের সার্ভারের পরিবর্তে কোনও অ্যাক্সেস টোকেনের বিনিময় হওয়া কোনও অনুমোদনের কোডটি ফেরত দেওয়ার পরিবর্তে, অনুমোদনের সার্ভারটি অ্যাক্সেস টোকেন দেয় returns

দয়া করে এখানে বিশদটি আবিষ্কার করুন http://oauth2.thephpleague.com/authorization-server/Wich-grant/

Comments

এই লিঙ্কটির জন্য ধন্যবাদ, এটি আমাকে প্রতিটি অনুদানের ধরণের এবং কখন একটি বেছে নেওয়ার মধ্যে পার্থক্য বুঝতে সহায়তা করেছে।

— ফ্রান্সোইস পোয়ার

Answer 5

অন্তর্নিহিত প্রবাহ

সুবিধাদি

• কার্যকর করা সহজ

অসুবিধেও

• ব্রাউজারে দৃশ্যমান অ্যাক্সেস টোকেন
• অ্যাক্সেস টোকেনগুলির উত্স নির্ধারণ করা যায় না
• অ্যাক্সেস টোকেনগুলির মেয়াদ শেষ হতে পারে না (গুগল নীতি দ্বারা)

---

অনুমোদনের কোড প্রবাহ

সুবিধাদি

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

অসুবিধেও

• একাধিক লেখার শেষ পয়েন্টগুলি প্রয়োগ করতে হবে

প্রশংসাপত্র: https://developers.google.com/ferences/develop/identity/oauth2-overview#supported_oauth_20_ প্রবাহ

Answer 6

উপরের উত্তরগুলি থেকে আমি যে পয়েন্টগুলি শিখেছি তার সংক্ষিপ্ত বিবরণ এবং আমার নিজের কিছু বোঝাপড়া যুক্ত করুন।

অনুমোদনের কোড প্রবাহ !!!

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

অন্তর্নিহিত অনুদান প্রবাহ !!!

• যখন আপনার কাছে OAuth ক্লায়েন্ট হিসাবে কাজ করার জন্য ওয়েব অ্যাপ্লিকেশন সার্ভার নেই
• আপনার যদি দীর্ঘকালীন অ্যাক্সেসের প্রয়োজন না হয় তবে কেবলমাত্র ডেটাতে অস্থায়ী অ্যাক্সেস প্রয়োজন।
• আপনার অ্যাপ্লিকেশনটি চালিত ব্রাউজারটিতে যদি আপনি বিশ্বাস করেন এবং অ্যাক্সেস টোকেনটি অবিশ্বস্ত ব্যবহারকারীদের কাছে ফাঁস হয়ে যাবে এমন সীমিত উদ্বেগ রয়েছে।

Answer 7

কোনটি আরও সুরক্ষিত এবং কেন?

উভয়ই সুরক্ষিত, এটি আপনি যে পরিবেশটি ব্যবহার করছেন তার উপর নির্ভর করে।

যখন সার্ভার সরাসরি অ্যাক্সেস টোকেন জারি করতে পারে তখন একটি কাজের প্রবাহে অতিরিক্ত পদক্ষেপ (টোকেনের জন্য বিনিময় অনুমোদনের কোড) যুক্ত করার কারণ আমি দেখছি না।

এটা সহজ. আপনার ক্লায়েন্ট নিরাপদ নয়। এর বিশদ বিবরণ দেখুন।

আপনি এর বিরুদ্ধে একটি অ্যাপ্লিকেশন বিকাশ করছেন তা বিবেচনা করুন Instagram API, সুতরাং আপনার অ্যাপ্লিকেশনটি আপনার সাথে নিবন্ধভুক্ত করুন Instagramএবং যা API'sআপনার প্রয়োজন তা নির্ধারণ করুন । Instagramআপনাকে সরবরাহ করবে client_idএবংclient_secrect

আপনার ওয়েবসাইটে আপনি একটি লিঙ্ক সেট আপ করেছেন যা বলে। "আমার অ্যাপ্লিকেশনটি আসুন এবং ব্যবহার করুন"। এটিতে আপনার ওয়েব অ্যাপ্লিকেশনটিতে ক্লিক করার জন্য দুটি কল করা উচিত Instagram API।

FirstInstagram Authentication Serverনীচের পরামিতিগুলির সাথে একটি অনুরোধ প্রেরণ করুন ।

1. `response_type` with the value `code`
2. `client_id` you have get from `Instagram`
3. `redirect_uri` this is a url on your server which do the second call
4. `scope` a space delimited list of scopes
5. `state` with a CSRF token. 

আপনি প্রেরণ করবেন নাclient_secret , আপনি ক্লায়েন্টকে বিশ্বাস করতে পারেন নি (ব্যবহারকারী এবং তার ব্রাউজার যা আপনাকে অ্যাপ্লিকেশনটি ব্যবহার করার চেষ্টা করে)। ক্লায়েন্টটি ইউআরএল বা জাভা স্ক্রিপ্ট দেখতে এবং আপনার client_secrectসহজেই খুঁজে পেতে পারে। এজন্য আপনার আরও একটি পদক্ষেপ দরকার।

আপনি একটি codeএবং state। codeএখানে temporaryএবং কোন যেখানে সংরক্ষিত হয় না।

তারপরে আপনি একটি secondকল করেন Instagram API(আপনার সার্ভার থেকে)

 1. `grant_type` with the value of `authorization_code`
 2. `client_id` with the client identifier
 3. `client_secret` with the client secret
 4. `redirect_uri` with the same redirect URI the user was redirect back to
 5. `code` which we have already received.

আমাদের সার্ভার থেকে কল করার সাথে সাথে আমরা নিরাপদে ব্যবহার করতে পারি client_secret(যা আমরা কেমন তা দেখায়) codeযা দেখায় যে ব্যবহারকারী client_idসংস্থানটি ব্যবহার করতে মঞ্জুর করেছেন ।

প্রতিক্রিয়া আমাদের হবে access_token

Answer 8

ব্যবহারিক দৃষ্টিকোণ থেকে (আমি যা বুঝতে পেরেছিলাম), আথজ কোড প্রবাহের মূল কারণটি হ'ল:

1. রিফ্রেশ টোকেনের জন্য সমর্থন (ব্যবহারকারীর পক্ষে অ্যাপ্লিকেশনগুলির দ্বারা দীর্ঘমেয়াদী অ্যাক্সেস), অন্তর্নিহিতভাবে সমর্থিত নয়: দেখুন: https://tools.ietf.org/html/rfc6749#section-4.2
2. সম্মতি পৃষ্ঠার জন্য সমর্থন যা এমন এক স্থান যেখানে সংস্থান সংস্থানকারীরা কী অ্যাক্সেস সরবরাহ করতে পারে তা নিয়ন্ত্রণ করতে পারে (গুগলে আপনি যেভাবে অনুমতি / অনুমোদনের পৃষ্ঠায় দেখেন)। নিখুঁতভাবে একই নেই। বিভাগটি দেখুন: https://tools.ietf.org/html/rfc6749#section-4.1 , পয়েন্ট (বি)

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

তা ছাড়া, রিফ্রেশ টোকেন ব্যবহার করে অ্যাপ্লিকেশনগুলি ব্যবহারকারী ডেটাতে দীর্ঘমেয়াদী অ্যাক্সেস পেতে পারে।

Answer 9

দুটি মূল পয়েন্ট রয়েছে বলে মনে হচ্ছে, এখনও অবধি আলোচনা করা হয়নি, যা কেন অনুমোদন কোড অনুদানের ধরণে সুরক্ষা যোগ করে তা ব্যাখ্যা করে।

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

দীর্ঘ সংস্করণ:

নিম্নলিখিতগুলিতে, আমি আরএফসি-তে সংজ্ঞায়িত OAuth 2 পরিভাষাটির সাথে আটকে থাকব (এটি একটি দ্রুত পঠনযোগ্য): রিসোর্স সার্ভার , ক্লায়েন্ট , অনুমোদন সার্ভার , সংস্থান মালিক ।

আপনি গুগল অ্যাকাউন্টের (= রিসোর্স সার্ভার) নির্দিষ্ট ডেটা অ্যাক্সেস করার জন্য কিছু তৃতীয় পক্ষের অ্যাপ্লিকেশন (= ক্লায়েন্ট) চান তা কল্পনা করুন। আসুন ধরে নেওয়া যাক গুগল OAuth 2 ব্যবহার করে You

প্রথমে ক্লায়েন্ট আপনাকে গুগল অনুমোদনের সার্ভারের সুরক্ষিত ইউআরএল প্রেরণ করতে একটি ব্রাউজার খুলবে। তারপরে আপনি অ্যাক্সেসের জন্য অনুরোধটি অনুমোদন করেছেন এবং অনুমোদনের সার্ভার আপনাকে ক্লায়েন্টের পূর্বে প্রদত্ত পুনর্নির্দেশ URL এ क्वेরি স্ট্রিংয়ের অনুমোদনের কোডটি পাঠিয়ে দেয়। এখন দুটি মূল পয়েন্টের জন্য:

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

অনুমোদনের কোড গ্রান্ট প্রকারের সাথে টোকনটি অবশেষে ক্লায়েন্টের কাছ থেকে অনুমোদনের সার্ভারে কল পেয়ে আসে, যেখানে সংক্রমণ সুরক্ষা কেবল ক্লায়েন্টের উপর নয়, অনুমোদনের সার্ভারের উপর নির্ভর করে ।