আপনি Apigee Edge ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন দেখুন। তথ্য
OAuth হোম: আমরা যে OAuth নির্দেশিকা প্রদান করি তার একটি টপ-লেভেল ভিউ পেতে OAuth হোম পেজ দেখুন ।
এই বিষয়ে Apigee Edge-এ OAuth 2.0-এর প্রাথমিক ওভারভিউ দেওয়া হয়েছে।
OAuth 2.0 কী?
OAuth 2.0-এর উপর অনেক বই, ব্লগ ও সাইট আছে। আমরা আপনাকে এগুলি করার জন্য বিশেষভাবে সাজেস্ট করি: IETF OAuth 2.0 স্পেসিফিকেশন পর্যালোচনা করে শুরু করুন। OAuth 2.0 IETF স্পেসিফিকেশন থেকে OAuth 2.0-এর সংজ্ঞা এখানে দেওয়া হল:
"OAuth 2.0 অনুমোদন ফ্রেমওয়ার্ক, থার্ড-পার্টি অ্যাপ্লিকেশনকে HTTP পরিষেবায় সীমিত অ্যাক্সেস পেতে সাহায্য করে। এটি রিসোর্স মালিকের হয়ে রিসোর্স মালিক ও HTTP পরিষেবার মধ্যে অনুমোদন ইন্টার্যাকশন অর্কেস্ট্রেট করে অথবা থার্ড-পার্টি অ্যাপ্লিকেশনকে নিজের হয়ে অ্যাক্সেস পেতে দেয়।"
আপনাকে যা জানতে হবে তা হল, OAuth 2.0 অ্যাপকে ব্যবহারকারীর সুরক্ষিত রিসোর্সে সীমিত অ্যাক্সেস পাওয়ার একটি উপায় প্রদান করে (ব্যাঙ্ক অ্যাকাউন্ট বা অন্য কোনও সংবেদনশীল তথ্য যা ব্যবহারকারী কোনও অ্যাপ থেকে অ্যাক্সেস করতে চাইতে পারেন) ব্যবহারকারীকে অ্যাপের কাছে তার লগ-ইন ক্রেডেনশিয়াল প্রকাশ করার প্রয়োজন ছাড়াই এটি করা হয়।
OAuth 2.0 ফ্লো
OAuth 2.0 নিরাপত্তা ফ্রেমওয়ার্কের সাধারণ ফ্লো এখানে দেওয়া হল। আমরা এই ফ্লোটি আরও বিস্তারিতভাবে এই বিষয়ে আলোচনা করব, একটি ডায়াগ্রাম দিয়ে শুরু করব, যা OAuth 2.0 কীভাবে কাজ করে সেই সম্পর্কে অনেক কিছু ব্যাখ্যা করে। এই ডায়াগ্রামে ব্যবহৃত শব্দগুলি সম্পর্কে আপনার কোনও ধারণা না থাকলে, এই বিভাগটি পড়ে দেখুন, তাহলে আপনি এগুলির একটি সংক্ষিপ্ত পরিচয় পাবেন।

যেসব শব্দ সম্পর্কে আপনার জানা উচিত
- ক্লায়েন্ট: এটিকে "অ্যাপ"ও বলা হয়। এটি মোবাইল ডিভাইসে রান করা কোনও অ্যাপ বা একটি ঐতিহ্যবাহী ওয়েব অ্যাপ হতে পারে। অ্যাপটি রিসোর্স মালিকের হয়ে সুরক্ষিত অ্যাসেটের জন্য রিসোর্স সার্ভারে অনুরোধ করে। সুরক্ষিত রিসোর্স অ্যাক্সেস করার জন্য রিসোর্সের মালিককে অ্যাপকে অনুমতি দিতে হবে।
- সম্পদের মালিক: এগুলিকে "গ্রাহক"ও বলা হয়। সাধারণত, এই ব্যক্তি (বা অন্য এন্টিটি) সুরক্ষিত রিসোর্সে অ্যাক্সেস দিতে পারেন। যেমন, কোনও অ্যাপ যদি আপনার সোশ্যাল মিডিয়া সাইটগুলির কোনও একটি থেকে ডেটা ব্যবহার করতে চায়, তাহলে আপনি হলেন সেই রিসোর্সের মালিক -- একমাত্র আপনিই অ্যাপটিকে আপনার ডেটা অ্যাক্সেস করার অনুমতি দিতে পারবেন।
- রিসোর্স সার্ভার: রিসোর্স সার্ভারকে Facebook, Google বা Twitter-এর মতো পরিষেবা হিসেবে ভাবুন; অথবা আপনার ইন্ট্রানেটে কোনও HR পরিষেবা; অথবা আপনার B2B এক্সট্রানেটে কোনও পার্টনার পরিষেবা। API অনুরোধ প্রসেস করার জন্য OAuth টোকেন যাচাইকরণের প্রয়োজন হলে Apigee Edge হল একটি রিসোর্স সার্ভার। অ্যাপকে সুরক্ষিত রিসোর্স পরিবেশন করার আগে রিসোর্স সার্ভারের কিছু ধরনের অনুমোদনের প্রয়োজন।
- অনুমোদন সার্ভার: অনুমোদন সার্ভারটি OAuth 2.0 স্পেসিফিকেশন মেনে ইমপ্লিমেন্ট করা হয় এবং এটি অনুমোদন গ্র্যান্ট যাচাই করা ও অ্যাক্সেস টোকেন ইস্যু করার জন্য দায়ী যা রিসোর্স সার্ভারে ব্যবহারকারীর ডেটা অ্যাক্সেস করার জন্য অ্যাপকে অনুমতি দেয়। আপনি Apigee Edge-এ "টোকেন এন্ডপয়েন্ট" কনফিগার করতে পারেন, সেক্ষেত্রে Edge অনুমোদন সার্ভারের ভূমিকা পালন করে।
- অনুমতি প্রদান: অ্যাপকে ব্যবহারকারীর হয়ে অ্যাক্সেস টোকেন রিট্রিভ করার অনুমতি দেয়। OAuth 2.0 চারটি নির্দিষ্ট "গ্র্যান্টের ধরন" নির্ধারণ করে। নিচে "OAuth 2.0 গ্র্যান্টের ধরন কী কী" দেখুন।
- অ্যাক্সেস টোকেন: অক্ষরের একটি দীর্ঘ স্ট্রিং যা একটি ক্রেডেনশিয়াল হিসেবে কাজ করে সুরক্ষিত রিসোর্স অ্যাক্সেস করতে ব্যবহৃত হয়। এছাড়াও, নিচে "অ্যাক্সেস টোকেন কী?" দেখুন।
- সুরক্ষিত রিসোর্স: রিসোর্স মালিকের মালিকানাধীন ডেটা। যেমন, ব্যবহারকারীর পরিচিতির তালিকা, অ্যাকাউন্টের তথ্য বা অন্যান্য সংবেদনশীল ডেটা।
Apigee Edge কোথায় ফিট করে
আপনি OAuth 2.0-এর মাধ্যমে Apigee Edge-এর মাধ্যমে প্রক্সি করা যেকোনও API সুরক্ষিত করতে পারবেন। Edge-এ একটি অনুমোদন সার্ভার প্রয়োগ করা আছে এবং সেই কারণে, অ্যাক্সেস টোকেন তৈরি ও যাচাই করতে পারে। ডেভেলপাররা Apigee Edge-এ তাদের অ্যাপ রেজিস্টার করার মাধ্যমে শুরু করেন। রেজিস্টার করা অ্যাপ চারটি অনুমতি ধরনের ইন্টার্যাকশনের মধ্যে যেকোনও একটির মাধ্যমে অ্যাক্সেস টোকেনের অনুরোধ করতে পারে।
Apigee-তে একটি বহু-মুখী OAuthV2 নীতি প্রদান করা হয় যা প্রতিটি গ্র্যান্ট টাইপের বিবরণ প্রয়োগ করে, এর ফলে Apigee Edge-এ OAuth সেট-আপ করা তুলনামূলকভাবে সহজ হয়ে যায়। যেমন, আপনি এমন একটি নীতি কনফিগার করতে পারেন যা অ্যাক্সেস টোকেনের জন্য একটি অনুরোধ পায়, সমস্ত প্রয়োজনীয় ক্রেডেনশিয়াল মূল্যায়ন করে এবং ক্রেডেনশিয়াল বৈধ হলে একটি অ্যাক্সেস টোকেন রিটার্ন করে।
মনে রাখবেন, আপনার সুরক্ষিত API প্রক্সি যে রিসোর্স সার্ভারকে কল করে সেটি যেন ফায়ারওয়ালের পিছনে থাকে (অর্থাৎ, API প্রক্সি বা অন্য কোনও ভালভাবে সুরক্ষিত API ছাড়া অন্য কোনও উপায়ে রিসোর্স যেন অ্যাক্সেস করা না যায়)।
OAuth 2.0 গ্র্যান্টের ধরন কী কী?
গ্র্যান্টের ধরনকে এমন বিভিন্ন পাথ বা ইন্টার্যাকশন হিসেবে ভাবুন যা কোনও অ্যাপ অ্যাক্সেস টোকেন পাওয়ার জন্য ব্যবহার করতে পারে। প্রতিটি গ্র্যান্টের ধরন এক বা একাধিক ব্যবহারের ক্ষেত্রকে অ্যাড্রেস করে এবং আপনার প্রয়োজন অনুযায়ী কোন গ্র্যান্ট টাইপ ব্যবহার করবেন তা আপনাকে বেছে নিতে হবে। সাধারণত, প্রতিটি গ্রান্টের ধরনের সুবিধা ও অসুবিধা আছে এবং আপনার ব্যবসার ব্যবহারের কেস অনুযায়ী আপনাকে ট্রেড-অফ বিবেচনা করতে হবে। একটি গুরুত্বপূর্ণ বিষয় হল, আপনার ডেটা অ্যাক্সেস করা অ্যাপের "বিশ্বাসযোগ্যতা"। সাধারণত, থার্ড-পার্টি অ্যাপগুলি কোনও এন্টারপ্রাইজের মধ্যে ডেভেলপ করা এবং ব্যবহার করা অ্যাপের তুলনায় কম বিশ্বাসযোগ্য হয়।
Apigee Edge চারটি প্রধান OAuth 2.0 গ্রান্টের ধরন সমর্থন করে:
- অনুমোদন কোড -- সবচেয়ে সুরক্ষিত গ্র্যান্টের ধরন হিসেবে বিবেচনা করা হয়। অনুমোদন সার্ভার অ্যাক্সেস টোকেন ইস্যু করার আগে, অ্যাপকে অবশ্যই রিসোর্স সার্ভারের থেকে প্রথমে একটি অনুমোদন কোড পেতে হবে। আপনার অ্যাপ যখনই রিসোর্স সার্ভারের লগ-ইন পৃষ্ঠা খোলে এবং আপনাকে নিজের আসল অ্যাকাউন্টে (যেমন, Facebook বা Twitter) লগ-ইন করার জন্য আমন্ত্রণ জানায়, তখনই আপনি এই ফ্লো দেখতে পান।
আপনি সফলভাবে লগ-ইন করলে, অ্যাপটি একটি অনুমোদন কোড পাবে যা এটি অনুমোদন সার্ভারের সাথে অ্যাক্সেস টোকেন নেগোসিয়েট করার জন্য ব্যবহার করতে পারে। সাধারণত, এই গ্র্যান্টের ধরন তখনই ব্যবহার করা হয় যখন অ্যাপ ক্লায়েন্টের পরিবর্তে সার্ভারে থাকে। এই গ্র্যান্টের ধরনটি খুবই সুরক্ষিত বলে মনে করা হয় কারণ ক্লায়েন্ট অ্যাপ কখনই রিসোর্স সার্ভারের (যেমন, অ্যাপটি কখনই আপনার Twitter ক্রেডেনশিয়াল দেখে বা ম্যানেজ করে না) জন্য ব্যবহারকারীর ইউজারনেম বা পাসওয়ার্ড ম্যানেজ করে না বা দেখে না। এই গ্র্যান্টের ধরন সংক্রান্ত ফ্লোকে "থ্রি-লেগড" OAuth-ও বলা হয়।
- ইমপ্লিসিট -- অনুমোদন কোডের একটি সরলীকৃত ভার্সন হিসেবে বিবেচনা করা হয়। সাধারণত, ক্লায়েন্টে অ্যাপ থাকলে এই ধরনের গ্র্যান্ট ব্যবহার করা হয়। যেমন, অ্যাপের কোড জাভাস্ক্রিপ্ট বা অন্য কোনও স্ক্রিপ্টিং ভাষা ব্যবহার করে কোনও ব্রাউজারে প্রয়োগ করা হয় (আলাদা ওয়েব সার্ভারে থাকা ও রান করার পরিবর্তে)। এই গ্র্যান্ট টাইপ ফ্লোতে, যাচাইকরণ সার্ভার ব্যবহারকারী যাচাইকৃত হলে সরাসরি অ্যাক্সেস টোকেন রিটার্ন করে, প্রথমে কোনও অনুমোদন কোড ইস্যু করে না। ইমপ্লিসিট গ্রান্ট কিছু ক্ষেত্রে অ্যাপের রেসপন্সিভনেস উন্নত করতে পারে, কিন্তু IETF স্পেসিফিকেশনে বর্ণিত সম্ভাব্য নিরাপত্তা সংক্রান্ত প্রভাবের সাথে এই সুবিধাটি তুলনা করে দেখতে হবে।
- রিসোর্স মালিকের পাসওয়ার্ড ক্রেডেনশিয়াল -- এই ফ্লোতে, ক্লায়েন্টকে অ্যাক্সেস টোকেন ইস্যু করা হয় যখন ব্যবহারকারীর ইউজারনেম/পাসওয়ার্ড অনুমোদন সার্ভার দ্বারা যাচাই করা হয়। খুবই বিশ্বস্ত অ্যাপ্লিকেশনের জন্য এই ফ্লো সাজেস্ট করা হয়। এই ফ্লোয়ের একটি সুবিধা হল, যেমন, সাধারণ যাচাইকরণের ক্ষেত্রে, ব্যবহারকারীকে শুধু একবারই ব্যবহারকারীর নাম/পাসওয়ার্ড দিতে হয়। তার পর থেকে অ্যাক্সেস টোকেন ব্যবহার করা হয়।
- ক্লায়েন্ট ক্রেডেনশিয়াল -- এমন পরিস্থিতির জন্য ব্যবহার করার কথা বিবেচনা করুন যেখানে ক্লায়েন্ট অ্যাপ নিজের হয়ে কাজ করছে। অর্থাৎ, ক্লায়েন্টই রিসোর্সের মালিক। এই গ্র্যান্ট টাইপ সাধারণত তখনই ব্যবহার করা হয় যখন অ্যাপকে ব্যাকএন্ড ডেটা স্টোরেজ পরিষেবা অ্যাক্সেস করতে হয়, যেমন উদাহরণস্বরূপ। অ্যাপটিকে কাজ করার জন্য পরিষেবাটি ব্যবহার করতে হয় এবং অন্যথায় পরিষেবাটি ব্যবহারকারীর কাছে অপ্রকাশিত থাকে। এই গ্র্যান্টের মাধ্যমে, কোনও অ্যাপ তার ক্লায়েন্ট আইডি ও ক্লায়েন্ট সিক্রেট কী অনুমোদনকারী সার্ভারে জমা দিয়ে অ্যাক্সেস টোকেন পেতে পারে। আর কোনও ধাপ অনুসরণ করার প্রয়োজন নেই। Edge একটি রেডি-টু-ইউজ ক্লায়েন্ট ক্রেডেনশিয়াল সমাধান প্রদান করে যা যেকোনও API প্রক্সির জন্য সহজেই প্রয়োগ করা যায়।
অ্যাক্সেস টোকেন কী?
অ্যাক্সেস টোকেন হল অক্ষরের একটি দীর্ঘ স্ট্রিং যা সুরক্ষিত রিসোর্স অ্যাক্সেস করার জন্য ব্যবহৃত একটি ক্রেডেনশিয়াল হিসেবে কাজ করে। রিসোর্স টোকেন (এটিকে বিয়ারার টোকেনও বলা হয়) Authorization হেডারে পাস করা হয়, যেমন:
$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \ http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282
রিসোর্স সার্ভার বুঝতে পারে যে অ্যাক্সেস টোকেনটি ইউজারনেম ও পাসওয়ার্ডের মতো ক্রেডেনশিয়ালের "প্রতিনিধিত্ব করে"। এছাড়াও, অ্যাক্সেস টোকেন বিধিনিষেধ সহ ইস্যু করা যেতে পারে, যাতে, যেমন, অ্যাপ রিসোর্স সার্ভারে ডেটা পড়তে পারে, কিন্তু লিখতে বা মুছে দিতে পারে না। মনে রাখবেন যে কোনও অ্যাক্সেস টোকেন প্রত্যাহার করা যেতে পারে, যেমন, অ্যাপটি যদি হ্যাক করা হয়। এই ক্ষেত্রে, অ্যাপ ব্যবহার করা চালিয়ে যেতে আপনাকে নতুন অ্যাক্সেস টোকেন পেতে হবে; তবে, সুরক্ষিত রিসোর্স সার্ভারে (যেমন, Facebook বা Twitter) আপনাকে ইউজারনেম বা পাসওয়ার্ড পরিবর্তন করতে হবে না।
অ্যাক্সেস টোকেনের সাধারণত মেয়াদ শেষ হয়ে যায় (নিরাপত্তার কারণে)। কিছু গ্র্যান্টের ধরন, রিফ্রেশ টোকেন ইস্যু করার জন্য অনুমোদন সার্ভারকে অনুমতি দেয়, যা পুরনো টোকেনের মেয়াদ শেষ হয়ে গেলে, অ্যাপকে নতুন অ্যাক্সেস টোকেন ফেচ করতে দেয়। অ্যাক্সেস ও রিফ্রেশ টোকেন সম্পর্কে আরও জানতে, IETF OAuth 2.0 স্পেসিফিকেশন দেখুন।
স্কোপের মাধ্যমে সীমিত অ্যাক্সেস
স্কোপের মেকানিজমের মাধ্যমে, OAuth 2.0 সুরক্ষিত রিসোর্সে কোনও অ্যাপকে সীমিত অ্যাক্সেস দিতে পারে। যেমন, কোনও অ্যাপের শুধু নির্দিষ্ট রিসোর্সে অ্যাক্সেস থাকতে পারে, রিসোর্স আপডেট করতে পারতে পারে অথবা শুধু 'শুধু পড়া যায়' অ্যাক্সেস থাকতে পারে। তথাকথিত "থ্রি-লেগড" OAuth ফ্লোতে, ব্যবহারকারী সাধারণত সম্মতি পৃষ্ঠার মাধ্যমে অ্যাক্সেসের লেভেল নির্দিষ্ট করেন (যেমন, একটি ওয়েবপেজ যেখানে ব্যবহারকারী অন্য মেকানিজমের চেকবক্সের মাধ্যমে স্কোপ বেছে নেন)।
অ্যাপ রেজিস্টার করা
যে OAuth 2.0 অনুমোদন সার্ভার থেকে অ্যাক্সেস টোকেন পেতে চান, সব ক্লায়েন্ট (অ্যাপ)-কে সেটির সাথে রেজিস্টার করতে হবে। আপনি কোনও অ্যাপ রেজিস্টার করলে, আপনাকে কীয়ের একটি সেট ফেরত দেওয়া হয়। একটি হল ক্লায়েন্ট শনাক্তকারী নামে পরিচিত পাবলিক কী এবং অন্যটি হল ক্লায়েন্ট সিক্রেট নামে পরিচিত সিক্রেট কী। এইসব কী ছাড়া, কোনও অ্যাপ অনুমোদনের কোড বা অ্যাক্সেস টোকেনের জন্য অনুরোধ করতে পারে না অনুমোদন সার্ভারে। মনে রাখবেন, IETF OAuth স্পেসিফিকেশন এইসব কী-কে ক্লায়েন্ট আইডি ও ক্লায়েন্ট সিক্রেট বলে, তবে Apigee Edge UI এগুলিকে কনজিউমার আইডি ও কনজিউমার সিক্রেট বলে। দুটিই একই।
OAuth 2.0 ব্যবহারের ক্ষেত্রগুলির সারসংক্ষেপ
আপনি কোন OAuth 2.0 গ্র্যান্ট টাইপ ফ্লো প্রয়োগ করতে চান তা আপনার নির্দিষ্ট ব্যবহারের কেসের উপর নির্ভর করে, কারণ কিছু গ্র্যান্ট টাইপ অন্যদের থেকে বেশি সুরক্ষিত। আপনি কোন ধরনের গ্র্যান্ট বেছে নেবেন তা ক্লায়েন্ট অ্যাপের বিশ্বাসযোগ্যতার উপর নির্ভর করে এবং এর জন্য খুব সাবধানে বিবেচনা করতে হয়, যা নিচের টেবিলে বর্ণনা করা হয়েছে:
| ব্যবহারের ক্ষেত্র | নির্ভরযোগ্যতা | OAuth 2.0 অনুমোদনের গ্র্যান্টের সাজেস্ট করা ধরন | বিবরণ |
|---|---|---|---|
| B2B (এক্সট্রানেট), ইন্ট্রানেট, অন্যান্য |
API প্রদানকারীর সাথে বিশ্বস্ত ব্যবসায়িক সম্পর্ক আছে এমন ইন্টার্নাল ডেভেলপার বা ডেভেলপারের লেখা খুবই বিশ্বস্ত অ্যাপ। যেসব অ্যাপকে নিজের হয়ে রিসোর্স অ্যাক্সেস করতে হয়। |
|
|
| ইন্ট্রানেট সাইট, পোর্টাল |
ইন্টার্নাল বা বিশ্বস্ত থার্ড-পার্টি ডেভেলপারদের লেখা বিশ্বস্ত অ্যাপ। এর একটি ভাল উদাহরণ হল, বীমা সংক্রান্ত বিকল্প বেছে নিতে, পর্যালোচনা জমা দিতে বা ব্যক্তিগত তথ্য পরিবর্তন করতে আপনার কোম্পানির এইচআর সাইটে লগ-ইন করা। |
|
|
| সর্বজনীনভাবে উপলভ্য অ্যাপ | API প্রদানকারীর সাথে বিশ্বাসযোগ্য ব্যবসায়িক সম্পর্ক নেই এমন থার্ড-পার্টি ডেভেলপাররা অবিশ্বাসযোগ্য অ্যাপ লেখেন। যেমন, যেসব ডেভেলপার পাবলিক API প্রোগ্রামে রেজিস্টার করেন, তাদের সাধারণত বিশ্বাস করা উচিত নয়। |
|
|
| B2C | এতে একজন স্বতন্ত্র এন্ড-ইউজার (মোবাইল ব্যবহারকারী) জড়িত এবং ব্যবহারকারীর ক্রেডেনশিয়াল মোবাইল ডিভাইসে স্টোর করা থাকে। |
|
|
OAuth 2.0 বনাম API key নিরাপত্তা
API 'কী' যাচাইকরণের জন্য Edge-এ একটি 'কী' পাঠাতে অ্যাপের প্রয়োজন। API প্রক্সির সাথে যুক্ত Apigee Edge ডেভেলপার অ্যাপ থেকে প্রাপ্ত কীটি অবশ্যই একটি বৈধ গ্রাহক কী হতে হবে । কোনও কারণে আপনি যদি প্রক্সি সার্ভারে কল করার জন্য ক্লায়েন্ট অ্যাপের অনুমতি তুলে নিতে চান, তাহলে আপনাকে অবশ্যই সেই কনজিউমার কী তুলে নিতে হবে। সেই কী ব্যবহার করা যেকোনও ক্লায়েন্ট অ্যাপও API প্রক্সি অ্যাক্সেস করতে পারবে না। অন্যদিকে, অ্যাপের কী বাতিল না করেই OAuth টোকেন যেকোনও সময় বাতিল করা যেতে পারে। অ্যাপটি ব্যবহারকারীর হয়ে নতুন টোকেনের অনুরোধ করতে পারে এবং টোকেন মঞ্জুর করা হলে, অ্যাপটি API প্রক্সি ব্যবহার করা চালিয়ে যেতে পারে।
API কী ও টোকেনের মধ্যে আরেকটি পার্থক্য হল, টোকেনে মেটাডেটা অ্যাট্রিবিউট থাকতে পারে যা আপনি পরে রিট্রিভ ও ব্যবহার করতে পারবেন। যেমন, আপনি API কল করা ব্যবহারকারীর ID স্টোর করতে পারেন এবং ব্যাকএন্ড টার্গেট পরিষেবায় কল কাস্টমাইজ করতে এটি ব্যবহার করতে পারেন।
API 'কী' যাচাইকরণ সম্পর্কে আরও জানতে, API 'কী' দেখুন। OAuth টোকেনের সাথে কাস্টম অ্যাট্রিবিউট ব্যবহার করা সম্পর্কে তথ্য পেতে, টোকেন কাস্টমাইজ করা এবং অনুমোদন কোড দেখুন।
সাজেস্ট করা রিসোর্স
পড়া
OAuth 2.0 সম্পর্কে জানুন লিঙ্কে দেখুন।