একটি RESTful API এ টোকেন নবায়ন / সেশনের মেয়াদ শেষ হবে Hand

Question

আমি একটি RESTful API তৈরি করছি যা ব্যবহারকারীর প্রমাণীকরণের জন্য JWT টোকেন ব্যবহার করে (একটি loginশেষ পয়েন্ট দ্বারা ইস্যু করা এবং পরে সমস্ত শিরোনামে প্রেরণ করা হয়), এবং টোকেনগুলি একটি নির্দিষ্ট সময়ের পরে পুনরায় রিফ্রেশ করা দরকার (একটি renewশেষ পয়েন্টকে অনুরোধ করে, যা একটি পুনর্নবীকরণ টোকেন দেয় )।

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

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

1. সেশনটি অবৈধ হয়ে গেছে বা টোকেনটির মেয়াদ শেষ হয়ে গেলে 412 কোড (পূর্বশর্ত ব্যর্থ হয়েছে) renewফিরে আসার পরে এবং শেষের পয়েন্টে কল করার সময়টি , যা একটি 200 (ঠিক আছে) কোডটি ফিরিয়ে দেবে এমন একটি HTTP 401 কোড (অননুমোদিত) ফেরত করুন ।
2. 401 রিটার্ন করুন যে সেশনটি অবৈধ বা টোকেনের মেয়াদ শেষ হয়ে গেছে aling এই ক্ষেত্রে ক্লায়েন্ট অবিলম্বে renewশেষ পয়েন্টটি কল করবে , যদি এটি 200 ফেরত দেয় তবে টোকেনটি রিফ্রেশ হয়, তবে যদি renew401 ফেরত দেয় তবে এর অর্থ ক্লায়েন্ট সিস্টেমের বাইরে চলে গেছে।

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

হালনাগাদ

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

Comments

টোকেনের মেয়াদ শেষ হওয়ার আগে কোনও ব্যবহারকারীর অধিবেশন কীভাবে অবৈধ হয়ে উঠবে, একটি সংক্ষিপ্ত (প্রায় 5 মিনিট) মেয়াদ উত্তীর্ণের সময় ধরে?

— জ্যাক

ব্যবসায়ের নিয়মের কারণে, সিস্টেমের একটি আলাদা অংশ সেশনটি অবৈধ করতে পারে।

— অস্কার লোপেজ

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

— জ্যাক

@ জ্যাক ঠিক! এটাই আমার বক্তব্য, এবং সেশন তথ্য সংরক্ষণের জন্য আমাকে অতিরিক্ত, রাষ্ট্রীয় স্তর ব্যবহার করার কারণ। সরল জেডাব্লুটিটি, এটি যেমন দুর্দান্ত হতে পারে, কেবল কাজের জন্য কাটেনি।

— অস্কার লোপেজ

আপনি তখন আমার

— জ্যাক

Answer 1

এই একটি ক্ষেত্রে মত শোনাচ্ছে প্রমাণীকরণ বনাম অনুমোদন ।

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

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

পরিস্থিতি এ - প্রমাণীকরণ

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

পরিস্থিতি বি - অনুমোদন

• বব: "হ্যালো জিম, আমি সীমাবদ্ধ স্টোরেজ প্রবেশ করতে চাই Here এখানে আমার ব্যাজ" "
• জিম: "আরে বব, এখানে toোকার জন্য আপনার স্তরের 2 স্তরের ছাড়পত্র প্রয়োজন Sorry দুঃখিত।"

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

এই দুটি ক্ষেত্রে স্বতন্ত্র HTTP প্রতিক্রিয়া কোড রয়েছে: 401 Unauthorizedএবং 403 Forbidden। দুর্ভাগ্যক্রমে নামের 401 কোডটি প্রমাণীকরণের জন্য যেমন নিখোঁজ, মেয়াদোত্তীর্ণ বা বাতিল হওয়া শংসাপত্রগুলির জন্য। 403 অনুমোদনের জন্য, যেখানে সার্ভারটি হুবহু জানেন যে আপনি কে কিন্তু আপনাকে যে জিনিসটি করার চেষ্টা করছেন তা করার অনুমতি আপনার কাছে নেই। কোনও ব্যবহারকারীর অ্যাকাউন্ট মুছে ফেলার ক্ষেত্রে, শেষ প্রান্তে জেডাব্লুটিটির সাথে কিছু করার চেষ্টা করার ফলে 403 নিষিদ্ধ প্রতিক্রিয়া দেখা দেয়। তবে, JWT এর মেয়াদ শেষ হলে সঠিক ফলাফল হবে 401 অননুমোদিত।

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

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

Comments

এটি সেই নির্দেশিকা যা আমি সন্ধান করছিলাম এবং আপনি আলোচনার জন্য খুব প্রাসঙ্গিক অন্তর্দৃষ্টি এনেছিলেন - এটি প্রমাণীকরণ বনাম অনুমোদনের ক্ষেত্রে এবং প্রতিটি ক্ষেত্রেই আলাদাভাবে আচরণ করা উচিত। ধন্যবাদ!

— অস্কার লোপেজ

Answer 2

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

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

আপনি যখন পুরোপুরি সেশনটি সরিয়ে ফেলেন, আপনি যদি একটি RESTful API এর জন্য লক্ষ্য রেখে থাকেন এবং কেবল JWT কে একটি প্রমাণীকরণকারী ফ্যাক্টর হিসাবে ব্যবহার করেন, তখন কোনও ব্যবহারকারী আপনার শেষ পয়েন্টটি ব্যবহার করার জন্য অনুমোদিত হয় বা না - এই ক্ষেত্রে 401 Unauthorizedপ্রতিক্রিয়া কোডটি উপযুক্ত - এবং আপনি যে পুনর্নবীকরণটি ব্যবহার করছেন তা সনাক্তকরণের renewসাথে grant_type=refresh_tokenবা শেষ পয়েন্টটি কল করতে হবে।

হালনাগাদ:

মন্তব্য থেকে দেখে মনে হচ্ছে আপনি বর্তমানে যে JWT ব্যবহার করছেন তার বৈধতা প্রবাহটি সঠিক নয়। যাচাইকরণটি এর মতো দেখতে পাওয়া যায়:

  Client        RESTful API      JWT Issuer
     |              |                |
     |----- 1. ---->|                | 
     |              |------ 2. ----->|-----
     |              |                | 3. |
     |              |<----- 4. ------|<----
-----|<---- 5. -----|                |
| 6. |              |                |
---->|----- 7. ---->|                |
     |              |------ 8. ----->|-----
     |              |                | 9. |
     |              |<----- 10. -----|<----
     |              |                |
     |              |------          |
     |              | 11. |          |
     |<---- 12. ----|<-----          |
     |              |                |
     .              .                .

1. Ask RESTful API for a JWT using login endpoint.
2. Ask Issuer to create a new JWT.
3. Create JWT.
4. Return JWT to the RESTful API.
5. Return JWT to Client.
6. Store JWT to append it to all future API requests.
7. Ask for data from API providing JWT as authorization.
8. Send JWT to Issuer for verification.
9. Issuer verifies JWT.
10. Issuer returns 200 OK, verification successful.
11. Retrieve and format data for Client.
12. Return data to Client.

সার্ভারটি, RESTful APIঅনুমোদনের হিসাবে প্রেরণ করা টোকেনের বৈধতা যাচাই করতে হবে। এটা দায়দায়িত্ব নয় Client। দেখে মনে হচ্ছে আপনি বর্তমানে এটি করছেন না। JWT এর যাচাইকরণটি এভাবে প্রয়োগ করুন এবং আপনার কোনও সেশনের দরকার নেই।

Comments

আপনার উত্তরের জন্য ধন্যবাদ. সম্মত হয়েছি, একটি অধিবেশন ব্যবহার করা 100% বিশ্রামপ্রাপ্ত পদ্ধতির হবে না, তবে আমি উপরে উল্লিখিত হিসাবে, টোকেনের মেয়াদ শেষ হওয়ার আগে আমাকে কিছু ব্যবহারকারীর অ্যাক্সেস অস্বীকার করতে হবে।

— এসকর লোপেজ

@ ÓscarLópez তারপরে ব্যবহারকারীরা যে টোকেনগুলি ব্যবহার করছেন তা কেবল অবৈধ করুন। তারা প্রদত্ত টোকেন (যা এখন অবৈধ হয়ে যাবে) ব্যবহার করে আর এপিআই অ্যাক্সেস করতে পারবে না এবং আপনার কোনও সেশনের দরকার নেই।

— অ্যান্ডি

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

— ইস্কার লোপেজ

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

— এস্কার লোপেজ

@ লাইভ আমি নোটপ্যাডে সিক্যুয়েন্স ডায়াগ্রাম তৈরি করেছি।

— অ্যান্ডি 21

Answer 3

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

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

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

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

Comments

jwt এর অর্থ রাষ্ট্রহীন। যে মুহুর্তে আপনি এর বিষয়বস্তুটি প্রশ্ন করবেন এবং এটি একটি ডিবি-এর বিপরীতে বৈধ করেছেন,

— রাষ্ট্রক্ষেত্র