টোকেন প্রমাণীকরণ বনাম কুকিজ


141

টোকেন প্রমাণীকরণ এবং কুকিজ ব্যবহার করে প্রমাণীকরণের মধ্যে পার্থক্য কী?

আমি আম্বর অথ রেলস ডেমো বাস্তবায়নের চেষ্টা করছি কিন্তু "টোকেন প্রমাণীকরণ কেন?" প্রশ্নে অ্যামবার অথ FAQ এ বর্ণিত টোকেন প্রমাণীকরণ ব্যবহার করার পিছনে কারণগুলি আমি বুঝতে পারি না ?


4
আপনার মোবাইল অ্যাপকে একটি টোকন দেওয়া যেতে পারে এবং এসপিএ অনুরোধে ব্যবহারের জন্য আপনার ব্রাউজারে জাভাস্ক্রিপ্টের মাধ্যমে পরে ব্যবহারের জন্য বা আপনার দ্বারা একটি ভেরিয়েবল (আপনার দ্বারা) সংরক্ষণ করা যেতে পারে। একটি কুকি সাধারণত একটি ব্রাউজারে ব্যবহৃত হয় (ব্রাউজার দ্বারা)।
টিনো ম্যাকলারেন

উত্তর:


34

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

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

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

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

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

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

আমি আশা করি আমার উত্তরটি আপনার প্রশ্নের আরও অর্থ প্রদান করবে।


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

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

5
আমি এখানে উভয় মন্তব্যেই একমত ... বাস্তবে, আমি অনুভব করি যে পুরো "এটিই অ্যাম্বার ওয়ে" সামান্য কিছুটা কপ-আউট
গ্রাফো

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

15
জিজ্ঞাসিত প্রশ্নটির উপর ফোকাস করে ember.js এর বিজ্ঞাপন করবেন না .. অসভ্য হয়ে দুঃখিত।
ভিক_প্রেকে

336

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

টোকেন প্রমাণীকরণ

  • সার্ভারে একটি অনুরোধ একটি "টোকেন" দ্বারা স্বাক্ষরিত হয় - সাধারণত এর অর্থ নির্দিষ্ট http শিরোনাম নির্ধারণ করা হয় তবে এগুলি http অনুরোধের কোনও অংশে (পোষ্ট বডি ইত্যাদি) প্রেরণ করা যেতে পারে)

  • পেশাদাররা:

    • আপনি কেবল অনুরোধগুলি অনুমোদন করতে পারেন যা আপনি অনুমোদিত করতে চান। (কুকিজ - এমনকি অনুমোদনের কুকি প্রতিটি একক অনুরোধের জন্য প্রেরণ করা হয়।)
    • এক্সএসআরএফ-এর প্রতিরোধক (এক্সএসআরএফের সংক্ষিপ্ত উদাহরণ - আমি আপনাকে ইমেলটিতে একটি লিঙ্ক প্রেরণ করব যা দেখতে দেখতে হবে <img src="http://bank.com?withdraw=1000&to=myself" />এবং আপনি যদি কুকি প্রমাণীকরণের মাধ্যমে bank.com এ লগ ইন হয়ে থাকেন এবং ব্যাংক ডটকমের এক্সএসআরএফের কোনও উপায় নেই) সুরক্ষা, আমি কেবল আপনার অ্যাকাউন্ট থেকে অর্থ প্রত্যাহার করব যে আপনার ব্রাউজারটি সেই ইউআরএলকে একটি অনুমোদিত জিইটি অনুরোধটি ট্রিগার করবে)) নোট করুন যে কুকি-ভিত্তিক প্রমাণীকরণের সাথে আপনি করতে পারেন এমন জালিয়াতি ব্যবস্থা রয়েছে - তবে আপনাকে সেগুলি বাস্তবায়ন করতে হবে।
    • কুকিজ একটি একক ডোমেনে আবদ্ধ। আপনার foo.com ডোমেইনে তৈরি একটি কুকি ডোমেন বার ডট কম দ্বারা পড়তে পারে না, আপনি নিজের পছন্দমতো যে কোনও ডোমেইনে টোকেন প্রেরণ করতে পারেন। এটি বিশেষত একক পৃষ্ঠাগুলির অ্যাপ্লিকেশনগুলির জন্য দরকারী যা একাধিক পরিষেবা গ্রহণ করছে যা অনুমোদনের প্রয়োজন হয় - তাই আমার ডোমেইন myapp.com এ একটি ওয়েব অ্যাপ্লিকেশন থাকতে পারে যা myservice1.com এবং myservice2.com এ অনুমোদিত ক্লায়েন্ট-সাইড অনুরোধ করতে পারে।
  • কনস:
    • আপনি টোকেন কোথাও সংরক্ষণ করতে হবে; যখন কুকিগুলি "বাক্সের বাইরে" সঞ্চিত থাকে। যে জায়গাগুলি মাথায় আসে সেগুলি হ'ল লোকালস্টোরেজ (কন: আপনি ব্রাউজার উইন্ডোটি বন্ধ করার পরেও টোকেনটি বজায় থাকে), সেশনস্টোরেজ (প্রো: টোকনটি আপনি ব্রাউজার উইন্ডোটি বন্ধ করার পরে বাতিল করা হবে, কন: একটি নতুন ট্যাবে একটি লিঙ্ক খোলার ফলে সেই ট্যাবটি রেন্ডার হবে) বেনামে) এবং কুকিজ (প্রো: আপনি ব্রাউজার উইন্ডোটি বন্ধ করার পরে টোকেনটি ফেলে দেওয়া হবে you আপনি যদি নতুন সারণীতে কোনও লিঙ্ক খোলার সময় সেশন কুকি ব্যবহার করেন তবে আপনাকে অনুমোদন দেওয়া হবে এবং আপনি এক্সএসআরএফ থেকে প্রতিরোধী হবেন যেহেতু আপনি এড়িয়ে যাচ্ছেন প্রমাণীকরণের জন্য কুকি, আপনি কেবল এটি টোকেন স্টোরেজ হিসাবে ব্যবহার করছেন Con কন: কুকিজ প্রতিটি অনুরোধের জন্য প্রেরণ করা হয় this
    • টোকেন ভিত্তিক প্রমাণীকরণের বিরুদ্ধে এক্সএসএস আক্রমণ করা কিছুটা সহজ (উদাহরণস্বরূপ যদি আমি আপনার সাইটে ইঞ্জেকশন স্ক্রিপ্ট চালাতে সক্ষম হয়েছি তবে আমি আপনার টোকনটি চুরি করতে পারি; তবে, কুকি ভিত্তিক প্রমাণীকরণটি কোনও রূপালী বুলেট নয় - যখন কুকিজ হিসাবে চিহ্নিত হয়েছে HTTP- কেবল ক্লায়েন্ট দ্বারা পঠিত যাবে না, ক্লায়েন্ট এখনও আপনার পক্ষ থেকে অনুরোধ করতে পারে যা স্বয়ংক্রিয়ভাবে অনুমোদনের কুকি অন্তর্ভুক্ত করবে))
    • কোনও ফাইল ডাউনলোড করার অনুরোধ, যা কেবলমাত্র অনুমোদিত ব্যবহারকারীদের জন্যই কাজ করে বলে মনে করা হয়, আপনার ফাইল এপিআই ব্যবহার করা দরকার। একই অনুরোধটি কুকি-ভিত্তিক প্রমাণীকরণের জন্য বাক্সের বাইরে কাজ করে।

কুকি প্রমাণীকরণ

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

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


56
এই উত্তরটি স্বীকৃত উত্তরটির চেয়ে এক প্রাসঙ্গিক উত্তরের নিকটবর্তী।
xlecoustillier

3
ধন্যবাদ @ অনদ্রেজ-স্বেজদার। এটি এখন পর্যন্ত সেরা উত্তর! আমি কেবল "বেশ কিছু কোডিং" অংশ নিয়ে তর্ক করব। যে কোনও ভাষার জন্য বেশ কয়েকটি লাইব্রেরি উপলব্ধ। সুতরাং আপনি যদি জেডব্লিউটি বাস্তবায়নের যান্ত্রিকতাকে সত্যিই জানতে না চান তবে স্ক্র্যাচ থেকে শুরু করার দরকার নেই।
ফুলস্ট্যাকফোর্জার

2
Are send out for every single requestটোকনগুলি প্রতিটি অনুরোধের জন্যও পাঠানো হয়
ইউজেন কনকভ

10
@ ইউজেনকনকভ নং নিকটবর্তী নয় আপনি যদি শিরোনাম যুক্ত করেন তবেই। আপনি চাইলে বা না চাইলে ব্রাউজার থেকে কুকিজ প্রেরণ করা হয়
রায়ই নামির

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

34
  • টোকেনগুলি কোথাও সংরক্ষণ করতে হবে (স্থানীয় / সেশন স্টোরেজ বা কুকিজ)

  • টোকেনগুলি কুকিজের মতো মেয়াদ শেষ করতে পারে তবে আপনার আরও নিয়ন্ত্রণ রয়েছে

  • স্থানীয় / সেশন স্টোরেজ ডোমেনগুলি জুড়ে কাজ করবে না, মার্কার কুকি ব্যবহার করুন

  • প্রতিটি সিওআরএস অনুরোধে প্রিফলাইট অনুরোধগুলি প্রেরণ করা হবে

  • আপনার যখন কিছু স্ট্রিম করার দরকার হয় তখন স্বাক্ষরিত অনুরোধটি পেতে টোকেনটি ব্যবহার করুন

  • এক্সএসআরএফের চেয়ে এক্সএসএসের সাথে ডিল করা সহজ

  • প্রতিটি অনুরোধে টোকেন প্রেরণ করা হয়, এর আকার দেখুন watch

  • আপনি যদি গোপনীয় তথ্য সঞ্চয় করেন তবে টোকেনটি এনক্রিপ্ট করুন

  • JSON ওয়েব টোকেনগুলি OAuth এ ব্যবহার করা যেতে পারে

  • টোকেনগুলি রূপালী বুলেট নয়, আপনার অনুমোদনের ক্ষেত্রে সাবধানতার সাথে ব্যবহারের বিষয়ে চিন্তা করুন

http://blog.auth0.com/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies/

http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/


14
এটি পরিষ্কার নয় যে আপনার পয়েন্টগুলি কুকিজ বা টোকেনগুলির জন্য, তারা কোন রাউন্ডে?
পিওরফেরেট

6
আমি বুঝতে পারি না কেন আপনি কুকিগুলির চেয়ে টোকেনের উপর "আরও নিয়ন্ত্রণ" রাখেন।
হারুন

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

18

গুগলারের জন্য :

  • মিশ্রিত করবেন না statefulness সঙ্গে রাষ্ট্র হস্তান্তর প্রক্রিয়া

STATEFULNESS

  • স্টেটফুল = সার্ভারে অনুমোদনের তথ্য সংরক্ষণ করুন, এটি theতিহ্যগত উপায় way
  • নিরপেক্ষতা নিশ্চিত করার জন্য স্বাক্ষর সহ স্টেটলেস = ক্লায়েন্টের পক্ষে অনুমোদনের তথ্য সংরক্ষণ করুন

গঠনতন্ত্র

  • কুকি = ব্রাউজারগুলির দ্বারা বিশেষ চিকিত্সা (অ্যাক্সেস, স্টোরেজ, মেয়াদোত্তীকরণ, সুরক্ষা, স্বতঃ-স্থানান্তর) সহ একটি বিশেষ শিরোনাম
  • কাস্টমAuthorization শিরোনাম = যেমন কোনও বিশেষ চিকিত্সা ছাড়াই কেবল শিরোনাম, ক্লায়েন্টকে স্থানান্তরের সমস্ত দিক পরিচালনা করতে হয় manage
  • অন্যান্য । অন্যান্য স্থানান্তর প্রক্রিয়াগুলি ব্যবহার করা যেতে পারে, উদাহরণস্বরূপ ক্যোরি স্ট্রিংটি কিছু সময়ের জন্য প্রমাণ আইডি স্থানান্তর করার পছন্দ ছিল তবে এটি তার নিরাপত্তাহীনতার জন্য ত্যাগ করা হয়েছিল

স্থিতিশীল যাত্রা

  • "স্টেটফুল অথরাইজেশন" এর অর্থ সার্ভারে ব্যবহারকারী অনুমোদনের তথ্য সার্ভার সংরক্ষণ করে এবং সংরক্ষণ করে, অনুমোদনের প্রয়োগের রাজ্যের অংশ করে তোলে "
  • এর অর্থ ক্লায়েন্টকে কেবল একটি "প্রমাণীকরণ আইডি" রাখতে হবে এবং সার্ভারটি তার ডাটাবেস থেকে লেখার বিশদটি পড়তে পারে
  • এটি সূচিত করে যে সার্ভারটি সক্রিয় লেখকদের একটি পুল রাখে (ব্যবহারকারীরা লগ ইন করেছেন) এবং প্রতিটি অনুরোধের জন্য এই তথ্যটি জিজ্ঞাসা করবে
  • "স্টেটলেস অথরাইজেশন" এর অর্থ সার্ভারটি ব্যবহারকারীর প্রমাণ তথ্য সংরক্ষণ এবং রক্ষণাবেক্ষণ করে না, এটি সহজেই জানে না কোন ব্যবহারকারীরা সাইন ইন করেছে এবং লেখক তথ্য উত্পাদন করতে ক্লায়েন্টের উপর নির্ভর করে
  • ক্লায়েন্ট আপনি (ব্যবহারকারী আইডি), এবং সম্ভবত অনুমতি, মেয়াদোত্তীকরণের সময় ইত্যাদির মতো সম্পূর্ণ প্রমাণীকরণ তথ্য সংরক্ষণ করবেন, এটি কেবল লেখক আইডির চেয়ে বেশি, সুতরাং এটি একটি নতুন নাম টোকেন দেওয়া হয়েছে
  • স্পষ্টতই ক্লায়েন্টকে বিশ্বাস করা যায় না, সুতরাং hash(data + secret key)গুপ্ত কীটি কেবলমাত্র সার্ভারের কাছেই জানা থাকে, সেখান থেকে উত্পন্ন স্বাক্ষরের সাথে প্রমাণীকরণের ডেটা সংরক্ষণ করা হয় , তাই টোকেন ডেটার অখণ্ডতা যাচাই করা যায়
  • নোট করুন যে টোকেন প্রক্রিয়া নিছক সততা নিশ্চিত করে, তবে গোপনীয়তা নয়, ক্লায়েন্টকে এটি প্রয়োগ করতে হবে
  • এর অর্থ প্রতিটি অনুরোধের ক্লায়েন্টকে একটি সম্পূর্ণ টোকেন জমা দিতে হবে, যা অতিরিক্ত ব্যান্ডউইদথকে অন্তর্ভুক্ত করে

মেকানিজম কমপ্লেসন

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

যোগ করা

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

লিংক


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

খুব খুব ভাল. আরও বিশদ নিয়ে আসে এবং কীভাবে এবং কেন উন্নত উপায়ে তা সত্যই ব্যাখ্যা করে।
কলিনওয়ং

8

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

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

সুতরাং, এটি কুকি ভিত্তিক এবং টোকেন ভিত্তিক মধ্যে পার্থক্য, পরেরটি ওয়েব স্টোরেজ ব্যবহার করে।


5

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

এখানে খুব ভাল নিবন্ধ:

http://www.toptal.com/web/cookie-free-authentication-with-json-web-tokens-an-example-in-laravel-and-angularjs


3

টোকেন ব্যবহার করুন যখন ...

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

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

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


1

প্রাথমিক পার্থক্যগুলির মধ্যে একটি হ'ল কুকিজগুলি একই উত্স নীতি সাপেক্ষে যদিও টোকেনগুলি নেই। এটি সমস্ত ধরণের ডাউন স্ট্রিম প্রভাব তৈরি করে।

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

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

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

সুতরাং সাধারণভাবে টোকেনগুলি প্রমাণীকরণ সরবরাহের সাথে সম্পর্কিত ঘর্ষণ এবং ব্যয়কে হ্রাস করে এবং সুরক্ষিত সিস্টেমের প্রয়োগ ও পরিচালনা উভয়ই সক্ষম করতে কেন্দ্রীয়ভাবে সুরক্ষিত ওয়েবের বিভিন্ন দিকের বোঝাটিকে আরও ভালভাবে সক্ষম করে তোলে ized

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