আপনি 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 এর সংজ্ঞাটি OAuth 2.0 IETF স্পেসিফিকেশন থেকে দেওয়া হল:
"OAuth 2.0 অনুমোদন ফ্রেমওয়ার্ক একটি তৃতীয় পক্ষের অ্যাপ্লিকেশনকে একটি HTTP পরিষেবাতে সীমিত অ্যাক্সেস পেতে সক্ষম করে, হয় সম্পদ মালিকের পক্ষ থেকে সম্পদের মালিক এবং HTTP পরিষেবার মধ্যে একটি অনুমোদনের মিথস্ক্রিয়া বা তৃতীয় পক্ষের অ্যাপ্লিকেশনকে অনুমতি দিয়ে। নিজের পক্ষ থেকে অ্যাক্সেস পাওয়ার জন্য।"
আপনার যে প্রধান জিনিসটি জানতে হবে তা হল যে OAuth 2.0 অ্যাপগুলিকে ব্যবহারকারীর সুরক্ষিত সংস্থানগুলিতে সীমিত অ্যাক্সেস পাওয়ার একটি উপায় প্রদান করে (ব্যাঙ্ক অ্যাকাউন্ট বা অন্য কোনও সংবেদনশীল তথ্যের কথা ভাবুন যা একজন ব্যবহারকারী একটি অ্যাপ থেকে অ্যাক্সেস করতে চান) ব্যবহারকারী তাদের লগইন শংসাপত্রগুলি অ্যাপে প্রকাশ করতে।
OAuth 2.0 ফ্লো
এখানে OAuth 2.0 নিরাপত্তা কাঠামোর জন্য সাধারণ প্রবাহ। আমরা এই বিষয়ে আরও বিস্তারিতভাবে এই প্রবাহ নিয়ে আলোচনা করব, একটি ডায়াগ্রাম দিয়ে শুরু করে, যা OAuth 2.0 কীভাবে কাজ করে সে সম্পর্কে অনেক কিছু ব্যাখ্যা করে। আপনি যদি এই চিত্রটিতে ব্যবহৃত পদগুলির সাথে অপরিচিত হন তবে একটি দ্রুত ভূমিকার জন্য এই বিভাগটি পড়ুন।
শর্তাবলী আপনার জানা উচিত
- ক্লায়েন্ট: "অ্যাপ" নামেও পরিচিত। এটি একটি মোবাইল ডিভাইসে চলমান একটি অ্যাপ বা একটি ঐতিহ্যগত ওয়েব অ্যাপ হতে পারে। অ্যাপটি রিসোর্স মালিকের পক্ষে সুরক্ষিত সম্পদের জন্য রিসোর্স সার্ভারের কাছে অনুরোধ করে। সম্পদের মালিককে অবশ্যই সংরক্ষিত সম্পদ অ্যাক্সেস করার জন্য অ্যাপটিকে অনুমতি দিতে হবে।
- সম্পদের মালিক: একে "শেষ ব্যবহারকারী"ও বলা হয়। এটি সাধারণত সেই ব্যক্তি (বা অন্য সত্তা) যিনি একটি সুরক্ষিত সম্পদে অ্যাক্সেস প্রদান করতে সক্ষম। উদাহরণ স্বরূপ, যদি কোনো অ্যাপের আপনার সোশ্যাল মিডিয়া সাইটগুলির একটি থেকে ডেটা ব্যবহার করার প্রয়োজন হয়, তাহলে আপনিই সম্পদের মালিক -- একমাত্র ব্যক্তি যিনি অ্যাপটিকে আপনার ডেটাতে অ্যাক্সেস দিতে পারেন৷
- রিসোর্স সার্ভার: রিসোর্স সার্ভারকে ফেসবুক, গুগল বা টুইটারের মতো একটি পরিষেবা হিসাবে ভাবুন; অথবা আপনার ইন্ট্রানেটে একটি HR পরিষেবা; অথবা আপনার B2B এক্সট্রানেটে একটি অংশীদার পরিষেবা। Apigee Edge হল একটি রিসোর্স সার্ভার যখনই API অনুরোধগুলি প্রক্রিয়া করার জন্য OAuth টোকেন যাচাইকরণের প্রয়োজন হয়৷ রিসোর্স সার্ভার অ্যাপে সুরক্ষিত সংস্থানগুলি পরিবেশন করার আগে এটির কিছু ধরণের অনুমোদনের প্রয়োজন।
- অনুমোদন সার্ভার: অনুমোদন সার্ভারটি OAuth 2.0 স্পেসিফিকেশনের সাথে সম্মতিতে প্রয়োগ করা হয় এবং এটি অনুমোদনের অনুদান যাচাই করার জন্য এবং অ্যাক্সেস টোকেন ইস্যু করার জন্য দায়ী যা অ্যাপটিকে রিসোর্স সার্ভারে ব্যবহারকারীর ডেটাতে অ্যাক্সেস দেয়। আপনি Apigee Edge এ "টোকেন এন্ডপয়েন্ট" কনফিগার করতে পারেন, এই ক্ষেত্রে এজ অনুমোদন সার্ভারের ভূমিকা নেয়।
- অনুমোদন অনুদান: অ্যাপটিকে শেষ ব্যবহারকারীর পক্ষে একটি অ্যাক্সেস টোকেন পুনরুদ্ধার করার অনুমতি দেয়। OAuth 2.0 চারটি নির্দিষ্ট "অনুদান প্রকার" সংজ্ঞায়িত করে। নীচে " OAuth 2.0 অনুদানের প্রকারগুলি কি কি " দেখুন৷
- অ্যাক্সেস টোকেন: অক্ষরের একটি দীর্ঘ স্ট্রিং যা সুরক্ষিত সংস্থানগুলি অ্যাক্সেস করতে ব্যবহৃত শংসাপত্র হিসাবে কাজ করে। এছাড়াও নীচে দেখুন " একটি অ্যাক্সেস টোকেন কি? "
- সুরক্ষিত সম্পদ: সম্পদ মালিকের মালিকানাধীন ডেটা। উদাহরণস্বরূপ, ব্যবহারকারীর যোগাযোগের তালিকা, অ্যাকাউন্টের তথ্য বা অন্যান্য সংবেদনশীল ডেটা।
যেখানে Apigee Edge ফিট করে
আপনি OAuth 2.0 এর সাথে Apigee Edge এর মাধ্যমে প্রক্সি করা যেকোন API রক্ষা করতে পারেন। এজ একটি অনুমোদন সার্ভার বাস্তবায়ন অন্তর্ভুক্ত করে, এবং যেমন, অ্যাক্সেস টোকেন তৈরি এবং যাচাই করতে পারে। ডেভেলপাররা অ্যাপিজি এজ-এ তাদের অ্যাপ নিবন্ধন করে শুরু করে। নিবন্ধিত অ্যাপগুলি চারটি অনুদান প্রকারের ইন্টারঅ্যাকশনের মাধ্যমে অ্যাক্সেস টোকেনগুলির জন্য অনুরোধ করতে পারে।
Apigee একটি বহুমুখী OAuthV2 নীতি প্রদান করে যা প্রতিটি অনুদান প্রকারের বিশদ প্রয়োগ করে, Apigee এজ-এ OAuth সেট আপ করা তুলনামূলকভাবে সহজ করে তোলে। উদাহরণস্বরূপ, আপনি একটি নীতি কনফিগার করতে পারেন যা একটি অ্যাক্সেস টোকেনের জন্য একটি অনুরোধ গ্রহণ করে, সমস্ত প্রয়োজনীয় শংসাপত্রের মূল্যায়ন করে এবং শংসাপত্রগুলি বৈধ হলে একটি অ্যাক্সেস টোকেন ফেরত দেয়।
মনে রাখবেন যে কোনও রিসোর্স সার্ভার যা আপনার সুরক্ষিত API প্রক্সি কলগুলি একটি ফায়ারওয়ালের পিছনে থাকা উচিত (অর্থাৎ, সংস্থানগুলি API প্রক্সি বা অন্য কোনও API যা ভালভাবে সুরক্ষিত আছে তা ছাড়া অন্য কোনও মাধ্যমে অ্যাক্সেসযোগ্য হওয়া উচিত নয়)৷
OAuth 2.0 অনুদানের প্রকারগুলি কী কী?
অনুদানের ধরনগুলিকে একটি অ্যাক্সেস টোকেন অর্জনের জন্য একটি অ্যাপ গ্রহণ করতে পারে এমন বিভিন্ন পথ বা মিথস্ক্রিয়া হিসাবে ভাবুন৷ প্রতিটি অনুদানের ধরন এক বা একাধিক ব্যবহারের ক্ষেত্রে সম্বোধন করে, এবং আপনার নিজের প্রয়োজনের উপর ভিত্তি করে কোন অনুদান প্রকার(গুলি) ব্যবহার করতে হবে তা নির্বাচন করতে হবে। সাধারণভাবে, প্রতিটি অনুদানের প্রকারের সুবিধা এবং অসুবিধা রয়েছে এবং আপনাকে আপনার ব্যবসায়িক ব্যবহারের ক্ষেত্রের উপর ভিত্তি করে ট্রেডঅফগুলি ওজন করতে হবে। একটি গুরুত্বপূর্ণ বিবেচনা হল অ্যাপগুলির "বিশ্বস্ততা" যা আপনার ডেটা অ্যাক্সেস করবে। সাধারণত, থার্ড-পার্টি অ্যাপ্লিকেশানগুলি কোনও এন্টারপ্রাইজের মধ্যে তৈরি এবং ব্যবহার করা অ্যাপগুলির তুলনায় কম বিশ্বস্ত।
Apigee Edge চারটি প্রধান OAuth 2.0 অনুদান প্রকার সমর্থন করে:
- অনুমোদন কোড -- সবচেয়ে সুরক্ষিত অনুদান প্রকার হিসাবে বিবেচিত। অনুমোদন সার্ভার একটি অ্যাক্সেস টোকেন ইস্যু করার আগে, অ্যাপটিকে প্রথমে রিসোর্স সার্ভার থেকে একটি অনুমোদন কোড পেতে হবে। আপনার অ্যাপ রিসোর্স সার্ভারের লগইন পৃষ্ঠায় একটি ব্রাউজার খোলে এবং আপনার প্রকৃত অ্যাকাউন্টে (উদাহরণস্বরূপ, Facebook বা Twitter) লগ ইন করার আমন্ত্রণ জানালে আপনি এই প্রবাহটি দেখেছেন।
আপনি সফলভাবে লগ ইন করলে, অ্যাপটি একটি অনুমোদন কোড পাবে যা এটি অনুমোদন সার্ভারের সাথে একটি অ্যাক্সেস টোকেন নিয়ে আলোচনা করতে ব্যবহার করতে পারে। সাধারণত, এই অনুদানের ধরনটি ব্যবহার করা হয় যখন অ্যাপটি ক্লায়েন্টের পরিবর্তে একটি সার্ভারে থাকে। এই অনুদানের ধরনটি অত্যন্ত নিরাপদ বলে বিবেচিত হয় কারণ ক্লায়েন্ট অ্যাপ কখনই রিসোর্স সার্ভারের জন্য ব্যবহারকারীর ব্যবহারকারীর নাম বা পাসওয়ার্ড পরিচালনা করে না বা দেখে না (যেমন, অ্যাপটি কখনই আপনার Twitter শংসাপত্রগুলি দেখতে বা পরিচালনা করে না)। এই অনুদানের প্রকার প্রবাহকে "তিন-পায়ের" OAuthও বলা হয়।
- অন্তর্নিহিত -- অনুমোদন কোডের একটি সরলীকৃত সংস্করণ বিবেচনা করা হয়। সাধারণত এই অনুদানের ধরনটি ব্যবহার করা হয় যখন অ্যাপটি ক্লায়েন্টে থাকে। উদাহরণস্বরূপ, অ্যাপের কোড জাভাস্ক্রিপ্ট বা অন্য স্ক্রিপ্টিং ভাষা ব্যবহার করে একটি ব্রাউজারে প্রয়োগ করা হয় (একটি পৃথক ওয়েব সার্ভারে থাকার পরিবর্তে)। এই অনুদানের প্রকারের প্রবাহে, অনুমোদন সার্ভার সরাসরি একটি অ্যাক্সেস টোকেন ফেরত দেয় যখন ব্যবহারকারীকে প্রমাণীকরণ করা হয়, প্রথমে একটি অনুমোদন কোড ইস্যু করার পরিবর্তে। অন্তর্নিহিত অনুদান কিছু ক্ষেত্রে অ্যাপের প্রতিক্রিয়াশীলতাকে উন্নত করতে পারে, তবে এই সুবিধাটি IETF স্পেসিফিকেশনে বর্ণিত সম্ভাব্য নিরাপত্তা প্রভাবগুলির বিরুদ্ধে ওজন করা দরকার।
- রিসোর্স মালিকের পাসওয়ার্ড শংসাপত্র -- এই প্রবাহে, ক্লায়েন্টকে একটি অ্যাক্সেস টোকেন জারি করা হয় যখন ব্যবহারকারীর ব্যবহারকারীর নাম/পাসওয়ার্ড অনুমোদন সার্ভার দ্বারা যাচাই করা হয়। এই প্রবাহ অত্যন্ত বিশ্বস্ত অ্যাপ্লিকেশনের জন্য সুপারিশ করা হয়. এই প্রবাহের একটি সুবিধা, বলুন, মৌলিক প্রমাণীকরণ, ব্যবহারকারী শুধুমাত্র একবার তাদের ব্যবহারকারীর নাম/পাসওয়ার্ড উপস্থাপন করে। তারপর থেকে, অ্যাক্সেস টোকেন ব্যবহার করা হয়।
- ক্লায়েন্ট শংসাপত্র -- এমন পরিস্থিতিতে ব্যবহার করার কথা বিবেচনা করুন যেখানে ক্লায়েন্ট অ্যাপ তার নিজের পক্ষে কাজ করছে। অর্থাৎ ক্লায়েন্টও সম্পদের মালিক। এই অনুদানের ধরনটি সাধারণত ব্যবহৃত হয় যখন অ্যাপটিকে একটি ব্যাকএন্ড ডেটা স্টোরেজ পরিষেবা অ্যাক্সেস করতে হয়, উদাহরণস্বরূপ। অ্যাপটিকে তার কাজ করার জন্য পরিষেবাটি ব্যবহার করতে হবে এবং পরিষেবাটি অন্যথায় শেষ ব্যবহারকারীর কাছে অস্বচ্ছ। এই অনুদানের প্রকারের সাথে, একটি অ্যাপ অনুমোদন সার্ভারে তার ক্লায়েন্ট আইডি এবং ক্লায়েন্ট গোপন কীগুলি উপস্থাপন করে একটি অ্যাক্সেস টোকেন পেতে পারে। আর কোনো পদক্ষেপের প্রয়োজন নেই। এজ একটি আউট-অফ-দ্য-বক্স ক্লায়েন্ট শংসাপত্র সমাধান প্রদান করে যা যেকোনো API প্রক্সির জন্য প্রয়োগ করা সহজ।
একটি অ্যাক্সেস টোকেন কি?
একটি অ্যাক্সেস টোকেন হ'ল অক্ষরের একটি দীর্ঘ স্ট্রিং যা সুরক্ষিত সংস্থানগুলি অ্যাক্সেস করতে ব্যবহৃত শংসাপত্র হিসাবে কাজ করে। রিসোর্স টোকেন (যাকে বহনকারী টোকেনও বলা হয়) অনুমোদনের শিরোনামে পাস করা হয়, এইভাবে:
$ 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 এগুলিকে Consumer ID এবং Consumer secret বলে। তারা সমতুল্য।
OAuth 2.0 ব্যবহারের ক্ষেত্রে সারাংশ
আপনি কোন OAuth 2.0 অনুদানের প্রকার প্রবাহ বাস্তবায়ন করতে বেছে নিয়েছেন তা নির্ভর করে আপনার নির্দিষ্ট ব্যবহারের ক্ষেত্রে, কারণ কিছু অনুদানের ধরন অন্যদের তুলনায় বেশি নিরাপদ। আপনার অনুদানের প্রকারের পছন্দ ক্লায়েন্ট অ্যাপের বিশ্বস্ততার উপর নির্ভর করে এবং নিম্নলিখিত সারণীতে বর্ণিত হিসাবে অত্যন্ত সতর্কতার সাথে বিবেচনা করা প্রয়োজন:
কেস ব্যবহার করুন | বিশ্বস্ততা | প্রস্তাবিত OAuth 2.0 অনুমোদন অনুদান প্রকার | বর্ণনা |
---|---|---|---|
B2B (extranet), ইন্ট্রানেট, অন্যান্য | API প্রদানকারীর সাথে বিশ্বস্ত ব্যবসায়িক সম্পর্ক সহ অভ্যন্তরীণ বিকাশকারী বা বিকাশকারীদের দ্বারা লেখা অত্যন্ত বিশ্বস্ত অ্যাপ। যে অ্যাপগুলিকে তাদের নিজস্ব তরফে সংস্থানগুলি অ্যাক্সেস করতে হবে৷ |
|
|
ইন্ট্রানেট সাইট, পোর্টাল | অভ্যন্তরীণ বা বিশ্বস্ত তৃতীয় পক্ষের বিকাশকারীদের দ্বারা লিখিত বিশ্বস্ত অ্যাপ। একটি ভাল উদাহরণ হল বীমা নির্বাচন করতে, পর্যালোচনা জমা দিতে বা ব্যক্তিগত তথ্য পরিবর্তন করতে আপনার কোম্পানির HR সাইটে লগ ইন করা। |
|
|
সর্বজনীনভাবে উপলব্ধ অ্যাপ | অবিশ্বস্ত অ্যাপগুলি তৃতীয় পক্ষের বিকাশকারীদের দ্বারা লেখা হয় যাদের API প্রদানকারীর সাথে বিশ্বস্ত ব্যবসায়িক সম্পর্ক নেই৷ উদাহরণস্বরূপ, যে সকল ডেভেলপাররা সর্বজনীন API প্রোগ্রামগুলির জন্য নিবন্ধন করেন তাদের সাধারণত বিশ্বাস করা উচিত নয়। |
|
|
B2C | এখানে একজন স্বতন্ত্র শেষ ব্যবহারকারী (মোবাইল ব্যবহারকারী) জড়িত, এবং ব্যবহারকারীর শংসাপত্র মোবাইল ডিভাইসে সংরক্ষণ করা হয়। |
|
|
OAuth 2.0 বনাম API কী নিরাপত্তা
এজ-এ একটি কী পাঠাতে API কী যাচাইকরণের জন্য একটি অ্যাপের প্রয়োজন। কীটি অবশ্যই একটি Apigee Edge বিকাশকারী অ্যাপ থেকে একটি বৈধ গ্রাহক কী হতে হবে যা API প্রক্সির সাথে যুক্ত৷ যদি কোনো কারণে আপনাকে কোনো প্রক্সিতে কল করার জন্য কোনো ক্লায়েন্ট অ্যাপের অনুমতি প্রত্যাহার করতে হয়, তাহলে আপনাকে অবশ্যই সেই ভোক্তা কী প্রত্যাহার করতে হবে। সেই কী ব্যবহার করে কোনো ক্লায়েন্ট অ্যাপও API প্রক্সি অ্যাক্সেস করতে অক্ষম হবে। অন্যদিকে, অ্যাপের কীগুলি প্রত্যাহার না করে যেকোন সময় একটি OAuth টোকেন প্রত্যাহার করা যেতে পারে৷ অ্যাপটি ব্যবহারকারীর পক্ষ থেকে একটি নতুন টোকেনের অনুরোধ করতে পারে এবং যদি একটি টোকেন দেওয়া হয়, অ্যাপটি API প্রক্সি ব্যবহার করে চলতে পারে।
একটি API কী এবং একটি টোকেনের মধ্যে আরেকটি পার্থক্য হল একটি টোকেনে মেটাডেটা বৈশিষ্ট্যগুলি অন্তর্ভুক্ত থাকতে পারে যা আপনি পুনরুদ্ধার করতে এবং পরে ব্যবহার করতে পারেন। উদাহরণস্বরূপ, আপনি API কল করার ব্যবহারকারীর ID সংরক্ষণ করতে পারেন এবং ব্যাকএন্ড টার্গেট পরিষেবাতে কলগুলি কাস্টমাইজ করতে এটি ব্যবহার করতে পারেন।
API কী যাচাইকরণের বিস্তারিত জানার জন্য, API কী দেখুন। OAuth টোকেনগুলির সাথে কাস্টম বৈশিষ্ট্যগুলি ব্যবহার করার বিষয়ে তথ্যের জন্য, টোকেন এবং অনুমোদনের কোডগুলি কাস্টমাইজ করা দেখুন৷
প্রস্তাবিত সম্পদ
পড়া
OAuth 2.0 সম্পর্কে জানুন দেখুন।