JWT এবং OAuth প্রমাণীকরণের মধ্যে প্রধান পার্থক্যগুলি কী কী?


356

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

এক্সএসআরএফ প্রতিরোধের জন্য আমি জেডাব্লুটিটিকে আমার এক্সএসআরএফ-টোকেন হিসাবে ব্যবহার করছি তবে আমাকে তাদের আলাদা রাখতে বলা হচ্ছে? আমি কি তাদের আলাদা রাখতে পারি? এখানে যে কোনও সহায়তার প্রশংসা করা হবে এবং সম্প্রদায়ের জন্য গাইডলাইনগুলির সেট তৈরি করতে পারে।

উত্তর:


330

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


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

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

অনুশীলনে, আপনি যা করছেন তা ইতিমধ্যে বাহক টোকেনের উপর ভিত্তি করে শ্রেণিবদ্ধ করা যেতে পারে। তবে, বিবেচনা করবেন না যে আপনি OAuth 2.0 সম্পর্কিত স্পেস দ্বারা বর্ণিত বাহক টোকেন ব্যবহার করছেন না (দেখুন আরএফসি 6750 )। এটি বোঝাবে যে Authorizationএইচটিটিপি শিরোনামের উপর নির্ভর করে এবং Bearerপ্রমাণীকরণের স্কিমটি ব্যবহার করবে ।

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

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

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

(উত্স: আরএফসি 6819, বিভাগ 5.4.1 )


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

2
কুকিজ বনাম টোকেন: নির্দিষ্ট নির্দেশিকা, অর্থাত্ auth0.com/blog/cookies-vs-tokens-definitive-guide নয কাজ এই অন্য মহান আলোচনা পোস্ট: stackoverflow.com/questions/37582444/...
সিদ্ধার্থ জৈন

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

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

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

281

OAuth 2.0 একটি প্রোটোকল সংজ্ঞায়িত করে, অর্থাৎ টোকেন কীভাবে স্থানান্তরিত হয় তা নির্দিষ্ট করে, জেডাব্লুটিটি একটি টোকেন বিন্যাসটি সংজ্ঞায়িত করে।

OAuth 2.0 এবং "JWT প্রমাণীকরণ" এর অনুরূপ উপস্থিতি যখন এটি দ্বিতীয় (দ্বিতীয়) পর্যায়ে আসে যেখানে ক্লায়েন্টটি রিসোর্স সার্ভারে টোকেন উপস্থাপন করে: টোকনটি একটি শিরোনামে পাস করা হয়।

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

সুতরাং আসল পার্থক্যটি হ'ল জেডাব্লুটিটি হ'ল একটি টোকেন ফর্ম্যাট, ওআউথ ২.০ একটি প্রোটোকল (এটি একটি জেডাব্লুটিটিকে টোকেন ফর্ম্যাট হিসাবে ব্যবহার করতে পারে)।


10
OAuth প্রোটোকল প্রয়োগগুলি কি বেশিরভাগ ক্ষেত্রে JWT কে টোকেন ফর্ম্যাট হিসাবে ব্যবহার করে? না হলে সবচেয়ে সাধারণ কী?
জেমস ওয়েয়ারজবা

14
ওউথের টোকেন ফর্ম্যাটটি অপরিজ্ঞাত, তবে
জেডাব্লুটিটি

128

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

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


7
আমি বুঝতে পারছি না কেন এই উত্তরটির প্রচুর পরিমাণে উত্সাহ রয়েছে, এটি বলে যে "OAuth একটি প্রমাণীকরণ কাঠামো" এবং এটি সম্পূর্ণ ভুল। OAuth একটি অনুমোদন প্রোটোকল এবং শুধুমাত্র একটি অনুমোদন প্রোটোকল।
মাইকেল 16 ই

4
হাই @ মিশেল এই সম্পর্কে খুব বেশি ভুল ধারণা রয়েছে। আমি আমার মন্তব্য সম্পাদনা করেছি আপনাকে ধন্যবাদ।
মেলিকাহ Şimşek

6
@ মিশেল, দয়া করে অন্যান্য বিসিজেডের জবাবের প্রশংসা করুন তিনি তাঁর পরিশোধিত জ্ঞান আমাদের সাথে ভাগ করেছেন এবং আমি উত্তরটি সত্যই উপভোগ করেছি।
ইয়াসির শাব্বির চৌধুরী

আপনি কি বলছেন যে ওউথটি কেবলমাত্র স্ট্যান্ডার্ডের একটি অংশ যা বিকাশকারীদের অনুসরণ করা উচিত? নাকি এটি আসলে একটি কাঠামো?
স্টর্মট্রোপার

65

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

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

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

সিএসআরএফ সুরক্ষা - আপনি যদি ব্রাউজারের কুকিতে টোকেন সংরক্ষণ না করেন তবে আপনার সিএসআরএফ সুরক্ষা বাস্তবায়ন করতে হবে না।

আপনি এখানে আরও বিশদ পড়তে পারেন http://proficientblog.com/microservices-security/


3
কোনও কুকিজ নেই == কোনও সিএসআরএফ সুরক্ষা নেই। আপনি যদি অনুমোদনের জন্য কুকি ব্যবহার না করেন তবে আপনাকে সিএসআরএফ সুরক্ষা সম্পর্কে চিন্তা করতে হবে না।
নিরঞ্জন হরপলে

51

দেখে মনে হচ্ছে যে এখানে যারা উত্তর দিয়েছেন তারা OAUTH এর মূল বিন্দুটি মিস করেছেন

উইকিপিডিয়া থেকে

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

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

যদি গ্রাহকরা কেবল তাদের বিশ্বস্ত ওয়েবসাইটগুলি (বা অ্যাপ্লিকেশনগুলি) যা আপনার আবার আপনার শেষ পয়েন্টগুলিতে হোস্ট করা হয় তার মাধ্যমে তাদের সংস্থাগুলিতে (আপনার শেষ পয়েন্টগুলি) অ্যাক্সেস করে তবে OAUTH ব্যবহারের কোনও লাভ নেই There

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

আরেকটি গুরুত্বপূর্ণ দ্রষ্টব্য:
আপনি অবাধে authenticationJWT এবং OAUTH শব্দটি ব্যবহার করছেন তবে প্রমাণীকরণের প্রক্রিয়াও সরবরাহ করেন না। হ্যাঁ একটি হ'ল একটি টোকেন মেকানিজম এবং অন্যটি প্রোটোকল তবে একবার প্রমাণীকৃত সেগুলি কেবল অনুমোদনের জন্য ব্যবহার করা হয় (অ্যাক্সেস ম্যানেজমেন্ট)। আপনাকে ওপেনআইডির প্রকারের প্রমাণীকরণ বা আপনার নিজের ক্লায়েন্টের শংসাপত্রাদি দিয়ে ব্যাক করতে হবে


4
OAuth এছাড়াও আপনার নিজস্ব ক্লায়েন্টদের জন্য ব্যবহার করা যেতে পারে, অগত্যা কেবল তৃতীয় পক্ষের নয়। পাসওয়ার্ড শংসাপত্রের অনুদানের ধরণটি ঠিক তা করে।
harpratap

1
আমি এরকম একটি কংক্রিট উত্তরের জন্য গুগলের সন্ধান করছিলাম কিন্তু কোনও উত্তর পেলাম না। প্রত্যেকেই সংজ্ঞা সম্পর্কে কথা বলছিল যেমন টোকেন বনাম প্রোটোকল। আপনার উত্তরটি একে অপরের উপরে ব্যবহারের আসল উদ্দেশ্য ব্যাখ্যা করেছে। তোমাকে অনেক ধন্যবাদ!
বিবেক গোয়েল

9

JWT এবং OAuth এর মধ্যে প্রধান পার্থক্যগুলি সন্ধান করুন find

  1. OAuth 2.0 একটি প্রোটোকল এবং JWT একটি টোকেন ফর্ম্যাট সংজ্ঞায়িত করে format

  2. OAuth JWT হয় টোকেন ফর্ম্যাট বা অ্যাক্সেস টোকেন হিসাবে ব্যবহার করতে পারে যা বহনকারী টোকেন।

  3. ওপেনআইডি সংযোগটি বেশিরভাগই টোকেন ফর্ম্যাট হিসাবে JWT ব্যবহার করে।


6

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

OAuth2 হ'ল একটি অনুমোদনের কাঠামো, যেখানে এটির একটি সাধারণ পদ্ধতি এবং ফ্রেমওয়ার্কটি দ্বারা সংজ্ঞায়িত সেটআপ রয়েছে। জেডাব্লুটিটি OAuth2 এর ভিতরে একটি প্রক্রিয়া হিসাবে ব্যবহার করা যেতে পারে।

আপনি এখানে আরও পড়তে পারেন

OAuth বা JWT? কোনটি ব্যবহার করতে হবে এবং কেন?


5

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

"কাঠামো" বলতে আমরা কী বুঝি? কেবল অনুরোধ এবং প্রতিক্রিয়াগুলির ক্রম এবং সেগুলির ফর্ম্যাটগুলি যা টোকেনের অনুরোধ করতে ব্যবহার করা উচিত এবং তা করা উচিত। OAuthv2 পৃথক পরিস্থিতিতে "পৃথক প্রবাহ" বা অনুদানের ধরণের বর্ণনা দেয় এবং নির্দিষ্ট প্রবাহের সুরক্ষা বাড়ানোর জন্য আলাদা এক্সটেনশন (যেমন PKCE) থাকে।

OAuthV2 অনুদানের মাধ্যমে একটি টোকেনের অনুরোধের ফলাফলটি ... একটি টোকেন। সেই জিনিসটি তখন "বহনকারী টোকেন" হিসাবে নিযুক্ত করা হয়েছে যার অর্থ, কোনও দল যে টোকেনটি ধরে রেখেছে, এপি-রিক অনুরোধের জন্য পরিষেবা দেওয়ার সময় এটি উপস্থাপন করতে পারে (যেমন, "আমার সঞ্চিত মান কার্ডের ভারসাম্য কি?") What's একজন বহনকারী টোকেন হিসাবে, এটি নগদ অর্থের মতো কাজ করে। যদি আপনি এটি ধরে রাখেন তবে আপনি এটি ব্যবহার করতে পারেন। (নগদ অর্থের বিপরীতে, একটি টোকেন এটি ব্যবহার এবং এটি হারাতে পারে না Maybe সম্ভবত আরও ভাল উপমাটি পাবলিক ট্রানজিট সিস্টেমে একটি সারাদিনের টিকিট টু রাইড, বা ডিজনি ওয়ার্ল্ডে সারাদিনের টিকিট)

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

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

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

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


0

Jwt স্বাক্ষরিত অ্যাক্সেস টোকেনগুলি প্রদান ও বৈধ করার জন্য নির্দেশের একটি কঠোর নির্দেশ। টোকেনগুলিতে এমন দাবি রয়েছে যা কোনও অ্যাপ্লিকেশন দ্বারা ব্যবহারকারীর অ্যাক্সেস সীমাবদ্ধ করতে ব্যবহৃত হয়

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

নোট oauth2 jwt, নমনীয় বাস্তবায়ন, বিভিন্ন অ্যাপ্লিকেশনগুলির কাছে বর্ধমানযোগ্য সাথে কাজ করতে পারে


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