আপনার পছন্দের ভাষায় কন্টেন্ট অনুবাদ করতে Google তার AI প্রযুক্তি ব্যবহার করে। AI-এর মাধ্যমে করা অনুবাদে ভুল থাকতে পারে।

মোবাইল ও ডেস্কটপ অ্যাপের জন্য OAuth 2.0

এই ডকুমেন্ট থেকে জানা যাবে যে ফোন, ট্যাবলেট ও কম্পিউটারের মতো ডিভাইসে ইনস্টল করা অ্যাপ্লিকেশন কীভাবে YouTube Analytics API বা YouTube Reporting API-তে অ্যাক্সেস অনুমোদন করার জন্য Google-এর OAuth 2.0 এন্ডপয়েন্ট ব্যবহার করে।

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

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

এই অনুমোদনের ফ্লো ওয়েব সার্ভার অ্যাপ্লিকেশন-এর জন্য ব্যবহৃত ফ্লোয়ের মতোই। প্রধান পার্থক্য হল ইনস্টল করা অ্যাপকে অবশ্যই সিস্টেম ব্রাউজার খুলতে হবে এবং Google-এর অনুমোদনকারী সার্ভার থেকে পাওয়া উত্তর ম্যানেজ করার জন্য একটি লোকাল রিডাইরেক্ট URI দিতে হবে।

লাইব্রেরি ও স্যাম্পেল

iOS অ্যাপের জন্য, আমরা Sign-in with Google iOS SDK-এর লেটেস্ট ভার্সন ব্যবহার করার সাজেশন দিই। SDK ব্যবহারকারীর অনুমোদন ম্যানেজ করে এবং এই গাইডে বর্ণিত লোয়ার-লেভেল প্রোটোকলের চেয়ে এটি প্রয়োগ করা সহজ।

যেসব ডিভাইসে সিস্টেম ব্রাউজার কাজ করে না বা যেগুলির ইনপুট ক্ষমতা সীমিত, যেমন টিভি, গেম কনসোল, ক্যামেরা বা প্রিন্টার, সেগুলিতে রান করা অ্যাপের জন্য, টিভি ও ডিভাইসের জন্য OAuth 2.0 বা টিভি ও সীমিত ইনপুট ডিভাইসে সাইন-ইন করা দেখুন।

পূর্বশর্ত

আপনার প্রোজেক্টের জন্য API চালু করা

Google API কল করে এমন যেকোনও অ্যাপ্লিকেশনকে API কনসোলে সেইসব API চালু করতে হবে।

আপনার প্রোজেক্টের জন্য API চালু করতে:

Google API Console-এ API লাইব্রেরি খুলুন।
প্রম্পট করা হলে, কোনও প্রোজেক্ট বেছে নিন অথবা নতুন একটি তৈরি করুন।
YouTube Analytics API ও YouTube Reporting API খুঁজে পেতে ও চালু করতে লাইব্রেরি পৃষ্ঠা ব্যবহার করুন। YouTube Analytics ডেটা রিট্রিভ করে এমন অনেক অ্যাপ্লিকেশন YouTube Data API-এর সাথেও ইন্টারফেস করে। আপনার অ্যাপ্লিকেশন ব্যবহার করবে এমন অন্য কোনও API খুঁজুন এবং সেগুলিও চালু করুন।

অনুমোদনের ক্রেডেনশিয়াল তৈরি করা

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

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

iOS

iOS অ্যাপ্লিকেশনের ধরন বেছে নিন।
OAuth ক্লায়েন্টের জন্য একটি নাম লিখুন। ক্লায়েন্টকে শনাক্ত করার জন্য আপনার প্রোজেক্টের ক্লায়েন্ট পৃষ্ঠায় এই নাম দেখানো হয়।
আপনার অ্যাপের বান্ডিল শনাক্তকারী লিখুন। বান্ডিল আইডি হল আপনার অ্যাপের তথ্য প্রপার্টি তালিকা রিসোর্স ফাইলের (info.plist) CFBundleIdentifier কী-এর ভ্যালু। ভ্যালু সাধারণত Xcode প্রোজেক্ট এডিটরের সাধারণ প্যানে বা সাইনিং ও ক্ষমতা প্যানে দেখানো হয়। এছাড়াও, বান্ডেল আইডিটি Apple-এর App Store Connect সাইটে অ্যাপের তথ্য পৃষ্ঠার সাধারণ তথ্য বিভাগে দেখানো হয়।
আপনার অ্যাপের জন্য সঠিক বান্ডিল আইডি ব্যবহার করছেন কিনা তা কনফার্ম করুন, কারণ আপনি App Check ফিচার ব্যবহার করলে এটি পরিবর্তন করতে পারবেন না।
(ঐচ্ছিক)
অ্যাপটি Apple-এর App Store-এ প্রকাশিত হলে আপনার অ্যাপের App Store আইডি লিখুন। স্টোর আইডি হল একটি সংখ্যাসূচক স্ট্রিং যা প্রতিটি Apple App Store URL-এ অন্তর্ভুক্ত থাকে।
1. আপনার iOS বা iPadOS ডিভাইসে Apple App Store অ্যাপ খুলুন।
2. আপনার অ্যাপ সার্চ করুন।
3. 'শেয়ার করুন' বোতাম (বর্গক্ষেত্র ও ঊর্ধ্বমুখী তীরচিহ্ন) বেছে নিন।
4. লিঙ্ক কপি করুন বিকল্প বেছে নিন।
5. টেক্সট এডিটরে লিঙ্কটি পেস্ট করুন। URL-এর শেষ অংশটি হল অ্যাপ স্টোর আইডি।
  উদাহরণ: https://apps.apple.com/app/google/id284815942
(ঐচ্ছিক)
আপনার টিম আইডি লিখুন। আরও তথ্যের জন্য Apple ডেভেলপার অ্যাকাউন্ট ডকুমেন্টেশনে আপনার টিম আইডি লোকেট করুন দেখুন।
মনে রাখবেন: আপনার ক্লায়েন্টের জন্য App Check চালু করলে, টিম আইডি ফিল্ড পূরণ করতে হবে।
(ঐচ্ছিক)
আপনার iOS অ্যাপের জন্য App Check চালু করুন। আপনি App Check চালু করলে, আপনার OAuth ক্লায়েন্ট থেকে আসা OAuth 2.0 অনুরোধগুলি আসল এবং আপনার অ্যাপ থেকে এসেছে কিনা তা যাচাই করতে Apple-এর App Attest পরিষেবা ব্যবহার করা হয়। এটি অ্যাপ ছদ্মবেশের ঝুঁকি কমাতে সাহায্য করে। আপনার iOS অ্যাপের জন্য 'অ্যাপ চেক' চালু করা সম্পর্কে আরও জানুন।
তৈরি করুন বিকল্পে ক্লিক করুন।

UWP

Universal Windows Platform অ্যাপ্লিকেশনের ধরন বেছে নিন।
OAuth ক্লায়েন্টের নাম লিখুন। ক্লায়েন্টকে শনাক্ত করতে আপনার প্রোজেক্টের নাম দেখানো হয়।
আপনার অ্যাপের ১২-অক্ষরের Microsoft Store আইডি লিখুন। আপনি এই ভ্যালু Microsoft পার্টনার সেন্টার-এ অ্যাপ ম্যানেজমেন্ট বিভাগের অ্যাপ আইডেন্টিটি পৃষ্ঠায় খুঁজে পাবেন।
তৈরি করুন বিকল্পে ক্লিক করুন।

UWP অ্যাপের জন্য, আপনার অ্যাপ্লিকেশনের অনন্য প্যাকেজ নিরাপত্তা শনাক্তকারী (SID) ব্যবহার করে রিডাইরেক্ট URI তৈরি করা হয়। আপনার Visual Studio প্রোজেক্টের মধ্যে Package.appxmanifest ফাইলে আপনার অ্যাপের Package SID খুঁজে পাবেন।

Google Cloud কনসোলে আপনার ক্লায়েন্ট আইডি তৈরি করার সময়, আপনাকে অবশ্যই নিম্নলিখিত ফর্ম্যাটে রিডাইরেক্ট URI উল্লেখ করতে হবে, এক্ষেত্রে আপনার প্যাকেজ SID-এর ছোট হাতের অক্ষর ব্যবহার করতে হবে:

ms-app://YOUR_APP_PACKAGE_SID

মনে রাখবেন: OAuth 2.0 রিডাইরেক্ট যাতে সঠিকভাবে কাজ করে তার জন্য ms-app:// স্কিম প্রয়োজন। এই স্কিমটি প্রোটোকল অ্যাক্টিভেশনের জন্য ব্যবহার করা হয়, যা অপারেটিং সিস্টেমকে আপনার অ্যাপ্লিকেশন চালু করতে এবং ব্যবহারকারী ব্রাউজারে যাচাই করার পরে Google থেকে অনুমোদন প্রতিক্রিয়া প্রদান করতে দেয়।

UWP অ্যাপের ক্ষেত্রে, কাস্টম URI স্কিম ৩৯ অক্ষরের বেশি হতে পারবে না, যেমনটি Microsoft ডকুমেন্টেশনে উল্লেখ করা আছে।

অ্যাক্সেস স্কোপ শনাক্ত করা

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

OAuth 2.0 অনুমোদন প্রয়োগ করা শুরু করার আগে, আমরা সাজেস্ট করি যে আপনার অ্যাপকে অ্যাক্সেস করার জন্য যেসব স্কোপের অনুমতি নিতে হবে সেগুলি শনাক্ত করুন।

YouTube Analytics API নিম্নলিখিত স্কোপ ব্যবহার করে:

ব্যাপ্তি	বর্ণনা
`https://www. googleapis. com/ auth/ youtube`	আপনার YouTube অ্যাকাউন্ট পরিচালনা করুন
`https://www. googleapis. com/ auth/ youtube. readonly`	আপনার YouTube অ্যাকাউন্ট দেখুন
`https://www. googleapis. com/ auth/ youtubepartner`	YouTube-এ আপনার সম্পদ এবং সংশ্লিষ্ট বিষয়বস্তু দেখুন ও পরিচালনা করুন
`https://www. googleapis. com/ auth/ yt-analytics-monetary. readonly`	আপনার YouTube সামগ্রীর জন্য আর্থিক এবং অ-আর্থিক YouTube বিশ্লেষণ প্রতিবেদনগুলি দেখুন৷
`https://www. googleapis. com/ auth/ yt-analytics. readonly`	আপনার YouTube সামগ্রীর জন্য YouTube বিশ্লেষণ প্রতিবেদনগুলি দেখুন৷

YouTube Reporting API নিম্নলিখিত স্কোপ ব্যবহার করে:

ব্যাপ্তি	বর্ণনা
`https://www. googleapis. com/ auth/ yt-analytics-monetary. readonly`	আপনার YouTube সামগ্রীর জন্য আর্থিক এবং অ-আর্থিক YouTube বিশ্লেষণ প্রতিবেদনগুলি দেখুন৷
`https://www. googleapis. com/ auth/ yt-analytics. readonly`	আপনার YouTube সামগ্রীর জন্য YouTube বিশ্লেষণ প্রতিবেদনগুলি দেখুন৷

OAuth 2.0 API স্কোপ ডকুমেন্টে স্কোপের সম্পূর্ণ তালিকা রয়েছে যা আপনি Google API অ্যাক্সেস করতে ব্যবহার করতে পারেন।

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

OAuth 2.0 অ্যাক্সেস টোকেন পাওয়া

নিম্নলিখিত ধাপগুলি দেখায় যে কীভাবে আপনার অ্যাপ্লিকেশন Google-এর OAuth 2.0 সার্ভারের সাথে ইন্টারঅ্যাক্ট করে ব্যবহারকারীর পক্ষে API অনুরোধ করার জন্য ব্যবহারকারীর সম্মতি নেয়। ব্যবহারকারীর অনুমোদন প্রয়োজন এমন Google API অনুরোধ কার্যকর করার আগে আপনার অ্যাপ্লিকেশনের কাছে অবশ্যই সেই সম্মতি থাকতে হবে।

ধাপ ১: কোড যাচাইকারী ও চ্যালেঞ্জ তৈরি করা

ইনস্টল করা অ্যাপের ফ্লো আরও সুরক্ষিত করতে Google প্রুফ কী ফর কোড এক্সচেঞ্জ (PKCE) প্রোটোকলকে সমর্থন করে। প্রতিটি অনুমোদনের অনুরোধের জন্য একটি অনন্য কোড যাচাইকারী তৈরি করা হয় এবং এর পরিবর্তিত মান, যাকে "code_challenge" বলা হয়, সেটি অনুমোদনের কোড পেতে অনুমোদনের সার্ভারে পাঠানো হয়।

কোড যাচাইকারী তৈরি করুন

code_verifier হল একটি হাই-এন্ট্রপি ক্রিপ্টোগ্রাফিক র‍্যান্ডম স্ট্রিং যা সংরক্ষিত নয় এমন অক্ষর [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~" ব্যবহার করে তৈরি করা হয়। এর ন্যূনতম দৈর্ঘ্য ৪৩টি অক্ষর এবং সর্বাধিক দৈর্ঘ্য ১২৮টি অক্ষর।

কোড যাচাইকারীতে যথেষ্ট এন্ট্রপি থাকতে হবে যাতে এর ভ্যালু অনুমান করা কঠিন হয়।

কোড চ্যালেঞ্জ তৈরি করুন

কোড চ্যালেঞ্জ তৈরি করার দুটি পদ্ধতি কাজ করে।

কোড চ্যালেঞ্জ জেনারেশন পদ্ধতি
S256 (সাজেস্ট করা হয়েছে)	কোড চ্যালেঞ্জ হল কোড যাচাইকারীর Base64URL (কোনও প্যাডিং নেই) এনকোড করা SHA256 হ্যাশ। `code_challenge` = BASE64URL-ENCODE(SHA256(ASCII(`code_verifier`)))
সাদা	কোড চ্যালেঞ্জ হল উপরে জেনারেট করা কোড যাচাইকারীর মতো একই ভ্যালু। `code_challenge` = `code_verifier`

ধাপ ২: Google-এর OAuth 2.0 সার্ভারে অনুরোধ পাঠান

ব্যবহারকারীর অনুমোদন পেতে, Google-এর অনুমোদন সার্ভারে অনুরোধ পাঠান, এই লিঙ্কে https://accounts.google.com/o/oauth2/v2/auth। এই এন্ডপয়েন্ট অ্যাক্টিভ সেশন লুক-আপ, ব্যবহারকারীকে যাচাইকরণ এবং ব্যবহারকারীর সম্মতি পাওয়া সংক্রান্ত কাজগুলি করে। এন্ডপয়েন্টটি শুধুমাত্র SSL-এর মাধ্যমে অ্যাক্সেস করা যায় এবং এটি HTTP (নন-SSL) কানেকশন প্রত্যাখ্যান করে।

ইনস্টল করা অ্যাপ্লিকেশনের জন্য অনুমোদনের সার্ভার নিম্নলিখিত কোয়েরি স্ট্রিং প্যারামিটারগুলি সাপোর্ট করে:

প্যারামিটারগুলি

client_id

আবশ্যক

আপনার অ্যাপ্লিকেশনের ক্লায়েন্ট আইডি। আপনি এই ভ্যালু Cloud Console ক্লায়েন্ট পৃষ্ঠায় দেখতে পাবেন।

redirect_uri

আবশ্যক

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

OAuth 2.0 ক্লায়েন্টের জন্য অনুমোদিত রিডাইরেক্ট URI-এর মধ্যে একটির সাথে ভ্যালু অবশ্যই মিলতে হবে, যা আপনি ক্লায়েন্টের Cloud Console ক্লায়েন্ট পৃষ্ঠা-তে কনফিগার করেছেন। এই ভ্যালু কোনও অনুমোদিত URI-এর সাথে ম্যাচ না করলে, আপনি redirect_uri_mismatch সমস্যা দেখতে পাবেন।

এই সারণীতে প্রতিটি পদ্ধতির জন্য উপযুক্ত redirect_uri প্যারামিটার ভ্যালু দেখানো হয়েছে:

redirect_uri ভ্যালু

কাস্টম URI স্কিম

com.example.app:redirect_uri_path

অথবা

com.googleusercontent.apps.123:redirect_uri_path

com.example.app হল আপনার নিয়ন্ত্রণে থাকা ডোমেনের রিভার্স ডিএনএস নোটেশন। কাস্টম স্কিমটি সঠিক হতে হলে তাতে অবশ্যই একটি পিরিয়ড থাকতে হবে।
com.googleusercontent.apps.123 হল ক্লায়েন্ট আইডির রিভার্স ডিএনএস নোটেশন।
redirect_uri_path হল ঐচ্ছিক পাথ কম্পোনেন্ট, যেমন /oauth2redirect. মনে রাখবেন, পাথটি একটি স্ল্যাশ দিয়ে শুরু হতে হবে, যা সাধারণ HTTP URL থেকে আলাদা।

লুপব্যাক IP অ্যাড্রেস

http://127.0.0.1:port বা http://[::1]:port

প্রাসঙ্গিক লুপব্যাক IP অ্যাড্রেসের জন্য আপনার প্ল্যাটফর্মে কোয়েরি করুন এবং উপলভ্য র‍্যান্ডম পোর্টে HTTP লিসনার শুরু করুন। আপনার অ্যাপ যে আসল পোর্ট নম্বর শোনে সেটি দিয়ে port প্রতিস্থাপন করুন।

মনে রাখবেন, মোবাইল অ্যাপে লুপব্যাক IP অ্যাড্রেস রিডাইরেক্ট করার বিকল্পের জন্য সহায়তা বন্ধ করা হয়েছে।

response_type

আবশ্যক

Google OAuth 2.0 এন্ডপয়েন্ট কোনও অনুমোদন কোড রিটার্ন করে কিনা তা নির্ধারণ করে।

ইনস্টল করা অ্যাপ্লিকেশনের জন্য প্যারামিটার ভ্যালু code হিসেবে সেট করুন।

scope

আবশ্যক

ব্যবহারকারীর হয়ে আপনার অ্যাপ্লিকেশন যেসব রিসোর্স অ্যাক্সেস করতে পারে, সেগুলি শনাক্ত করার জন্য স্পেস-ডিলিমিটেড স্কোপের তালিকা। এইসব ভ্যালু সম্মতি স্ক্রিনকে জানায় যে Google ব্যবহারকারীকে কী দেখাবে।

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

YouTube Analytics API নিম্নলিখিত স্কোপ ব্যবহার করে:

ব্যাপ্তি	বর্ণনা
`https://www. googleapis. com/ auth/ youtube`	আপনার YouTube অ্যাকাউন্ট পরিচালনা করুন
`https://www. googleapis. com/ auth/ youtube. readonly`	আপনার YouTube অ্যাকাউন্ট দেখুন
`https://www. googleapis. com/ auth/ youtubepartner`	YouTube-এ আপনার সম্পদ এবং সংশ্লিষ্ট বিষয়বস্তু দেখুন ও পরিচালনা করুন
`https://www. googleapis. com/ auth/ yt-analytics-monetary. readonly`	আপনার YouTube সামগ্রীর জন্য আর্থিক এবং অ-আর্থিক YouTube বিশ্লেষণ প্রতিবেদনগুলি দেখুন৷
`https://www. googleapis. com/ auth/ yt-analytics. readonly`	আপনার YouTube সামগ্রীর জন্য YouTube বিশ্লেষণ প্রতিবেদনগুলি দেখুন৷

YouTube Reporting API নিম্নলিখিত স্কোপ ব্যবহার করে:

ব্যাপ্তি	বর্ণনা
`https://www. googleapis. com/ auth/ yt-analytics-monetary. readonly`	আপনার YouTube সামগ্রীর জন্য আর্থিক এবং অ-আর্থিক YouTube বিশ্লেষণ প্রতিবেদনগুলি দেখুন৷
`https://www. googleapis. com/ auth/ yt-analytics. readonly`	আপনার YouTube সামগ্রীর জন্য YouTube বিশ্লেষণ প্রতিবেদনগুলি দেখুন৷

OAuth 2.0 API স্কোপ ডকুমেন্ট স্কোপের সম্পূর্ণ তালিকা প্রদান করে যা আপনি Google API অ্যাক্সেস করতে ব্যবহার করতে পারেন।

code_challenge

সাজেস্ট করা হয়

এনকোড করা code_verifier নির্দিষ্ট করে যা অথরাইজেশন কোড এক্সচেঞ্জের সময় সার্ভার-সাইড চ্যালেঞ্জ হিসেবে ব্যবহার করা হবে। আরও তথ্যের জন্য কোড তৈরি করুন চ্যালেঞ্জ দেখুন।

code_challenge_method

সাজেস্ট করা হয়

code_verifier এনকোড করার জন্য কোন পদ্ধতি ব্যবহার করা হয়েছে তা নির্দিষ্ট করে, যা অনুমোদন কোড এক্সচেঞ্জের সময় ব্যবহার করা হবে। এই প্যারামিটারটি অবশ্যই code_challenge প্যারামিটারের সাথে ব্যবহার করতে হবে। code_challenge_method-এর ভ্যালু ডিফল্ট হিসেবে plain হয়ে যায় যদি অনুরোধে এটি না থাকে, যার মধ্যে code_challenge অন্তর্ভুক্ত। এই প্যারামিটারের জন্য শুধুমাত্র S256 বা plain ভ্যালু কাজ করে।

state

সাজেস্ট করা হয়

আপনার অ্যাপ্লিকেশন, আপনার অনুমতি সংক্রান্ত অনুরোধ এবং অনুমতি সার্ভারের উত্তরের মধ্যে স্টেট বজায় রাখার জন্য ব্যবহার করে এমন যেকোনও স্ট্রিং ভ্যালু নির্দিষ্ট করে। ব্যবহারকারী আপনার অ্যাপ্লিকেশনের অ্যাক্সেস অনুরোধে সম্মতি বা অসম্মতি জানানোর পরে, সার্ভার redirect_uri-এর মধ্যে আপনি যে সঠিক ভ্যালু name=value পেয়ার হিসেবে পাঠান সেটি URL ফ্র্যাগমেন্ট আইডেন্টিফায়ার (#) হিসেবে রিটার্ন করে।

আপনি এই প্যারামিটারটি বিভিন্ন উদ্দেশ্যে ব্যবহার করতে পারেন, যেমন ব্যবহারকারীকে আপনার অ্যাপ্লিকেশনের সঠিক রিসোর্সে নির্দেশ করা, ননস পাঠানো এবং ক্রস-সাইট অনুরোধ জালিয়াতি কমানো। আপনার redirect_uri অনুমান করা যেতে পারে, তাই state ভ্যালু ব্যবহার করলে, ইনকামিং কানেকশন যে একটি যাচাইকরণ অনুরোধের ফলাফল, সেই ব্যাপারে আপনার নিশ্চয়তা বাড়তে পারে। আপনি যদি কোনও র‍্যান্ডম স্ট্রিং তৈরি করেন বা কোনও কুকির হ্যাশ এনকোড করেন অথবা অন্য কোনও ভ্যালু যা ক্লায়েন্টের স্ট্যাটাস ক্যাপচার করে, তাহলে আপনি অনুরোধ এবং উত্তর একই ব্রাউজার থেকে এসেছে কিনা তা অতিরিক্তভাবে নিশ্চিত করতে উত্তরটি যাচাই করতে পারেন, ক্রস-সাইট অনুরোধ জালিয়াতি-এর মতো আক্রমণ থেকে সুরক্ষা প্রদান করে। state টোকেন কীভাবে তৈরি ও কনফার্ম করতে হয় তার উদাহরণ দেখতে OpenID Connect ডকুমেন্টেশন দেখুন।

গুরুত্বপূর্ণ: OAuth ক্লায়েন্টকে অবশ্যই CSRF প্রতিরোধ করতে হবে, যেমনটি OAuth2 স্পেসিফিকেশন -এ বলা হয়েছে। এটি করার একটি উপায় হল, আপনার অনুমোদনের অনুরোধ এবং অনুমোদন সার্ভারের উত্তরের মধ্যে স্ট্যাটাস বজায় রাখতে state প্যারামিটার ব্যবহার করা।

login_hint

ঐচ্ছিক

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

প্যারামিটারের মান কোনও ইমেল আইডি বা sub আইডেন্টিফায়ারে সেট করুন, যা ব্যবহারকারীর Google আইডির সমতুল্য।

মনে রাখবেন: ইনস্টল করা অ্যাপের সাথে ইনক্রিমেন্টাল অনুমোদন কাজ করে না, কারণ ক্লায়েন্ট client_secret গোপনীয়তা

বজায় রাখতে পারে না।

অনুমোদনকারী URL-এর নমুনা

নিচের ট্যাবগুলি বিভিন্ন রিডাইরেক্ট URI বিকল্পের জন্য স্যাম্পেল অথরাইজেশন URL দেখায়।

প্রতিটি URL এমন একটি স্কোপে অ্যাক্সেসের অনুরোধ করে যা ব্যবহারকারীর YouTube Analytics রিপোর্ট উদ্ধার করার জন্য অ্যাক্সেসের অনুমতি দেয়।

redirect_uri প্যারামিটারের ভ্যালু ছাড়া URL-গুলি একই রকম। এছাড়াও, URL-এ প্রয়োজনীয় response_type ও client_id প্যারামিটার এবং ঐচ্ছিক state প্যারামিটার থাকে। প্রতিটি URL-এ লাইন ব্রেক ও স্পেস থাকে যাতে পড়তে সুবিধা হয়।

কাস্টম URI স্কিম

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyt-analytics.readonly&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=com.example.app%3A/oauth2redirect&
 client_id=client_id

লুপব্যাক IP অ্যাড্রেস

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyt-analytics.readonly&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=http%3A//127.0.0.1%3A9004&
 client_id=client_id

ধাপ ৩: Google ব্যবহারকারীর কাছে সম্মতি চায়

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

এই পর্যায়ে আপনার অ্যাপ্লিকেশনকে কিছু করতে হবে না কারণ এটি Google-এর OAuth 2.0 সার্ভার থেকে উত্তরের জন্য অপেক্ষা করে যা থেকে বোঝা যায় যে কোনও অ্যাক্সেস দেওয়া হয়েছে কিনা। সেই উত্তরটি নিম্নলিখিত ধাপে ব্যাখ্যা করা হয়েছে।

সমস্যা

Google-এর OAuth 2.0 অনুমোদনের এন্ডপয়েন্টে করা অনুরোধে প্রত্যাশিত যাচাইকরণ ও অনুমোদনের ফ্লোয়ের পরিবর্তে ব্যবহারকারী নিজে ইন্টার‌্যাক্ট করতে পারেন এমন ত্রুটি মেসেজ দেখানো হতে পারে। সাধারণ সমস্যার কোড ও সাজেস্ট করা সমাধান হল:

`admin_policy_enforced`

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

`disallowed_useragent`

Google-এর OAuth 2.0 নীতি অনুযায়ী অনুমোদিত নয় এমন একটি এম্বেড করা ইউজার-এজেন্টের মধ্যে অনুমোদনের এন্ডপয়েন্ট দেখানো হয়।

iOS এবং macOS ডেভেলপাররা WKWebView-এ অনুমোদনের অনুরোধ খোলার সময় এই সমস্যার সম্মুখীন হতে পারেন। পরিবর্তে ডেভেলপারদের iOS লাইব্রেরি ব্যবহার করা উচিত, যেমন iOS-এর জন্য Google Sign-In বা OpenID Foundation-এর iOS-এর জন্য AppAuth।

iOS বা macOS অ্যাপ এম্বেড করা ইউজার-এজেন্টে সাধারণ ওয়েব লিঙ্ক খুললে এবং ব্যবহারকারী আপনার সাইট থেকে Google-এর OAuth 2.0 অনুমোদন এন্ডপয়েন্টে নেভিগেট করলে ওয়েব ডেভেলপাররা এই সমস্যার সম্মুখীন হতে পারেন। ডেভেলপারদের উচিত অপারেটিং সিস্টেমের ডিফল্ট লিঙ্ক হ্যান্ডলারে সাধারণ লিঙ্ক খোলার অনুমতি দেওয়া, যার মধ্যে ইউনিভার্সাল লিঙ্ক হ্যান্ডলার বা ডিফল্ট ব্রাউজার অ্যাপ, দুটিই অন্তর্ভুক্ত। SFSafariViewController লাইব্রেরিও একটি কাজ করে এমন বিকল্প।

`org_internal`

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

`deleted_client`

অনুরোধ করার জন্য যে OAuth ক্লায়েন্ট ব্যবহার করা হচ্ছে সেটি মুছে দেওয়া হয়েছে। মুছে দেওয়ার কাজটি ম্যানুয়ালি অথবা অটোমেটিক করা যেতে পারে, যদি অব্যবহৃত ক্লায়েন্ট হয়। মুছে ফেলার ৩০ দিনের মধ্যে মুছে ফেলা ক্লায়েন্টকে ফিরিয়ে আনা যেতে পারে। আরও জানুন ।

`invalid_grant`

আপনি যদি কোড যাচাইকারী এবং চ্যালেঞ্জ ব্যবহার করেন, তাহলে code_callenge প্যারামিটারটি ভুল বা অনুপস্থিত। নিশ্চিত করুন যে code_challenge প্যারামিটার সঠিকভাবে সেট করা হয়েছে।

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

`redirect_uri_mismatch`

অনুমোদনের অনুরোধে পাস করা redirect_uri OAuth ক্লায়েন্ট আইডির জন্য অনুমোদিত রিডাইরেক্ট URI-এর সাথে মিলছে না। Google Cloud Console-এর ক্লায়েন্ট পৃষ্ঠায় অনুমোদিত রিডাইরেক্ট URI পর্যালোচনা করুন।

ক্লায়েন্টের ধরনের জন্য পাস করা redirect_uri সঠিক নাও হতে পারে।

redirect_uri প্যারামিটার OAuth আউট-অফ-ব্যান্ড (OOB) ফ্লোকে রেফার করতে পারে যা বন্ধ করা হয়েছে এবং আর কাজ করে না। আপনার ইন্টিগ্রেশন আপডেট করতে মাইগ্রেশন গাইড দেখুন।

`invalid_request`

আপনার করা অনুরোধে কোনও সমস্যা হয়েছে। এটি একাধিক কারণে হতে পারে:

অনুরোধটি সঠিকভাবে ফর্ম্যাট করা হয়নি
অনুরোধে প্রয়োজনীয় প্যারামিটার ছিল না
অনুরোধটি এমন একটি যাচাইকরণ পদ্ধতি ব্যবহার করে যা Google-এ কাজ করে না। যাচাই করুন যে আপনার OAuth ইন্টিগ্রেশন একটি সাজেস্ট করা ইন্টিগ্রেশন পদ্ধতি ব্যবহার করে
রিডাইরেক্ট URI-এর জন্য কাজ করে না এমন কাস্টম স্কিম ব্যবহার করা হয়েছে। আপনি যদি এই সমস্যার মেসেজটি দেখতে পান Android বা Chrome অ্যাপে কাস্টম URI স্কিম কাজ করে না, কাস্টম URI স্কিমের বিকল্প সম্পর্কে আরও জানুন।

ধাপ ৪: OAuth 2.0 সার্ভার রেসপন্স ম্যানেজ করা

আপনার অ্যাপ্লিকেশন যেভাবে অনুমোদন সংক্রান্ত উত্তর পায় তা সেটির ব্যবহার করা রিডাইরেক্ট URI স্কিমের উপর নির্ভর করে। স্কিম যাই হোক না কেন, উত্তরে অনুমোদন কোড (code) বা সমস্যা (error) থাকবে। যেমন, error=access_denied থেকে বোঝা যায় যে ব্যবহারকারী অনুরোধ প্রত্যাখ্যান করেছেন।

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

ধাপ ৫: রিফ্রেশ ও অ্যাক্সেস টোকেনের জন্য যাচাইকরণ কোড বিনিময় করুন

অ্যাক্সেস টোকেনের জন্য যাচাইকরণ কোড পেতে, https://oauth2.googleapis.com/token এন্ডপয়েন্ট কল করুন এবং নিম্নলিখিত প্যারামিটার সেট করুন:

ফিল্ড
`client_id`	Cloud Console-এর ক্লায়েন্ট পৃষ্ঠা থেকে ক্লায়েন্ট আইডি পাওয়া গেছে।
`client_secret`	ঐচ্ছিক Cloud Console-এর ক্লায়েন্ট পৃষ্ঠা থেকে পাওয়া ক্লায়েন্ট সিক্রেট।
`code`	প্রাথমিক অনুরোধ থেকে অথরাইজেশন কোড ফিরে এসেছে।
`code_verifier`	ধাপ ১-এ আপনার তৈরি করা কোড ভেরিফায়ার।
`grant_type`	OAuth 2.0 স্পেসিফিকেশনে যেমন উল্লেখ করা আছে, এই ফিল্ডের ভ্যালু অবশ্যই `authorization_code` হিসেবে সেট করতে হবে।
`redirect_uri`	প্রদত্ত `client_id`-এর জন্য Cloud Console ক্লায়েন্ট পৃষ্ঠায় আপনার প্রোজেক্টের জন্য তালিকাভুক্ত রিডাইরেক্ট URI-এর মধ্যে একটি।

DPoP-এর ব্যবহার ঐচ্ছিক হলেও, আরও বেশি নিরাপত্তার জন্য এটি ব্যবহার করার সাজেশন দেওয়া হয়। DPoP-এর নিরাপত্তা একটি ডিভাইসে সীমাবদ্ধ থাকা ব্যক্তিগত কী-এর উপর নির্ভর করে; আমরা এটি এমনভাবে সেভ করার পরামর্শ দিই যাতে এটি ডিভাইস থেকে কপি করা না যায়, যেমন TPM, Secure Enclaves বা অন্যান্য হার্ডওয়্যার-ব্যাকড কীস্টোর ব্যবহার করে। DPoP ব্যবহার করতে, আপনার অ্যাপ্লিকেশনকে টোকেন এন্ডপয়েন্টে প্রতিটি অনুরোধের জন্য একটি নতুন, অনন্য DPoP প্রমাণ JWT তৈরি করতে হবে এবং এটি একটি HTTP অনুরোধ হেডার হিসাবে যোগ করতে হবে।

শিরোনাম	প্রয়োজনীয়	বিবরণ
`DPoP`	ঐচ্ছিক	DPoP প্রমাণ হল একটি JWT যা প্রাইভেট কীয়ের মালিকানা প্রমাণ করে। এটি একটি হেডার, প্যারামিটার নয়। প্রদান করা হলে, ফিরে আসা টোকেন এই কী-এর সাথে আবদ্ধ থাকে। প্রতিটি অনুরোধের জন্য একটি নতুন, অনন্য প্রমাণ তৈরি করতে হবে এবং এতে অবশ্যই `htm` (HTTP পদ্ধতি) এবং `htu` (HTTP URI) দাবি অন্তর্ভুক্ত থাকতে হবে যা অনুরোধের সাথে মেলে।

নিচের স্নিপেটে অনুরোধের একটি নমুনা দেখানো হয়েছে:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik\
 VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR\
 nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE\
 QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiItQndDM0VTYzZhY2MybFRjIiwiaHRtIj\
 oiUE9TVCIsImh0dSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwia\
 WF0IjoxNTYyMjYyNjE2fQ.2-GxA6T8lP4vfrg8v-FdWP0A0zdrj8igiMLvqRMUvwnQg\
 4PtFLbdLXiOSsX0x7NVY-FNyJK70nfbV37xRZT3Lg

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your_client_id&
redirect_uri=http://127.0.0.1:9004&
grant_type=authorization_code

DPoP প্রমাণ তৈরি করা

কমান্ড লাইন থেকে OpenSSL ব্যবহার করে কীভাবে DPoP প্রমাণ তৈরি করতে হয় তা নিম্নলিখিত ধাপগুলি থেকে জানতে পারবেন:

EC P-256 কী পেয়ার জেনারেট করুন:

openssl ecparam -name prime256v1 -genkey -noout -out dpop_private.pem
openssl ec -in dpop_private.pem -pubout -out dpop_public.pem

DPoP হেডার তৈরি করুন:
হেডারে অবশ্যই typ, alg এবং jwk (সর্বজনীন কী) দাবি অন্তর্ভুক্ত করতে হবে। x এবং y ভ্যালু হল আপনার EC সর্বজনীন কীয়ের Base64Url-এনকোড করা কোঅর্ডিনেট। এই JSON-কে Base64Url এনকোড করুন:
```
{
  "typ":"dpop+jwt",
  "alg":"ES256",
  "jwk": {
    "kty":"EC",
    "x":"YOUR_PUBLIC_KEY_X",
    "y":"YOUR_PUBLIC_KEY_Y",
    "crv":"P-256"
  }
}
```
DPoP পে-লোড তৈরি করুন:
পে-লোডে অবশ্যই jti (অনুরোধের জন্য একটি অনন্য শনাক্তকারী), htm (HTTP পদ্ধতি, যেমন, POST), htu (HTTP URI, যেমন, https://oauth2.googleapis.com/token), এবং iat (ইস্যু করার সময়) অন্তর্ভুক্ত থাকতে হবে। আপনি যদি কোনও আগের অনুরোধের উত্তরে সার্ভার থেকে DPoP-Nonce হেডার হিসেবে ননস পেয়ে থাকেন, তাহলে আপনাকে অবশ্যই সেই ননস ভ্যালু nonce দাবি হিসেবে অন্তর্ভুক্ত করতে হবে। অনুমোদন কোড এক্সচেঞ্জের জন্য ননস ক্লেম ঐচ্ছিক এবং শুধুমাত্র তখনই ব্যবহার করা হয় যখন DPoP-Nonce হেডার আগে পাওয়া যায়। এই JSON-কে Base64Url এনকোড করুন:
```
{
  "jti":"JTI_VALUE",
  "htm":"POST",
  "htu":"https://oauth2.googleapis.com/token",
  "iat":YOUR_JWT_ISSUED_TIME,
  "nonce":"SERVER_PROVIDED_NONCE"
}
```
jti ভ্যালু এক্সচেঞ্জের ধরনের উপর নির্ভর করে:
- অনুমোদন কোড এক্সচেঞ্জের জন্য, jti অবশ্যই অনুমোদন কোডের Base64Url-এনকোড করা SHA256 হ্যাশ হতে হবে: "jti":"BASE64URL(SHA256(AUTHORIZATION_CODE))".
- রিফ্রেশ টোকেন এক্সচেঞ্জের জন্য, jti অবশ্যই একটি অনন্য প্রতি-অনুরোধ শনাক্তকারী হতে হবে: "jti":"YOUR_UNIQUE_PER_REQUEST_IDENTIFIER".
প্রমাণে স্বাক্ষর করুন:
এনকোড করা হেডার ও পেলোডকে একটি পিরিয়ড (.) দিয়ে কনক্যাটিনেট করুন, তারপর ES256 ব্যবহার করে আপনার ব্যক্তিগত কী দিয়ে ফলাফলটি সাইন করুন। মনে রাখবেন যে JWS-এর ক্ষেত্রে স্বাক্ষরটি র R | S কনক্যাটিনেটেড ফর্ম্যাটে (P-256-এর জন্য ৬৪ বাইট) হতে হবে। সরাসরি OpenSSL ব্যবহার করলে, আপনাকে অবশ্যই ডিফল্ট ASN.1 DER-এনকোডেড সিগনেচারকে এই র ফর্ম্যাটে কনভার্ট করতে হবে।

সফল এক্সচেঞ্জ 200 OK টোকেন সহ উত্তরের মাধ্যমে দেখানো হয়। এক্সচেঞ্জের সময় কোনও সঠিক DPoP প্রমাণ ব্যবহার করা হলে, Google যে রিফ্রেশ টোকেন রিটার্ন করবে সেটি আপনার কী-এর সাথে DPoP-বাউন্ড হবে, কিন্তু অ্যাক্সেস টোকেন DPoP-বাউন্ড হবে না। অ্যাক্সেস টোকেন DPoP-এর পরিবর্তে Bearer-এর token_type বজায় রাখবে। এছাড়াও, Google উত্তরে একটি DPoP-Nonce HTTP হেডার ফেরত দেয়। আপনার ক্লায়েন্টকে অবশ্যই এই ননস ক্যাশে করতে হবে এবং পরবর্তী অনুরোধে (যেমন, নতুন অ্যাক্সেস টোকেনের জন্য রিফ্রেশ টোকেন এক্সচেঞ্জ করার সময় অথবা DPoP-সুরক্ষিত API কল করার সময়) nonce DPoP প্রমাণের দাবি অন্তর্ভুক্ত করতে হবে। এই আগে থেকে ইস্যু করা ননস ব্যবহার করে, আপনি পরবর্তী অনুরোধে অতিরিক্ত রাউন্ড-ট্রিপ ব্যর্থতা (use_dpop_nonce) এড়াতে পারবেন।

DPoP-বাউন্ড রিফ্রেশ টোকেন ব্যবহার করে টোকেন এক্সচেঞ্জ করার অনুরোধের ক্ষেত্রে DPoP প্রমাণ অন্তর্ভুক্ত করতে হবে।

এক্সচেঞ্জ সম্পূর্ণ না হওয়ার ঘটনা ঘটে যদি প্রত্যাশিত DPoP হেডার না থাকে, ভুল থাকে অথবা প্রমাণে টোকেনের সাথে যুক্ত কী-এর থেকে আলাদা কী ব্যবহার করা হয়। এইসব ক্ষেত্রে, সার্ভার একটি 400 Bad Request সমস্যা রিটার্ন করে। DPoP প্রমাণের htm বা htu দাবি না মিললে, মেয়াদ শেষ হয়ে গেলে iat, আবার ব্যবহার করা হলে jti অথবা ভুল সিগনেচার থাকলে, Google একটি invalid_dpop_proof সমস্যার কোড রিটার্ন করে। যদি DPoP ননসের প্রয়োজন হয়, যেমন রিফ্রেশ টোকেন এক্সচেঞ্জের সময় এবং DPoP প্রমাণে nonce দাবি না থাকে অথবা ননসের ভ্যালু সার্ভারের কাছে গ্রহণযোগ্য না হয় (যেমন, এটির মেয়াদ শেষ হয়ে গেছে, আগে থেকেই ব্যবহার করা হয়েছে অথবা ভুল), তাহলে Google একটি use_dpop_nonce ত্রুটি কোড সহ DPoP-Nonce HTTP হেডার পাঠায় যাতে নতুন ননস থাকে এবং আপনি পরবর্তী অনুরোধে সেটি ব্যবহার করতে পারেন। অন্যান্য ব্যর্থতার ক্ষেত্রে invalid_grant রিটার্ন করা হতে পারে।

Google এই অনুরোধের উত্তরে একটি JSON অবজেক্ট পাঠায় যাতে একটি স্বল্পমেয়াদী অ্যাক্সেস টোকেন এবং একটি রিফ্রেশ টোকেন থাকে।

উত্তরে নিম্নলিখিত ফিল্ডগুলি থাকে:

ফিল্ড
`access_token`	Google API অনুরোধ অনুমোদন করার জন্য আপনার অ্যাপ্লিকেশন যে টোকেন পাঠায়।
`expires_in`	অ্যাক্সেস টোকেনের বাকি মেয়াদ সেকেন্ডে।
`id_token`	মনে রাখবেন: আপনার অনুরোধে পরিচয় সংক্রান্ত স্কোপ অন্তর্ভুক্ত থাকলে তবেই এই প্রপার্টি ফেরত দেওয়া হয়, যেমন `openid`, `profile` বা `email`। ভ্যালু হল একটি JSON ওয়েব টোকেন (JWT) যাতে ব্যবহারকারীর ডিজিটাল স্বাক্ষর করা পরিচয় সংক্রান্ত তথ্য থাকে।
`refresh_token`	একটি টোকেন যা আপনি একটি নতুন অ্যাক্সেস টোকেন পেতে ব্যবহার করতে পারেন। ব্যবহারকারী অ্যাক্সেস প্রত্যাহার না করা পর্যন্ত বা রিফ্রেশ টোকেনের মেয়াদ শেষ না হওয়া পর্যন্ত রিফ্রেশ টোকেন বৈধ থাকে। DPoP ব্যবহার করা হলে, DPoP প্রমাণে স্বাক্ষর করার জন্য ব্যবহৃত ব্যক্তিগত কী-এর সাথে রিফ্রেশ টোকেনটি বাউন্ড করা থাকে। মনে রাখবেন, ইনস্টল করা অ্যাপ্লিকেশনের জন্য রিফ্রেশ টোকেন সবসময় ফেরত দেওয়া হয়।
`refresh_token_expires_in`	রিফ্রেশ টোকেনের বাকি থাকা মেয়াদ সেকেন্ডে। এই ভ্যালু তখনই সেট করা হয় যখন ব্যবহারকারী সময়-ভিত্তিক অ্যাক্সেস দেন।
`scope`	`access_token`-এর মাধ্যমে মঞ্জুর করা অ্যাক্সেসের স্কোপ স্পেস-ডিলিমিটেড, ছোট ও বড় হাতের অক্ষরের মধ্যে পার্থক্য করা হয় এমন স্ট্রিংয়ের তালিকা হিসেবে প্রকাশ করা হয়।
`token_type`	ফেরত আসা টোকেনের ধরন। DPoP ব্যবহার করা হলেও এই ভ্যালু সবসময় `Bearer` হয়।

গুরুত্বপূর্ণ: আপনার অ্যাপ্লিকেশনকে অবশ্যই দুটি টোকেনই একটি সুরক্ষিত, দীর্ঘস্থায়ী লোকেশনে স্টোর করতে হবে যা আপনার অ্যাপ্লিকেশনের বিভিন্ন ইনভোকেশনগুলির মধ্যে অ্যাক্সেস করা যায়। আপনার অ্যাক্সেস টোকেনের মেয়াদ শেষ হয়ে গেলে, রিফ্রেশ টোকেন আপনার অ্যাপ্লিকেশনকে নতুন অ্যাক্সেস টোকেন পেতে সাহায্য করে। তাই, আপনার অ্যাপ্লিকেশন রিফ্রেশ টোকেন হারিয়ে ফেললে, ব্যবহারকারীকে OAuth 2.0 সম্মতি ফ্লো আবার সম্পূর্ণ করতে হবে যাতে আপনার অ্যাপ্লিকেশন একটি নতুন রিফ্রেশ টোকেন পেতে পারে।

DPoP ব্যবহার করা হলে, নিম্নলিখিত স্নিপেটটি একটি সফল রেসপন্স হেডার এবং বডির নমুনা দেখায়:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
DPoP-Nonce: AN3XwJjZsjnb0ZuWkRlek8QU7wY-Zhf-5IP6tO0tORz0KgtDT1Bo8FX-w4nz3r5lnepI

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "token_type": "Bearer",
  "scope": "https://www.googleapis.com/auth/yt-analytics.readonly https://www.googleapis.com/auth/calendar.readonly",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

মনে রাখবেন: আপনার অ্যাপ্লিকেশনে ব্যবহারকারীর জন্য আগে থেকেই রিফ্রেশ টোকেন থাকলে এবং আপনি নতুন DPoP-বাউন্ড রিফ্রেশ টোকেন পেতে চাইলে, ব্যবহারকারীকে অবশ্যই আগে থেকে থাকা অনুমতি প্রত্যাহার করতে হবে অথবা নতুন রিফ্রেশ টোকেন ইস্যু করা হয়েছে কিনা তা নিশ্চিত করতে প্রাথমিক অনুমোদনের অনুরোধে আপনাকে অবশ্যই prompt=consent প্যারামিটার ব্যবহার করতে হবে।

ধাপ ৬: ব্যবহারকারীরা কোন কোন স্কোপে অ্যাক্সেস দিয়েছেন তা চেক করুন

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

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

আরও বিস্তারিত তথ্য পেতে, গ্র্যানুলার অনুমতি কীভাবে ম্যানেজ করতে হয় দেখুন।

ব্যবহারকারী আপনার অ্যাপ্লিকেশনকে কোনও নির্দিষ্ট স্কোপে অ্যাক্সেস দিয়েছেন কিনা তা চেক করতে, অ্যাক্সেস টোকেন রেসপন্সে scope ফিল্ড পরীক্ষা করুন। space-delimited, কেস-সংবেদনশীল স্ট্রিংয়ের তালিকা হিসেবে প্রকাশ করা access_token-এর মাধ্যমে দেওয়া অ্যাক্সেসের সুযোগ।

যেমন, নিম্নলিখিত স্যাম্পেল অ্যাক্সেস টোকেন রেসপন্স থেকে বোঝা যায় যে ব্যবহারকারী আপনার অ্যাপ্লিকেশনকে শুধু-পড়া-যাবে এমন Drive অ্যাক্টিভিটি এবং Calendar ইভেন্টের অনুমতি দিয়েছেন:

  {
    "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
    "expires_in": 3920,
    "token_type": "Bearer",
    "scope": "https://www.googleapis.com/auth/yt-analytics.readonly https://www.googleapis.com/auth/calendar.readonly",
    "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
  }

Google API কল করুন

আপনার অ্যাপ্লিকেশন অ্যাক্সেস টোকেন পাওয়ার পরে, আপনি টোকেন ব্যবহার করে কোনও নির্দিষ্ট ব্যবহারকারীর অ্যাকাউন্টের হয়ে Google API-এ কল করতে পারবেন, যদি API-এর জন্য প্রয়োজনীয় অ্যাক্সেসের স্কোপ মঞ্জুর করা হয়ে থাকে। এটি করতে, API-তে পাঠানো অনুরোধে অ্যাক্সেস টোকেন যোগ করুন। এর জন্য access_token কোয়েরি প্যারামিটার অথবা Authorization HTTP হেডার Bearer ভ্যালু যোগ করতে হবে। সম্ভব হলে, HTTP হেডার ব্যবহার করা ভালো, কারণ কোয়েরি স্ট্রিং সার্ভার লগে দেখা যায়। বেশিরভাগ ক্ষেত্রে, Google API-তে আপনার কল সেট-আপ করতে আপনি ক্লায়েন্ট লাইব্রেরি ব্যবহার করতে পারবেন (যেমন, YouTube Analytics API কল করার সময়)।

মনে রাখবেন, YouTube Analytics API-তে পরিষেবা অ্যাকাউন্ট ফ্লো কাজ করে না। YouTube Reporting API শুধুমাত্র একাধিক YouTube চ্যানেলের মালিক ও ম্যানেজার, যেমন রেকর্ড লেবেল ও মুভি স্টুডিওর মতো YouTube কন্টেন্টের মালিকদের জন্য পরিষেবা অ্যাকাউন্ট কাজ করে।

আপনি সব Google API ব্যবহার করে দেখতে পারেন এবং OAuth 2.0 Playground-এ সেগুলির স্কোপ দেখতে পারেন।

HTTP GET-এর উদাহরণ

Authorization: Bearer HTTP হেডার ব্যবহার করে reports.query এন্ডপয়েন্টে (YouTube Analytics API) কল করলে তা নিচে দেখানো ছবির মতো দেখতে লাগতে পারে। মনে রাখবেন, আপনাকে নিজের অ্যাক্সেস টোকেন উল্লেখ করতে হবে:

GET /youtube/v2/reports?ids=channel%3D%3DMINE&startDate=2016-05-01&endDate=2016-06-30&metrics=views HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

এখানে যাচাই করা ব্যবহারকারীর জন্য একই API-তে কল করা হয়েছে, এর জন্য access_token কোয়েরি স্ট্রিং প্যারামিটার ব্যবহার করা হয়েছে:

GET https://www.googleapis.com/youtube/v2/reports?access_token=access_token&ids=channel%3D%3DMINE&startDate=2016-05-01&endDate=2016-06-30&metrics=views

`curl`টি উদাহরণ

আপনি curl কমান্ড-লাইন অ্যাপ্লিকেশনের মাধ্যমে এইসব কমান্ড পরীক্ষা করতে পারবেন। HTTP হেডার বিকল্প ব্যবহার করে এমন একটি উদাহরণ এখানে দেওয়া হল (পছন্দসই):

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/v2/reports?ids=channel%3D%3DMINE&startDate=2016-05-01&endDate=2016-06-30&metrics=views

অথবা, বিকল্প হিসেবে, কোয়েরি স্ট্রিং প্যারামিটার বিকল্প:

curl https://www.googleapis.com/youtube/v2/reports?access_token=access_token&ids=channel%3D%3DMINE&startDate=2016-05-01&endDate=2016-06-30&metrics=views

অ্যাক্সেস টোকেন রিফ্রেশ করুন

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

অ্যাক্সেস টোকেন রিফ্রেশ করতে, আপনার অ্যাপ্লিকেশন Google-এর অনুমোদন সার্ভারে (https://oauth2.googleapis.com/token) একটি HTTPS POST অনুরোধ পাঠায়, যার অনুরোধের বডিতে নিম্নলিখিত প্যারামিটার অন্তর্ভুক্ত থাকে:

নাম	ভ্যালু
`client_id`	API কনসোল থেকে পাওয়া ক্লায়েন্ট আইডি।
`client_secret`	ঐচ্ছিক API কনসোল থেকে পাওয়া ক্লায়েন্ট সিক্রেট। (Android, iOS বা Chrome অ্যাপ্লিকেশন হিসেবে রেজিস্টার করা ক্লায়েন্টদের থেকে আসা অনুরোধের ক্ষেত্রে `client_secret` প্রযোজ্য নয়।)
`grant_type`	OAuth 2.0 স্পেসিফিকেশনে যেমন বলা হয়েছে, এই ফিল্ডের ভ্যালু `refresh_token` হিসেবে সেট করতে হবে।
`refresh_token`	অথরাইজেশন কোড এক্সচেঞ্জ থেকে রিফ্রেশ টোকেন ফেরত এসেছে।

DPoP ব্যবহার করা ঐচ্ছিক হলেও, আরও বেশি নিরাপত্তার জন্য এটি ব্যবহার করার সাজেশন দেওয়া হয়। রিফ্রেশ টোকেনের সাথে DPoP ব্যবহার করতে, আপনার অ্যাপ্লিকেশনকে টোকেন এন্ডপয়েন্টে করা প্রতিটি অনুরোধের জন্য একটি নতুন, অনন্য DPoP প্রুফ JWT তৈরি করতে হবে। এই প্রমাণটি অবশ্যই সেই একই ব্যক্তিগত কী দিয়ে স্বাক্ষর করতে হবে যা প্রাথমিক অনুমোদন কোড এক্সচেঞ্জের সময় ব্যবহার করা হয়েছিল। আপনার অ্যাপ্লিকেশন HTTP অনুরোধ হেডার হিসেবে প্রমাণ যোগ করে।

শিরোনাম	প্রয়োজনীয়	বিবরণ
`DPoP`	ঐচ্ছিক	DPoP প্রমাণ হল একটি JWT যা প্রাইভেট কীয়ের মালিকানা প্রমাণ করে। এটি একটি হেডার, প্যারামিটার নয়। প্রদান করা হলে, ফেরত আসা টোকেন এই 'কী'-এর সাথে বাউন্ড করা হয়। প্রতিটি অনুরোধের জন্য একটি নতুন, অনন্য প্রমাণ তৈরি করতে হবে এবং এতে অবশ্যই `htm` (HTTP পদ্ধতি) এবং `htu` (HTTP URI) দাবি অন্তর্ভুক্ত থাকতে হবে যা অনুরোধের সাথে মেলে।

নিচের স্নিপেটে অনুরোধের একটি নমুনা দেখানো হয়েছে:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded
DPoP: DPOP_PROOF_JWT

client_id=your_client_id&
refresh_token=refresh_token&
grant_type=refresh_token

রিফ্রেশ টোকেনের সাথে DPoP ব্যবহার করতে, আপনাকে অবশ্যই অনুরোধের জন্য একটি নতুন, অনন্য DPoP প্রমাণ JWT জেনারেট করতে হবে। কী পেয়ার জেনারেট করা এবং JWT তৈরি করার বিষয়ে ধাপে ধাপে নির্দেশাবলীর জন্য DPoP প্রমাণ তৈরি করুন দেখুন।

সফল এক্সচেঞ্জ হলে, নতুন অ্যাক্সেস টোকেন সহ 200 OK উত্তর পাওয়া যায়। DPoP ব্যবহার করা হলে, token_type হল Bearer। সফল রেসপন্স কনফার্ম করে যে রিফ্রেশ টোকেনের জন্য DPoP প্রমাণ গ্রহণ করা হয়েছে। Google উত্তরে একটি নতুন DPoP-Nonce HTTP হেডারও পাঠাতে পারে; যদি পাঠানো হয়, তাহলে আপনার ক্লায়েন্টকে অবশ্যই এই ননস ক্যাশে করতে হবে এবং পরবর্তী অনুরোধে DPoP প্রমাণের nonce দাবিতে এটি অন্তর্ভুক্ত করতে হবে।

DPoP হেডার না থাকলে, ভুল থাকলে বা ভুল কী ব্যবহার করলে এক্সচেঞ্জ ব্যর্থ হয়। নির্দিষ্ট DPoP ত্রুটি কোড এবং ননস ম্যানেজ করা সম্পর্কে বিশদ বিবরণের জন্য, ব্যর্থ এক্সচেঞ্জ দেখুন।

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
DPoP-Nonce: AN3XwJjZsjnb0ZuWkRlek8QU7wY-Zhf-5IP6tO0tORz0KgtDT1Bo8FX-w4nz3r5lnepI

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

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

টোকেন তুলে নেওয়া

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

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

প্রোগ্রাম্যাটিক্যালি টোকেন তুলে নিতে, আপনার অ্যাপ্লিকেশন https://oauth2.googleapis.com/revoke-এ অনুরোধ করে এবং প্যারামিটার হিসেবে টোকেন অন্তর্ভুক্ত করে:

curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
        https://oauth2.googleapis.com/revoke?token={token}

টোকেনটি অ্যাক্সেস টোকেন বা রিফ্রেশ টোকেন হতে পারে। টোকেনটি যদি অ্যাক্সেস টোকেন হয় এবং সেটির সাথে সংশ্লিষ্ট রিফ্রেশ টোকেন থাকে, তাহলে রিফ্রেশ টোকেনটিও বাতিল করা হবে।

প্রত্যাহার করার অনুরোধ সফলভাবে প্রসেস করা হলে, উত্তরের HTTP স্ট্যাটাস কোড হল 200। সমস্যার ক্ষেত্রে, সমস্যার কোডের সাথে HTTP স্ট্যাটাস কোড 400 রিটার্ন করা হয়।

অ্যাপ রিডাইরেক্ট পদ্ধতি

কাস্টম URI স্কিম

কাস্টম URI স্কিম হল ডিপলিঙ্কিংয়ের একটি ফর্ম যা আপনার অ্যাপ খোলার জন্য কাস্টম-সংজ্ঞায়িত স্কিম ব্যবহার করে।

Chrome অ্যাপে কাস্টম URI স্কিম ব্যবহার করার বিকল্প

Chrome Identity API ব্যবহার করুন যা OAuth 2.0 উত্তর সরাসরি আপনার অ্যাপে ডেলিভার করে, এর ফলে রিডাইরেক্ট URI-এর প্রয়োজন হয় না।

লুপব্যাক IP অ্যাড্রেস (macOS, Linux, Windows ডেস্কটপ)

এই URL ব্যবহার করে অথরাইজেশন কোড পেতে হলে, আপনার অ্যাপ্লিকেশনকে অবশ্যই লোকাল ওয়েব সার্ভারে লিসেন করতে হবে। এটি অনেক প্ল্যাটফর্মে করা সম্ভব হলেও সব প্ল্যাটফর্মে করা যায় না। তবে, আপনার প্ল্যাটফর্ম এতে কাজ করলে, অনুমোদন কোড পাওয়ার জন্য এটিই সাজেস্ট করা মেকানিজম।

আপনার অ্যাপ অনুমোদনের উত্তর পেলে, সবচেয়ে ভালো ব্যবহারযোগ্যতার জন্য এটি এমন একটি HTML পৃষ্ঠা দেখানোর মাধ্যমে উত্তর দেবে যা ব্যবহারকারীকে ব্রাউজার বন্ধ করে আপনার অ্যাপে ফিরে যেতে নির্দেশ দেয়।

ব্যবহারের ব্যাপারে সাজেশন	macOS, Linux এবং Windows ডেস্কটপ (তবে ইউনিভার্সাল Windows প্ল্যাটফর্ম নয়) অ্যাপ
ফর্মের ভ্যালু	অ্যাপ্লিকেশনের ধরন ডেস্কটপ অ্যাপ হিসেবে সেট করুন।

মনে রাখবেন: লুপব্যাক IP অ্যাড্রেস সম্পর্কে আরও তথ্য পেতে redirect_uri প্যারামিটারের সংজ্ঞা দেখুন। লুপব্যাক আইপির পরিবর্তে localhost ব্যবহার করাও সম্ভব, তবে এই কনফিগারেশনের ফলে ক্লায়েন্ট ফায়ারওয়ালের সাথে সমস্যা হতে পারে। বেশিরভাগ, তবে সব ফায়ারওয়াল লুপব্যাক কমিউনিকেশনকে অনুমতি দেয় না।

ম্যানুয়ালি কপি/পেস্ট করা (বন্ধ করা হয়েছে)

আপনার অ্যাপ সুরক্ষিত রাখুন

Chrome-এর জন্য অ্যাপের মালিকানা যাচাই করা

অ্যাপের ছদ্মবেশ ধারণের ঝুঁকি কমাতে, আপনার অ্যাপ্লিকেশনের মালিকানা যাচাই করতে পারেন।

যাচাইকরণ প্রসেস সম্পূর্ণ করতে, আপনাকে Chrome Web Store ডেভেলপার অ্যাকাউন্ট ব্যবহার করতে হবে। যাচাইকরণ সফলভাবে সম্পূর্ণ করতে নিম্নলিখিত শর্ত পূরণ করতে হবে:

আপনি যে Chrome এক্সটেনশন OAuth ক্লায়েন্টের জন্য যাচাইকরণ সম্পূর্ণ করছেন, সেটির আইটেম আইডির সাথে একই আইটেম আইডি সহ Chrome Web Store Developer Dashboard-এ আপনার একটি রেজিস্টার করা আইটেম থাকতে হবে।
আপনাকে Chrome ওয়েব স্টোর আইটেমের প্রকাশক হতে হবে। Chrome Web Store Developer Dashboard-এ অ্যাক্সেস ম্যানেজমেন্ট সম্পর্কে আরও জানুন।

Chrome এক্সটেনশন ক্লায়েন্টের অ্যাপের মালিকানা যাচাই করুন বিভাগে, যাচাইকরণ প্রক্রিয়া সম্পূর্ণ করতে মালিকানা যাচাই করুন বোতামে ক্লিক করুন।

মনে রাখবেন: আপনার অ্যাকাউন্টে অ্যাক্সেস দেওয়ার পরে যাচাইকরণ প্রক্রিয়া সম্পূর্ণ করার আগে কয়েক মিনিট অপেক্ষা করুন।

যাচাইকরণ সম্পূর্ণ হলে, যাচাইকরণ প্রক্রিয়া সম্পূর্ণ হওয়ার বিষয়টি কনফার্ম করার জন্য একটি বিজ্ঞপ্তি দেখানো হবে। অন্যথায়, সমস্যা সংক্রান্ত প্রম্পট দেখানো হবে।

যাচাইকরণ সম্পূর্ণ না হলে, নিম্নলিখিত বিষয়গুলি চেষ্টা করে দেখুন:

আপনি যে Chrome এক্সটেনশন OAuth ক্লায়েন্টের জন্য যাচাইকরণ সম্পূর্ণ করছেন, সেটির আইটেম আইডির সাথে একই আইটেম আইডি সহ Chrome Web Store Developer Dashboard-এ একটি রেজিস্টার করা আইটেম আছে কিনা তা নিশ্চিত করুন।
আপনি অ্যাপের প্রকাশক কিনা তা নিশ্চিত করুন, অর্থাৎ আপনাকে অ্যাপের ব্যক্তিগত প্রকাশক অথবা অ্যাপের গ্রুপ প্রকাশকের সদস্য হতে হবে। Chrome Web Store Developer Dashboard-এ অ্যাক্সেস ম্যানেজমেন্ট সম্পর্কে আরও জানুন।
আপনি যদি গ্রুপ প্রকাশক তালিকা আপডেট করে থাকেন, তাহলে Chrome Web Store Developer Dashboard-এ গ্রুপ প্রকাশক মেম্বারশিপ তালিকা সিঙ্ক করা আছে কিনা তা যাচাই করুন। আপনার প্রকাশকের মেম্বারশিপ তালিকা সিঙ্ক করার ব্যাপারে আরও জানুন।

App Check (শুধুমাত্র iOS)

অ্যাপ চেক ফিচার Apple-এর অ্যাপ অ্যাটেস্ট পরিষেবা ব্যবহার করে আপনার iOS অ্যাপ্লিকেশনকে অননুমোদিত ব্যবহার থেকে রক্ষা করতে সাহায্য করে। এর মাধ্যমে Google-এর OAuth 2.0 এন্ডপয়েন্টে করা অনুরোধগুলি আপনার আসল অ্যাপ্লিকেশন থেকে এসেছে কিনা তা যাচাই করা হয়। এটি অ্যাপের ছদ্মবেশীতার ঝুঁকি কমাতে সাহায্য করে।

আপনার iOS ক্লায়েন্টের জন্য অ্যাপ চেক করার সুবিধা চালু করুন

আপনার iOS ক্লায়েন্টের জন্য অ্যাপ চেক সফলভাবে চালু করতে নিম্নলিখিত প্রয়োজনীয়তা পূরণ করতে হবে:

আপনার iOS ক্লায়েন্টের জন্য টিম আইডি উল্লেখ করতে হবে।
আপনার বান্ডেল আইডিতে ওয়াইল্ডকার্ড ব্যবহার করা যাবে না, কারণ এটি একাধিক অ্যাপের সাথে কানেক্ট করতে পারে। এর অর্থ হল, বান্ডেল আইডিতে অবশ্যই অ্যাস্টেরিক্স (*) চিহ্ন থাকা চলবে না।

সতর্কতা: App Check চালু করা থাকলে, নতুন ক্লায়েন্ট তৈরি না করে আপনি OAuth ক্লায়েন্ট বান্ডিল আইডি এডিট করতে পারবেন না। আপনার iOS ক্লায়েন্ট তৈরি করা বা App Check চালু করার আগে, আপনি সঠিক বান্ডিল আইডি ব্যবহার করছেন কিনা তা যাচাই করুন। আপনি যদি রিডাইরেক্ট URI হিসেবে বান্ডিল আইডি ব্যবহার করেন, তাহলে আগে থেকে থাকা প্রোজেক্টের জন্য বান্ডিল আইডি আপডেট করলে আপনার অ্যাপ ব্যবহারকারীদের অভিজ্ঞতা বিঘ্নিত হতে পারে।

App Check চালু করতে, আপনার iOS ক্লায়েন্টের এডিট ভিউতে Firebase App Check-এর মাধ্যমে আপনার OAuth ক্লায়েন্টকে অপব্যবহার থেকে সুরক্ষিত রাখুন টগল বোতামটি চালু করুন।

App Check চালু করার পরে, আপনি OAuth ক্লায়েন্টের এডিট ভিউতে আপনার ক্লায়েন্ট থেকে আসা OAuth অনুরোধ সম্পর্কিত মেট্রিক দেখতে শুরু করবেন। আপনি App Check প্রয়োগ না করা পর্যন্ত যাচাই না করা সোর্স থেকে আসা অনুরোধ ব্লক করা হবে না। মেট্রিক্স মনিটরিং পৃষ্ঠার তথ্য আপনাকে এনফোর্সমেন্ট কখন শুরু করতে হবে তা নির্ধারণ করতে সাহায্য করতে পারে।

আপনার iOS অ্যাপের জন্য App Check চালু করার সময়, আপনি App Check ফিচার সম্পর্কিত সমস্যা দেখতে পেতে পারেন। এইসব সমস্যার সমাধান করতে, নিচে উল্লেখ করা বিষয়গুলি চেষ্টা করে দেখুন:

আপনার উল্লেখ করা বান্ডিল আইডি ও টিম আইডি সঠিক কিনা তা যাচাই করুন।
বান্ডিল আইডির জন্য আপনি ওয়াইল্ডকার্ড ব্যবহার করছেন না তা যাচাই করুন।

আপনার iOS ক্লায়েন্টের জন্য অ্যাপ চেক করার সুবিধা এনফোর্স করা

আপনার অ্যাপের জন্য অ্যাপ চেক চালু করলে, তা অটোমেটিক শনাক্ত না করতে পারা অনুরোধ ব্লক করে না। এই সুরক্ষা প্রয়োগ করতে, আপনার iOS ক্লায়েন্টের এডিট ভিউতে যান। সেখানে, আপনি iOS-এর জন্য Google Identity বিভাগের অধীনে পৃষ্ঠার ডানদিকে App Check মেট্রিক্স দেখতে পাবেন। মেট্রিক্সের মধ্যে নিম্নলিখিত তথ্য অন্তর্ভুক্ত:

যাচাই করা অনুরোধের সংখ্যা - যেসব অনুরোধে সঠিক App Check টোকেন আছে। আপনি App Check এনফোর্সমেন্ট চালু করার পরে, শুধুমাত্র এই বিভাগের অনুরোধগুলি সফল হবে।
যাচাই না করা অনুরোধের সংখ্যা: সম্ভবত পুরনো ক্লায়েন্ট অনুরোধ - অনুরোধে App Check টোকেন নেই; এইসব অনুরোধ আপনার অ্যাপের পুরনো ভার্সন থেকে আসতে পারে যাতে App Check প্রয়োগ করা নেই।
যাচাই না করা অনুরোধের সংখ্যা: অজানা সোর্স থেকে আসা অনুরোধ - App Check টোকেন নেই এমন অনুরোধ যা দেখে মনে হয় না যে আপনার অ্যাপ থেকে এসেছে।
যাচাই না করা অনুরোধের সংখ্যা: ভুল অনুরোধ - ভুল App Check টোকেন সহ অনুরোধ, যা আপনার অ্যাপের ছদ্মবেশে প্রমাণিত নয় এমন ক্লায়েন্ট বা এমুলেট করা পরিবেশ থেকে আসতে পারে।

App Check এনফোর্স করলে আপনার ব্যবহারকারীদের উপর কী প্রভাব পড়বে তা বুঝতে এই মেট্রিকগুলি পর্যালোচনা করুন।

App Check এনফোর্স করতে, ENFORCE বোতামে ক্লিক করে আপনার পছন্দ কনফার্ম করুন। এনফোর্সমেন্ট অ্যাক্টিভ হয়ে গেলে, আপনার ক্লায়েন্টের থেকে আসা সব যাচাই না করা অনুরোধ প্রত্যাখ্যান করা হবে।

মনে রাখবেন: এনফোর্সমেন্ট চালু করার পরে, পরিবর্তনগুলি কার্যকর হতে ১৫ মিনিট পর্যন্ত সময় লাগতে পারে।

আপনার iOS ক্লায়েন্টের জন্য অ্যাপ চেক এনফোর্স করা বন্ধ করুন

আপনার অ্যাপের জন্য App Check এনফোর্স না করলে এনফোর্সমেন্ট বন্ধ হয়ে যাবে এবং আপনার ক্লায়েন্ট থেকে Google OAuth 2.0 এন্ডপয়েন্টে আসা সব অনুরোধের অনুমতি দেওয়া হবে, যার মধ্যে যাচাই না করা অনুরোধও অন্তর্ভুক্ত।

আপনার iOS ক্লায়েন্টের জন্য App Check প্রয়োগ করা বন্ধ করতে, iOS ক্লায়েন্টের এডিট ভিউতে যান এবং প্রয়োগ করা বন্ধ করুন বোতামে ক্লিক করে আপনার পছন্দ কনফার্ম করুন।

মনে রাখবেন: App Check প্রয়োগ করা বন্ধ করার পরে, পরিবর্তন কার্যকর হতে ১৫ মিনিট পর্যন্ত সময় লাগতে পারে।

আপনার iOS ক্লায়েন্টের জন্য App Check বন্ধ করা

আপনার অ্যাপের জন্য App Check বন্ধ করে দিলে, সব App Check মনিটরিং এবং এনফোর্সমেন্ট বন্ধ হয়ে যাবে। পরিবর্তে, App Check এনফোর্স না করার কথা বিবেচনা করুন যাতে আপনি ক্লায়েন্টের জন্য মেট্রিক মনিটর করা চালিয়ে যেতে পারেন।

আপনার iOS ক্লায়েন্টের জন্য App Check বন্ধ করতে, iOS ক্লায়েন্টের এডিট ভিউতে গিয়ে Firebase App Check-এর মাধ্যমে আপনার OAuth ক্লায়েন্টকে অপব্যবহার থেকে সুরক্ষিত রাখুন টগল বোতাম বন্ধ করুন।

মনে রাখবেন: App Check বন্ধ করার পরে, পরিবর্তন কার্যকর হতে ১৫ মিনিট পর্যন্ত সময় লাগতে পারে।

সময়-ভিত্তিক অ্যাক্সেস

সময়-ভিত্তিক অ্যাক্সেস কোনও ব্যবহারকারীকে কোনও অ্যাকশন সম্পূর্ণ করার জন্য সীমিত সময়ের জন্য আপনার অ্যাপকে তার ডেটা অ্যাক্সেস করার অনুমতি দেয়। সম্মতি ফ্লো চলাকালীন বেছে নেওয়া Google প্রোডাক্টে সময়-ভিত্তিক অ্যাক্সেস উপলভ্য থাকে, যা ব্যবহারকারীদের সীমিত সময়ের জন্য অ্যাক্সেস দেওয়ার বিকল্প দেয়। এর একটি উদাহরণ হল Data Portability API যা ডেটার এককালীন ট্রান্সফার করার সুবিধা দেয়।

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

ক্রস-অ্যাকাউন্ট সুরক্ষা প্রয়োগ করা

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

Google-এর ক্রস-অ্যাকাউন্ট সুরক্ষা পরিষেবা আপনার অ্যাপে যে ধরনের ইভেন্ট পাঠায় তার কিছু উদাহরণ হল:

https://schemas.openid.net/secevent/risc/event-type/sessions-revoked
https://schemas.openid.net/secevent/oauth/event-type/token-revoked
https://schemas.openid.net/secevent/risc/event-type/account-disabled

ক্রস-অ্যাকাউন্ট সুরক্ষা কীভাবে প্রয়োগ করবেন এবং উপলভ্য ইভেন্টের সম্পূর্ণ তালিকা সম্পর্কে আরও তথ্য পেতে ক্রস-অ্যাকাউন্ট সুরক্ষার মাধ্যমে ব্যবহারকারীর অ্যাকাউন্ট সুরক্ষিত করুন পৃষ্ঠা দেখুন।

লাইব্রেরি ও স্যাম্পেল

পূর্বশর্ত

আপনার প্রোজেক্টের জন্য API চালু করা

অনুমোদনের ক্রেডেনশিয়াল তৈরি করা

iOS

UWP

অ্যাক্সেস স্কোপ শনাক্ত করা

OAuth 2.0 অ্যাক্সেস টোকেন পাওয়া

ধাপ ১: কোড যাচাইকারী ও চ্যালেঞ্জ তৈরি করা

কোড যাচাইকারী তৈরি করুন

কোড চ্যালেঞ্জ তৈরি করুন

ধাপ ২: Google-এর OAuth 2.0 সার্ভারে অনুরোধ পাঠান

অনুমোদনকারী URL-এর নমুনা

কাস্টম URI স্কিম

লুপব্যাক IP অ্যাড্রেস

ধাপ ৩: Google ব্যবহারকারীর কাছে সম্মতি চায়

সমস্যা

admin_policy_enforced

disallowed_useragent

org_internal

deleted_client

invalid_grant

redirect_uri_mismatch

invalid_request

ধাপ ৪: OAuth 2.0 সার্ভার রেসপন্স ম্যানেজ করা

ধাপ ৫: রিফ্রেশ ও অ্যাক্সেস টোকেনের জন্য যাচাইকরণ কোড বিনিময় করুন

DPoP প্রমাণ তৈরি করা

ধাপ ৬: ব্যবহারকারীরা কোন কোন স্কোপে অ্যাক্সেস দিয়েছেন তা চেক করুন

Google API কল করুন

HTTP GET-এর উদাহরণ

curlটি উদাহরণ

অ্যাক্সেস টোকেন রিফ্রেশ করুন

টোকেন তুলে নেওয়া

অ্যাপ রিডাইরেক্ট পদ্ধতি

কাস্টম URI স্কিম

Chrome অ্যাপে কাস্টম URI স্কিম ব্যবহার করার বিকল্প

লুপব্যাক IP অ্যাড্রেস (macOS, Linux, Windows ডেস্কটপ)

ম্যানুয়ালি কপি/পেস্ট করা (বন্ধ করা হয়েছে)

আপনার অ্যাপ সুরক্ষিত রাখুন

Chrome-এর জন্য অ্যাপের মালিকানা যাচাই করা

App Check (শুধুমাত্র iOS)

আপনার iOS ক্লায়েন্টের জন্য অ্যাপ চেক করার সুবিধা চালু করুন

আপনার iOS ক্লায়েন্টের জন্য অ্যাপ চেক করার সুবিধা এনফোর্স করা

আপনার iOS ক্লায়েন্টের জন্য অ্যাপ চেক এনফোর্স করা বন্ধ করুন

আপনার iOS ক্লায়েন্টের জন্য App Check বন্ধ করা

সময়-ভিত্তিক অ্যাক্সেস

আরও পড়ুন

ক্রস-অ্যাকাউন্ট সুরক্ষা প্রয়োগ করা

`admin_policy_enforced`

`disallowed_useragent`

`org_internal`

`deleted_client`

`invalid_grant`

`redirect_uri_mismatch`

`invalid_request`

`curl`টি উদাহরণ