জেডব্লিউটি (জেএসএন ওয়েব টোকন) মেয়াদ শেষ হওয়ার স্বয়ংক্রিয়ভাবে দীর্ঘায়িত

Question

আমি আমাদের নতুন REST এপিআইতে JWT- ভিত্তিক প্রমাণীকরণ প্রয়োগ করতে চাই। তবে মেয়াদোত্তীর্ণটি টোকনে সেট করা হওয়ায় এটি কী স্বয়ংক্রিয়ভাবে দীর্ঘায়িত করা সম্ভব? আমি চাই না যে ব্যবহারকারীরা যদি সেই সময়ের মধ্যে সক্রিয়ভাবে অ্যাপ্লিকেশনটি ব্যবহার করে থাকেন তবে প্রতি X মিনিটের পরে সাইন ইন করতে হবে। এটি একটি বিশাল ইউএক্স ব্যর্থ হবে।

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

আমি খুঁজে পেলাম কীভাবে Auth0 এটি সমাধান করেছে। তারা কেবল জেডাব্লুটি টোকেনই নয় একটি রিফ্রেশ টোকনও ব্যবহার করে: https://docs.auth0.com/refresh-token

তবে আবার এটি প্রয়োগ করতে (Auth0 ব্যতীত) আমার রিফ্রেশ টোকেন সংরক্ষণ করতে হবে এবং তাদের মেয়াদ শেষ করতে হবে। তাহলে আসল লাভ কি? কেন কেবল একটি টোকেন নেই (জেডাব্লুটিটি নয়) এবং সার্ভারে মেয়াদ শেষ হবে?

অন্য বিকল্প আছে? JWT ব্যবহার করা কি এই দৃশ্যের জন্য উপযুক্ত নয়?

Comments

প্রকৃতপক্ষে একবারে অনেকগুলি বৈধ টোকেন নিয়ে কোনও সুরক্ষা সমস্যা নেই ... সেখানে বৈধ টোকেনের প্রকৃত অসীম সংখ্যা রয়েছে ... সুতরাং, কেন তখন একটি রিফ্রেশ টোকন রাখবেন? প্রতিটি অনুরোধের পরে আমি তাদের পুনরুত্থিত করব, এটি আসলে কোনও সমস্যা নয়।

— মেরিও

এসপিএর জন্য, আমার ব্লগ পোস্টটি চেকআউট করুন: blog.wong2.me/2017/02/20/refresh-auth0-token-in-spa

— wong2

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

— জাভা-আসক্তি 301

Answer 1

আমি আথ0 এ কাজ করি এবং আমি রিফ্রেশ টোকেন বৈশিষ্ট্যটির নকশায় যুক্ত ছিলাম।

এটি সমস্ত প্রয়োগের ধরণের উপর নির্ভর করে এবং এখানে আমাদের প্রস্তাবিত পদ্ধতি।

ওয়েব অ্যাপ্লিকেশন

একটি ভাল প্যাটার্নটি টোকেনটির মেয়াদ শেষ হওয়ার আগে রিফ্রেশ করা।

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

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

মোবাইল / নেটিভ অ্যাপ্লিকেশন

বেশিরভাগ নেটিভ অ্যাপ্লিকেশনগুলি একবার এবং কেবল একবার লগইন করে।

ধারণাটি হ'ল রিফ্রেশ টোকেন কখনই শেষ হয় না এবং এটি কোনও বৈধ জেডব্লিউটি এর জন্য সর্বদা বিনিময় হতে পারে।

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

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

আমরা বিশ্বাস করি যে JWT এই ব্যবহারের ক্ষেত্রে কার্যকর নয় তাই আমরা একটি এলোমেলোভাবে উত্পন্ন স্ট্রিংটি ব্যবহার করি এবং আমরা এটি আমাদের পাশে সঞ্চয় করি।

Comments

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

— ব্যবহারকারী 12121234

@ ওয়েবেঞ্জ হ্যাঁ বাধা দেওয়া একটি সমস্যা, এমনকি কুকিজ সহ। আপনার https ব্যবহার করা উচিত।

— হোসে এফ রোমানিলো

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

— লো-ট্যান

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

— psamaan

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

— ফিল

Answer 2

আপনি যেখানে লেখককে নিজেরাই পরিচালনা করেন (যেমন Auth0 এর মতো কোনও সরবরাহকারী ব্যবহার করবেন না) সেখানে নিম্নলিখিতগুলি কাজ করতে পারে:

1. অপেক্ষাকৃত স্বল্প মেয়াদ শেষ হওয়ার সাথে জেডাব্লুটি টোকেন ইস্যু করুন, 15 মিনিট বলুন say
2. কোনও টোকেনের প্রয়োজন হয় এমন কোনও লেনদেনের আগে অ্যাপ্লিকেশন টোকেনের সমাপ্তির তারিখটি পরীক্ষা করে (টোকেনের মেয়াদ শেষ হওয়ার তারিখ থাকে)। যদি টোকেনের মেয়াদ শেষ হয়ে গেছে, তবে এটি প্রথমে এপিআইকে টোকেনকে 'রিফ্রেশ' করতে বলবে (এটি ইউএক্সে স্বচ্ছভাবে করা হবে)।
3. এপিআই টোকেন রিফ্রেশ অনুরোধ পেয়েছে, তবে প্রথমে ব্যবহারকারীর ডাটাবেসটি পরীক্ষা করে দেখুন যে সেই ব্যবহারকারীর প্রোফাইলের বিরুদ্ধে 'রিউথ' পতাকা সেট করা হয়েছে কিনা (টোকেনে ব্যবহারকারী আইডি থাকতে পারে)। পতাকা উপস্থিত থাকলে টোকেন রিফ্রেশ অস্বীকার করা হয়, অন্যথায় একটি নতুন টোকেন জারি করা হয়।
4. পদ্ধতি পুনরাবৃত্তি করুন।

ডাটাবেস ব্যাকএন্ডে 'রিউথ' পতাকাটি সেট করা হবে যখন উদাহরণস্বরূপ, ব্যবহারকারী তাদের পাসওয়ার্ড পুনরায় সেট করবেন। ব্যবহারকারী পরবর্তী সময় লগ ইন করলে পতাকাটি সরানো হবে।

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

Comments

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

— ব্যবহারকারী 2924127

@ user2924127 কোনও প্রমাণ সমাধান সঠিক নয় এবং সর্বদা ট্রেড অফস থাকবে। যদি কোনও আক্রমণকারী 'আপনার টোকেন চুরি' করার অবস্থানে থাকে, তবে আপনার উদ্বেগের আরও বড় সমস্যা হতে পারে। সর্বাধিক টোকেন আজীবন সেট করা উপরের দিকে একটি দরকারী টুইঙ্ক হবে।

— ইয়ানবি

ডাটাবেস, রিউথ ফ্ল্যাগে অন্য ক্ষেত্রের পরিবর্তে আপনি টোকনে হ্যাশ (বিক্রিপ্ট_প্যাসওয়ার্ড_হ্যাশ) অন্তর্ভুক্ত করতে পারেন। তারপরে টোকেনকে রিফ্রেশ করার সময়, আপনি কেবলমাত্র নিশ্চিত করে নিন যে হ্যাশ (bcrypt_password_hash) টোকেন থেকে কোনও মানের সমান। টোকেন রিফ্রেশ অস্বীকার করতে, আপনাকে কেবল পাসওয়ার্ড হ্যাশ আপডেট করতে হবে।

— বেস

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

— le0diaz

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

— রাল্ফ

Answer 3

ব্যাকএন্ডে RESTful এপিআই সহ আমাদের অ্যাপ্লিকেশনগুলি HTML5 এ সরিয়ে দেওয়ার সময় আমি ঘোরাঘুরি করছিলাম। আমি যে সমাধানটি নিয়ে এসেছি তা হ'ল:

1. সফল লগইন করার পরে ক্লায়েন্টটি 30 মিনিটের সেশন সময়ের সাথে টোকন দিয়ে জারি করা হয় (বা সাধারণ সার্ভারের সেশন সময়টি যাই হোক না কেন)।
2. টোকেনটির মেয়াদ শেষ হওয়ার আগে পুনর্নবীকরণের জন্য কোনও পরিষেবা কল করার জন্য ক্লায়েন্ট-সাইড টাইমার তৈরি করা হয়। নতুন টোকেন ভবিষ্যতের কলগুলিতে বিদ্যমানগুলি প্রতিস্থাপন করবে।

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

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

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

Comments

কম্পিউটার স্থগিত / ঘুম হলে কি হবে। টাইমারটি এখনও মেয়াদ শেষ না হওয়া পর্যন্ত গণনা করবে তবে টোকেনটি ইতিমধ্যে ইতিমধ্যে শেষ হয়ে গেছে। টাইমার এই পরিস্থিতিতে কাজ করে না

— অ্যালেক্স পারিজ

: @AlexParij তোমার মত এই কিছু একটি নির্দিষ্ট সময় বিরুদ্ধে তুলনা হবে, stackoverflow.com/a/35182296/1038456

— অপরাজিতা

ক্লায়েন্টকে পছন্দসই মেয়াদ শেষ হওয়ার তারিখ সহ একটি নতুন টোকেনের অনুরোধ করার অনুমতি দেওয়া আমার কাছে সুরক্ষা ঝুঁকির মতো গন্ধ পেয়েছে।

— java-addict301

Answer 4

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

একটি নতুন জেডাব্লুটি তৈরি করার সময়, জেডাব্লুটি পেওলোডে এনকোড করুন jwt_version, Jচ্ছিকভাবে আগেই মান বাড়িয়ে দেওয়া হয় যদি নতুন জেডব্লিউটি অন্য সকলকে প্রতিস্থাপন করে।

জেডাব্লুটিটি বৈধকরণের সময়, মাঠটির jwt_versionসাথে তুলনা করা হয় user_idএবং মেলে তবেই অনুমোদন দেওয়া হয়।

Comments

এটিতে একাধিক ডিভাইস নিয়ে সমস্যা রয়েছে। মূলত আপনি যদি একটি ডিভাইসে লগ আউট করেন তবে এটি সর্বত্র লগ আউট করে। রাইট?

— স্যাম ওয়াশবার্ন

আরে, এটি আপনার প্রয়োজনীয়তার উপর নির্ভর করে "সমস্যা" নাও হতে পারে, তবে আপনি ঠিক বলেছেন; এটি প্রতি ডিভাইস সেশন ম্যানেজমেন্টকে সমর্থন করে না।

— অলি বনেট

এর অর্থ কি এই নয় যে jwt_version সার্ভারের পাশে এমনভাবে সংরক্ষণ করতে হবে যা প্রমাণীকরণ স্কিমটি "সেশনের মতো" হয়ে যায় এবং JWTs এর মৌলিক উদ্দেশ্যকে হারায়?

— চিটপ্রিক্লস

Answer 5

ভাল প্রশ্ন- এবং নিজেই প্রশ্নটিতে তথ্য প্রচুর আছে।

নিবন্ধ রিফ্রেশ টোকেন: যখন তাদের ব্যবহার করার জন্য এবং কিভাবে সেগুলি ইন্টারঅ্যাক্ট JWTs সঙ্গে এই দৃশ্যকল্প জন্য একটি ভাল ধারণা দেয়। কিছু বিষয়:

• রিফ্রেশ টোকেনগুলি একটি নতুন অ্যাক্সেস টোকেন পেতে প্রয়োজনীয় তথ্য বহন করে।
• রিফ্রেশ টোকেনগুলির মেয়াদও শেষ হতে পারে তবে এটি দীর্ঘজীবী long
• রিফ্রেশ টোকেনগুলি সাধারণত ফাঁস না হওয়ার বিষয়টি নিশ্চিত করার জন্য কঠোর স্টোরেজ প্রয়োজনীয়তার সাপেক্ষে।
• এগুলি অনুমোদনের সার্ভার দ্বারা কালো তালিকাভুক্ত করা যেতে পারে।

এছাড়াও একবার দেখুন auth0 / কৌণিক- jwt Angularjs দেখুন

ওয়েব এপিআই এর জন্য। পড়া এএসপি ডট নেট ওয়েব এপিআই 2 ব্যবহার সক্ষম করুন AngularJS অ্যাপ OAuth এর রিফ্রেশ টোকেন এবং Owin

Comments

হয়তো আমি এটি ভুল পড়েছি ... তবে একটি শিরোনাম সহ নিবন্ধ যা "রিফ্রেশ টোকেন ..." হিসাবে শুরু হয় আপনি এখানে উল্লেখ করেছেন তা বাদ দিয়ে রিফ্রেশ টোকেন সম্পর্কে কিছুই নেই।

— আইভজেন মার্টিনভ

Answer 6

আমি প্রকৃতপক্ষে পিএইচপি-তে এটি প্রয়োগ করে গুজল ক্লায়েন্টকে এপিআইয়ের জন্য একটি ক্লায়েন্ট লাইব্রেরি তৈরি করেছিলাম, তবে ধারণাটি অন্যান্য প্ল্যাটফর্মগুলির জন্য কাজ করা উচিত।

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

যদি সংক্ষিপ্ত টোকেনটির মেয়াদ শেষ হয়ে যায়, তবে এখনও খাঁটি এবং লং টোকেনটি বৈধ এবং খাঁটি হয় তবে এটি পরিষেবাটিতে একটি বিশেষ শেষ পয়েন্ট ব্যবহার করে শর্ট টোকনকে রিফ্রেশ করবে যে দীর্ঘ টোকেনটি অনুমোদন দেয় (এটি কেবলমাত্র এটির জন্য ব্যবহার করা যেতে পারে)। এরপরে এটি একটি নতুন দীর্ঘ টোকেন পেতে শর্ট টোকন ব্যবহার করবে, এরপরে এটি প্রতিবার সংক্ষিপ্ত টোকনকে রিফ্রেশ করে আরও এক সপ্তাহ বাড়িয়ে দেবে।

এই পদ্ধতিটি আমাদের সর্বাধিক 5 মিনিটের মধ্যে অ্যাক্সেস প্রত্যাহার করার অনুমতি দেয়, যা টোকেনের একটি কালো তালিকা বাদ না দিয়ে আমাদের ব্যবহারের জন্য গ্রহণযোগ্য।

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

Answer 7

নীচে আপনার JWT অ্যাক্সেস টোকেন প্রত্যাহার করার পদক্ষেপগুলি রয়েছে:

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

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

Comments

আপনি কি দয়া করে আপনার প্রকল্পের লিঙ্কটি যদি গিটহাবে থাকে তবে ভাগ করে নিতে পারেন?

— অরুণ কুমার এন

লিঙ্কটির জন্য এখানে ক্লিক করুন

— ভূপিন্দর সিং

Answer 8

jwt-স্বয়ংক্রিয়-রিফ্রেশ

আপনি যদি নোড ব্যবহার করেন (প্রতিক্রিয়া / রেডাক্স / ইউনিভার্সাল জেএস) আপনি ইনস্টল করতে পারেন npm i -S jwt-autorefresh।

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

সম্পূর্ণ উদাহরণ বাস্তবায়ন

import autorefresh from 'jwt-autorefresh'

/** Events in your app that are triggered when your user becomes authorized or deauthorized. */
import { onAuthorize, onDeauthorize } from './events'

/** Your refresh token mechanism, returning a promise that resolves to the new access tokenFunction (library does not care about your method of persisting tokens) */
const refresh = () => {
  const init =  { method: 'POST'
                , headers: { 'Content-Type': `application/x-www-form-urlencoded` }
                , body: `refresh_token=${localStorage.refresh_token}&grant_type=refresh_token`
                }
  return fetch('/oauth/token', init)
    .then(res => res.json())
    .then(({ token_type, access_token, expires_in, refresh_token }) => {
      localStorage.access_token = access_token
      localStorage.refresh_token = refresh_token
      return access_token
    })
}

/** You supply a leadSeconds number or function that generates a number of seconds that the refresh should occur prior to the access token expiring */
const leadSeconds = () => {
  /** Generate random additional seconds (up to 30 in this case) to append to the lead time to ensure multiple clients dont schedule simultaneous refresh */
  const jitter = Math.floor(Math.random() * 30)

  /** Schedule autorefresh to occur 60 to 90 seconds prior to token expiration */
  return 60 + jitter
}

let start = autorefresh({ refresh, leadSeconds })
let cancel = () => {}
onAuthorize(access_token => {
  cancel()
  cancel = start(access_token)
})

onDeauthorize(() => cancel())

দাবি অস্বীকার: আমি রক্ষণাবেক্ষণকারী

Comments

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

— জিয়ান ফ্রাঙ্কো জবারিনো

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

— চেম্বারলাইন

ওহ জেনে রাখা ভাল, কিছু বোঝার ছিল না তবে এখন তা করে। উত্তরের জন্য ধন্যবাদ.

— জিয়ান ফ্রাঙ্কো জবারিনো

Answer 9

টোকেন ডেটাতে ভেরিয়েবল যুক্ত করে আমি এই সমস্যাটি সমাধান করেছি:

softexp - I set this to 5 mins (300 seconds)

expiresInব্যবহারকারীকে আবার লগইন করতে বাধ্য করার আগে আমি আমার কাঙ্ক্ষিত সময়ে বিকল্প সেট করেছিলাম । খনি 30 মিনিটে সেট করা আছে। এটির মানটির চেয়ে বড় হওয়া আবশ্যক softexp।

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

যদি টোকেনটি এখনও expiredInমানের ভিত্তিতে বৈধ হয় তবে এটি ইতিমধ্যে softexpমানটি ছাড়িয়ে গেছে তবে সার্ভারটি এই ত্রুটির জন্য পৃথক স্থিতিতে প্রতিক্রিয়া জানাবে, যেমন। EXPIRED_TOKEN:

(Math.floor(Date.now() / 1000) > decoded.softexp)

ক্লায়েন্টের পক্ষ থেকে, যদি এটি EXPIRED_TOKENপ্রতিক্রিয়া পেয়ে থাকে তবে এটি সার্ভারে পুনর্নবীকরণের অনুরোধ প্রেরণ করে স্বয়ংক্রিয়ভাবে টোকনটি পুনর্নবীকরণ করা উচিত। এটি ব্যবহারকারীর কাছে স্বচ্ছ এবং স্বয়ংক্রিয়ভাবে ক্লায়েন্ট অ্যাপের যত্ন নেওয়া হচ্ছে।

সার্ভারে নবায়ন পদ্ধতিতে টোকেনটি এখনও বৈধ কিনা তা অবশ্যই পরীক্ষা করতে হবে:

jwt.verify(token, secret, (err, decoded) => {})

সার্ভারটি উপরের পদ্ধতিটিতে ব্যর্থ হলে টোকেনগুলি নবায়ন করতে অস্বীকার করবে।

Comments

এই কৌশলটি ভাল দেখাচ্ছে। তবে আমি মনে করি এক ধরণের "সর্বাধিক পরিমাণ পুনর্নবীকরণ" দিয়ে পরিপূরক হওয়া উচিত কারণ (সম্ভবত) একজন ব্যবহারকারী সেশিয়ান চিরকাল বেঁচে থাকতে পারেন।

— জুয়ান ইগনাসিও বারিসিচ

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

— জেমস এ

এটাই সঠিক. আমি এটিকে "আবশ্যক" হিসাবে বিবেচনা করি।

— হুয়ান ইগনাসিও ব্যারিশিচ

Answer 10

এই পদ্ধতির সম্পর্কে কীভাবে:

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

এই ক্ষেত্রে টোকেনটি রিফ্রেশ করার জন্য আমাদের অতিরিক্ত শেষ পয়েন্টের প্রয়োজন নেই। যে কোনও ফিডাককে প্রশংসা করবে।

Comments

এটি কি এই দিনটিতে একটি ভাল পছন্দ, বাস্তবায়নের জন্য এটি দেখতে বেশ সহজ।

— বি.বেইন

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

— antgar9

Answer 11

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

তাহলে আসল লাভ কি? কেন কেবল একটি টোকেন নেই (জেডাব্লুটিটি নয়) এবং সার্ভারে মেয়াদ শেষ হবে?

অন্য বিকল্প আছে? JWT ব্যবহার করা কি এই দৃশ্যের জন্য উপযুক্ত নয়?

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

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

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

এই ত্রুটিগুলি আরও বিশদে ব্যাখ্যা করে একটি পোস্ট লিখেছিলাম । পরিষ্কার হওয়ার জন্য, আপনি আরও জটিলতা (স্লাইডিং সেশন, রিফ্রেশ টোকেন ইত্যাদি) যোগ করে এগুলি ঘিরে কাজ করতে পারেন

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