Google API যাচাইকরণ ও অনুমোদনের জন্য OAuth 2.0 প্রোটোকল ব্যবহার করে। Google সাধারণ OAuth 2.0 সিনারিওতে কাজ করে যেমন ওয়েব সার্ভার, ক্লায়েন্ট-সাইড, ইনস্টল করা এবং সীমিত-ইনপুট ডিভাইস অ্যাপ্লিকেশন।
শুরু করতে, Google API Console থেকে OAuth 2.0 ক্লায়েন্ট ক্রেডেনশিয়াল সংগ্রহ করুন। তারপর আপনার ক্লায়েন্ট অ্যাপ্লিকেশন Google Authorization Server থেকে অ্যাক্সেস টোকেনের অনুরোধ করে, উত্তর থেকে টোকেন এক্সট্র্যাক্ট করে এবং আপনি যে Google API অ্যাক্সেস করতে চান সেখানে টোকেন পাঠায়। Google-এর সাথে OAuth 2.0 ব্যবহার করার ইন্টার্যাক্টিভ ডেমো (আপনার নিজস্ব ক্লায়েন্ট ক্রেডেনশিয়াল ব্যবহার করার বিকল্প সহ) দেখতে, OAuth 2.0 Playground-এর সাথে এক্সপেরিমেন্ট করুন।
এই পৃষ্ঠায় Google-এর মাধ্যমে কাজ করে এমন OAuth 2.0 অনুমোদনের সিনারিও সম্পর্কে ওভারভিউ দেওয়া হয়েছে এবং আরও বিস্তারিত কন্টেন্টের লিঙ্ক দেওয়া হয়েছে। যাচাইকরণের জন্য OAuth 2.0 ব্যবহার করার বিষয়ে বিস্তারিত জানতে, OpenID Connect দেখুন।
প্রাথমিক ধাপ
OAuth 2.0 ব্যবহার করে Google API অ্যাক্সেস করার সময় সব অ্যাপ্লিকেশন একটি প্রাথমিক প্যাটার্ন অনুসরণ করে। উচ্চ লেভেলে, আপনি পাঁচটি ধাপ অনুসরণ করেন:
১. Google API Console থেকে OAuth 2.0 ক্রেডেনশিয়াল পান।
Google এবং আপনার অ্যাপ্লিকেশন, উভয়েরই জানা ক্লায়েন্ট আইডি এবং ক্লায়েন্ট সিক্রেটের মতো OAuth 2.0 ক্রেডেনশিয়াল পেতে Google API কনসোল-এ যান। আপনি কোন ধরনের অ্যাপ্লিকেশন তৈরি করছেন তার উপর ভিত্তি করে ভ্যালুর সেট আলাদা হয়। যেমন, JavaScript অ্যাপ্লিকেশনের জন্য কোনও গোপন কী প্রয়োজন হয় না, কিন্তু ওয়েব সার্ভার অ্যাপ্লিকেশনের জন্য প্রয়োজন হয়।
আপনার অ্যাপ যে প্ল্যাটফর্মে চলবে তার জন্য উপযুক্ত OAuth ক্লায়েন্ট আপনাকে তৈরি করতে হবে, যেমন:
- Android অ্যাপের জন্য, Android অ্যাপ্লিকেশনের ধরন ব্যবহার করুন।
-
iOS অ্যাপের জন্য,
iOS অ্যাপ্লিকেশন টাইপ ব্যবহার করুন।
- desktop_windows ডেস্কটপ অ্যাপের জন্য (যেমন Windows, macOS বা Linux অ্যাপ্লিকেশন বা CLI টুল), ডেস্কটপ অ্যাপ অ্যাপ্লিকেশনের ধরন ব্যবহার করুন।
- কোড সার্ভার-সাইড অথবা জাভাস্ক্রিপ্ট ওয়েব অ্যাপের জন্য ওয়েব অ্যাপ্লিকেশন অ্যাপ্লিকেশন টাইপ ব্যবহার করুন। নেটিভ বা মোবাইল অ্যাপের মতো অন্য কোনও অ্যাপ্লিকেশনের জন্য এই ধরনের অ্যাপ্লিকেশন ব্যবহার করবেন না।
- chrome_extension Chrome এক্সটেনশনের জন্য, Chrome এক্সটেনশন অ্যাপ্লিকেশন টাইপ ব্যবহার করুন।
- tv লিমিটেড ইনপুট ডিভাইসের জন্য, যেমন টিভি বা এম্বেড করা ডিভাইস, টিভি এবং লিমিটেড ইনপুট ডিভাইস অ্যাপ্লিকেশন টাইপ ব্যবহার করুন।
- হোস্ট সার্ভার-টু-সার্ভার ইন্টার্যাকশনের জন্য, পরিষেবা অ্যাকাউন্ট ব্যবহার করুন। কোনও OAuth ক্লায়েন্ট আইডি প্রয়োজন নেই।
২. Google অথরাইজেশন সার্ভার থেকে অ্যাক্সেস টোকেন পান।
Google API ব্যবহার করে আপনার অ্যাপ্লিকেশন ব্যক্তিগত ডেটা অ্যাক্সেস করার আগে, এটিকে অবশ্যই একটি অ্যাক্সেস টোকেন পেতে হবে যা সেই API-তে অ্যাক্সেস প্রদান করে। একটি অ্যাক্সেস টোকেন
একাধিক API-তে বিভিন্ন মাত্রার অ্যাক্সেস দিতে পারে। scope নামক একটি পরিবর্তনশীল প্যারামিটার রিসোর্স ও অপারেশনের সেটকে নিয়ন্ত্রণ করে, যা অ্যাক্সেস টোকেন
অনুমতি দেয়। অ্যাক্সেস-টোকেন অনুরোধের সময়, আপনার অ্যাপ্লিকেশন scope প্যারামিটারে এক বা একাধিক
ভ্যালু পাঠায়।
এই অনুরোধ করার একাধিক উপায় আছে এবং আপনি যে ধরনের অ্যাপ্লিকেশন তৈরি করছেন তার উপর ভিত্তি করে সেগুলি আলাদা হয়। যেমন, কোনও জাভাস্ক্রিপ্ট অ্যাপ্লিকেশন Google-এ ব্রাউজার রিডাইরেক্ট ব্যবহার করে অ্যাক্সেস টোকেনের অনুরোধ করতে পারে, আবার ব্রাউজার নেই এমন ডিভাইসে ইনস্টল করা কোনও অ্যাপ্লিকেশন ওয়েব পরিষেবা অনুরোধ ব্যবহার করে। কীভাবে অনুরোধ করতে হবে সেই সম্পর্কে আরও তথ্যের জন্য, Scenarios এবং প্রতিটি অ্যাপের ধরনের জন্য বিস্তারিত প্রয়োগ করার নির্দেশিকা দেখুন।
কিছু অনুরোধের ক্ষেত্রে যাচাইকরণের ধাপ প্রয়োজন হয় যেখানে ব্যবহারকারী তার Google অ্যাকাউন্ট দিয়ে লগ-ইন করেন। লগ-ইন করার পরে, ব্যবহারকারীকে জিজ্ঞাসা করা হয় যে আপনার অ্যাপ্লিকেশন যেসব অনুমতি চাইছে, সেগুলির মধ্যে এক বা একাধিক অনুমতি দিতে তিনি ইচ্ছুক কিনা। এই প্রক্রিয়াকে ব্যবহারকারীর সম্মতি বলা হয়।
ব্যবহারকারী অন্তত একটি অনুমতি দিলে, Google Authorization Server আপনার অ্যাপ্লিকেশনকে একটি অ্যাক্সেস টোকেন (অথবা একটি অনুমোদন কোড যা আপনার অ্যাপ্লিকেশন অ্যাক্সেস টোকেন পেতে ব্যবহার করতে পারে) এবং সেই টোকেন দ্বারা অনুমোদিত অ্যাক্সেসের স্কোপের একটি তালিকা পাঠায়। ব্যবহারকারী অনুমতি না দিলে, সার্ভার একটি ত্রুটি দেখায়।
সাধারণত, অ্যাক্সেসের প্রয়োজন হলে, আগে থেকে না করে, ইনক্রিমেন্টাল পদ্ধতিতে স্কোপের অনুরোধ করা পেশাদার পদ্ধতি হিসেবে বিবেচিত হয়। যেমন, কোনও অ্যাপ যদি ক্যালেন্ডারে ইভেন্ট সেভ করার সুবিধা দিতে চায়, তাহলে ব্যবহারকারী "ক্যালেন্ডারে যোগ করুন" বোতামে প্রেস না করা পর্যন্ত Google Calendar অ্যাক্সেস করার অনুরোধ করা উচিত নয়; ইনক্রিমেন্টাল অনুমোদন দেখুন।
৩. ব্যবহারকারীর দেওয়া অ্যাক্সেসের স্কোপ পরীক্ষা করুন।
অ্যাক্সেস টোকেন রেসপন্সে অন্তর্ভুক্ত স্কোপের সাথে প্রয়োজনীয় স্কোপের তুলনা করুন যাতে আপনার অ্যাপ্লিকেশনের ফিচার ও কার্যকারিতা অ্যাক্সেস করা যায়, যা সম্পর্কিত Google API-এর অ্যাক্সেসের উপর নির্ভর করে। আপনার অ্যাপের এমন কোনও ফিচার বন্ধ করুন যা সংশ্লিষ্ট API-তে অ্যাক্সেস না থাকলে কাজ করতে পারে না।
আপনার অনুরোধে অন্তর্ভুক্ত স্কোপ আপনার উত্তরে অন্তর্ভুক্ত স্কোপের সাথে নাও মিলতে পারে, এমনকি ব্যবহারকারী অনুরোধ করা সমস্ত স্কোপ মঞ্জুর করলেও। অ্যাক্সেসের জন্য প্রয়োজনীয় স্কোপের ব্যাপারে জানতে
প্রতিটি Google API-এর ডকুমেন্টেশন দেখুন। একটি API
একাধিক স্কোপ স্ট্রিং ভ্যালুকে অ্যাক্সেসের একটি একক স্কোপে ম্যাপ করতে পারে, অনুরোধে অনুমোদিত সমস্ত ভ্যালুর জন্য একই
স্কোপ স্ট্রিং ফেরত দেয়। উদাহরণ: Google People API
https://www.googleapis.com/auth/contacts-এর একটি স্কোপ ফিরিয়ে দিতে পারে যখন কোনও অ্যাপ
ব্যবহারকারীকে https://www.google.com/m8/feeds/-এর একটি স্কোপ অনুমোদন করার অনুরোধ করে;
Google People API পদ্ধতি
people.updateContact-এর জন্য
https://www.googleapis.com/auth/contacts-এর একটি অনুমোদিত স্কোপ প্রয়োজন।
৪. API-তে অ্যাক্সেস টোকেন পাঠান।
কোনও অ্যাপ্লিকেশন অ্যাক্সেস টোকেন পাওয়ার পরে, এটি HTTP Authorization অনুরোধ হেডারে Google API-তে টোকেন পাঠায়। URI কোয়েরি-স্ট্রিং প্যারামিটার হিসেবে টোকেন পাঠানো সম্ভব, তবে আমরা এটি করার সুপারিশ করি না, কারণ URI প্যারামিটার লগ ফাইলে শেষ হতে পারে যা সম্পূর্ণরূপে সুরক্ষিত নয়। এছাড়াও, অপ্রয়োজনীয় URI প্যারামিটারের নাম তৈরি করা এড়িয়ে চলা REST-এর ক্ষেত্রে ভাল অভ্যাস।
অ্যাক্সেস টোকেন শুধুমাত্র টোকেন অনুরোধের scope-এ বর্ণিত অপারেশন এবং রিসোর্সের সেটের জন্য
বৈধ। যেমন, Google Calendar API-এর জন্য অ্যাক্সেস টোকেন ইস্যু করা হলে, সেটি Google Contacts API-এর জন্য অ্যাক্সেস প্রদান করে না। তবে, আপনি একই ধরনের অপারেশনের জন্য Google Calendar API-তে একাধিকবার
সেই অ্যাক্সেস টোকেন পাঠাতে পারবেন।
৫. প্রয়োজন হলে, অ্যাক্সেস টোকেন রিফ্রেশ করুন।
অ্যাক্সেস টোকেনের মেয়াদ সীমিত। আপনার অ্যাপ্লিকেশনের যদি একটি অ্যাক্সেস টোকেনের লাইফটাইমের বাইরে কোনও Google API-তে অ্যাক্সেসের প্রয়োজন হয়, তাহলে এটি একটি রিফ্রেশ টোকেন পেতে পারে। রিফ্রেশ টোকেন আপনার অ্যাপ্লিকেশনকে নতুন অ্যাক্সেস টোকেন পেতে দেয়।
পরিস্থিতি
এইসব পরিস্থিতিতে কীভাবে OAuth 2.0 ব্যবহার করে অথরাইজেশন কোডের অনুরোধ করতে হয় এবং বিভিন্ন ধরনের অ্যাপ্লিকেশনের জন্য অ্যাক্সেস ও রিফ্রেশ টোকেন পেতে হয় তা বর্ণনা করা হয়েছে।
ওয়েব সার্ভার অ্যাপ্লিকেশন
Google OAuth 2.0 এন্ডপয়েন্ট PHP, Java, Go, Python, Ruby এবং ASP.NET-এর মতো ভাষা ও ফ্রেমওয়ার্ক ব্যবহার করে এমন ওয়েব সার্ভার অ্যাপ্লিকেশনকে সাপোর্ট করে।
আপনার অ্যাপ্লিকেশন কোনও ব্রাউজারকে Google URL-এ রিডাইরেক্ট করলে, অনুমোদনের ক্রম শুরু হয়; URL-এ কোয়েরি প্যারামিটার থাকে যা কী ধরনের অ্যাক্সেসের অনুরোধ করা হচ্ছে তা নির্দেশ করে। Google ব্যবহারকারীর পরিচয় যাচাইকরণ, সেশন বেছে নেওয়া এবং ব্যবহারকারীর সম্মতি ম্যানেজ করে। এর ফলে একটি অনুমোদন কোড পাওয়া যায়, যা অ্যাপ্লিকেশনটি অ্যাক্সেস টোকেন এবং রিফ্রেশ টোকেনের জন্য এক্সচেঞ্জ করতে পারে।
ভবিষ্যতে ব্যবহারের জন্য অ্যাপ্লিকেশনটির রিফ্রেশ টোকেন স্টোর করা উচিত এবং Google API অ্যাক্সেস করার জন্য অ্যাক্সেস টোকেন ব্যবহার করা উচিত। অ্যাক্সেস টোকেনের মেয়াদ শেষ হয়ে গেলে, অ্যাপ্লিকেশনটি নতুন একটি টোকেন পেতে রিফ্রেশ টোকেন ব্যবহার করে।
আরও জানতে, ওয়েব সার্ভার অ্যাপ্লিকেশনের জন্য OAuth 2.0 ব্যবহার করা দেখুন।
ইনস্টল করা অ্যাপ্লিকেশন
Google OAuth 2.0 এন্ডপয়েন্ট কম্পিউটার, মোবাইল ডিভাইস ও ট্যাবলেটের মতো ডিভাইসে ইনস্টল করা অ্যাপ্লিকেশনকে সাপোর্ট করে। Google API Console-এর মাধ্যমে ক্লায়েন্ট আইডি তৈরি করার সময়, এটি যে একটি ইনস্টল করা অ্যাপ্লিকেশন তা উল্লেখ করুন, তারপর অ্যাপ্লিকেশনের ধরন হিসেবে Android, Chrome এক্সটেনশন, iOS বা ডেস্কটপ অ্যাপ বেছে নিন।
এই প্রসেসের ফলে একটি ক্লায়েন্ট আইডি এবং কিছু ক্ষেত্রে একটি ক্লায়েন্ট সিক্রেট তৈরি হয়, যা আপনি নিজের অ্যাপ্লিকেশনের সোর্স কোডে এম্বেড করেন। (এই প্রসঙ্গে, ক্লায়েন্ট সিক্রেটকে অবশ্যই সিক্রেট হিসেবে বিবেচনা করা হয় না।)
আপনার অ্যাপ্লিকেশন কোনও ব্রাউজারকে Google URL-এ রিডাইরেক্ট করলে, অনুমোদনের ক্রম শুরু হয়; URL-এ কোয়েরি প্যারামিটার থাকে যা কী ধরনের অ্যাক্সেসের অনুরোধ করা হচ্ছে তা নির্দেশ করে। Google ব্যবহারকারীর পরিচয় যাচাইকরণ, সেশন বেছে নেওয়া এবং ব্যবহারকারীর সম্মতি ম্যানেজ করে। এর ফলে একটি অনুমোদন কোড পাওয়া যায়, যা অ্যাপ্লিকেশনটি অ্যাক্সেস টোকেনের জন্য এক্সচেঞ্জ করতে পারে।
Google API অনুরোধে অন্তর্ভুক্ত করার আগে অ্যাপ্লিকেশনটির অ্যাক্সেস টোকেন যাচাই করা উচিত। টোকেনের মেয়াদ শেষ হয়ে গেলে, অ্যাপ্লিকেশনটি প্রসেসটি আবার করে।
বিকল্প হিসেবে, ব্যাকএন্ড সার্ভার রিফ্রেশ টোকেনের জন্য অনুমোদনের কোড এক্সচেঞ্জ করতে পারে, এটি একটি সুরক্ষিত লোকেশনে স্টোর করে। অ্যাক্সেস টোকেনের মেয়াদ শেষ হয়ে গেলে, ব্যাকএন্ড সার্ভার রিফ্রেশ টোকেন ব্যবহার করে অ্যাপ্লিকেশনের জন্য নতুন টোকেন পায়।
বিস্তারিত জানতে, Android-এর জন্য Google ব্যবহারকারীর ডেটায় অ্যাক্সেস অথরাইজ করুন, iOS অ্যাপে Google API অ্যাক্সেস করুন এবং ডেস্কটপ অ্যাপের জন্য OAuth 2.0 দেখুন।
ক্লায়েন্ট-সাইড (JavaScript) অ্যাপ্লিকেশন
Google OAuth 2.0 এন্ডপয়েন্ট ব্রাউজারে চলা JavaScript অ্যাপ্লিকেশনকে সাপোর্ট করে।
আপনার অ্যাপ্লিকেশন কোনও ব্রাউজারকে Google URL-এ রিডাইরেক্ট করলে, অনুমোদনের ক্রম শুরু হয়; URL-এ কোয়েরি প্যারামিটার থাকে যা কী ধরনের অ্যাক্সেসের অনুরোধ করা হচ্ছে তা নির্দেশ করে। Google ব্যবহারকারীর পরিচয় যাচাইকরণ, সেশন বেছে নেওয়া এবং ব্যবহারকারীর সম্মতি ম্যানেজ করে।
ফলাফল হল একটি অ্যাক্সেস টোকেন, যা ক্লায়েন্টকে Google API অনুরোধে অন্তর্ভুক্ত করার আগে যাচাই করতে হবে। টোকেনের মেয়াদ শেষ হয়ে গেলে, অ্যাপ্লিকেশনটি প্রসেসটি রিপিট করে।
বিস্তারিত জানতে, ক্লায়েন্ট-সাইড অ্যাপ্লিকেশনের জন্য OAuth 2.0 ব্যবহার করা দেখুন।
সীমিত-ইনপুট ডিভাইসে অ্যাপ্লিকেশন
Google OAuth 2.0 এন্ডপয়েন্ট এমন অ্যাপ্লিকেশনকে সাপোর্ট করে যা গেম কনসোল, ভিডিও ক্যামেরা ও প্রিন্টারের মতো সীমিত-ইনপুট ডিভাইসে চলে।
অনুমোদনের ক্রম শুরু হয় অ্যাপ্লিকেশন থেকে Google URL-এ অনুমোদনের কোডের জন্য ওয়েব পরিষেবা অনুরোধ করার মাধ্যমে। উত্তরে URL এবং কোড সহ একাধিক প্যারামিটার থাকে যা অ্যাপ্লিকেশন ব্যবহারকারীকে দেখায়।
ব্যবহারকারী ডিভাইস থেকে URL ও কোড পান, তারপর আরও ভাল ইনপুট ক্ষমতা সহ আলাদা ডিভাইস বা কম্পিউটারে পরিবর্তন করেন। ব্যবহারকারী ব্রাউজার চালু করে, নির্দিষ্ট URL-এ নেভিগেট করে, লগ-ইন করে এবং কোডটি লিখে।
এদিকে, অ্যাপ্লিকেশনটি নির্দিষ্ট বিরতিতে একটি Google URL পোল করে। ব্যবহারকারী অ্যাক্সেস অনুমোদন করার পরে, Google সার্ভার থেকে পাওয়া উত্তরে অ্যাক্সেস টোকেন ও রিফ্রেশ টোকেন থাকে। ভবিষ্যতে ব্যবহারের জন্য অ্যাপ্লিকেশনকে রিফ্রেশ টোকেন স্টোর করতে হবে এবং Google API অ্যাক্সেস করার জন্য অ্যাক্সেস টোকেন ব্যবহার করতে হবে। অ্যাক্সেস টোকেনের মেয়াদ শেষ হয়ে গেলে, অ্যাপ্লিকেশনটি রিফ্রেশ টোকেন ব্যবহার করে নতুন একটি টোকেন পায়।
আরও জানতে, ডিভাইসের জন্য OAuth 2.0 ব্যবহার করা দেখুন।
পরিষেবা অ্যাকাউন্ট
Google API যেমন Prediction API এবং Google Cloud Storage ব্যবহারকারীর তথ্য অ্যাক্সেস না করেই আপনার অ্যাপ্লিকেশনের হয়ে কাজ করতে পারে। এইসব পরিস্থিতিতে আপনার অ্যাপ্লিকেশনকে API-এর কাছে নিজের পরিচয় প্রমাণ করতে হয়, তবে ব্যবহারকারীর সম্মতির প্রয়োজন হয় না। একইভাবে, এন্টারপ্রাইজ পরিস্থিতিতে, আপনার অ্যাপ্লিকেশন কিছু রিসোর্সের জন্য ডেলিগেট করা অ্যাক্সেসের অনুরোধ করতে পারে।
এই ধরনের সার্ভার-টু-সার্ভার ইন্টার্যাকশনের জন্য আপনার একটি পরিষেবা অ্যাকাউন্ট প্রয়োজন, যা কোনও ব্যক্তিগত ব্যবহারকারীর পরিবর্তে আপনার অ্যাপ্লিকেশনের সাথে সম্পর্কিত একটি অ্যাকাউন্ট। আপনার অ্যাপ্লিকেশন পরিষেবা অ্যাকাউন্টের হয়ে Google API কল করে এবং ব্যবহারকারীর সম্মতির প্রয়োজন হয় না। (পরিষেবা-অ্যাকাউন্ট নয় এমন পরিস্থিতিতে, আপনার অ্যাপ্লিকেশন ব্যবহারকারীর হয়ে Google API কল করে এবং কখনও কখনও ব্যবহারকারীর সম্মতি প্রয়োজন হয়।)
Google API কনসোল থেকে আপনি যে পরিষেবা অ্যাকাউন্টের ক্রেডেনশিয়াল পান, তার মধ্যে একটি অনন্য ইমেল আইডি, ক্লায়েন্ট আইডি এবং অন্তত একটি পাবলিক/ব্যক্তিগত কী পেয়ার থাকে। আপনি ক্লায়েন্ট আইডি ও একটি ব্যক্তিগত কী ব্যবহার করে স্বাক্ষরিত JWT তৈরি করেন এবং সঠিক ফর্ম্যাটে অ্যাক্সেস-টোকেন অনুরোধ তৈরি করেন। আপনার অ্যাপ্লিকেশন তখন Google OAuth 2.0 অনুমোদন সার্ভারে টোকেন অনুরোধ পাঠায়, যা একটি অ্যাক্সেস টোকেন ফেরত দেয়। অ্যাপ্লিকেশনটি Google API অ্যাক্সেস করতে টোকেন ব্যবহার করে। টোকেনের মেয়াদ শেষ হয়ে গেলে, অ্যাপ্লিকেশনটি প্রসেসটি আবার করে।
বিস্তারিত জানতে, পরিষেবা-অ্যাকাউন্ট ডকুমেন্টেশন দেখুন।
টোকেনের সাইজ
টোকেনের সাইজ আলাদা হতে পারে, তবে তা নিম্নলিখিত সীমার মধ্যে থাকে:
Google Cloud-এর Security Token Service API থেকে পাওয়া অ্যাক্সেস টোকেন Google API OAuth 2.0 অ্যাক্সেস টোকেনের মতোই স্ট্রাকচার করা হয়, তবে টোকেনের সাইজের সীমা আলাদা হয়। বিস্তারিত জানতে, API ডকুমেন্টেশন দেখুন।
Google এই সীমার মধ্যে টোকেনের সাইজ পরিবর্তন করার অধিকার সংরক্ষণ করে এবং আপনার অ্যাপ্লিকেশনকে সেই অনুযায়ী পরিবর্তনশীল টোকেন সাইজ সাপোর্ট করতে হবে।
রিফ্রেশ টোকেনের মেয়াদ শেষ হওয়া
আপনাকে এমনভাবে কোড লিখতে হবে যাতে আগে থেকে অনুমান করা যায় যে মঞ্জুর করা রিফ্রেশ টোকেন আর কাজ নাও করতে পারে। এইসব কারণে রিফ্রেশ টোকেন কাজ করা বন্ধ করে দিতে পারে:
Google Cloud Platform প্রোজেক্টে OAuth কনসেন্ট স্ক্রিন এক্সটার্নাল ব্যবহারকারীর ধরন এবং "টেস্টিং" প্রকাশনার স্ট্যাটাসের জন্য কনফিগার করা থাকলে, রিফ্রেশ টোকেন ইস্যু করা হয় যা ৭ দিনে শেষ হয়ে যায়। তবে, শুধুমাত্র OAuth স্কোপের অনুরোধ করা হলে, তা নাম, ইমেল আইডি এবং ব্যবহারকারীর প্রোফাইলের (userinfo.email, userinfo.profile, openid স্কোপ বা তার OpenID Connect সমতুল্য) সাবসেট হয়।
বর্তমানে প্রতিটি Google অ্যাকাউন্টের জন্য প্রতিটি OAuth 2.0 ক্লায়েন্ট আইডিতে ১০০টি রিফ্রেশ টোকেনের সীমা আছে। সীমা পেরিয়ে গেলে, নতুন রিফ্রেশ টোকেন তৈরি করলে সবচেয়ে পুরনো রিফ্রেশ টোকেন কোনও সতর্কবার্তা ছাড়াই অটোমেটিক বাতিল হয়ে যায়। এই সীমা পরিষেবা অ্যাকাউন্টের ক্ষেত্রে প্রযোজ্য নয়।
এছাড়াও, সমস্ত ক্লায়েন্ট জুড়ে কোনও ব্যবহারকারীর অ্যাকাউন্ট বা পরিষেবা অ্যাকাউন্টে থাকতে পারে এমন রিফ্রেশ টোকেনের মোট সংখ্যার উপর একটি বড় সীমা রয়েছে। বেশিরভাগ সাধারণ ব্যবহারকারী এই সীমা অতিক্রম করবেন না, তবে কোনও ডেভেলপার অ্যাকাউন্ট যা ইমপ্লিমেন্টেশন পরীক্ষা করার জন্য ব্যবহার করা হয়, তা করতে পারে।
আপনাকে একাধিক প্রোগ্রাম, মেশিন বা ডিভাইস অনুমোদন করতে হলে, একটি সমাধান হল প্রতি Google অ্যাকাউন্টে আপনার অনুমোদিত ক্লায়েন্টের সংখ্যা ১৫ বা ২০-তে সীমিত করা। আপনি যদি Google Workspace অ্যাডমিন হন, তাহলে আপনি অ্যাডমিনিস্ট্রেটরের বিশেষ সুবিধা সহ অতিরিক্ত ব্যবহারকারী তৈরি করতে এবং কিছু ক্লায়েন্টকে অনুমোদন দিতে তাদের ব্যবহার করতে পারবেন।
Google Cloud Platform (GCP) সংস্থার জন্য সেশন কন্ট্রোল নীতি ম্যানেজ করা
GCP সংস্থার অ্যাডমিনিস্ট্রেটরদের, GCP রিসোর্স অ্যাক্সেস করার সময়,
Google Cloud সেশন কন্ট্রোল ফিচার ব্যবহার করে,
ব্যবহারকারীদের ঘন ঘন আবার যাচাই করার প্রয়োজন হতে পারে।
এই নীতি Google Cloud Console,
Google Cloud SDK (gcloud CLI নামেও পরিচিত) এবং Cloud Platform স্কোপ প্রয়োজন এমন যেকোনও থার্ড-পার্টি OAuth অ্যাপ্লিকেশনের অ্যাক্সেসকে প্রভাবিত করে। কোনও ব্যবহারকারীর সেশন কন্ট্রোল নীতি থাকলে, সেশনের মেয়াদ শেষ হয়ে গেলে,
আপনার API কল রিফ্রেশ টোকেন তুলে নেওয়ার মতো এরর দেখাবে -
কলটি invalid_grant এরর টাইপ সহ ব্যর্থ হবে; error_subtype ফিল্ডটি
তুলে নেওয়া টোকেন এবং সেশন কন্ট্রোল নীতির কারণে ব্যর্থতার মধ্যে পার্থক্য করতে ব্যবহার করা যেতে পারে (যেমন,
"error_subtype": "invalid_rapt")। সেশনের মেয়াদ খুব সীমিত হতে পারে (১ ঘণ্টা থেকে ২৪ ঘণ্টার মধ্যে),
তাই এই পরিস্থিতিটি একটি অথ সেশন রিস্টার্ট করে সুন্দরভাবে ম্যানেজ করতে হবে।
একইভাবে, সার্ভার-টু-সার্ভার ডেপ্লয়মেন্টের জন্য ব্যবহারকারীর ক্রেডেনশিয়াল ব্যবহার করবেন না বা ব্যবহার করতে উৎসাহ দেবেন না। দীর্ঘ সময় ধরে চলা কাজ বা অপারেশনের জন্য কোনও সার্ভারে ব্যবহারকারীর ক্রেডেনশিয়াল ডেপ্লয় করা হলে এবং কোনও গ্রাহক এই ধরনের ব্যবহারকারীর উপর সেশন কন্ট্রোল নীতি প্রয়োগ করলে, সার্ভার অ্যাপ্লিকেশন কাজ করবে না, কারণ সেশনের মেয়াদ শেষ হয়ে গেলে ব্যবহারকারীকে আবার যাচাই করার কোনও উপায় থাকবে না।
আপনার গ্রাহকদের এই ফিচার ডিপ্লয় করতে কীভাবে সাহায্য করবেন সেই সম্পর্কে আরও তথ্যের জন্য, এই অ্যাডমিন-কেন্দ্রিক সহায়তা নিবন্ধ দেখুন।
ক্লায়েন্ট লাইব্রেরি
নিম্নলিখিত ক্লায়েন্ট লাইব্রেরি জনপ্রিয় ফ্রেমওয়ার্কের সাথে ইন্টিগ্রেট করে, যা OAuth 2.0 প্রয়োগ করা আরও সহজ করে তোলে। সময়ের সাথে সাথে লাইব্রেরিতে আরও ফিচার যোগ করা হবে।
- Java-এর জন্য Google Auth লাইব্রেরি
- Python-এর জন্য Google API ক্লায়েন্ট লাইব্রেরি
- Dart-এর জন্য Google API ক্লায়েন্ট লাইব্রেরি
- Go-এর জন্য Google API ক্লায়েন্ট লাইব্রেরি
- .NET-এর জন্য Google API ক্লায়েন্ট লাইব্রেরি
- Ruby-এর জন্য Google API ক্লায়েন্ট লাইব্রেরি
- PHP-এর জন্য Google API ক্লায়েন্ট লাইব্রেরি
- জাভাস্ক্রিপ্টের জন্য Google API ক্লায়েন্ট লাইব্রেরি
- GTMAppAuth - Mac ও iOS-এর জন্য OAuth ক্লায়েন্ট লাইব্রেরি