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

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

শুরু করতে, OAuth 2.0 ক্লায়েন্ট শংসাপত্রগুলি থেকে পান Google API Console । তারপর আপনার ক্লায়েন্ট অ্যাপ্লিকেশন 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 অ্যাক্সেস করার সময় সমস্ত অ্যাপ্লিকেশন একটি মৌলিক প্যাটার্ন অনুসরণ করে। উচ্চ স্তরে, আপনাকে পাঁচটি ধাপ অনুসরণ করতে হবে:

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

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

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

• android অ্যান্ড্রয়েড অ্যাপের জন্য, ব্যবহার করুন অ্যান্ড্রয়েড ক্লায়েন্টের ধরণ।
• iOS এবং macOS অ্যাপের জন্য, ব্যবহার করুন আইওএস ক্লায়েন্টের ধরণ।
• কোড সার্ভার-সাইড বা জাভাস্ক্রিপ্ট ওয়েব অ্যাপের জন্য ব্যবহার করুন ওয়েব অ্যাপ্লিকেশন ক্লায়েন্ট টাইপ। এই ক্লায়েন্ট টাইপটি অন্য কোনও অ্যাপ্লিকেশনের জন্য ব্যবহার করবেন না, যেমন নেটিভ বা মোবাইল অ্যাপ।
• grid_view ইউনিভার্সাল উইন্ডোজ প্ল্যাটফর্ম অ্যাপের জন্য, ব্যবহার করুন ইউনিভার্সাল উইন্ডোজ প্ল্যাটফর্ম (UWP) ক্লায়েন্টের ধরণ।
• chrome_extension Chrome এক্সটেনশনের জন্য, Chrome এক্সটেনশন ক্লায়েন্ট টাইপ ব্যবহার করুন।
• টিভি সীমিত ইনপুট ডিভাইসের জন্য, যেমন টিভি বা এমবেডেড ডিভাইস, ব্যবহার করুন টিভি এবং সীমিত ইনপুট ডিভাইস ক্লায়েন্টের ধরণ।
• হোস্ট সার্ভার-টু-সার্ভার ইন্টারঅ্যাকশনের জন্য, পরিষেবা অ্যাকাউন্ট ব্যবহার করুন। কোনও OAuth ক্লায়েন্ট আইডি প্রয়োজন নেই।

২. গুগল অথরাইজেশন সার্ভার থেকে একটি অ্যাক্সেস টোকেন পান।

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

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

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

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

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

৩. ব্যবহারকারী কর্তৃক প্রদত্ত অ্যাক্সেসের সুযোগ পরীক্ষা করুন।

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

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

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

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

অ্যাক্সেস টোকেনগুলি শুধুমাত্র টোকেন অনুরোধের scope বর্ণিত ক্রিয়াকলাপ এবং সংস্থানগুলির সেটের জন্য বৈধ। উদাহরণস্বরূপ, যদি Google ক্যালেন্ডার API-এর জন্য একটি অ্যাক্সেস টোকেন জারি করা হয়, তবে এটি Google Contacts API-তে অ্যাক্সেস দেয় না। তবে, আপনি একই ধরণের ক্রিয়াকলাপের জন্য সেই অ্যাক্সেস টোকেনটি Google ক্যালেন্ডার 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 Extension, iOS, Universal Windows Platform (UWP), অথবা Desktop অ্যাপ নির্বাচন করুন।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

টোকেনের আকার

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

• কোড অনুমোদন কোড
  ২৫৬ বাইট
• contextual_token অ্যাক্সেস টোকেন
  ২০৪৮ বাইট
• restore_page টোকেন রিফ্রেশ করুন
  ৫১২ বাইট

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

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

টোকেনের মেয়াদ শেষ হওয়ার তারিখ রিফ্রেশ করুন

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

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

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

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

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

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

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

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

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

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

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

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

• জাভার জন্য গুগল অথ লাইব্রেরি
• পাইথনের জন্য গুগল এপিআই ক্লায়েন্ট লাইব্রেরি
• ডার্টের জন্য গুগল এপিআই ক্লায়েন্ট লাইব্রেরি
• গুগল এপিআই ক্লায়েন্ট লাইব্রেরি ফর গো
• .NET এর জন্য Google API ক্লায়েন্ট লাইব্রেরি
• রুবির জন্য গুগল এপিআই ক্লায়েন্ট লাইব্রেরি
• পিএইচপির জন্য গুগল এপিআই ক্লায়েন্ট লাইব্রেরি
• জাভাস্ক্রিপ্টের জন্য গুগল এপিআই ক্লায়েন্ট লাইব্রেরি
• GTMAppAuth - Mac এবং iOS এর জন্য OAuth ক্লায়েন্ট লাইব্রেরি