REST এপিআই টোকেন-ভিত্তিক প্রমাণীকরণ

Question

আমি একটি REST এপিআই বিকাশ করছি যার প্রমাণীকরণ প্রয়োজন। এইচটিটিপি-র মাধ্যমে প্রমাণীকরণটি একটি বাহ্যিক ওয়েবসার্চির মাধ্যমে ঘটে তাই আমি যুক্তি দিয়েছিলাম যে আমরা বার বার প্রমাণীকরণ পরিষেবাটি কল করা এড়াতে টোকেন সরবরাহ করব ens যা আমার প্রথম প্রশ্নের ঝরঝরে আমাকে এনেছে:

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

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

বর্তমানে টোকেনগুলি এই জাতীয়ভাবে অর্জিত হয়:

curl -X POST localhost/token --data "api_key=81169d80...
                                     &verifier=2f5ae51a...
                                     &timestamp=1234567
                                     &user=foo
                                     &pass=bar"

api_key, timestampএবং verifierসমস্ত অনুরোধ দ্বারা প্রয়োজন হয়। "যাচাইকারী" এর দ্বারা ফিরে আসে:

sha1(timestamp + api_key + shared_secret)

আমার উদ্দেশ্য হ'ল কেবল পরিচিত দলগুলির কলকে মঞ্জুরি দেওয়া এবং কলগুলি পুনরায় ব্যবহার থেকে বিরত রাখা।

এটা কি যথেষ্ট? Underkill? Overkill?

একটি টোকেন হাতে রেখে, ক্লায়েন্টরা সংস্থানগুলি অর্জন করতে পারে:

curl localhost/posts?api_key=81169d80...
                    &verifier=81169d80...
                    &token=9fUyas64...
                    &timestamp=1234567

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

Comments

Sha1 (টাইমস্ট্যাম্প + এপিআইকি + শারদ_সেক্রেট) ব্যবহার না করে আপনার উন্নত সুরক্ষার জন্য এনএইচ উইকিপিডিয়া.org / উইকি / হ্যাশ- বেসড_মেসেজ_অথেন্টিকেশন_কোড

— মিগুয়েল এ।

@ মিগুয়েলএ.ক্যারাসকো এবং 2017 এর মধ্যে theক্যমত্য বলে মনে হচ্ছে যে বিক্রিপ্ট হ্যাশিংয়ের নতুন সরঞ্জাম।

— শন

Answer 1

আমাকে সমস্ত কিছু আলাদা করতে এবং বিচ্ছিন্নভাবে প্রতিটি সমস্যার পদ্ধতির সমাধান করতে দিন:

প্রমাণীকরণ

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

আথ সার্ভার লোড

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

সংক্রমণ সুরক্ষা

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

url = username:[e-mail]/api/call/nonce

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

nonce = generate_secure_password(length: 16);
one_time_key = nonce + '-' + sha1(nonce+salt+shared_key);
url = username:[e-mail]/api/call

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

সুরক্ষিত গোপন স্টোরেজ

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

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

(*) সম্পাদনা করুন: এসএসএল সংযোগগুলি তাদের যাচাই করার জন্য অতিরিক্ত পদক্ষেপ না নিয়ে আর নিরাপদ হিসাবে বিবেচনা করা উচিত নয় ।

Comments

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

— ক্যান্টলিন

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

— জাস্টামার্টিন

Answer 2

একটি খাঁটি RESTful API এর অন্তর্নিহিত প্রোটোকল স্ট্যান্ডার্ড বৈশিষ্ট্যগুলি ব্যবহার করা উচিত:

1. এইচটিটিপি-র জন্য, আরএসএসএফুল এপিআইয়ের বিদ্যমান এইচটিটিপি স্ট্যান্ডার্ড শিরোনামগুলির সাথে সম্মতি জানানো উচিত। নতুন এইচটিটিপি শিরোনাম যুক্ত করা REST নীতিগুলি লঙ্ঘন করে। চাকাটি পুনরায় উদ্ভাবন করবেন না, এইচটিটিপি / 1.1 মানকগুলিতে সমস্ত স্ট্যান্ডার্ড বৈশিষ্ট্যগুলি ব্যবহার করুন - স্ট্যাটাস রেসপন্স কোড, শিরোনাম এবং আরও কিছু সহ। আরআরএসটিফুল ওয়েব পরিষেবাদিগুলির এইচটিটিপি স্ট্যান্ডার্ডগুলির উপর নির্ভর করা এবং নির্ভর করা উচিত।

2. বিশ্রামের পরিষেবাগুলি অবশ্যই স্ট্যাটলেস থাকতে হবে। কোনও কৌশল, যেমন টোকেন ভিত্তিক প্রমাণীকরণ যা সার্ভারে পূর্ববর্তী REST অনুরোধগুলির স্থিতি মনে রাখার চেষ্টা করে তবে REST নীতিগুলি লঙ্ঘন করে। আবার, এটি একটি আবশ্যক; এটি হ'ল, যদি আপনি ওয়েব সার্ভার সার্ভারে যে কোনও অনুরোধ / প্রতিক্রিয়া প্রসঙ্গে সম্পর্কিত তথ্য সার্ভারে কোনও ধরণের সেশন স্থাপনের চেষ্টা করে সংরক্ষণ করেন, তবে আপনার ওয়েব পরিষেবা স্টেটলেস নয়। এবং এটি রাষ্ট্রবিহীন না হলে এটি বিশ্রাম নয়।

নীচের লাইন: প্রমাণীকরণ / অনুমোদনের উদ্দেশ্যে আপনার HTTP স্ট্যান্ডার্ড অনুমোদনের শিরোনাম ব্যবহার করা উচিত। এটি হ'ল, পরবর্তী প্রতিটি অনুরোধে আপনার প্রমাণীকরণের প্রয়োজন এমন HTTP অনুমোদন / প্রমাণীকরণ শিরোনাম যুক্ত করা উচিত। আরআরএসআইপি এইচটিটিপি প্রমাণীকরণ প্রকল্পের মান অনুসরণ করা উচিত this এই শিরোনামটি কীভাবে ফর্ম্যাট করা উচিত তার নির্দিষ্ট বিবরণগুলি আরএফসি 2616 HTTP 1.1 মানগুলিতে সংজ্ঞায়িত করা হয়েছে - বিভাগ 14.8 আরএফসি 2616 এর অনুমোদন, এবং আরএফসি 2617 HTTP প্রমাণীকরণ: বেসিক এবং ডাইজেস্ট অ্যাক্সেস প্রমাণীকরণ ।

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

Comments

"নতুন এইচটিটিপি শিরোনাম যুক্ত করা REST নীতিগুলিকে লঙ্ঘন করে" কীভাবে? এবং আপনি যদি এটির কাছে থাকেন তবে আপনি নির্দিষ্ট সময় পরে মেয়াদ শেষ হয়ে যাওয়া পাসওয়ার্ড এবং একটি নির্দিষ্ট সময়ের পরে মেয়াদ শেষ হওয়ার একটি টোকেনের মধ্যে ঠিক কী পার্থক্য (নীতিগুলি সম্পর্কে) তা বোঝাতে খুব দয়াবান হতে পারেন।

— আরও ভাল অলিভার

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

— আরও ভাল অলিভার

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

— জেপিকে

-1 "সার্ভারে পূর্ববর্তী REST অনুরোধগুলির স্থিতি স্মরণ করার চেষ্টা করে এমন টোকন-ভিত্তিক প্রমাণীকরণের মতো কোনও কৌশলগুলি REST নীতিগুলি লঙ্ঘন করে" " টোকেন ভিত্তিক প্রমাণীকরণের পূর্ববর্তী আরএসটি অনুরোধগুলির স্থিতির সাথে কোনও সম্পর্ক নেই এবং এটি আরইএসটি-র রাষ্ট্রহীনতা লঙ্ঘন করে না ।

— কেরেম বায়ডোয়ান

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

— জাস্টামার্টিন

Answer 3

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

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

আমি বুঝতে পেরেছি যে ডাকা হয় এমন অনেকগুলি REST সরবরাহকারী এইচটিটিপি শিরোনামে "অনুমোদন: বহনকারী" হিসাবে পাস করার জন্য OAuth1 বা OAuth2 গ্রহণযোগ্য-টোকেনের মতো টোকেন ব্যবহার করছেন। যাইহোক, আমার কাছে এটি উপস্থিত হয় যে এই টোকেনগুলি RESTful পরিষেবাদির জন্য ব্যবহার করা সত্যিকারের স্টেটলেসের অর্থ লঙ্ঘন করবে যার অর্থ REST আলিঙ্গন করে; কারণ সেই টোকেন হয় অস্থায়ী নির্মিত ডেটার টুকরা / একটি ওয়েব ক্লায়েন্ট / সার্ভার কথোপকথনের বৈধ সময়কাল জন্য কোনো সুনির্দিষ্ট ওয়েব ক্লায়েন্ট ইউজার এজেন্ট চিহ্নিত করতে সার্ভার প্রান্তের উপর বজায় রেখেছিল। অতএব, যদি আমরা কোনও স্টেটলাস প্রোটোকলের সত্যিকার অর্থে আঁকতে চাই তবে যে সমস্ত পরিষেবা O OAuth1 / 2 টোকেনগুলি ব্যবহার করছে তাকে REST বলা উচিত নয়।

রুবেনস