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

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

<0x

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

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

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

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

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

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

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

পূর্বশর্ত

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

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

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

Google API কনসোলে 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 অ্যাপের জন্য App Check চালু করুন। আপনি App Check চালু করলে, আপনার OAuth ক্লায়েন্ট থেকে আসা OAuth 2.0 অনুরোধগুলি আসল এবং আপনার অ্যাপ থেকে এসেছে কিনা তা যাচাই করতে Apple-এর App Attest পরিষেবা ব্যবহার করা হয়। এটি অ্যাপ ছদ্মবেশের ঝুঁকি কমাতে সাহায্য করে। আপনার iOS অ্যাপের জন্য App Check চালু করা সম্পর্কে আরও জানুন।
তৈরি করুন বিকল্পে ক্লিক করুন।

UWP

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

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.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%2Fyoutube.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`	আপনার প্রোজেক্টের জন্য তালিকাভুক্ত রিডাইরেক্ট 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",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

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

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

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

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

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

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

যেমন, অ্যাক্সেস টোকেন সংক্রান্ত নিম্নলিখিত নমুনা উত্তর থেকে বোঝা যায় যে ব্যবহারকারী আপনার অ্যাপ্লিকেশনকে ব্যবহারকারীর YouTube ভিডিও, রেটিং, কমেন্ট ও ক্যাপশন দেখতে, এডিট করতে ও স্থায়ীভাবে মুছে দিতে অনুমতি দিয়েছেন:

  {
    "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
    "expires_in": 3920,
    "token_type": "Bearer",
    "scope": "https://www.googleapis.com/auth/youtube.force-ssl",
    "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
  }

Google API কল করা

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

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

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

HTTP GET-এর উদাহরণ

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

GET /youtube/v3/channels?part=snippet&mine=true HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

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

GET https://www.googleapis.com/youtube/v3/channels?access_token=access_token&part=snippet&mine=true

`curl`টি উদাহরণ

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

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/v3/channels?part=snippet&mine=true

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

curl https://www.googleapis.com/youtube/v3/channels?access_token=access_token&part=snippet&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",
  "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 প্যারামিটারের সংজ্ঞা দেখুন। এছাড়াও, লুপব্যাক IP-এর পরিবর্তে 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)

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

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

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

আপনার 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`টি উদাহরণ