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

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

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

OAuth 2.0 ব্যবহারকারীদের তাদের ইউজারনেম, পাসওয়ার্ড ও অন্যান্য তথ্য গোপন রেখে কোনও অ্যাপ্লিকেশনের সাথে নির্দিষ্ট ডেটা শেয়ার করার অনুমতি দেয়। যেমন, কোনও অ্যাপ্লিকেশন, চ্যানেলের YouTube ডেটা ফিরিয়ে আনার অনুমতি পেতে 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 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 অ্যাপের জন্য অ্যাপ চেক চালু করুন। অ্যাপ চেক চালু করলে, আপনার OAuth ক্লায়েন্ট থেকে আসা OAuth 2.0 অনুরোধ যে আসল এবং আপনার অ্যাপ থেকে এসেছে তা যাচাই করতে Apple-এর অ্যাপ অ্যাটেস্ট পরিষেবা ব্যবহার করা হয়। এটি অ্যাপের ছদ্মবেশীতার ঝুঁকি কমাতে সাহায্য করে। আপনার 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 Data API v3 নিম্নলিখিত স্কোপ ব্যবহার করে:

ব্যাপ্তি	বর্ণনা
`https://www. googleapis. com/ auth/ youtube`	আপনার YouTube অ্যাকাউন্ট পরিচালনা করুন
`https://www. googleapis. com/ auth/ youtube. channel-memberships. creator`	আপনার বর্তমান সক্রিয় চ্যানেল সদস্যদের তালিকা, তাদের বর্তমান স্তর এবং তারা কখন সদস্য হয়েছেন তা দেখুন
`https://www. googleapis. com/ auth/ youtube. force-ssl`	আপনার YouTube ভিডিও, রেটিং, মন্তব্য এবং ক্যাপশনগুলি দেখুন, সম্পাদনা করুন এবং স্থায়ীভাবে মুছুন৷
`https://www. googleapis. com/ auth/ youtube. readonly`	আপনার YouTube অ্যাকাউন্ট দেখুন
`https://www. googleapis. com/ auth/ youtube. upload`	আপনার YouTube ভিডিও পরিচালনা করুন
`https://www. googleapis. com/ auth/ youtubepartner`	YouTube-এ আপনার সম্পদ এবং সংশ্লিষ্ট বিষয়বস্তু দেখুন ও পরিচালনা করুন
`https://www. googleapis. com/ auth/ youtubepartner-channel-audit`	একটি 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 Data API v3 নিম্নলিখিত স্কোপ ব্যবহার করে:

ব্যাপ্তি	বর্ণনা
`https://www. googleapis. com/ auth/ youtube`	আপনার YouTube অ্যাকাউন্ট পরিচালনা করুন
`https://www. googleapis. com/ auth/ youtube. channel-memberships. creator`	আপনার বর্তমান সক্রিয় চ্যানেল সদস্যদের তালিকা, তাদের বর্তমান স্তর এবং তারা কখন সদস্য হয়েছেন তা দেখুন
`https://www. googleapis. com/ auth/ youtube. force-ssl`	আপনার YouTube ভিডিও, রেটিং, মন্তব্য এবং ক্যাপশনগুলি দেখুন, সম্পাদনা করুন এবং স্থায়ীভাবে মুছুন৷
`https://www. googleapis. com/ auth/ youtube. readonly`	আপনার YouTube অ্যাকাউন্ট দেখুন
`https://www. googleapis. com/ auth/ youtube. upload`	আপনার YouTube ভিডিও পরিচালনা করুন
`https://www. googleapis. com/ auth/ youtubepartner`	YouTube-এ আপনার সম্পদ এবং সংশ্লিষ্ট বিষয়বস্তু দেখুন ও পরিচালনা করুন
`https://www. googleapis. com/ auth/ youtubepartner-channel-audit`	একটি 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-এর URL ফ্র্যাগমেন্ট আইডেন্টিফায়ারে (#) name=value পেয়ার হিসেবে পাঠান।

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

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

login_hint

ঐচ্ছিক

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

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

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

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

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

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

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%2Fyoutube.force-ssl&
 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%2Fyoutube.force-ssl&
 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`	আপনার প্রোজেক্টের জন্য তালিকাভুক্ত রিডাইরেক্ট URI-এর মধ্যে একটি হল প্রদত্ত `client_id`-এর জন্য Cloud Console-এর ক্লায়েন্ট পৃষ্ঠা।

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 কল করার সময়) DPoP প্রমাণের nonce দাবিতে এটি অন্তর্ভুক্ত করতে হবে। এই আগে ইস্যু করা ননস ব্যবহার করে, আপনি অতিরিক্ত রাউন্ড-ট্রিপ ব্যর্থতা (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/youtube.force-ssl 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/youtube.force-ssl 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 লাইভ স্ট্রিমিং API কল করার সময়)।

মনে রাখবেন যে YouTube লাইভ স্ট্রিমিং API-তে পরিষেবা অ্যাকাউন্ট ফ্লো কাজ করে না। যেহেতু YouTube অ্যাকাউন্টের সাথে কোনও পরিষেবা অ্যাকাউন্ট লিঙ্ক করার কোনও উপায় নেই, তাই এই ফ্লোয়ের মাধ্যমে অনুরোধ অনুমোদনের চেষ্টা করলে NoLinkedYouTubeAccount সমস্যা দেখা দেবে।

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

HTTP GET-এর উদাহরণ

Authorization: Bearer HTTP হেডার ব্যবহার করে liveBroadcasts.list এন্ডপয়েন্টে (YouTube Live Streaming API) কল করলে তা নিম্নলিখিত উদাহরণের মতো দেখতে হতে পারে। মনে রাখবেন যে আপনাকে নিজের অ্যাক্সেস টোকেন উল্লেখ করতে হবে:

GET /youtube/v3/liveBroadcasts?part=id%2Csnippet&mine=true HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

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

GET https://www.googleapis.com/youtube/v3/liveBroadcasts?access_token=access_token&part=id%2Csnippet&mine=true

`curl`টি উদাহরণ

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

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/v3/liveBroadcasts?part=id%2Csnippet&mine=true

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

curl https://www.googleapis.com/youtube/v3/liveBroadcasts?access_token=access_token&part=id%2Csnippet&mine=true

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

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

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

নাম	ভ্যালু
`client_id`	API কনসোল থেকে পাওয়া ক্লায়েন্ট আইডি।
`client_secret`	ঐচ্ছিক API কনসোল থেকে পাওয়া ক্লায়েন্ট সিক্রেট। (`client_secret` Android, iOS বা Chrome অ্যাপ্লিকেশন হিসেবে রেজিস্টার করা ক্লায়েন্টের অনুরোধের ক্ষেত্রে প্রযোজ্য নয়। )
`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 ত্রুটি কোড এবং ননস ম্যানেজ করা সম্পর্কে বিশদ বিবরণের জন্য, ব্যর্থ এক্সচেঞ্জ দেখুন।

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

অ্যাপ চেক (শুধুমাত্র iOS)

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

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

আপনার iOS ক্লায়েন্টের জন্য App Check চালু করতে নিম্নলিখিত শর্ত পূরণ করতে হবে:

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

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

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

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

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

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

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

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

আপনার 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-এর জন্য অ্যাপের মালিকানা যাচাই করা

অ্যাপ চেক (শুধুমাত্র iOS)

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

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

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

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

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

আরও পড়ুন

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

`admin_policy_enforced`

`disallowed_useragent`

`org_internal`

`deleted_client`

`invalid_grant`

`redirect_uri_mismatch`

`invalid_request`

`curl`টি উদাহরণ