ওআউথ ২.০ বেরিয়ার টোকেন ঠিক কী?


171

মতে RFC6750 বিয়ারার টোকেন ব্যবহার, বাহক হয় টোকেন: স্বয়ংক্রিয়ভাবে OAuth এর 2.0 অনুমোদন ফ্রেমওয়ার্ক:

টোকেনের দখলে থাকা কোনও পক্ষ ("" ধারক ") যে সংস্থার মালিকানাধীন অন্য কোনও পক্ষ যেভাবেই টোকনটি ব্যবহার করতে পারে সেই সম্পত্তির সাথে সুরক্ষা টোকেন।

আমার কাছে এই সংজ্ঞাটি অস্পষ্ট এবং আমি কোনও স্পেসিফিকেশন পাই না।

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

যে কোনও পয়েন্টারের জন্য আপনাকে ধন্যবাদ।


ধরুন আমি কোনও অনুমোদন প্রদানকারীকে প্রয়োগ করছি, আমি কি বাহক টোকেনের জন্য কোনও ধরণের স্ট্রিং সরবরাহ করতে পারি? এটি কি এলোমেলো স্ট্রিং হতে পারে? অ্যাক্সেস টোকেনগুলি Auth0 এর OAuth 2.0 2.0 পয়েন্ট: / অনুমোদন এবং / oauth / টোকেনের মাধ্যমে জারি করা হয়। অ্যাক্সেস টোকেনগুলি পেতে আপনি যে কোনও OAuth 2.0- সামঞ্জস্যপূর্ণ লাইব্রেরি ব্যবহার করতে পারেন। আপনার যদি ইতিমধ্যে পছন্দসই OAuth 2.0 লাইব্রেরি না থাকে তবে Auth0 অনেক ভাষা এবং ফ্রেমওয়ার্কের জন্য লাইব্রেরি সরবরাহ করে।
ভরথকুমার ভি

উত্তর:


146

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

বিয়ারার টোকেন প্রমাণীকরণ সার্ভার দ্বারা আপনার জন্য তৈরি করা হয়েছে। যখন কোনও ব্যবহারকারী আপনার অ্যাপ্লিকেশনটিকে (ক্লায়েন্ট) প্রমাণীকরণ করে তবে প্রমাণীকরণের সার্ভারটি গিয়ে আপনার জন্য একটি টোকেন তৈরি করে। বহনকারী টোকেনগুলি OAuth 2.0 এর সাথে ব্যবহৃত প্রকারের অ্যাক্সেস টোকেন। একজন বহনকারী টোকেন মূলত "এই টোকেন অ্যাক্সেসের বাহককে দিন" বলে।

বিয়ারার টোকেন সাধারণত প্রমাণীকরণ সার্ভার দ্বারা তৈরি এক ধরণের অস্বচ্ছ মান। এটি এলোমেলো নয়; এটি আপনাকে অ্যাক্সেস দেওয়ার ব্যবহারকারী এবং ক্লায়েন্টকে আপনার অ্যাপ্লিকেশন অ্যাক্সেস দিচ্ছে তার ভিত্তিতে এটি তৈরি করা হয়েছে।

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

গুগল রিফ্রেশ টোকেন এর মতো দেখতে দেখতে: 1 / mZ1edKKACtPAb7zGlwSzvs72PvhAbGmB8K1ZrGxpcNM

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

হালনাগাদ:

বিয়ারার টোকেন প্রতিটি ইনলাইন অ্যাকশন HTTP অনুরোধের অনুমোদনের শিরোনামে সেট করা থাকে। উদাহরণ স্বরূপ:

POST /rsvp?eventId=123 HTTP/1.1
Host: events-organizer.com
Authorization: Bearer AbCdEf123456
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/1.0 (KHTML, like Gecko; Gmail Actions)

rsvpStatus=YES

"AbCdEf123456"উপরের উদাহরণের স্ট্রিংটি বাহক অনুমোদনের টোকেন। এটি প্রমাণীকরণ সার্ভার দ্বারা উত্পাদিত একটি ক্রিপ্টোগ্রাফিক টোকেন। ক্রিয়াসমূহ সহ প্রেরিত সমস্ত বাহক টোকেনগুলির ইস্যু ক্ষেত্র রয়েছে, দর্শকের ক্ষেত্রে প্রেরক ডোমেনটি https: // ফর্মের URL হিসাবে নির্দিষ্ট করে। উদাহরণস্বরূপ, ইমেলটি যদি noreply@example.com থেকে আসে তবে শ্রোতা https://example.com

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

বহনকারী টোকেনগুলি OAuth V2 স্ট্যান্ডার্ডের একটি অংশ এবং বহু API দ্বারা ব্যাপকভাবে গৃহীত।


2
@ জাভিয়ের ইজিয়া বেরার টোকেন মূলত আপনার রিফ্রেশ টোকেন এবং অ্যাক্সেস টোকেন নয়।
আখিল নাম্বিয়ার

13
টোকেন বিয়ারার তার একটি রিফ্রেশ টোকেন @AqeelSmith মানে এই নয় tools.ietf.org/html/rfc6750#section-6.1.1
সুমন কুন্ডু

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

8
উত্তরটি পড়ার পরে আমিও ভাবলাম বেরার টোকেন এবং রিফ্রেশ টোকেনগুলি একই। এটি পরিষ্কার করার জন্য উত্তরটি আপডেট করা উচিত।
KurioZ7

2
এই উত্তরটি খুব বিভ্রান্তিকর। এই উত্তরের প্রাথমিক বিবৃতি অনুসারে বহনকারী টোকেন টোকেনকে রিফ্রেশ করবেন না। সংশোধন করুন.
01

67

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

তবে আপনার প্রশ্নটি বেরার টোকেন কার্যকারিতাটির উত্তর খুঁজে পাওয়ার চেষ্টা করছে বলে মনে হচ্ছে:

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

সুতরাং, আমি কীভাবে বেয়ার টোকেন এবং টোকেন টোকেনগুলি কাজ করে তা বোঝানোর চেষ্টা করব:

ব্যবহারকারী যখন এসএসএলের মাধ্যমে টোকেন প্রেরণকারী ব্যবহারকারী এবং পাসওয়ার্ডের জন্য সার্ভারে অনুরোধ করেন, সার্ভার দুটি জিনিস ফেরত দেয়: একটি অ্যাক্সেস টোকেন এবং একটি রিফ্রেশ টোকেন

অ্যাক্সেস টোকেন এমন একটি বেয়ার টোকেন যা আপনাকে কংক্রিট ব্যবহারকারী হিসাবে প্রমাণীকরণের জন্য সমস্ত অনুরোধ শিরোনাম যুক্ত করতে হবে।

Authorization: Bearer <access_token>

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

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

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

রিফ্রেশ টোকেনগুলি ডিবিতে সংরক্ষণ করা হয় এবং এর দীর্ঘ মেয়াদ শেষ হবে (উদাহরণস্বরূপ: 1 মাস) 1

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

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


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

1
@ কিভিমিকাল আপনি ঠিক বলেছেন আমি উত্তরে এটি পরিবর্তন করেছি। রিসোর্স সার্ভার প্রতিটি অনুরোধে টোকেন (অনুমোদনের সার্ভারটি টোকেন তৈরির প্রক্রিয়াটিতে এনক্রিপ্ট করেছে) এবং এটি ডিক্রিপ্ট করে।
জাভিয়ার এজিয়া

1
@ কেভিকল প্রকৃতপক্ষে, একটি টোকেন ডিক্রিপ্ট করার জন্য অনুমোদনের সাথে সম্পর্কিত কিছু হওয়া উচিত, সুতরাং এটি অনুমোদনের সার্ভারের অন্তর্ভুক্ত। এজন্য একজন উত্তরে এটি লিখেছিল। তবে অনুশীলনে, এর অর্থ হ'ল প্রতিটি অনুরোধে আপনাকে অনুমোদন সার্ভারের সাথে টোকেন প্রাপ্ত টোকেনটি (সম্ভবত অন্য কোনও অনুরোধ সম্পাদন করতে হবে) দিয়ে বৈধ করতে হবে। সুতরাং, কর্মক্ষমতা হ্রাস এড়াতে, রিসোর্স সার্ভারে টোকেনটি ডিক্রিপ্ট করার জন্য কিছু কার্যকারিতা দেওয়া ভাল। : পরবর্তী লিংক চেক করুন stackoverflow.com/questions/12296017/...
জেভিয়ার Egea

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

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

8

বর্ণনাকারী টোকেন হ'ল বর্ণের এক বা একাধিক পুনরাবৃত্তি, "-", "।" , "_", "~", "+", "/" এর পরে 0 বা আরও "=" হয়।

আরএফসি 6750 2.1। অনুমোদনের অনুরোধ শিরোনাম ক্ষেত্র (ফর্ম্যাটটি হল এবিএনএফ (অগমেন্টেড বিএনএফ))

The syntax for Bearer credentials is as follows:

     b64token    = 1*( ALPHA / DIGIT /
                       "-" / "." / "_" / "~" / "+" / "/" ) *"="
     credentials = "Bearer" 1*SP b64token

এটি বেস 64৪ এর মতো দেখায় তবে অনুসারে শিরোনামের টোকনটি বেস 64 কে এনকোড করা উচিত? , এইটা না.

"HTTP / 1.1, অংশ 7: প্রমাণীকরণ" ** কিছুটা গভীরে খনন করা যাইহোক, আমি দেখতে পাচ্ছি যে b64token কেবলমাত্র একটি ABNF বাক্য সংজ্ঞা যা সাধারণত বেস 64, বেস64url ইত্যাদিতে ব্যবহৃত অক্ষরের জন্য অনুমতি দেয় So সুতরাং বি 64 টোকেন না যে কোনও এনকোডিং বা ডিকোডিং সংজ্ঞায়িত করুন তবে কেবলমাত্র অনুমোদনের শিরোনামের অংশে কী অক্ষরগুলি ব্যবহার করা যেতে পারে তা সংজ্ঞায়িত করে যাতে অ্যাক্সেস টোকেন থাকবে।

তথ্যসূত্র


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