জাসন ওয়েব টোকেনকে অবৈধ করছে


420

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

প্রকল্পটি এমন একটি গেম যা সকেট.আইও ব্যবহার করে - টোকন-ভিত্তিক সেশনটি এমন দৃশ্যে কার্যকর হবে যেখানে একক সেশনে একাধিক যোগাযোগের চ্যানেল থাকবে (ওয়েব এবং সকেট.আইও)

কেউ কীভাবে jwt অ্যাপ্রোচ ব্যবহার করে সার্ভার থেকে টোকেন / সেশন অবৈধকরণ সরবরাহ করবে?

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

সুতরাং, বলুন আমার কাছে নিম্নলিখিতগুলি রয়েছে ( এটি এবং এটি থেকে অভিযোজিত ):

সেশন স্টোর লগইন:

app.get('/login', function(request, response) {
    var user = {username: request.body.username, password: request.body.password };
    // Validate somehow
    validate(user, function(isValid, profile) {
        // Create session token
        var token= createSessionToken();

        // Add to a key-value database
        KeyValueStore.add({token: {userid: profile.id, expiresInMinutes: 60}});

        // The client should save this session token in a cookie
        response.json({sessionToken: token});
    });
}

টোকেন ভিত্তিক লগইন:

var jwt = require('jsonwebtoken');
app.get('/login', function(request, response) {
    var user = {username: request.body.username, password: request.body.password };
    // Validate somehow
    validate(user, function(isValid, profile) {
        var token = jwt.sign(profile, 'My Super Secret', {expiresInMinutes: 60});
        response.json({token: token});
    });
}

-

সেশন স্টোর পদ্ধতির জন্য একটি লগআউট (বা অবৈধ) করার জন্য নির্দিষ্ট টোকেন সহ কীভ্যালিউস্টোর ডাটাবেসের আপডেট দরকার।

দেখে মনে হচ্ছে টোকেন ভিত্তিক পদ্ধতির মধ্যে এই জাতীয় ব্যবস্থাটির অস্তিত্ব থাকবে না কারণ টোকেনে নিজেই মূল-মূল্যের স্টোরটিতে এমন তথ্য উপস্থিত থাকবে।


1
আপনি যদি 'এক্সপ্রেস- jwt' প্যাকেজটি ব্যবহার করেন তবে আপনি isRevokedবিকল্পটি একবার দেখে নিতে পারেন বা একই কার্যকারিতাটি প্রতিলিপি দেওয়ার চেষ্টা করতে পারেন। github.com/auth0/express-jwt#revused-tokens
Signus

1
অ্যাক্সেস টোকনে একটি স্বল্প মেয়াদোত্তীর্ণ সময় ব্যবহার এবং একটি দীর্ঘকালীন মেয়াদোত্তীর্ণ মেয়াদ সহ একটি রিফ্রেশ টোকেন ব্যবহার করে বিবেচনা করুন যাতে কোনও ডাটাবেজে (ব্ল্যাকলিস্টিং) ব্যবহারকারীর অ্যাক্সেসের স্থিতি পরীক্ষা করার অনুমতি দেয়। auth0.com/blog/...
Rohmer

jwt টোকেন তৈরি করার সময় একই আইপি ঠিকানার জন্য সঞ্চিত আইপি বনাম আগত অনুরোধ পরীক্ষা করার সময় অন্য বিকল্পটি পে-লোডে আইপি ঠিকানা সংযুক্ত করা হবে। উদাহরণস্বরূপ: নোডজেগুলিতে req.connection.remoteAdress। এমন আইএসপি সরবরাহকারী রয়েছে যা গ্রাহক প্রতি স্ট্যাটিক আইপি ইস্যু করে না, আমি মনে করি কোনও ক্লায়েন্ট ইন্টারনেটে পুনরায় সংযুক্ত না হলে এটি কোনও সমস্যা হবে না।
জিহান সান্দারু

উত্তর:


391

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

1) ক্লায়েন্ট থেকে টোকেনটি কেবল সরান

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

2) একটি টোকেন ব্ল্যাকলিস্ট তৈরি করুন

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

3) কেবল টোকেন মেয়াদ শেষ হওয়ার সময়গুলি ছোট রাখুন এবং প্রায়শই তাদের ঘোরান

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

পরিকল্পনা

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

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

টোকেন ব্যবহার করে আক্রমণগুলির সাথে মিলের সাথে পার্থক্যের ক্ষেত্রে, এই পোস্টটি প্রশ্নের উত্তর দেয়: https://github.com/dentarg/blog/blob/master/_posts/2014-01-07-angularjs-authentication-with-cookies -vs-token.markdown


3
দুর্দান্ত পন্থা। আমার অন্ত্রে সমস্ত 3 এর সংমিশ্রণ করা হবে এবং / অথবা, প্রতিটি "এন" অনুরোধের পরে (টাইমার বিপরীতে) একটি নতুন টোকেনের অনুরোধ জানানো হবে। আমরা ইন-মেমোরি অবজেক্ট স্টোরেজের জন্য পুনরায় ব্যবহার করছি, এবং আমরা সহজেই এটি # 2 ক্ষেত্রে ব্যবহার করতে পারি, এবং তারপরে বিলম্বটি ওয়েয়ে নেমে যেতে পারে।
অ্যারন ওয়াগনার

2
এই কোডিং হরর পোস্টটি কিছু পরামর্শ দেয়: সেশন বহনকারী কুকিজ (বা টোকেন) ছোট রাখুন তবে এটি ব্যবহারকারীর কাছে অদৃশ্য করে দিন - যা # 3 এর সাথে মিল রয়েছে বলে মনে হয় appears আমার নিজের অন্ত্রে (সম্ভবত এটি আরও প্রচলিত কারণ) কেবলমাত্র টোকেন (বা এটির একটি হ্যাশ) সাদা-তালিকাভুক্ত সেশন ডেটাবেজে (# 2 এর অনুরূপ) কী হিসাবে কাজ করবে
ফানসিকি

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

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

4
একটি ব্ল্যাকলিস্টকে এটিকে স্মৃতিতে রেখে দক্ষ করে তোলা যেতে পারে, যাতে অবৈধতা রেকর্ড করতে এবং মেয়াদোত্তীর্ণ অবৈধতাগুলি সরাতে এবং কেবল সার্ভার লঞ্চে পড়ার জন্য ডিবিকে আঘাত করা দরকার। লোড-ব্যালেন্সিং আর্কিটেকচারের অধীনে, ইন-মেমরি ব্ল্যাকলিস্টটি 10s এর মতো স্বল্প বিরতিতে ডিবিটিকে পোল করতে পারে, অবৈধ টোকেনগুলির এক্সপোজারকে সীমাবদ্ধ করে। এই পদ্ধতিগুলি প্রতি-অনুরোধ ডিবি অ্যাক্সেস ছাড়াই সার্ভারকে অনুরোধগুলি অনুমোদনের অনুমতি দেয়।
জো ল্যাপ

85

উপরে পোস্ট করা ধারণাগুলি ভাল, তবে বিদ্যমান সমস্ত জেডাব্লুটিটি অবৈধ করার খুব সহজ এবং সহজ উপায় হ'ল গোপনীয়তা পরিবর্তন করা।

যদি আপনার সার্ভার JWT তৈরি করে, এটি একটি গোপন (JWS) দিয়ে স্বাক্ষর করে তারপরে এটি ক্লায়েন্টকে প্রেরণ করে, কেবল গোপনীয় পরিবর্তনটি সমস্ত বিদ্যমান টোকেনকে অকার্যকর করে দেয় এবং সমস্ত ব্যবহারকারীদের তাদের পুরানো টোকেনটি হঠাৎ করে অবৈধ হয়ে যাওয়ায় প্রমাণীকরণের জন্য একটি নতুন টোকেন অর্জন করতে হবে সার্ভারে।

এটির আসল টোকেন সামগ্রীতে (বা লুকিং আইডি) কোনও পরিবর্তন দরকার নেই।

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


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

1
@ কিজানাউইগার্ড, একটি সরকারী / ব্যক্তিগত কী জুটিটি কার্যকরভাবে আরএস 256 অ্যালগরিদমের গোপন হিসাবে স্বাক্ষরটিকে বৈধ করতে ব্যবহার করা যেতে পারে। এখানে প্রদর্শিত উদাহরণে তিনি একটি জেডাব্লুটিটি অবৈধ করার জন্য গোপনীয়তা পরিবর্তনের কথা উল্লেখ করেছেন। এটি হয় ক) ক) স্বাক্ষর মেলে না এমন একটি নকল পাব্বির প্রবর্তন করে বা খ) একটি নতুন পাবকি তৈরি করার মাধ্যমে can সেই পরিস্থিতিতে এটি আদর্শের চেয়ে কম নয়।
সাইনাস

1
@ সাইনাস - গেটচা গোপনীয়তা হিসাবে পাবলিক কী ব্যবহার না করে, তবে অন্যরা স্বাক্ষরটি যাচাই করতে পাবলিক কীতে নির্ভর করে।
কিজানা উডার্ড

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

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

67

এটি প্রাথমিকভাবে @ ম্যাটওয়ে দ্বারা উত্তরের পক্ষে সমর্থন এবং বিল্ডিং long

প্রদত্ত:

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

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

প্রদত্ত:

আদর্শ, বাস্তব বিশ্বের ওয়েব অ্যাপ্লিকেশনটির জন্য সত্যই স্টেটলেস জেডাব্লুটি প্রমাণীকরণ অর্জন করা যায় না কারণ স্টেটলেস জেডাব্লুটিটির নিম্নলিখিত গুরুত্বপূর্ণ ব্যবহারের ক্ষেত্রে তাত্ক্ষণিক এবং সুরক্ষিত সহায়তা সরবরাহ করার উপায় নেই :

ব্যবহারকারীর অ্যাকাউন্ট মুছে ফেলা / অবরুদ্ধ / স্থগিত করা হয়েছে।

ব্যবহারকারীর পাসওয়ার্ড পরিবর্তন করা হয়েছে।

ব্যবহারকারীর ভূমিকা বা অনুমতিগুলি পরিবর্তন করা হয়েছে।

ব্যবহারকারী প্রশাসক দ্বারা লগ আউট করেছেন।

জেডাব্লুটি টোকনে অন্য কোনও অ্যাপ্লিকেশন সমালোচনামূলক ডেটা সাইট প্রশাসক দ্বারা পরিবর্তন করা হয়েছে।

আপনি এই ক্ষেত্রে টোকেন মেয়াদ শেষ হওয়ার জন্য অপেক্ষা করতে পারবেন না cannot টোকেন অবৈধতা অবিলম্বে ঘটতে হবে। এছাড়াও, আপনি ক্লায়েন্টকে পুরানো টোকেনের অনুলিপি রাখার এবং ব্যবহার না করার বিষয়ে বিশ্বাস করতে পারবেন না, তা দূষিত অভিপ্রায় সহ হোক না কেন।

অতএব: আমি মনে করি @ ম্যাট-ওয়ে, # 2 টোকেনব্ল্যাকলিস্ট থেকে উত্তরটি জেডাব্লুটি ভিত্তিক প্রমাণীকরণে প্রয়োজনীয় রাষ্ট্র যুক্ত করার পক্ষে সবচেয়ে কার্যকর উপায়।

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

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


15
আমি আপনার উত্তরের সাথে একমত নই একটি ডাটাবেস হিট কিছুই রাষ্ট্রীয় করে তোলে না; আপনার ব্যাকএন্ডে রাজ্য সংরক্ষণ করে জেডব্লিউটি তৈরি করা হয়নি যাতে প্রতিটি অনুরোধে আপনাকে ডাটাবেস হিট করতে না হয় J জেডাব্লুটি সম্পূর্ণ ভিন্ন সমস্যা সমাধান করে। en.wikedia.org/wiki/Stateless_protocol
জুলিয়ান

6
@ জুলিয়ান আপনি কি এই বিষয়ে একটু বিস্তারিত বলতে পারবেন? জেডব্লিউটি আসলে কোন সমস্যার সমাধান করে?
শূন্য01 আলফা

8
@ শূন্য01 আলফা প্রমাণীকরণ: এটি JWT ব্যবহারের জন্য সর্বাধিক সাধারণ দৃশ্য। ব্যবহারকারী একবার লগ ইন হয়ে গেলে, পরবর্তী প্রতিটি অনুরোধে জেডাব্লুটিটি অন্তর্ভুক্ত থাকবে, যা ব্যবহারকারীকে সেই টোকেনের সাথে অনুমোদিত রুট, পরিষেবা এবং সংস্থানগুলি অ্যাক্সেস করার অনুমতি দেবে। ইনফরমেশন এক্সচেঞ্জ: জেএসএন ওয়েব টোকেনগুলি পার্টির মধ্যে নিরাপদে তথ্য প্রেরণের একটি ভাল উপায়। যেহেতু জেডাব্লুটি টি স্বাক্ষরিত হতে পারে আপনি নিশ্চিত হতে পারেন যে প্রেরকরা তারা তারা বলে যে তারা। Jwt.io/intr پيداوار
জুলিয়ান

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

1
Jwt.io/intr پيداوار থেকেIf the JWT contains the necessary data, the need to query the database for certain operations may be reduced, though this may not always be the case.
দৈত্য

43

আমি ব্যবহারকারীর মডেলটিতে jwt সংস্করণ নম্বর রেকর্ড করব। নতুন jwt টোকেনগুলি এতে তাদের সংস্করণ স্থাপন করবে।

আপনি যখন jwt যাচাই করেন, কেবল এটির ব্যবহারকারীর বর্তমান jwt সংস্করণের সমান সংস্করণ নম্বর রয়েছে তা পরীক্ষা করুন।

আপনি যে কোনও সময় পুরানো jwts অবৈধ করতে চান, কেবল ব্যবহারকারীদের jwt সংস্করণ নম্বরটি টানুন।


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

13
সম্ভবত আপনি ইতিমধ্যে আপনার টোকেনে একটি ব্যবহারকারী আইডি সঞ্চয় করছেন এবং তারপরে ব্যবহারকারী আপি / এন্ডপয়েন্টে অ্যাক্সেস করার জন্য অনুমোদিত / ব্যবহারকারী রয়েছেন কিনা তা পরীক্ষা করতে ডাটাবেসটি জিজ্ঞাসা করছেন। সুতরাং আপনি jwt টোকেন সংস্করণ নম্বরটি ব্যবহারকারীর সাথে একটির সাথে তুলনা করে কোনও অতিরিক্ত ডিবি অনুসন্ধান করছেন না।
দফটমনক

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

11
যদি ব্যবহারকারী একাধিক ডিভাইস থেকে লগ ইন করে? এই সমস্তগুলিতে একটি টোকেন ব্যবহার করা উচিত বা লগইন করা সমস্ত পূর্ববর্তীকে অবৈধ করতে হবে?
meeDamian

10
আমি @ সার্জিওকোরিয়ার সাথে একমত, এটি JWT কে অন্য কোনও টোকেন প্রমাণীকরণ প্রক্রিয়া হিসাবে প্রায় রাষ্ট্রীয় করে তুলবে।
এড জে

40

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

গোল:

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

সমাধান:

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

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

কনস:

  • তবুও রিফ্রেশ টোকেন অনুরোধে একটি ডেটা স্টোর লক করতে হবে।
  • টোকেনের টিটিএল অ্যাক্সেসের জন্য অবৈধ টোকেনগুলি চালিয়ে যেতে পারে।

পেশাদাররা:

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

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


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

5
অথবা আপনি জেস / স্থানীয় সঞ্চয়স্থান বা কুকি থেকে আপনার JWT অপসারণ করতে পারেন।
কামিল কিয়েসজেউস্কি

1
ধন্যবাদ @ অষ্টোনিয়ান ব্যাপক গবেষণা করার পরে, আমি জেডাব্লুটিটি ছেড়ে দিয়েছি। গোপন কীটি সুরক্ষিত করার জন্য আপনি অসাধারণ দৈর্ঘ্যে না গেলে বা আপনি যদি কোনও নিরাপদ OAuth প্রয়োগের জন্য প্রতিনিধি না করেন তবে JWTs নিয়মিত সেশনের চেয়ে অনেক বেশি ঝুঁকির মধ্যে রয়েছে। আমার সম্পূর্ণ প্রতিবেদনটি দেখুন: by.jtl.xyz/2016/06/the-unspoken-vulnerability-of-jwts.html
জো ল্যাপ

2
রিফ্রেশ টোকেন ব্যবহার করা ব্ল্যাকলিস্টিংয়ের অনুমতি দেওয়ার মূল চাবিকাঠি। গ্রেট ব্যাখ্যা: auth0.com/blog/...
Rohmer

1
এটি আমার কাছে সেরা উত্তর বলে মনে হচ্ছে কারণ এটি একটি দীর্ঘকালীন অ্যাক্সেস টোকেনকে দীর্ঘকালীন রিফ্রেশ টোকেনের সাথে সংযুক্ত করে যা কালো তালিকাভুক্ত করা যেতে পারে। লগআউটে ক্লায়েন্টের অ্যাক্সেস টোকেনটি মুছে ফেলা উচিত যাতে ২ য় ব্যবহারকারী অ্যাক্সেস পেতে না পারে (যদিও অ্যাক্সেস টোকেন লগআউট করার পরে আরও কয়েক মিনিটের জন্য বৈধ থাকবে)। @ জো ল্যাপ বলেছেন যে একজন হ্যাকার (২ য় ব্যবহারকারী) মুছে ফেলার পরেও অ্যাক্সেস টোকেন পাবে। কিভাবে?
এম

14

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

আমি এটির প্রধান ক্ষতিটি দেখতে পাচ্ছি হ'ল এটি যদি তারা একাধিক ব্রাউজারে থাকে বা তাদের মোবাইল ক্লায়েন্ট থাকে তবে এটি তাদের সমস্ত সেশন থেকে লগ আউট করে।

কোনও সিস্টেমে সমস্ত JWT গুলি অবৈধ করার জন্য এটি একটি দুর্দান্ত প্রক্রিয়াও হতে পারে। চেকটির অংশটি শেষ বৈধ iatসময়ের বৈশ্বিক টাইমস্ট্যাম্পের বিপরীতে হতে পারে ।


1
ভালো চিন্তা! "একটি ডিভাইস" সমস্যা সমাধান করার জন্য এটি লগআউটের পরিবর্তে একটি आकस्मिक বৈশিষ্ট্য তৈরি করা। ব্যবহারকারীর রেকর্ডে একটি তারিখ সংরক্ষণ করুন যা এর আগে জারি করা সমস্ত টোকেনকে অবৈধ করে দেয়। কিছু token_valid_afterবা কিছু। অসাধারণ!
OneHoopyFrood

1
আরে @ ওনিহপি ফ্রিড আমাকে আরও ভালভাবে ধারণাটি বুঝতে সাহায্য করার জন্য আপনার কাছে একটি উদাহরণ কোড রয়েছে? আমি সত্যিই আপনার সাহায্য তারিফ করা!
alexventuraio

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

9

আমি এখানে কিছুটা দেরি করেছি, তবে আমি মনে করি আমার কাছে একটি শালীন সমাধান রয়েছে।

আমার ডাটাবেসে আমার একটি "সর্বশেষ_পাসওয়ার্ড_চেঞ্জ" কলাম রয়েছে যা পাসওয়ার্ডটি সর্বশেষ পরিবর্তন করার সময় তারিখ এবং সময় সংরক্ষণ করে। আমি ইস্যু করার তারিখ / সময় জেডাব্লুটিটিতেও সঞ্চয় করি। একটি টোকেন বৈধকরণের সময়, আমি টোকেন জারি করার পরে পাসওয়ার্ডটি পরিবর্তন করা হয়েছে কিনা তা যাচাই করেছিলাম এবং এটি যদি টোকেন ছিল তবে এটির মেয়াদ শেষ না হওয়া সত্ত্বেও তা প্রত্যাখ্যান করা হয়েছে।


1
আপনি কীভাবে প্রত্যাখ্যান করবেন? আপনি একটি সংক্ষিপ্ত উদাহরণ কোড প্রদর্শন করতে পারেন?
alexventuraio

1
if (jwt.issue_date < user.last_pw_change) { /* not valid, redirect to login */}
ভানুয়ান

15
একটি ডিবি লুকআপ প্রয়োজন!
রব ইভান্স

5

আপনার ব্যবহারকারীর নথি / রেকর্ডে আপনার ডিবিতে একটি "সর্বশেষ_কী_যুক্ত" ক্ষেত্র থাকতে পারে।

যখন ব্যবহারকারী ব্যবহারকারীর সাথে লগ ইন করে এবং পাস করে, একটি নতুন এলোমেলো স্ট্রিং উত্পন্ন করে, এটি সর্বশেষ_কী_যুক্ত ক্ষেত্রে সংরক্ষণ করুন এবং টোকেনে স্বাক্ষর করার সময় পে-লোডে যুক্ত করুন।

যখন ব্যবহারকারী টোকেনটি ব্যবহার করে লগইন করে, টোকেনের সাথে একটিটির সাথে মেলে ডিবিতে সর্বশেষ_কি_টি পরীক্ষা করুন।

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


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

যখন ব্যবহারকারী লগ আউট করে কেবল তখনই কীটি পরিবর্তন করার দরকার নেই, যখন তারা তাদের পাসওয়ার্ড পরিবর্তন করে বা-আপনি এটি সরবরাহ করেন- যখন তারা সমস্ত ডিভাইস থেকে লগ আউট বেছে নেন
নিক ভার্চা

3

মেমরির তালিকার মতো রাখুন

user_id   revoke_tokens_issued_before
-------------------------------------
123       2018-07-02T15:55:33
567       2018-07-01T12:34:21

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


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

@ ব্যবহারকারী 2555515 সমস্ত সার্ভারগুলি ডাটাবেসের সাথে সিঙ্ক্রোনাইজ করা যায়। এটি আপনার পছন্দ হ'ল ডাটাবেসটিকে প্রতিবার আঘাত করা বা না। এটি বলতে পারে যে এটি কী সমস্যা নিয়ে আসে।
এডুয়ার্ডো

3

------------------------ এই উত্তরের জন্য দেরি করলেও এটি কারও পক্ষে সহায়তা করবে ------------- -----------

ক্লায়েন্ট সাইড থেকে, ব্রাউজারের স্টোরেজ থেকে টোকেন সরানো সহজতম উপায়।

তবে, আপনি যদি নোড সার্ভারের টোকেনটি নষ্ট করতে চান তবে -

জেডাব্লুটি প্যাকেজটিতে সমস্যাটি হ'ল এটি টোকেনটি ধ্বংস করার কোনও পদ্ধতি বা উপায় সরবরাহ করে না। আপনি উপরে উল্লিখিত জেডব্লিউটি সম্পর্কিত বিভিন্ন পদ্ধতি ব্যবহার করতে পারেন। তবে এখানে আমি jwt-redis নিয়ে যাই।

সুতরাং সার্ভারসাইডে টোকেনটি ধ্বংস করতে আপনি JWT-redis প্যাকেজটি JWT এর পরিবর্তে ব্যবহার করতে পারেন

এই গ্রন্থাগারটি (jwt-redis) একটি গুরুত্বপূর্ণ সংযোজন সহ লাইব্রেরি jsonwebtoken এর পুরো কার্যকারিতাটি সম্পূর্ণরূপে পুনরুক্ত করে। Jwt-redis আপনাকে বৈধতা যাচাই করতে redis এ টোকেন লেবেল সংরক্ষণ করতে দেয়। রেডিসে টোকেন লেবেলের অনুপস্থিতি টোকেনটিকে বৈধ নয়। Jwt-redis এ টোকেনটি ধ্বংস করতে একটি ধ্বংস পদ্ধতি রয়েছে

এটি এইভাবে কাজ করে:

1) এনপিএম থেকে jwt-redis ইনস্টল করুন

2) তৈরি করতে -

var redis = require('redis');
var JWTR =  require('jwt-redis').default;
var redisClient = redis.createClient();
var jwtr = new JWTR(redisClient);

jwtr.sign(payload, secret)
    .then((token)=>{
            // your code
    })
    .catch((error)=>{
            // error handling
    });

3) যাচাই করতে -

jwtr.verify(token, secret);

4) ধ্বংস করতে -

jwtr.destroy(token)

দ্রষ্টব্য : আপনি JWT তে যেমন সরবরাহ করেছেন তেমন টোকেনের সাইন ইন চলাকালীন মেয়াদ শেষ হতে পারে।

এটি হতে পারে কারও সাহায্য করবে


2

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


হ্যাঁ এটা. ব্যবহারকারীর টেবিল এবং একটি নতুন (সেশন) টেবিলের মধ্যে একের সাথে একাধিক সম্পর্ক তৈরি করতে পারে, যাতে আপনি jti দাবির সাথে মেটা ডেটা সঞ্চয় করতে পারেন।
পিটার লাডা

2
  1. টোকেনগুলির জন্য 1 দিনের মেয়াদোত্তীর্ণ সময় দিন
  2. প্রতিদিনের ব্ল্যাকলিস্ট বজায় রাখুন।
  3. অবৈধ / লগআউট টোকেনগুলি কালো তালিকাতে রাখুন

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

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


4
কালো তালিকাতে টোকেন রাখুন এবং সেখানে আপনার রাষ্ট্রহীনতা চলে যায়
কেরেম বায়ডোয়ান

2

পার্টিতে দেরীতে, আমার গবেষণার পরে দু'টি সেন্ট নীচে দেওয়া হয়েছে। লগআউট করার সময়, নিশ্চিত হয়ে নিন যে নিম্নলিখিত জিনিসগুলি ঘটছে ...

ক্লায়েন্ট স্টোরেজ / সেশন সাফ করুন

লগইন তারিখ-সময় এবং লগআউট তারিখ-সময় যথাক্রমে লগইন বা লগআউট ঘটে ব্যবহারকারী সারণী আপডেট করুন। সুতরাং লগইন তারিখের সময়টি সর্বদা লগআউটের চেয়ে বেশি হওয়া উচিত (বা বর্তমান অবস্থা লগইন থাকলে এবং লগ আউট না হয়ে থাকলে লগআউটের তারিখ নਾਲ রাখুন)

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


2

প্রতি ব্যবহারকারী স্ট্রিং অনন্য, এবং গ্লোবাল স্ট্রিং একসাথে হ্যাশ

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

এখানে একটি উদাহরণ:

HEADER:ALGORITHM & TOKEN TYPE

{
  "alg": "HS256",
  "typ": "JWT"
}
PAYLOAD:DATA

{
  "sub": "1234567890",
  "some": "data",
  "iat": 1516239022
}
VERIFY SIGNATURE

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload), 
  HMACSHA256('perUserString'+'globalString')
)

where HMACSHA256 is your local crypto sha256
  nodejs 
    import sha256 from 'crypto-js/sha256';
    sha256(message);

উদাহরণস্বরূপ ব্যবহারের জন্য https://jwt.io দেখুন (তারা গতিশীল 256 বিট সিক্রেটস পরিচালনা করে তা নিশ্চিত নয়)


1
আরও কিছু বিশদ যথেষ্ট হবে
দৈত্য

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

1

আমি নিম্নলিখিত পদ্ধতিতে এটি করেছি:

  1. একটি তৈরি করুন unique hash, এবং তারপর এ সঞ্চয় redis এবং আপনার JWT । এটিকে একটি অধিবেশন বলা যেতে পারে
    • আমরা সংখ্যা সংরক্ষণ করব অনুরোধ বিশেষ JWT করেছেন - প্রতিটি সময় একটি jwt সার্ভারে পাঠানো, তখন আমরা বাড়ায় অনুরোধ পূর্ণসংখ্যা। (এটি alচ্ছিক)

সুতরাং যখন একটি ব্যবহারকারী লগ, একটি অনন্য হ্যাশ তৈরি করা হয়, redis সঞ্চিত এবং আপনার মধ্যে ইনজেকশনের JWT

একটি ব্যবহারকারী চেষ্টা একটি সুরক্ষিত শেষবিন্দু দেখার জন্য তখন আপনি আপনার থেকে অনন্য অধিবেশন হ্যাশ দখল করব JWT , ক্যোয়ারী redis করুন এবং দেখুন এটি একটি ম্যাচ আছে!

আমরা এটি থেকে প্রসারিত করতে পারি এবং আমাদের জেডাব্লুটিটিকে আরও সুরক্ষিত করতে পারি, এখানে কীভাবে:

প্রতিটি এক্স একটি নির্দিষ্ট জেডাব্লুটি তৈরি করার অনুরোধ করে, আমরা একটি নতুন অনন্য সেশন তৈরি করি, এটি আমাদের জেডাব্লুটিটিতে সঞ্চয় করি এবং তারপরে পূর্ববর্তীটিকে কালো তালিকাভুক্ত করি।

এর অর্থ হ'ল জেডব্লিউটি ক্রমাগত পরিবর্তন করে এবং বাসি জেডাব্লুটিটির হ্যাক, চুরি বা অন্য কিছু হওয়া বন্ধ করে দেয় ।


1
আপনি টোকেন নিজেই হ্যাশ করতে পারেন এবং টোকেনটিতে একটি নতুন হ্যাশ ইনজেকশনের পরিবর্তে সেই মানটি redis এ সঞ্চয় করতে পারেন।
ফ্রুং

জেডাব্লুটিটিতেও পরীক্ষা করে দেখুন audএবং jtiদাবি করুন, আপনি সঠিক পথে আছেন।
পিটার লাদা

1

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

আমি এটি চেষ্টা করে দেখিনি, তবে ডিবি হিটকে ন্যূনতম রাখার সময় টোকেন প্রত্যাহার করার জন্য আমি নীচের পদ্ধতির পরামর্শ দিচ্ছি -

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

প্রতিটি JWT টোকেন গ্রুপ আইডি এবং টোকেন তৈরির সময় তৈরি করা একটি টাইমস্ট্যাম্প ধারণ করবে। যেমন,{ "group_id": 1, "timestamp": 1551861473716 }

সার্ভারের সমস্ত গ্রুপ আইডিকে মেমোরিতে রাখা হবে এবং প্রতিটি গ্রুপের একটি টাইমস্ট্যাম্প থাকবে যা ইঙ্গিত দেয় যে কখন সেই গ্রুপের অন্তর্গত কোনও ব্যবহারকারীর সর্বশেষ লগ-আউট ইভেন্ট ছিল। যেমন,{ "group1": 1551861473714, "group2": 1551861487293, ... }

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

সুতরাং -

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

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

1

যদি "সমস্ত ডিভাইস থেকে লগআউট" বিকল্পটি গ্রহণযোগ্য হয় (বেশিরভাগ ক্ষেত্রে এটি হয়):

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

বেশিরভাগ ক্ষেত্রে ব্যবহারকারীর রেকর্ড পেতে একটি ডিবি ট্রিপ প্রয়োজন যাইহোক তাই এটি বৈধকরণ প্রক্রিয়াতে খুব বেশি ওভারহেড যুক্ত করে না। একটি ব্ল্যাকলিস্ট বজায় রাখার মতো নয়, যেখানে যোগদান বা পৃথক কল ব্যবহারের প্রয়োজনীয়তার কারণে ডিবি লোড তাৎপর্যপূর্ণ, পুরানো রেকর্ডগুলি পরিষ্কার করুন and


0

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

  1. লাস্টভালিডটাইম (ডিফল্ট: তৈরির সময়)
  2. লগ-ইন (ডিফল্ট: সত্য)

যখনই ব্যবহারকারীর কাছ থেকে লগ আউট করার অনুরোধ আসে আমরা লাস্টভালিডটাইমকে বর্তমান সময়ে আপডেট করব এবং লগ-ইনকে মিথ্যে বলব। লগ-ইন অনুরোধ থাকলে আমরা লাস্টভালিডটাইমটি পরিবর্তন করব না তবে লগড-ইনটি সত্য হয়ে যাবে set

আমরা জেডাব্লুটিটি তৈরি করার সময় পে-লোডে জেডব্লিউটি তৈরির সময় পাব। আমরা যখন কোনও পরিষেবার জন্য অনুমোদন দিই আমরা 3 টি শর্ত পরীক্ষা করব

  1. JWT বৈধ
  2. JWT পে-লোড তৈরির সময়টি ব্যবহারকারী লাস্টভালিডটাইমের চেয়ে বেশি
  3. ব্যবহারকারী লগ-ইন করা হয়

একটি বাস্তব দৃশ্য দেখতে দিন।

ইউজার এক্স এর দুটি ডিভাইস এ, বি রয়েছে He সে ডিভাইস এ এবং ডিভাইস বি ব্যবহার করে সন্ধ্যা সাতটায় আমাদের সার্ভারে লগ ইন করেছে (যাক বলুন যে JWT এর মেয়াদ শেষ হওয়ার সময় 12 ঘন্টা)। এ এবং বি উভয়ের জেডব্লিউটি রয়েছে ক্রিয়েটটাইম সহ: সন্ধ্যা। টা

রাত ৯ টায় তিনি তার ডিভাইসটি হারিয়ে ফেলেন immediately

সাড়ে ৯ টায় মিঃ ট্রিফ বি ডিভাইসটি ব্যবহার করে লগ ইন করার চেষ্টা করে আমরা লগ-ইনটিও মিথ্যা বলে ডেটাবেসগুলি পরীক্ষা করে দেখব তাই আমরা অনুমতি দেব না।

রাত ১০ টায় মিঃ এক্স তার ডিভাইস থেকে লগ ইন করুন। এখন ডিভাইসটির তৈরি সময়ের সাথে জেডাব্লুটিটি রয়েছে: রাত ১০ টা। এখন ডাটাবেস লগ-ইন করা হয়েছে "সত্য"

রাত সাড়ে দশটায় মিঃফ্রিফ লগ ইন করার চেষ্টা করেন though যদিও লগ-ইন সত্য। লাস্টভালিডটাইম ডাটাবেজে রাত ৯ টা হলেও বি এর জেডাব্লুটিটি সন্ধ্যা 7 টা হিসাবে সময় তৈরি করেছে। সুতরাং সে পরিষেবাটিতে প্রবেশের অনুমতি পাবে না। সুতরাং পাসওয়ার্ড না রেখে ডিভাইস বি ব্যবহার করে তিনি একটি ডিভাইস লগ আউট করার পরে ইতিমধ্যে তৈরি জেডাব্লুটিটি ব্যবহার করতে পারবেন না।


0

কিএক্লোকের মতো আইএএম সমাধান (যা আমি কাজ করেছি) টোকন প্রত্যাখ্যানের শেষ পয়েন্ট সরবরাহ করে

টোকেন প্রত্যাহার শেষ পয়েন্ট /realms/{realm-name}/protocol/openid-connect/revoke

এর মধ্যে যদি আপনি কেবল কোনও ইউজারেজেন্ট (বা ব্যবহারকারী) লগআউট করতে চান তবে আপনি একটি শেষ পয়েন্টও কল করতে পারেন (এটি কেবল টোকেনকে অবৈধ করে দেবে)। আবার, কিক্লোকের ক্ষেত্রে, রিলিং পার্টিকে কেবল শেষ পয়েন্টটি কল করতে হবে

/realms/{realm-name}/protocol/openid-connect/logout

আপনি আরও জানতে চাইলে লিঙ্ক করুন


-1

এটি প্রতিটি টোকেন যাচাইকরণের উপর ডিবি লুকআপ ছাড়া সমাধান করা সত্যিই কঠিন বলে মনে হচ্ছে। যে বিকল্পটি আমি ভাবতে পারি তা হ'ল অবৈধ টোকেন সার্ভার-সাইডের একটি কালো তালিকা রাখা; বর্তমান ব্ল্যাকলিস্টটি লোড করতে সার্ভারটি পুনরায় চালু করার পরে ডাটাবেসটি পরীক্ষা করে সার্ভারের মাধ্যমে পুনরায় আরম্ভগুলি জুড়ে পরিবর্তনগুলি অবিচ্ছিন্ন করার জন্য কোনও ডাটাবেসে আপডেট করা উচিত।

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

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

এটি কি ভয়ঙ্কর জটিল মনে হচ্ছে? এটা আমার কি!

দাবি অস্বীকার: আমি রেডিস ব্যবহার করিনি।


-1

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

function searchForData() {   // front-end js function, user searches for the data
    // protected route, token that is sent along http request for verification
    var validToken = 'Bearer ' + whereYouStoredToken; // token stored in the browser 

    // route will trigger destroying token when user clicks and executes this func
    axios.post('/my-data', {headers: {'Authorization': validToken}})
     .then((response) => {
   // If Admin set user_enabled in the db as false, we destroy token in the browser localStorage
       if (response.data.user_enabled === false) {  // user_enabled is field in the db
           window.localStorage.clear();  // we destroy token and other credentials
       }  
    });
     .catch((e) => {
       console.log(e);
    });
}

-3

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

আমি মনে করি এটি আমার পক্ষে সেরা সমাধান নয় for


2
অবশ্যই এটি সেরা নয়! ডিবিতে অ্যাক্সেস থাকা যে কেউ সহজেই যে কোনও ব্যবহারকারীর ছদ্মবেশ তৈরি করতে পারেন।
ব্যবহারকারী 2555515

1
@ user2555515 এই সমাধানটি ঠিকঠাক কাজ করে যদি ডাটাবেসে সঞ্চিত টোকেনটি এনক্রিপ্ট করা হয়, ঠিক তেমন ডাটাবেসে থাকা কোনও পাসওয়ার্ডের মতো হওয়া উচিত। Stateless JWTএবং Stateful JWT(যা সেশনের সাথে খুব মিল) এর মধ্যে পার্থক্য রয়েছে । Stateful JWTটোকেন শ্বেত তালিকাটি বজায় রেখে উপকার পেতে পারে।
TheDarkIn1978
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.