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 Console-এ যান। আপনি কোন ধরনের অ্যাপ্লিকেশন তৈরি করছেন তার উপর ভিত্তি করে ভ্যালুর সেট আলাদা হয়। যেমন, JavaScript অ্যাপ্লিকেশনের জন্য কোনও সিক্রেট প্রয়োজন হয় না, কিন্তু ওয়েব সার্ভার অ্যাপ্লিকেশনের জন্য প্রয়োজন হয়।
আপনার অ্যাপ যে প্ল্যাটফর্মে চলবে তার জন্য উপযুক্ত একটি OAuth ক্লায়েন্ট তৈরি করতে হবে, যেমন:
- Android অ্যাপের জন্য, Android অ্যাপ্লিকেশনের ধরন ব্যবহার করুন।
-
iOS অ্যাপের জন্য, iOS অ্যাপ্লিকেশন টাইপ ব্যবহার করুন।
- desktop_windows ডেস্কটপ অ্যাপের জন্য (যেমন Windows, macOS বা Linux অ্যাপ্লিকেশন বা CLI টুল), ডেস্কটপ অ্যাপ অ্যাপ্লিকেশন টাইপ ব্যবহার করুন।
- কোড সার্ভার-সাইড অথবা JavaScript ওয়েব অ্যাপের জন্য ওয়েব অ্যাপ্লিকেশন অ্যাপ্লিকেশন টাইপ ব্যবহার করুন। নেটিভ বা মোবাইল অ্যাপের মতো অন্য কোনও অ্যাপ্লিকেশনের জন্য এই ধরনের অ্যাপ্লিকেশন ব্যবহার করবেন না।
- chrome_extension Chrome এক্সটেনশনের জন্য, Chrome এক্সটেনশন অ্যাপ্লিকেশন টাইপ ব্যবহার করুন।
- tv টিভি বা এম্বেড করা ডিভাইসের মতো সীমিত ইনপুট ডিভাইসের জন্য, টিভি এবং সীমিত ইনপুট ডিভাইস অ্যাপ্লিকেশন টাইপ ব্যবহার করুন।
- হোস্ট সার্ভার-টু-সার্ভার ইন্টার্যাকশনের জন্য, পরিষেবা অ্যাকাউন্ট ব্যবহার করুন। কোনও OAuth ক্লায়েন্ট আইডি প্রয়োজন নেই।
২. Google অথরাইজেশন সার্ভার থেকে অ্যাক্সেস টোকেন পান।
আপনার অ্যাপ্লিকেশন Google API ব্যবহার করে ব্যক্তিগত ডেটা অ্যাক্সেস করার আগে, এটিকে অবশ্যই একটি
অ্যাক্সেস টোকেন পেতে হবে যা সেই API-তে অ্যাক্সেস প্রদান করে। একটি অ্যাক্সেস টোকেন একাধিক API-তে বিভিন্ন মাত্রার
অ্যাক্সেস দিতে পারে। scope নামক একটি পরিবর্তনশীল প্যারামিটার, অ্যাক্সেস টোকেন দ্বারা অনুমোদিত রিসোর্স ও অপারেশনের সেট
নিয়ন্ত্রণ করে। অ্যাক্সেস-টোকেন অনুরোধের সময়,
আপনার অ্যাপ্লিকেশন scope প্যারামিটারে এক বা একাধিক ভ্যালু পাঠায়।
এই অনুরোধ করার বিভিন্ন উপায় আছে এবং আপনি যে ধরনের অ্যাপ্লিকেশন তৈরি করছেন তার উপর ভিত্তি করে সেগুলি আলাদা হয়। যেমন, কোনও JavaScript অ্যাপ্লিকেশন, 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 অনুমোদনের অনুরোধ হেডারে 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 ব্যবহার করা দেখুন।
পরিষেবা অ্যাকাউন্ট
Prediction API এবং Google Cloud Storage-এর মতো Google API ব্যবহারকারীর তথ্য অ্যাক্সেস না করেই আপনার অ্যাপ্লিকেশনের হয়ে কাজ করতে পারে। এই পরিস্থিতিতে আপনার অ্যাপ্লিকেশনকে API-এর কাছে নিজের পরিচয় প্রমাণ করতে হয়, তবে ব্যবহারকারীর সম্মতির প্রয়োজন হয় না। একইভাবে, এন্টারপ্রাইজ পরিস্থিতিতে, আপনার অ্যাপ্লিকেশন কিছু রিসোর্সের জন্য ডেলিগেট করা অ্যাক্সেসের অনুরোধ করতে পারে।
এই ধরনের সার্ভার-টু-সার্ভার ইন্টার্যাকশনের জন্য আপনার একটি পরিষেবা অ্যাকাউন্ট প্রয়োজন, যা হল এমন একটি অ্যাকাউন্ট যা কোনও ব্যক্তিগত ব্যবহারকারীর পরিবর্তে আপনার অ্যাপ্লিকেশনের সাথে সম্পর্কিত। আপনার অ্যাপ্লিকেশন পরিষেবা অ্যাকাউন্টের হয়ে Google API কল করে এবং ব্যবহারকারীর সম্মতির প্রয়োজন হয় না। (পরিষেবা-অ্যাকাউন্ট নয় এমন পরিস্থিতিতে, আপনার অ্যাপ্লিকেশন ব্যবহারকারীর হয়ে Google API কল করে এবং কখনও কখনও ব্যবহারকারীর সম্মতি প্রয়োজন হয়।)
Google API Console থেকে পাওয়া কোনও পরিষেবা অ্যাকাউন্টের ক্রেডেনশিয়ালে একটি অনন্য ইমেল আইডি, একটি ক্লায়েন্ট আইডি এবং অন্তত একটি পাবলিক/প্রাইভেট কী পেয়ার থাকে। আপনি ক্লায়েন্ট আইডি এবং একটি ব্যক্তিগত কী ব্যবহার করে স্বাক্ষরিত 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 ক্লায়েন্ট লাইব্রেরি