এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

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

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

শুরু করতে, থেকে OAuth 2.0 ক্লায়েন্ট শংসাপত্রগুলি পান৷ Google API Console . তারপর আপনার ক্লায়েন্ট অ্যাপ্লিকেশন Google অনুমোদন সার্ভার থেকে একটি অ্যাক্সেস টোকেন অনুরোধ করে, প্রতিক্রিয়া থেকে একটি টোকেন বের করে এবং আপনি যে Google API-এ অ্যাক্সেস করতে চান সেটিকে টোকেন পাঠায়। Google এর সাথে OAuth 2.0 ব্যবহার করার একটি ইন্টারেক্টিভ প্রদর্শনের জন্য (আপনার নিজস্ব ক্লায়েন্ট শংসাপত্রগুলি ব্যবহার করার বিকল্প সহ), OAuth 2.0 প্লেগ্রাউন্ডের সাথে পরীক্ষা করুন৷

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

দ্রষ্টব্য: সঠিক বাস্তবায়নের নিরাপত্তার প্রভাবের পরিপ্রেক্ষিতে, আমরা দৃঢ়ভাবে Google এর OAuth 2.0 এন্ডপয়েন্টের সাথে ইন্টারঅ্যাক্ট করার সময় OAuth 2.0 লাইব্রেরি ব্যবহার করার জন্য উৎসাহিত করি। অন্যদের দ্বারা প্রদত্ত ভাল-ডিবাগ করা কোড ব্যবহার করা এটি একটি সর্বোত্তম অভ্যাস এবং এটি আপনাকে নিজেকে এবং আপনার ব্যবহারকারীদের রক্ষা করতে সহায়তা করবে৷ আরও তথ্যের জন্য, ক্লায়েন্ট লাইব্রেরি দেখুন।

মৌলিক পদক্ষেপ

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

1. থেকে OAuth 2.0 শংসাপত্রগুলি পান৷ Google API Console.

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

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

সার্ভার-সাইড বা জাভাস্ক্রিপ্ট ওয়েব অ্যাপের জন্য "ওয়েব" ক্লায়েন্ট টাইপ ব্যবহার করুন। অন্য কোনো অ্যাপ্লিকেশনের জন্য এই ক্লায়েন্ট টাইপ ব্যবহার করবেন না, যেমন নেটিভ বা মোবাইল অ্যাপ।
Android অ্যাপ্লিকেশানগুলির জন্য, "Android" ক্লায়েন্ট প্রকার ব্যবহার করুন৷
iOS এবং macOS অ্যাপগুলির জন্য, "iOS" ক্লায়েন্ট টাইপ ব্যবহার করুন৷
ইউনিভার্সাল উইন্ডোজ প্ল্যাটফর্ম অ্যাপের জন্য, "ইউনিভার্সাল উইন্ডোজ প্ল্যাটফর্ম" ক্লায়েন্ট টাইপ ব্যবহার করুন।
সীমিত ইনপুট ডিভাইসের জন্য, যেমন টিভি বা এমবেডেড ডিভাইস, "টিভি এবং সীমিত ইনপুট ডিভাইস" ক্লায়েন্ট প্রকার ব্যবহার করুন।
সার্ভার-টু-সার্ভার ইন্টারঅ্যাকশনের জন্য, পরিষেবা অ্যাকাউন্ট ব্যবহার করুন।

2. Google অনুমোদন সার্ভার থেকে একটি অ্যাক্সেস টোকেন পান৷

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

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

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

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

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

3. ব্যবহারকারী দ্বারা প্রদত্ত অ্যাক্সেসের সুযোগগুলি পরীক্ষা করুন৷

একটি সম্পর্কিত 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 এর একটি প্রদত্ত সুযোগ প্রয়োজন।

4. একটি API এ অ্যাক্সেস টোকেন পাঠান।

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

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

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

অ্যাক্সেস টোকেন সীমিত জীবনকাল আছে. আপনার অ্যাপ্লিকেশানের যদি একটি একক অ্যাক্সেস টোকেনের জীবনকালের বাইরে একটি Google API-এ অ্যাক্সেসের প্রয়োজন হয়, তবে এটি একটি রিফ্রেশ টোকেন পেতে পারে। একটি রিফ্রেশ টোকেন আপনার অ্যাপ্লিকেশনকে নতুন অ্যাক্সেস টোকেন পেতে অনুমতি দেয়।

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

দৃশ্যকল্প

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

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

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

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

আপনার অ্যাপ্লিকেশন Google অনুমোদন সার্ভারে একটি টোকেন অনুরোধ পাঠায়, একটি অনুমোদন কোড গ্রহণ করে, একটি টোকেনের জন্য কোড বিনিময় করে এবং একটি Google API এন্ডপয়েন্ট কল করতে টোকেন ব্যবহার করে৷

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

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

Google OAuth 2.0 এন্ডপয়েন্ট কম্পিউটার, মোবাইল ডিভাইস এবং ট্যাবলেটের মতো ডিভাইসে ইনস্টল করা অ্যাপ্লিকেশনগুলিকে সমর্থন করে৷ আপনি যখন এর মাধ্যমে একটি ক্লায়েন্ট আইডি তৈরি করবেন Google API Console , নির্দিষ্ট করুন যে এটি একটি ইনস্টল করা অ্যাপ্লিকেশন, তারপর অ্যাপ্লিকেশন প্রকার হিসাবে Android, Chrome অ্যাপ, iOS, ইউনিভার্সাল উইন্ডোজ প্ল্যাটফর্ম (UWP), বা ডেস্কটপ অ্যাপ নির্বাচন করুন।

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

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

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

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

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

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

আপনার JS অ্যাপ্লিকেশন 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 যেমন ভবিষ্যদ্বাণী API এবং Google ক্লাউড স্টোরেজ ব্যবহারকারীর তথ্য অ্যাক্সেস না করেই আপনার অ্যাপ্লিকেশনের পক্ষে কাজ করতে পারে৷ এই পরিস্থিতিতে আপনার আবেদনের API এর নিজস্ব পরিচয় প্রমাণ করতে হবে, কিন্তু ব্যবহারকারীর সম্মতির প্রয়োজন নেই। একইভাবে, এন্টারপ্রাইজ পরিস্থিতিতে, আপনার অ্যাপ্লিকেশন কিছু সম্পদে অর্পিত অ্যাক্সেসের অনুরোধ করতে পারে।

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

দ্রষ্টব্য: এই পরিষেবা-অ্যাকাউন্টের পরিস্থিতিতে JSON ওয়েব টোকেন (JWTs) তৈরি এবং ক্রিপ্টোগ্রাফিকভাবে স্বাক্ষর করার জন্য অ্যাপ্লিকেশন প্রয়োজন। আমরা দৃঢ়ভাবে এই কাজগুলি সম্পাদন করার জন্য একটি লাইব্রেরি ব্যবহার করার জন্য আপনাকে উত্সাহিত করি৷ আপনি যদি টোকেন তৈরি এবং স্বাক্ষরকে বিমূর্ত করে এমন একটি লাইব্রেরি ব্যবহার না করে এই কোডটি লেখেন, তাহলে আপনি এমন ত্রুটি করতে পারেন যা আপনার অ্যাপ্লিকেশনের নিরাপত্তার উপর মারাত্মক প্রভাব ফেলবে। এই দৃশ্যকে সমর্থন করে এমন লাইব্রেরির তালিকার জন্য, পরিষেবা-অ্যাকাউন্ট ডকুমেন্টেশন দেখুন।

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

আপনার সার্ভার অ্যাপ্লিকেশন Google অনুমোদন সার্ভার থেকে একটি টোকেন অনুরোধ করতে একটি JWT ব্যবহার করে, তারপর একটি Google API এন্ডপয়েন্ট কল করতে টোকেন ব্যবহার করে। কোন শেষ ব্যবহারকারী জড়িত নয়.

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

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

টোকেনের আকার

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

অনুমোদন কোড: 256 বাইট
অ্যাক্সেস টোকেন: 2048 বাইট
রিফ্রেশ টোকেন: 512 বাইট

Google ক্লাউডের নিরাপত্তা টোকেন পরিষেবা API দ্বারা প্রত্যাবর্তিত অ্যাক্সেস টোকেনগুলি Google API OAuth 2.0 অ্যাক্সেস টোকেনগুলির অনুরূপভাবে গঠন করা হয় তবে বিভিন্ন টোকেন আকারের সীমা রয়েছে৷ বিস্তারিত জানার জন্য, API ডকুমেন্টেশন দেখুন।

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

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

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

ব্যবহারকারী আপনার অ্যাপের অ্যাক্সেস প্রত্যাহার করেছে ৷
রিফ্রেশ টোকেনটি ছয় মাস ধরে ব্যবহার করা হয়নি।
ব্যবহারকারী পাসওয়ার্ড পরিবর্তন করেছে এবং রিফ্রেশ টোকেনে Gmail স্কোপ রয়েছে।
ব্যবহারকারীর অ্যাকাউন্টটি সর্বাধিক অনুমোদিত (লাইভ) রিফ্রেশ টোকেনের সংখ্যা অতিক্রম করেছে।
যদি কোনো প্রশাসক আপনার অ্যাপের স্কোপে অনুরোধ করা কোনো পরিষেবাকে সীমাবদ্ধ করে সেট করেন (ত্রুটিটি হল admin_policy_enforced )।
Google ক্লাউড প্ল্যাটফর্ম API-এর জন্য - অ্যাডমিনের দ্বারা সেট করা সেশনের দৈর্ঘ্য অতিক্রম করা যেতে পারে।

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

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

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

আপনি যদি একাধিক প্রোগ্রাম, মেশিন বা ডিভাইস অনুমোদন করতে চান, তাহলে একটি সমাধান হল আপনি প্রতি Google অ্যাকাউন্টে অনুমোদিত ক্লায়েন্টের সংখ্যা 15 বা 20-এর মধ্যে সীমাবদ্ধ করুন। আপনি যদি একজন Google Workspace অ্যাডমিন হন, তাহলে আপনি প্রশাসনিক সুবিধা সহ অতিরিক্ত ব্যবহারকারী তৈরি করতে পারেন এবং ক্লায়েন্টদের কিছু অনুমোদন করতে তাদের ব্যবহার করুন।

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

GCP সংস্থার অ্যাডমিনিস্ট্রেটররা Google ক্লাউড সেশন কন্ট্রোল বৈশিষ্ট্য ব্যবহার করে GCP সংস্থানগুলি অ্যাক্সেস করার সময় ব্যবহারকারীদের ঘন ঘন পুনরায় প্রমাণীকরণের প্রয়োজন হতে পারে৷ এই নীতিটি Google ক্লাউড কনসোল, Google ক্লাউড SDK (জিক্লাউড CLI নামেও পরিচিত), এবং ক্লাউড প্ল্যাটফর্ম স্কোপের প্রয়োজন এমন যেকোনো তৃতীয় পক্ষের OAuth অ্যাপ্লিকেশনের অ্যাক্সেসকে প্রভাবিত করে৷ যদি কোনও ব্যবহারকারীর একটি সেশন নিয়ন্ত্রণ নীতি থাকে তবে সেশনের মেয়াদ শেষ হওয়ার পরে, আপনার API কলগুলি রিফ্রেশ টোকেন প্রত্যাহার করা হলে যা ঘটবে তার অনুরূপ ত্রুটি হবে - কলটি একটি ত্রুটির প্রকারের সাথে ব্যর্থ হবে invalid_grant ; error_subtype ক্ষেত্রটি একটি প্রত্যাহার করা টোকেন এবং একটি সেশন নিয়ন্ত্রণ নীতির কারণে ব্যর্থতার মধ্যে পার্থক্য করতে ব্যবহার করা যেতে পারে (উদাহরণস্বরূপ, "error_subtype": "invalid_rapt" )। যেহেতু সেশনের সময়কাল খুব সীমিত হতে পারে (1 ঘন্টা থেকে 24 ঘন্টার মধ্যে), এই দৃশ্যটি অবশ্যই একটি প্রমাণীকরণ সেশন পুনরায় আরম্ভ করার মাধ্যমে সুন্দরভাবে পরিচালনা করা উচিত।

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

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

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

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