Google API অ্যাক্সেস করতে OAuth 2.0 ব্যবহার করা হচ্ছে

গুগল এপিআইগুলো প্রমাণীকরণ এবং অনুমোদনের জন্য OAuth 2.0 প্রোটোকল ব্যবহার করে। গুগল ওয়েব সার্ভার, ক্লায়েন্ট-সাইড, ইনস্টল করা এবং সীমিত-ইনপুট ডিভাইস অ্যাপ্লিকেশনের মতো সাধারণ OAuth 2.0 পরিস্থিতিগুলোকে সমর্থন করে।

শুরু করার জন্য, গুগল এপিআই কনসোল থেকে OAuth 2.0 ক্লায়েন্ট ক্রেডেনশিয়াল সংগ্রহ করুন। এরপর আপনার ক্লায়েন্ট অ্যাপ্লিকেশনটি গুগল অথরাইজেশন সার্ভারের কাছে একটি অ্যাক্সেস টোকেনের জন্য অনুরোধ করবে, রেসপন্স থেকে একটি টোকেন বের করে নেবে এবং আপনি যে গুগল এপিআই অ্যাক্সেস করতে চান, সেখানে টোকেনটি পাঠিয়ে দেবে। গুগলের সাথে OAuth 2.0 ব্যবহারের একটি ইন্টারেক্টিভ ডেমোনস্ট্রেশনের জন্য (যেখানে আপনার নিজের ক্লায়েন্ট ক্রেডেনশিয়াল ব্যবহার করার বিকল্পও রয়েছে), OAuth 2.0 প্লেগ্রাউন্ডটি ব্যবহার করে দেখুন।

এই পৃষ্ঠাটি গুগল দ্বারা সমর্থিত OAuth 2.0 অনুমোদন পরিস্থিতিগুলির একটি সংক্ষিপ্ত বিবরণ দেয় এবং আরও বিস্তারিত তথ্যের জন্য লিঙ্ক প্রদান করে। প্রমাণীকরণের জন্য OAuth 2.0 ব্যবহারের বিশদ বিবরণের জন্য, OpenID Connect দেখুন।

প্রাথমিক পদক্ষেপ

OAuth 2.0 ব্যবহার করে গুগল এপিআই অ্যাক্সেস করার সময় সমস্ত অ্যাপ্লিকেশন একটি মৌলিক প্যাটার্ন অনুসরণ করে। মোটা দাগে, আপনাকে পাঁচটি ধাপ অনুসরণ করতে হয়:

১. গুগল এপিআই কনসোল থেকে OAuth 2.0 ক্রেডেনশিয়াল সংগ্রহ করুন।

ক্লায়েন্ট আইডি এবং ক্লায়েন্ট সিক্রেটের মতো OAuth 2.0 ক্রেডেনশিয়াল পেতে Google API Console-এ যান, যা Google এবং আপনার অ্যাপ্লিকেশন উভয়ের কাছেই পরিচিত। আপনি কী ধরনের অ্যাপ্লিকেশন তৈরি করছেন তার উপর ভিত্তি করে এই মানগুলো পরিবর্তিত হয়। উদাহরণস্বরূপ, একটি জাভাস্ক্রিপ্ট অ্যাপ্লিকেশনের জন্য সিক্রেটের প্রয়োজন হয় না, কিন্তু একটি ওয়েব সার্ভার অ্যাপ্লিকেশনের জন্য হয়।

আপনাকে অবশ্যই সেই প্ল্যাটফর্মের জন্য উপযুক্ত একটি OAuth ক্লায়েন্ট তৈরি করতে হবে যেখানে আপনার অ্যাপটি চলবে, উদাহরণস্বরূপ:

২. গুগল অনুমোদন সার্ভার থেকে একটি অ্যাক্সেস টোকেন সংগ্রহ করুন।

আপনার অ্যাপ্লিকেশন কোনো গুগল এপিআই ব্যবহার করে ব্যক্তিগত ডেটা অ্যাক্সেস করার আগে, এটিকে অবশ্যই একটি অ্যাক্সেস টোকেন সংগ্রহ করতে হবে যা সেই এপিআই-তে অ্যাক্সেসের অনুমতি দেয়। একটিমাত্র অ্যাক্সেস টোকেন একাধিক এপিআই-তে বিভিন্ন মাত্রার অ্যাক্সেস দিতে পারে। scope নামক একটি পরিবর্তনশীল প্যারামিটার সেই রিসোর্স এবং অপারেশনগুলোর সেট নিয়ন্ত্রণ করে, যা একটি অ্যাক্সেস টোকেন অনুমোদন করে। অ্যাক্সেস-টোকেন অনুরোধের সময়, আপনার অ্যাপ্লিকেশন scope প্যারামিটারে এক বা একাধিক ভ্যালু পাঠায়।

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

কিছু অনুরোধের জন্য একটি প্রমাণীকরণ ধাপের প্রয়োজন হয়, যেখানে ব্যবহারকারী তার গুগল অ্যাকাউন্ট দিয়ে লগ ইন করেন। লগ ইন করার পর, ব্যবহারকারীকে জিজ্ঞাসা করা হয় যে আপনার অ্যাপ্লিকেশনটি যে এক বা একাধিক অনুমতি চাইছে, তা তিনি দিতে ইচ্ছুক কিনা। এই প্রক্রিয়াটিকে ব্যবহারকারীর সম্মতি বলা হয়।

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

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

৩. ব্যবহারকারী কর্তৃক প্রদত্ত প্রবেশাধিকারের পরিধি পরীক্ষা করুন।

অ্যাক্সেস টোকেন রেসপন্সে অন্তর্ভুক্ত স্কোপগুলোর সাথে আপনার অ্যাপ্লিকেশনের সেইসব ফিচার ও কার্যকারিতা অ্যাক্সেস করার জন্য প্রয়োজনীয় স্কোপগুলোর তুলনা করুন, যা একটি সম্পর্কিত গুগল এপিআই-এর অ্যাক্সেসের উপর নির্ভরশীল। আপনার অ্যাপের যে ফিচারগুলো সম্পর্কিত এপিআই-এর অ্যাক্সেস ছাড়া কাজ করতে পারে না, সেগুলোকে নিষ্ক্রিয় করুন।

আপনার অনুরোধে অন্তর্ভুক্ত স্কোপটি আপনার প্রতিক্রিয়ায় অন্তর্ভুক্ত স্কোপের সাথে নাও মিলতে পারে, এমনকি যদি ব্যবহারকারী অনুরোধ করা সমস্ত স্কোপের অনুমতি দিয়ে থাকেন। অ্যাক্সেসের জন্য প্রয়োজনীয় স্কোপগুলো জানতে প্রতিটি গুগল এপিআই-এর ডকুমেন্টেশন দেখুন। একটি এপিআই একাধিক স্কোপ স্ট্রিং ভ্যালুকে একটিমাত্র অ্যাক্সেস স্কোপে ম্যাপ করতে পারে এবং অনুরোধে অনুমোদিত সমস্ত ভ্যালুর জন্য একই স্কোপ স্ট্রিং রিটার্ন করতে পারে। উদাহরণস্বরূপ: যখন কোনো অ্যাপ ব্যবহারকারীকে https://www.google.com/m8/feeds/ স্কোপের অনুমতি দিতে অনুরোধ করে, তখন গুগল পিপল এপিআই https://www.googleapis.com/auth/contacts স্কোপটি রিটার্ন করতে পারে; গুগল পিপল এপিআই-এর people.updateContact মেথডটির জন্য https://www.googleapis.com/auth/contacts স্কোপের অনুমতি প্রয়োজন।

৪. অ্যাক্সেস টোকেনটি একটি এপিআই-তে পাঠান।

কোনো অ্যাপ্লিকেশন অ্যাক্সেস টোকেন পাওয়ার পর, সেটি একটি HTTP Authorization রিকোয়েস্ট হেডারে টোকেনটি গুগল এপিআই-তে পাঠায়। টোকেনগুলোকে URI কোয়েরি-স্ট্রিং প্যারামিটার হিসেবে পাঠানো সম্ভব, কিন্তু আমরা এর সুপারিশ করি না, কারণ URI প্যারামিটারগুলো এমন লগ ফাইলে চলে যেতে পারে যা সম্পূর্ণ সুরক্ষিত নয়। এছাড়াও, অপ্রয়োজনীয় URI প্যারামিটারের নাম তৈরি করা এড়িয়ে চলা একটি ভালো REST অনুশীলন।

অ্যাক্সেস টোকেন শুধুমাত্র টোকেন অনুরোধের scope বর্ণিত অপারেশন এবং রিসোর্সগুলোর জন্যই বৈধ। উদাহরণস্বরূপ, যদি গুগল ক্যালেন্ডার এপিআই-এর জন্য একটি অ্যাক্সেস টোকেন ইস্যু করা হয়, তবে এটি গুগল কন্টাক্টস এপিআই-তে অ্যাক্সেস প্রদান করে না। তবে, আপনি একই ধরনের অপারেশনের জন্য সেই অ্যাক্সেস টোকেনটি গুগল ক্যালেন্ডার এপিআই-তে একাধিকবার পাঠাতে পারেন।

৫. প্রয়োজনে অ্যাক্সেস টোকেনটি রিফ্রেশ করুন।

অ্যাক্সেস টোকেনের একটি সীমিত মেয়াদ থাকে। যদি আপনার অ্যাপ্লিকেশনের একটিমাত্র অ্যাক্সেস টোকেনের মেয়াদের পরেও কোনো গুগল এপিআই (Google API) অ্যাক্সেস করার প্রয়োজন হয়, তবে এটি একটি রিফ্রেশ টোকেন সংগ্রহ করতে পারে। একটি রিফ্রেশ টোকেন আপনার অ্যাপ্লিকেশনকে নতুন অ্যাক্সেস টোকেন সংগ্রহ করার সুযোগ দেয়।

দৃশ্যকল্প

এই দৃশ্যকল্পগুলোতে বর্ণনা করা হয়েছে কীভাবে OAuth 2.0 ব্যবহার করে বিভিন্ন ধরনের অ্যাপ্লিকেশনের জন্য অনুমোদন কোডের অনুরোধ করা যায় এবং অ্যাক্সেস ও রিফ্রেশ টোকেন পাওয়া যায়।

ওয়েব সার্ভার অ্যাপ্লিকেশন

গুগল OAuth 2.0 এন্ডপয়েন্টটি PHP, Java, Go, Python, Ruby, এবং ASP.NET-এর মতো ভাষা ও ফ্রেমওয়ার্ক ব্যবহারকারী ওয়েব সার্ভার অ্যাপ্লিকেশনগুলোকে সমর্থন করে।

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

অ্যাপ্লিকেশনটি ভবিষ্যতের ব্যবহারের জন্য রিফ্রেশ টোকেনটি সংরক্ষণ করবে এবং গুগল এপিআই অ্যাক্সেস করার জন্য অ্যাক্সেস টোকেনটি ব্যবহার করবে। অ্যাক্সেস টোকেনের মেয়াদ শেষ হয়ে গেলে, অ্যাপ্লিকেশনটি একটি নতুন টোকেন পাওয়ার জন্য রিফ্রেশ টোকেনটি ব্যবহার করবে।

আপনার অ্যাপ্লিকেশনটি গুগল অথরাইজেশন সার্ভারে একটি টোকেন অনুরোধ পাঠায়, একটি অথরাইজেশন কোড গ্রহণ করে, কোডটিকে একটি টোকেনের জন্য বিনিময় করে, এবং টোকেনটি ব্যবহার করে একটি গুগল এপিআই এন্ডপয়েন্টকে কল করে।

বিস্তারিত জানতে, “ওয়েব সার্ভার অ্যাপ্লিকেশনের জন্য OAuth 2.0 ব্যবহার” দেখুন।

ইনস্টল করা অ্যাপ্লিকেশনগুলি

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

এই প্রক্রিয়ার ফলে একটি ক্লায়েন্ট আইডি এবং কিছু ক্ষেত্রে একটি ক্লায়েন্ট সিক্রেট পাওয়া যায়, যা আপনি আপনার অ্যাপ্লিকেশনের সোর্স কোডে অন্তর্ভুক্ত করেন। (এই প্রসঙ্গে, ক্লায়েন্ট সিক্রেটটিকে স্পষ্টতই গোপনীয় হিসেবে গণ্য করা হয় না।)

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

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

আপনার অ্যাপ্লিকেশনটি গুগল অথরাইজেশন সার্ভারে একটি টোকেন অনুরোধ পাঠায়, একটি অথরাইজেশন কোড গ্রহণ করে, কোডটিকে একটি টোকেনের জন্য বিনিময় করে, এবং টোকেনটি ব্যবহার করে একটি গুগল এপিআই এন্ডপয়েন্টকে কল করে।

বিস্তারিত জানতে, Android-এর জন্য Google ব্যবহারকারীর ডেটাতে অ্যাক্সেস অনুমোদন এবং iOS ও ডেস্কটপ অ্যাপের জন্য OAuth 2.0 দেখুন।

ক্লায়েন্ট-সাইড (জাভাস্ক্রিপ্ট) অ্যাপ্লিকেশন

গুগল OAuth 2.0 এন্ডপয়েন্ট ব্রাউজারে চালিত জাভাস্ক্রিপ্ট অ্যাপ্লিকেশনগুলোকে সমর্থন করে।

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

এর ফলে একটি অ্যাক্সেস টোকেন পাওয়া যায়, যা গুগল এপিআই অনুরোধে অন্তর্ভুক্ত করার আগে ক্লায়েন্টের যাচাই করা উচিত। টোকেনটির মেয়াদ শেষ হয়ে গেলে, অ্যাপ্লিকেশনটি প্রক্রিয়াটি পুনরায় করে।

আপনার JS অ্যাপ্লিকেশনটি গুগল অথরাইজেশন সার্ভারে একটি টোকেন অনুরোধ পাঠায়, একটি টোকেন গ্রহণ করে, টোকেনটি যাচাই করে, এবং টোকেনটি ব্যবহার করে একটি গুগল এপিআই এন্ডপয়েন্ট কল করে।

বিস্তারিত জানতে, ক্লায়েন্ট-সাইড অ্যাপ্লিকেশনগুলির জন্য OAuth 2.0-এর ব্যবহার দেখুন।

সীমিত-ইনপুট ডিভাইসে অ্যাপ্লিকেশন

গুগল OAuth 2.0 এন্ডপয়েন্টটি গেম কনসোল, ভিডিও ক্যামেরা এবং প্রিন্টারের মতো সীমিত-ইনপুট ডিভাইসে চালিত অ্যাপ্লিকেশনগুলিকে সমর্থন করে।

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

ব্যবহারকারী ডিভাইস থেকে ইউআরএল এবং কোডটি সংগ্রহ করেন, তারপর আরও উন্নত ইনপুট সুবিধা সম্পন্ন একটি আলাদা ডিভাইস বা কম্পিউটারে চলে যান। ব্যবহারকারী একটি ব্রাউজার চালু করে নির্দিষ্ট ইউআরএল-এ যান, লগ ইন করেন এবং কোডটি প্রবেশ করান।

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

ব্যবহারকারী একটি আলাদা ডিভাইসে লগ ইন করেন যেটিতে একটি ব্রাউজার আছে।

বিস্তারিত জানতে, ডিভাইসের জন্য OAuth 2.0 ব্যবহার দেখুন।

পরিষেবা অ্যাকাউন্ট

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

এই ধরনের সার্ভার-টু-সার্ভার ইন্টারঅ্যাকশনের জন্য আপনার একটি সার্ভিস অ্যাকাউন্ট প্রয়োজন, যা কোনো স্বতন্ত্র ব্যবহারকারীর পরিবর্তে আপনার অ্যাপ্লিকেশনের নিজস্ব অ্যাকাউন্ট। আপনার অ্যাপ্লিকেশনটি সার্ভিস অ্যাকাউন্টের পক্ষ থেকে গুগল এপিআই (Google APIs) কল করে এবং এর জন্য ব্যবহারকারীর সম্মতির প্রয়োজন হয় না। (যেসব ক্ষেত্রে সার্ভিস অ্যাকাউন্ট থাকে না, সেখানে আপনার অ্যাপ্লিকেশনটি ব্যবহারকারীদের পক্ষ থেকে গুগল এপিআই (Google APIs) কল করে এবং এক্ষেত্রে ব্যবহারকারীর সম্মতির প্রয়োজন হতে পারে।)

একটি সার্ভিস অ্যাকাউন্টের ক্রেডেনশিয়াল, যা আপনি গুগল এপিআই কনসোল থেকে পান, তার মধ্যে একটি অনন্য জেনারেটেড ইমেল অ্যাড্রেস, একটি ক্লায়েন্ট আইডি এবং অন্তত একটি পাবলিক/প্রাইভেট কী পেয়ার অন্তর্ভুক্ত থাকে। আপনি ক্লায়েন্ট আইডি এবং একটি প্রাইভেট কী ব্যবহার করে একটি সাইনড JWT তৈরি করেন এবং উপযুক্ত ফরম্যাটে একটি অ্যাক্সেস-টোকেন রিকোয়েস্ট প্রস্তুত করেন। এরপর আপনার অ্যাপ্লিকেশনটি টোকেন রিকোয়েস্টটি গুগল OAuth 2.0 অথরাইজেশন সার্ভারে পাঠায়, যা একটি অ্যাক্সেস টোকেন ফেরত পাঠায়। অ্যাপ্লিকেশনটি একটি গুগল এপিআই অ্যাক্সেস করার জন্য টোকেনটি ব্যবহার করে। টোকেনের মেয়াদ শেষ হয়ে গেলে, অ্যাপ্লিকেশনটি প্রক্রিয়াটি পুনরায় করে।

আপনার সার্ভার অ্যাপ্লিকেশনটি গুগল অথরাইজেশন সার্ভার থেকে একটি টোকেন অনুরোধ করার জন্য একটি JWT ব্যবহার করে, তারপর সেই টোকেনটি ব্যবহার করে একটি গুগল এপিআই এন্ডপয়েন্ট কল করে। এতে কোনো এন্ড-ইউজার জড়িত নন।

বিস্তারিত জানতে সার্ভিস-অ্যাকাউন্ট ডকুমেন্টেশন দেখুন।

টোকেনের আকার

টোকেনগুলোর আকার নিম্নলিখিত সীমা পর্যন্ত ভিন্ন হতে পারে:

  • কোড অনুমোদন কোড
    ২৫৬ বাইট
  • প্রসঙ্গ_টোকেন অ্যাক্সেস টোকেন
    ২০৪৮ বাইট
  • পুনরুদ্ধার_পৃষ্ঠা টোকেন রিফ্রেশ করুন
    ৫১২ বাইট

গুগল ক্লাউডের সিকিউরিটি টোকেন সার্ভিস এপিআই দ্বারা ফেরত দেওয়া অ্যাক্সেস টোকেনগুলোর গঠন গুগল এপিআই ওঅথ ২.০ অ্যাক্সেস টোকেনের মতোই, কিন্তু এগুলোর টোকেন আকারের সীমা ভিন্ন। বিস্তারিত জানতে এপিআই ডকুমেন্টেশন দেখুন।

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

রিফ্রেশ টোকেনের মেয়াদ শেষ

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

একটি গুগল ক্লাউড প্ল্যাটফর্ম প্রজেক্ট, যেখানে বহিরাগত ব্যবহারকারীর ধরনের জন্য একটি OAuth সম্মতি স্ক্রিন কনফিগার করা আছে এবং পাবলিশিং স্ট্যাটাস "টেস্টিং" রয়েছে, সেটিকে ৭ দিন মেয়াদী একটি রিফ্রেশ টোকেন দেওয়া হয়; যদি না শুধুমাত্র নাম, ইমেল ঠিকানা এবং ব্যবহারকারীর প্রোফাইলের একটি উপসেট OAuth স্কোপের জন্য অনুরোধ করা হয় ( userinfo.email, userinfo.profile, openid স্কোপ বা তাদের OpenID Connect সমতুল্য স্কোপের মাধ্যমে)।

বর্তমানে, প্রতিটি OAuth 2.0 ক্লায়েন্ট আইডির জন্য প্রতি গুগল অ্যাকাউন্টে ১০০টি রিফ্রেশ টোকেনের একটি সীমা রয়েছে। এই সীমায় পৌঁছালে, একটি নতুন রিফ্রেশ টোকেন তৈরি করার সময় কোনো সতর্কতা ছাড়াই সবচেয়ে পুরোনো রিফ্রেশ টোকেনটি স্বয়ংক্রিয়ভাবে বাতিল হয়ে যায়। এই সীমাটি সার্ভিস অ্যাকাউন্টের ক্ষেত্রে প্রযোজ্য নয়।

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

যদি আপনাকে একাধিক প্রোগ্রাম, মেশিন বা ডিভাইস অনুমোদন করার প্রয়োজন হয়, তবে এর একটি সমাধান হলো প্রতিটি গুগল অ্যাকাউন্টের অধীনে অনুমোদিত ক্লায়েন্টের সংখ্যা ১৫ বা ২০-এ সীমাবদ্ধ রাখা। আপনি যদি একজন গুগল ওয়ার্কস্পেস অ্যাডমিন হন, তবে আপনি প্রশাসনিক সুবিধাসহ অতিরিক্ত ব্যবহারকারী তৈরি করতে পারেন এবং তাদের ব্যবহার করে কিছু ক্লায়েন্টকে অনুমোদন দিতে পারেন।

গুগল ক্লাউড প্ল্যাটফর্ম (GCP) সংস্থাগুলির জন্য সেশন নিয়ন্ত্রণ নীতিগুলি পরিচালনা করা

GCP সংস্থাগুলির প্রশাসকগণ Google Cloud সেশন কন্ট্রোল ফিচার ব্যবহার করে GCP রিসোর্স অ্যাক্সেস করার সময় ব্যবহারকারীদের ঘন ঘন পুনঃপ্রমাণীকরণের প্রয়োজন অনুভব করতে পারেন। এই নীতিটি Google Cloud Console, Google Cloud SDK (যা gcloud CLI নামেও পরিচিত), এবং Cloud Platform স্কোপের প্রয়োজন এমন যেকোনো থার্ড-পার্টি OAuth অ্যাপ্লিকেশনের অ্যাক্সেসকে প্রভাবিত করে। যদি কোনো ব্যবহারকারীর একটি সেশন কন্ট্রোল পলিসি চালু থাকে, তাহলে সেশনের মেয়াদ শেষ হয়ে গেলে আপনার API কলগুলিতে ত্রুটি দেখা দেবে, যা রিফ্রেশ টোকেন বাতিল হয়ে গেলে যা ঘটে তার অনুরূপ – কলটি invalid_grant নামক একটি এরর টাইপ সহ ব্যর্থ হবে; একটি বাতিল টোকেন এবং সেশন কন্ট্রোল পলিসির কারণে ব্যর্থতার মধ্যে পার্থক্য করার জন্য error_subtype ফিল্ডটি ব্যবহার করা যেতে পারে (উদাহরণস্বরূপ, "error_subtype": "invalid_rapt" )। যেহেতু সেশনের মেয়াদ খুব সীমিত হতে পারে (১ ঘন্টা থেকে ২৪ ঘন্টার মধ্যে), তাই একটি অথেন্টিকেশন সেশন পুনরায় চালু করার মাধ্যমে এই পরিস্থিতিটি সুষ্ঠুভাবে সামাল দিতে হবে।

একইভাবে, সার্ভার-টু-সার্ভার ডেপ্লয়মেন্টের জন্য ব্যবহারকারীর ক্রেডেনশিয়াল ব্যবহার করা বা এর ব্যবহারে উৎসাহিত করা উচিত নয়। যদি দীর্ঘস্থায়ী কাজ বা অপারেশনের জন্য কোনো সার্ভারে ব্যবহারকারীর ক্রেডেনশিয়াল ডেপ্লয় করা হয় এবং কোনো গ্রাহক সেই ব্যবহারকারীদের উপর সেশন কন্ট্রোল পলিসি প্রয়োগ করেন, তাহলে সার্ভার অ্যাপ্লিকেশনটি ব্যর্থ হবে, কারণ সেশনের মেয়াদ শেষ হয়ে গেলে ব্যবহারকারীকে পুনরায় অথেন্টিকেট করার কোনো উপায় থাকবে না।

আপনার গ্রাহকদের এই ফিচারটি স্থাপন করতে কীভাবে সাহায্য করবেন সে সম্পর্কে আরও তথ্যের জন্য, অ্যাডমিন-কেন্দ্রিক এই সহায়ক নিবন্ধটি দেখুন।

ক্লায়েন্ট লাইব্রেরি

নিম্নলিখিত ক্লায়েন্ট লাইব্রেরিগুলো জনপ্রিয় ফ্রেমওয়ার্কগুলোর সাথে সমন্বিত, যা OAuth 2.0 বাস্তবায়নকে আরও সহজ করে তোলে। সময়ের সাথে সাথে লাইব্রেরিগুলোতে আরও বৈশিষ্ট্য যুক্ত করা হবে।