কুকি-ভিত্তিক বনাম সেশন বনাম টোকেন-ভিত্তিক বনাম দাবি-ভিত্তিক প্রমাণীকরণ

Question

আমি প্রামাণ্যতা সম্পর্কে পড়েছি এবং ধরণের শ্রেণিবিন্যাস সম্পর্কে বিভ্রান্ত হয়ে পড়েছি।

আসুন কুকি-ভিত্তিক প্রমাণীকরণ থেকে শুরু করুন, যদি আমি এটি সঠিকভাবে বুঝতে পারি তবে মূল বিষয় হ'ল ব্যবহারকারীর প্রমাণীকরণের জন্য প্রয়োজনীয় সমস্ত ডেটা কুকিগুলিতে সঞ্চিত। এবং এটি আমার প্রথম বিভ্রান্তি: কুকিগুলিতে আমরা সঞ্চয় করতে পারি

• সেশন আইডি এবং তাই এটি একটি সেশন-ভিত্তিক প্রমাণীকরণ হয়ে যায়?
• দাবি, এবং তাই এটি কি দাবি-ভিত্তিক প্রমাণীকরণ হিসাবে ডাকা উচিত?
• আমি দেখতে পেয়েছি যে কিছু লোক এমনকি কুকিগুলিতে JWT টোকেন সংরক্ষণ করে তবে এটি নিজস্ব লেখার প্রবাহকে কাস্টম প্রয়োগের মতো বলে মনে হচ্ছে ...

এখন আসুন দাবি-ভিত্তিক প্রমাণীকরণে স্যুইচ করুন। মূল উপাদানটি দাবি এবং সংগ্রহগুলি ধারক হিসাবে ব্যবহার করতে পারে

• কুকিজ (উপরে আলোচনা হিসাবে)
• টোকেন (উদাহরণ হিসাবে JWT)।

অন্যদিকে, আমরা যখন টোকেনের কথা বলছি তখন এতে কোনও ধরণের তথ্য থাকতে পারে ... উদাহরণস্বরূপ সেশন আইডি ...

তাহলে আমি কী মিস করেছি? প্রমাণীকরণের প্রকারের কথা বলার সময় লোকেরা কেন এমন কিছু Cookie-Session-basedবা Token-Claims-basedপ্রমাণীকরণের সংজ্ঞা দেয় না ?

Answer 1

আমি একমত যে বিভিন্ন ধারণার নামকরণ বিভ্রান্তিকর। ওয়েব প্রসঙ্গে প্রমাণীকরণের বিষয়ে কথা বলার সময় বিভিন্ন দিক বিবেচনা করা উচিত।

প্রমাণীকরণের সময় ক্লায়েন্ট কোন তথ্য প্রেরণ করে?

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

কীভাবে ক্লায়েন্ট প্রমাণীকরণের তথ্য পাঠায়?

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

প্রমাণীকরণ তথ্যের বিন্যাস কী?

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

বোনাস: ক্লায়েন্ট কীভাবে স্থানীয়ভাবে তথ্য সংরক্ষণ করে

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

লোকেরা যখন বলে তখন কী বোঝায় ...

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

Comments

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

— ব্র্যান্ডন

Answer 2

সহজভাবে করা,

1. কুকি-ভিত্তিক প্রমাণীকরণ

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

2. সেশন-ভিত্তিক প্রমাণীকরণ

   • ওয়েব-ক্লায়েন্ট কুকির পাশাপাশি, কোনও ওয়েব-সার্ভার যদি ব্যবহারকারী অথন ডাটা তাদের ব্যাক-এন্ডে সঞ্চয় করে, তবে এটিকে সেশন-ভিত্তিক প্রমাণীকরণ বলা হবে।
   • ওয়েব ক্লায়েন্ট সিস্টেমটিতে অ্যাক্সেস পাওয়া উচিত না এমন কোনও লঙ্ঘনের ঘটনায় এটি খুব কার্যকর, তারপরে ব্যাক-এন্ড থেকে, ওয়েব-ক্লায়েন্টের সেশনটি প্রশাসকের দ্বারা বাতিল করা যেতে পারে।

3. টোকেন ভিত্তিক প্রমাণীকরণ

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

4. দাবি-ভিত্তিক প্রমাণীকরণ

   • এটি টোকেন-ভিত্তিক প্রমাণীকরণের মতো, কেবল এটি ক্লায়েন্ট এবং / অথবা ক্লায়েন্টের সাথে সম্পর্কিত ব্যবহারকারী সম্পর্কে টোকনে আরও কিছু ডেটা যুক্ত করে।
   • এই ডেটাগুলি অনুমোদনের সাথে সম্পর্কিত, যা ক্লায়েন্টটি সংস্থার মধ্যে কী করবে সে সম্পর্কে কথা বলে (যেমন: মেল.ড্রেড, মেইল.ডিলেট, ক্যালেন্ডার.ড্রেড)।