এই ডকুমেন্টটিতে ব্যাখ্যা করা হয়েছে যে, ফোন, ট্যাবলেট এবং কম্পিউটারের মতো ডিভাইসে ইনস্টল করা অ্যাপ্লিকেশনগুলি কীভাবে ইউটিউব অ্যানালিটিক্স এপিআই (YouTube Analytics API) বা ইউটিউব রিপোর্টিং এপিআই (YouTube Reporting API)-তে অ্যাক্সেস অনুমোদন করার জন্য গুগলের OAuth 2.0 এন্ডপয়েন্টগুলি ব্যবহার করে।
OAuth 2.0 ব্যবহারকারীদের ইউজারনেম, পাসওয়ার্ড এবং অন্যান্য তথ্য গোপন রেখে কোনো অ্যাপ্লিকেশনের সাথে নির্দিষ্ট ডেটা শেয়ার করার সুযোগ দেয়। উদাহরণস্বরূপ, একটি অ্যাপ্লিকেশন কোনো চ্যানেলের ইউটিউব অ্যানালিটিক্স ডেটা সংগ্রহের অনুমতি পেতে OAuth 2.0 ব্যবহার করতে পারে।
ইনস্টল করা অ্যাপগুলো আলাদা আলাদা ডিভাইসে বিতরণ করা হয় এবং ধরে নেওয়া হয় যে এই অ্যাপগুলো গোপনীয় তথ্য রক্ষা করতে পারে না। ব্যবহারকারী অ্যাপটিতে উপস্থিত থাকা অবস্থায় অথবা অ্যাপটি ব্যাকগ্রাউন্ডে চলার সময়েও এগুলো গুগল এপিআই (Google API) অ্যাক্সেস করতে পারে।
এই অনুমোদন প্রক্রিয়াটি ওয়েব সার্ভার অ্যাপ্লিকেশনগুলির জন্য ব্যবহৃত প্রক্রিয়ার অনুরূপ। প্রধান পার্থক্য হলো, ইনস্টল করা অ্যাপগুলিকে অবশ্যই সিস্টেম ব্রাউজার খুলতে হবে এবং গুগলের অনুমোদন সার্ভার থেকে আসা প্রতিক্রিয়াগুলি পরিচালনা করার জন্য একটি স্থানীয় রিডাইরেক্ট ইউআরআই সরবরাহ করতে হবে।
লাইব্রেরি এবং নমুনা
iOS অ্যাপের জন্য আমরা ‘Sign In With Google iOS SDK’- এর সর্বশেষ সংস্করণটি ব্যবহার করার পরামর্শ দিই। এই SDK ব্যবহারকারীর অনুমোদন পরিচালনা করে এবং এই নির্দেশিকায় বর্ণিত নিম্ন-স্তরের প্রোটোকলের চেয়ে এটি প্রয়োগ করা সহজতর।
যেসব ডিভাইসে সিস্টেম ব্রাউজার সাপোর্ট করে না অথবা যেগুলোর ইনপুট ক্ষমতা সীমিত, যেমন টিভি, গেম কনসোল, ক্যামেরা বা প্রিন্টার, সেগুলোতে চালিত অ্যাপের জন্য ‘টিভি ও ডিভাইসের জন্য OAuth 2.0’ অথবা ‘টিভি এবং সীমিত ইনপুট ডিভাইসে সাইন-ইন’ দেখুন।
পূর্বশর্ত
আপনার প্রোজেক্টের জন্য এপিআই (API) সক্রিয় করুন
যে কোনো অ্যাপ্লিকেশন যা গুগল এপিআই কল করে, তাকে এপিআই কনসোলে সেই এপিআইগুলো সক্রিয় করতে হবে।
আপনার প্রোজেক্টের জন্য একটি API সক্রিয় করতে:
- গুগল এপিআই কনসোলে এপিআই লাইব্রেরিটি খুলুন ।
- অনুরোধ করা হলে, একটি প্রজেক্ট নির্বাচন করুন অথবা নতুন একটি তৈরি করুন।
- লাইব্রেরি পৃষ্ঠা ব্যবহার করে ইউটিউব অ্যানালিটিক্স এপিআই এবং ইউটিউব রিপোর্টিং এপিআই খুঁজুন ও সক্রিয় করুন। অনেক অ্যাপ্লিকেশন যা ইউটিউব অ্যানালিটিক্স ডেটা সংগ্রহ করে, সেগুলো ইউটিউব ডেটা এপিআই-এর সাথেও ইন্টারফেস করে। আপনার অ্যাপ্লিকেশন ব্যবহার করবে এমন অন্য যেকোনো এপিআই খুঁজুন এবং সেগুলোও সক্রিয় করুন।
অনুমোদনের প্রমাণপত্র তৈরি করুন
যে কোনো অ্যাপ্লিকেশন যা গুগল এপিআই (Google API) অ্যাক্সেস করার জন্য OAuth 2.0 ব্যবহার করে, সেটির অবশ্যই এমন অনুমোদন ক্রেডেনশিয়াল (authorization credentials) থাকতে হবে যা গুগলের OAuth 2.0 সার্ভারের কাছে অ্যাপ্লিকেশনটিকে শনাক্ত করে। নিম্নলিখিত ধাপগুলোতে আপনার প্রোজেক্টের জন্য ক্রেডেনশিয়াল তৈরি করার পদ্ধতি ব্যাখ্যা করা হয়েছে। এরপর আপনার অ্যাপ্লিকেশনগুলো সেই ক্রেডেনশিয়াল ব্যবহার করে আপনার প্রোজেক্টের জন্য সক্রিয় করা এপিআইগুলো অ্যাক্সেস করতে পারবে।
- ক্লায়েন্ট পৃষ্ঠায় যান।
- ক্লায়েন্ট তৈরি করুন -এ ক্লিক করুন।
- নিম্নলিখিত বিভাগগুলিতে গুগলের অনুমোদন সার্ভার দ্বারা সমর্থিত ক্লায়েন্টের প্রকারগুলি বর্ণনা করা হয়েছে। আপনার অ্যাপ্লিকেশনের জন্য প্রস্তাবিত ক্লায়েন্টের প্রকারটি বেছে নিন, আপনার OAuth ক্লায়েন্টের নাম দিন এবং ফর্মের অন্যান্য ক্ষেত্রগুলি যথাযথভাবে সেট করুন।
আইওএস
- iOS অ্যাপ্লিকেশনটির ধরন নির্বাচন করুন।
- OAuth ক্লায়েন্টের জন্য একটি নাম লিখুন। ক্লায়েন্টকে শনাক্ত করার জন্য এই নামটি আপনার প্রোজেক্টের ক্লায়েন্টস পেজে প্রদর্শিত হয়।
- আপনার অ্যাপের জন্য বান্ডেল আইডেন্টিফায়ারটি লিখুন। বান্ডেল আইডি হলো আপনার অ্যাপের ইনফরমেশন প্রপার্টি লিস্ট রিসোর্স ফাইলের ( info.plist ) CFBundleIdentifier কী-এর ভ্যালু। এই ভ্যালুটি সাধারণত Xcode প্রজেক্ট এডিটরের জেনারেল প্যানে অথবা সাইনিং অ্যান্ড ক্যাপাবিলিটিস প্যানে প্রদর্শিত হয়। এছাড়াও, Apple-এর App Store Connect সাইটে অ্যাপটির অ্যাপ ইনফরমেশন পেজের জেনারেল ইনফরমেশন সেকশনেও বান্ডেল আইডিটি দেখা যায়।
আপনার অ্যাপের জন্য সঠিক বান্ডেল আইডি ব্যবহার করছেন কিনা তা নিশ্চিত করুন, কারণ 'অ্যাপ চেক' ফিচারটি ব্যবহার করলে আপনি এটি পরিবর্তন করতে পারবেন না।
- (ঐচ্ছিক)
আপনার অ্যাপটি যদি অ্যাপলের অ্যাপ স্টোরে প্রকাশিত হয়ে থাকে, তবে আপনার অ্যাপের অ্যাপ স্টোর আইডিটি লিখুন। স্টোর আইডি হলো একটি সাংখ্যিক স্ট্রিং যা প্রতিটি অ্যাপল অ্যাপ স্টোর ইউআরএল-এ অন্তর্ভুক্ত থাকে।
- আপনার iOS বা iPadOS ডিভাইসে Apple App Store অ্যাপটি খুলুন।
- আপনার অ্যাপটি খুঁজুন।
- শেয়ার বাটনটি (বর্গাকার এবং ঊর্ধ্বমুখী তীর চিহ্ন) নির্বাচন করুন।
- কপি লিঙ্ক নির্বাচন করুন।
- লিঙ্কটি একটি টেক্সট এডিটরে পেস্ট করুন। অ্যাপ স্টোর আইডি হলো URL-এর শেষ অংশ।
উদাহরণ:
https://apps.apple.com/app/google/id 284815942
- (ঐচ্ছিক)
আপনার টিম আইডি লিখুন। আরও তথ্যের জন্য অ্যাপল ডেভেলপার অ্যাকাউন্ট ডকুমেন্টেশনে আপনার টিম আইডি খুঁজুন দেখুন।
দ্রষ্টব্য: আপনি যদি আপনার ক্লায়েন্টের জন্য অ্যাপ চেক সক্রিয় করেন, তাহলে টিম আইডি ফিল্ডটি আবশ্যক। - (ঐচ্ছিক)
আপনার iOS অ্যাপের জন্য অ্যাপ চেক (App Check) চালু করুন। আপনি যখন অ্যাপ চেক চালু করেন, তখন আপনার OAuth ক্লায়েন্ট থেকে আসা OAuth 2.0 অনুরোধগুলি আসল এবং আপনার অ্যাপ থেকেই আসছে কিনা, তা যাচাই করার জন্য Apple-এর অ্যাপ অ্যাটেস্ট (App Attest) পরিষেবাটি ব্যবহৃত হয়। এটি অ্যাপ ছদ্মবেশের ঝুঁকি কমাতে সাহায্য করে। আপনার iOS অ্যাপের জন্য অ্যাপ চেক চালু করা সম্পর্কে আরও জানুন ।
- তৈরি করুন- এ ক্লিক করুন।
ইউডব্লিউপি
- ইউনিভার্সাল উইন্ডোজ প্ল্যাটফর্ম অ্যাপ্লিকেশন টাইপ নির্বাচন করুন।
- OAuth ক্লায়েন্টের জন্য একটি নাম লিখুন। এই নামটি আপনার প্রোজেক্টে প্রদর্শিত হবে। ক্লায়েন্টকে শনাক্ত করতে।
- আপনার অ্যাপের ১২-অক্ষরের মাইক্রোসফট স্টোর আইডিটি প্রবেশ করান। আপনি মাইক্রোসফট পার্টনার সেন্টারের অ্যাপ ম্যানেজমেন্ট বিভাগের অ্যাপ আইডেন্টিটি পেজে এই মানটি খুঁজে পাবেন।
- তৈরি করুন- এ ক্লিক করুন।
UWP অ্যাপের ক্ষেত্রে, আপনার অ্যাপ্লিকেশনের অনন্য প্যাকেজ সিকিউরিটি আইডেন্টিফায়ার (SID) ব্যবহার করে রিডাইরেক্ট URI তৈরি করা হয়। আপনি আপনার ভিজ্যুয়াল স্টুডিও প্রজেক্টের মধ্যে থাকা Package.appxmanifest ফাইলে আপনার অ্যাপের Package SID খুঁজে পেতে পারেন।
গুগল ক্লাউড কনসোলে আপনার ক্লায়েন্ট আইডি তৈরি করার সময়, আপনাকে অবশ্যই আপনার প্যাকেজ SID-এর ছোট হাতের অক্ষর ব্যবহার করে নিম্নলিখিত বিন্যাসে রিডাইরেক্ট URI উল্লেখ করতে হবে:
ms-app://YOUR_APP_PACKAGE_SID
মাইক্রোসফট ডকুমেন্টেশনে যেমন উল্লেখ করা হয়েছে, UWP অ্যাপের জন্য কাস্টম URI স্কিম ৩৯ অক্ষরের বেশি হতে পারবে না।
অ্যাক্সেসের পরিধি শনাক্ত করুন
স্কোপ আপনার অ্যাপ্লিকেশনকে শুধুমাত্র প্রয়োজনীয় রিসোর্সগুলিতে অ্যাক্সেসের অনুরোধ করার সুযোগ দেয় এবং একই সাথে ব্যবহারকারীদেরকে আপনার অ্যাপ্লিকেশনকে দেওয়া অ্যাক্সেসের পরিমাণ নিয়ন্ত্রণ করতে সক্ষম করে। সুতরাং, অনুরোধ করা স্কোপের সংখ্যা এবং ব্যবহারকারীর সম্মতি পাওয়ার সম্ভাবনার মধ্যে একটি বিপরীত সম্পর্ক থাকতে পারে।
OAuth 2.0 অথরাইজেশন প্রয়োগ করা শুরু করার আগে, আমরা আপনাকে সেই স্কোপগুলি চিহ্নিত করার পরামর্শ দিই যেগুলিতে আপনার অ্যাপের অ্যাক্সেসের জন্য অনুমতির প্রয়োজন হবে।
ইউটিউব অ্যানালিটিক্স এপিআই নিম্নলিখিত স্কোপগুলো ব্যবহার করে:
| ব্যাপ্তি | বর্ণনা |
|---|---|
https://www. googleapis. com/ auth/ youtube | আপনার YouTube অ্যাকাউন্ট পরিচালনা করুন |
https://www. googleapis. com/ auth/ youtube. readonly | আপনার YouTube অ্যাকাউন্ট দেখুন |
https://www. googleapis. com/ auth/ youtubepartner | YouTube-এ আপনার সম্পদ এবং সংশ্লিষ্ট বিষয়বস্তু দেখুন ও পরিচালনা করুন |
https://www. googleapis. com/ auth/ yt-analytics-monetary. readonly | আপনার YouTube সামগ্রীর জন্য আর্থিক এবং অ-আর্থিক YouTube বিশ্লেষণ প্রতিবেদনগুলি দেখুন৷ |
https://www. googleapis. com/ auth/ yt-analytics. readonly | আপনার YouTube সামগ্রীর জন্য YouTube বিশ্লেষণ প্রতিবেদনগুলি দেখুন৷ |
ইউটিউব রিপোর্টিং এপিআই নিম্নলিখিত স্কোপগুলো ব্যবহার করে:
| ব্যাপ্তি | বর্ণনা |
|---|---|
https://www. googleapis. com/ auth/ yt-analytics-monetary. readonly | আপনার YouTube সামগ্রীর জন্য আর্থিক এবং অ-আর্থিক YouTube বিশ্লেষণ প্রতিবেদনগুলি দেখুন৷ |
https://www. googleapis. com/ auth/ yt-analytics. readonly | আপনার YouTube সামগ্রীর জন্য YouTube বিশ্লেষণ প্রতিবেদনগুলি দেখুন৷ |
OAuth 2.0 API Scopes ডকুমেন্টটিতে সেই সমস্ত স্কোপের একটি সম্পূর্ণ তালিকা রয়েছে যা আপনি গুগল এপিআই অ্যাক্সেস করতে ব্যবহার করতে পারেন।
OAuth 2.0 অ্যাক্সেস টোকেন প্রাপ্তি
নিম্নলিখিত ধাপগুলোতে দেখানো হয়েছে, কীভাবে আপনার অ্যাপ্লিকেশনটি কোনো ব্যবহারকারীর পক্ষ থেকে একটি এপিআই (API) অনুরোধ সম্পাদন করার জন্য তার সম্মতি পেতে গুগলের OAuth 2.0 সার্ভারের সাথে যোগাযোগ করে। ব্যবহারকারীর অনুমোদন প্রয়োজন এমন কোনো গুগল এপিআই অনুরোধ কার্যকর করার আগে আপনার অ্যাপ্লিকেশনটির অবশ্যই সেই সম্মতি থাকতে হবে।
ধাপ ১: একটি কোড ভেরিফায়ার এবং চ্যালেঞ্জ তৈরি করুন
ইনস্টল করা অ্যাপের প্রবাহকে আরও সুরক্ষিত করতে গুগল প্রুফ কী ফর কোড এক্সচেঞ্জ (PKCE) প্রোটোকল সমর্থন করে। প্রতিটি অনুমোদন অনুরোধের জন্য একটি অনন্য কোড ভেরিফায়ার তৈরি করা হয় এবং এর রূপান্তরিত মান, যাকে "কোড_চ্যালেঞ্জ" বলা হয়, অনুমোদন কোডটি পাওয়ার জন্য অনুমোদন সার্ভারে পাঠানো হয়।
কোড যাচাইকারী তৈরি করুন
একটি code_verifier হলো একটি উচ্চ-এনট্রপি ক্রিপ্টোগ্রাফিক র্যান্ডম স্ট্রিং, যা [AZ] / [az] / [0-9] / "-" / "." / "_" / "~" এই অসংরক্ষিত অক্ষরগুলো ব্যবহার করে তৈরি, যার সর্বনিম্ন দৈর্ঘ্য ৪৩ অক্ষর এবং সর্বোচ্চ দৈর্ঘ্য ১২৮ অক্ষর।
কোড যাচাইকারীর যথেষ্ট এনট্রপি থাকা উচিত, যাতে এর মান অনুমান করা অবাস্তব হয়ে পড়ে।
কোড চ্যালেঞ্জ তৈরি করুন
কোড চ্যালেঞ্জ তৈরি করার দুটি পদ্ধতি সমর্থিত।
| কোড চ্যালেঞ্জ তৈরির পদ্ধতি | |
|---|---|
| S256 (সুপারিশকৃত) | কোড চ্যালেঞ্জটি হলো কোড ভেরিফায়ারের Base64URL (কোনো প্যাডিং ছাড়া) দ্বারা এনকোড করা SHA256 হ্যাশ।
|
| সমতল | কোড চ্যালেঞ্জের মানটি উপরে তৈরি করা কোড ভেরিফায়ারের মানের সমান।
|
ধাপ ২: গুগলের OAuth 2.0 সার্ভারে একটি অনুরোধ পাঠান
ব্যবহারকারীর অনুমোদন পেতে, https://accounts.google.com/o/oauth2/v2/auth ঠিকানায় গুগলের অনুমোদন সার্ভারে একটি অনুরোধ পাঠান। এই এন্ডপয়েন্টটি সক্রিয় সেশন অনুসন্ধান, ব্যবহারকারীর প্রমাণীকরণ এবং ব্যবহারকারীর সম্মতি গ্রহণ করে। এন্ডপয়েন্টটি শুধুমাত্র SSL-এর মাধ্যমে অ্যাক্সেসযোগ্য এবং এটি HTTP (নন-SSL) সংযোগ গ্রহণ করে না।
অনুমোদন সার্ভারটি ইনস্টল করা অ্যাপ্লিকেশনগুলির জন্য নিম্নলিখিত কোয়েরি স্ট্রিং প্যারামিটারগুলি সমর্থন করে:
| প্যারামিটার | |||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
client_id | প্রয়োজনীয় আপনার অ্যাপ্লিকেশনের ক্লায়েন্ট আইডি। আপনি এই মানটি ক্লাউড কনসোল ক্লায়েন্টস পৃষ্ঠায় খুঁজে পাবেন। | ||||||||||||||||||
redirect_uri | প্রয়োজনীয় এটি নির্ধারণ করে যে গুগলের অনুমোদন সার্ভার আপনার অ্যাপে কীভাবে প্রতিক্রিয়া পাঠাবে। ইনস্টল করা অ্যাপগুলির জন্য বেশ কয়েকটি রিডাইরেক্ট বিকল্প উপলব্ধ রয়েছে, এবং আপনি একটি নির্দিষ্ট রিডাইরেক্ট পদ্ধতি মাথায় রেখে আপনার অনুমোদন ক্রেডেনশিয়ালগুলি সেট আপ করে থাকবেন। মানটিকে অবশ্যই OAuth 2.0 ক্লায়েন্টের জন্য অনুমোদিত রিডাইরেক্ট URI-গুলোর একটির সাথে হুবহু মিলতে হবে, যা আপনি আপনার ক্লায়েন্টের ক্লাউড কনসোল ক্লায়েন্টস পৃষ্ঠায় কনফিগার করেছেন। যদি এই মানটি কোনো অনুমোদিত URI-এর সাথে না মেলে, তাহলে আপনি একটি সারণিটি প্রতিটি পদ্ধতির জন্য উপযুক্ত
| ||||||||||||||||||
response_type | প্রয়োজনীয় গুগল OAuth 2.0 এন্ডপয়েন্টটি একটি অনুমোদন কোড ফেরত দেবে কিনা তা নির্ধারণ করে। ইনস্টল করা অ্যাপ্লিকেশনগুলির | ||||||||||||||||||
scope | প্রয়োজনীয় স্পেস দিয়ে আলাদা করা স্কোপগুলোর একটি তালিকা, যা সেই রিসোর্সগুলোকে শনাক্ত করে যেগুলো আপনার অ্যাপ্লিকেশন ব্যবহারকারীর পক্ষ থেকে অ্যাক্সেস করতে পারে। এই মানগুলো গুগল কর্তৃক ব্যবহারকারীকে দেখানো সম্মতি স্ক্রিনটিকে তথ্যসমৃদ্ধ করে। স্কোপ আপনার অ্যাপ্লিকেশনকে শুধুমাত্র প্রয়োজনীয় রিসোর্সগুলিতে অ্যাক্সেসের অনুরোধ করার সুযোগ দেয় এবং একই সাথে ব্যবহারকারীদেরকে আপনার অ্যাপ্লিকেশনকে দেওয়া অ্যাক্সেসের পরিমাণ নিয়ন্ত্রণ করতে সক্ষম করে। সুতরাং, অনুরোধ করা স্কোপের সংখ্যা এবং ব্যবহারকারীর সম্মতি পাওয়ার সম্ভাবনার মধ্যে একটি বিপরীত সম্পর্ক রয়েছে। ইউটিউব অ্যানালিটিক্স এপিআই নিম্নলিখিত স্কোপগুলো ব্যবহার করে:
ইউটিউব রিপোর্টিং এপিআই নিম্নলিখিত স্কোপগুলো ব্যবহার করে:
OAuth 2.0 API Scopes ডকুমেন্টটিতে সেই সমস্ত স্কোপের একটি সম্পূর্ণ তালিকা দেওয়া আছে যা আপনি গুগল এপিআই অ্যাক্সেস করতে ব্যবহার করতে পারেন। | ||||||||||||||||||
code_challenge | সুপারিশকৃত একটি এনকোডেড | ||||||||||||||||||
code_challenge_method | সুপারিশকৃত অনুমোদন কোড বিনিময়ের সময় ব্যবহৃত হবে এমন একটি | ||||||||||||||||||
state | সুপারিশকৃত এটি এমন যেকোনো স্ট্রিং ভ্যালু নির্দিষ্ট করে যা আপনার অ্যাপ্লিকেশনটি আপনার অথরাইজেশন রিকোয়েস্ট এবং অথরাইজেশন সার্ভারের রেসপন্সের মধ্যবর্তী অবস্থা (state) বজায় রাখতে ব্যবহার করে। ব্যবহারকারী আপনার অ্যাপ্লিকেশনের অ্যাক্সেস রিকোয়েস্টে সম্মতি বা অস্বীকৃতি জানানোর পর, সার্ভারটি আপনি এই প্যারামিটারটি বিভিন্ন উদ্দেশ্যে ব্যবহার করতে পারেন, যেমন ব্যবহারকারীকে আপনার অ্যাপ্লিকেশনের সঠিক রিসোর্সে নির্দেশ করা, ননস (nonce) পাঠানো এবং ক্রস-সাইট রিকোয়েস্ট ফোরজারি প্রতিরোধ করা। যেহেতু আপনার | ||||||||||||||||||
login_hint | ঐচ্ছিক আপনার অ্যাপ্লিকেশনটি যদি জানে কোন ব্যবহারকারী প্রমাণীকরণের চেষ্টা করছেন, তবে এটি গুগল অথেনটিকেশন সার্ভারকে একটি ইঙ্গিত দেওয়ার জন্য এই প্যারামিটারটি ব্যবহার করতে পারে। সার্ভারটি এই ইঙ্গিত ব্যবহার করে সাইন-ইন ফর্মের ইমেল ফিল্ডটি আগে থেকে পূরণ করে অথবা উপযুক্ত মাল্টি-লগইন সেশনটি নির্বাচন করে লগইন প্রক্রিয়াকে সহজ করে তোলে। প্যারামিটারের মান হিসেবে একটি ইমেল অ্যাড্রেস বা | ||||||||||||||||||
নমুনা অনুমোদন ইউআরএল
নিচের ট্যাবগুলোতে বিভিন্ন রিডাইরেক্ট ইউআরআই অপশনের জন্য নমুনা অথরাইজেশন ইউআরএল দেখানো হয়েছে।
প্রতিটি URL এমন একটি স্কোপে অ্যাক্সেসের অনুরোধ করে, যা ব্যবহারকারীর ইউটিউব অ্যানালিটিক্স রিপোর্টগুলো পুনরুদ্ধার করার অনুমতি দেয়। redirect_uri প্যারামিটারের মান ছাড়া URL-গুলো হুবহু একই। URL-গুলোতে প্রয়োজনীয় response_type ও client_id প্যারামিটারের পাশাপাশি ঐচ্ছিক state প্যারামিটারও রয়েছে। পাঠযোগ্যতার জন্য প্রতিটি URL-এ লাইন ব্রেক এবং স্পেস দেওয়া আছে।
কাস্টম ইউআরআই স্কিম
https://accounts.google.com/o/oauth2/v2/auth? scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyt-analytics.readonly& response_type=code& state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken& redirect_uri=com.example.app%3A/oauth2redirect& client_id=client_id
লুপব্যাক আইপি ঠিকানা
https://accounts.google.com/o/oauth2/v2/auth? scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyt-analytics.readonly& response_type=code& state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken& redirect_uri=http%3A//127.0.0.1%3A9004& client_id=client_id
ধাপ ৩: গুগল ব্যবহারকারীর কাছে সম্মতি চায়
এই ধাপে, ব্যবহারকারী আপনার অ্যাপ্লিকেশনকে অনুরোধ করা অ্যাক্সেস দেবেন কিনা, সেই সিদ্ধান্ত নেন। এই পর্যায়ে, গুগল একটি সম্মতি উইন্ডো প্রদর্শন করে, যেখানে আপনার অ্যাপ্লিকেশনের নাম, ব্যবহারকারীর অনুমোদন ক্রেডেনশিয়াল ব্যবহার করে যে গুগল এপিআই পরিষেবাগুলিতে অ্যাক্সেসের অনুমতি চাওয়া হচ্ছে তার নাম এবং যে অ্যাক্সেসের পরিধিগুলো মঞ্জুর করা হবে তার একটি সারসংক্ষেপ দেখানো হয়। এরপর ব্যবহারকারী আপনার অ্যাপ্লিকেশনের অনুরোধ করা এক বা একাধিক পরিধিতে অ্যাক্সেস মঞ্জুর করতে সম্মতি দিতে পারেন অথবা অনুরোধটি প্রত্যাখ্যান করতে পারেন।
এই পর্যায়ে আপনার অ্যাপ্লিকেশনের কিছু করার প্রয়োজন নেই, কারণ এটি গুগলের OAuth 2.0 সার্ভার থেকে অ্যাক্সেস দেওয়া হয়েছে কিনা সেই প্রতিক্রিয়ার জন্য অপেক্ষা করে। সেই প্রতিক্রিয়াটি পরবর্তী ধাপে ব্যাখ্যা করা হয়েছে।
ত্রুটি
গুগলের OAuth 2.0 অথরাইজেশন এন্ডপয়েন্টে করা অনুরোধগুলিতে প্রত্যাশিত অথেন্টিকেশন এবং অথরাইজেশন ফ্লো-এর পরিবর্তে ব্যবহারকারীর কাছে ত্রুটির বার্তা প্রদর্শিত হতে পারে। সাধারণ ত্রুটি কোড এবং প্রস্তাবিত সমাধানগুলি হলো:
admin_policy_enforced
আপনার Google Workspace অ্যাডমিনিস্ট্রেটরের নীতিমালার কারণে Google অ্যাকাউন্টটি অনুরোধ করা এক বা একাধিক স্কোপ অনুমোদন করতে পারছে না। একজন অ্যাডমিনিস্ট্রেটর কীভাবে আপনার OAuth ক্লায়েন্ট আইডিতে স্পষ্টভাবে অ্যাক্সেস মঞ্জুর না করা পর্যন্ত সমস্ত স্কোপ অথবা সংবেদনশীল ও সীমাবদ্ধ স্কোপগুলিতে অ্যাক্সেস সীমাবদ্ধ করতে পারেন, সে সম্পর্কে আরও তথ্যের জন্য "কোন তৃতীয়-পক্ষ ও অভ্যন্তরীণ অ্যাপ Google Workspace ডেটা অ্যাক্সেস করবে তা নিয়ন্ত্রণ করুন" শীর্ষক Google Workspace অ্যাডমিন হেল্প আর্টিকেলটি দেখুন।
disallowed_useragent
অনুমোদন এন্ডপয়েন্টটি একটি এমবেডেড ইউজার-এজেন্টের ভিতরে প্রদর্শিত হয়, যা গুগলের OAuth 2.0 নীতিমালা দ্বারা নিষিদ্ধ।
WKWebView তে অথরাইজেশন রিকোয়েস্ট খোলার সময় iOS এবং macOS ডেভেলপাররা এই ত্রুটির সম্মুখীন হতে পারেন। এর পরিবর্তে ডেভেলপারদের Google Sign-In for iOS অথবা OpenID Foundation-এর AppAuth for iOS-এর মতো iOS লাইব্রেরি ব্যবহার করা উচিত।
যখন কোনো iOS বা macOS অ্যাপ একটি এমবেডেড ইউজার-এজেন্টে একটি সাধারণ ওয়েব লিঙ্ক খোলে এবং কোনো ব্যবহারকারী আপনার সাইট থেকে Google-এর OAuth 2.0 অথরাইজেশন এন্ডপয়েন্টে যান, তখন ওয়েব ডেভেলপাররা এই ত্রুটির সম্মুখীন হতে পারেন। ডেভেলপারদের উচিত সাধারণ লিঙ্কগুলোকে অপারেটিং সিস্টেমের ডিফল্ট লিঙ্ক হ্যান্ডলারে খোলার অনুমতি দেওয়া, যার মধ্যে ইউনিভার্সাল লিঙ্ক হ্যান্ডলার এবং ডিফল্ট ব্রাউজার অ্যাপ উভয়ই অন্তর্ভুক্ত। SFSafariViewController লাইব্রেরিটিও একটি সমর্থিত বিকল্প।
org_internal
অনুরোধে থাকা OAuth ক্লায়েন্ট আইডিটি একটি প্রকল্পের অংশ, যা একটি নির্দিষ্ট Google Cloud Organization- এর Google অ্যাকাউন্টগুলিতে অ্যাক্সেস সীমিত করে। এই কনফিগারেশন বিকল্পটি সম্পর্কে আরও তথ্যের জন্য, "আপনার OAuth সম্মতি স্ক্রিন সেট আপ করা" সাহায্য নিবন্ধের "ব্যবহারকারীর প্রকার" বিভাগটি দেখুন।
deleted_client
অনুরোধটি করার জন্য ব্যবহৃত OAuth ক্লায়েন্টটি মুছে ফেলা হয়েছে। অব্যবহৃত ক্লায়েন্টের ক্ষেত্রে, এই মুছে ফেলার কাজটি ম্যানুয়ালি বা স্বয়ংক্রিয়ভাবে হতে পারে। মুছে ফেলার ৩০ দিনের মধ্যে ক্লায়েন্ট পুনরুদ্ধার করা যেতে পারে। আরও জানুন ।
invalid_grant
আপনি যদি কোড ভেরিফায়ার এবং চ্যালেঞ্জ ব্যবহার করেন, তাহলে code_callenge প্যারামিটারটি অবৈধ বা অনুপস্থিত। নিশ্চিত করুন যে code_challenge প্যারামিটারটি সঠিকভাবে সেট করা আছে।
অ্যাক্সেস টোকেন রিফ্রেশ করার সময় , টোকেনটির মেয়াদ শেষ হয়ে যেতে পারে বা এটি অবৈধ হয়ে যেতে পারে। ব্যবহারকারীকে পুনরায় প্রমাণীকরণ করুন এবং নতুন টোকেন পাওয়ার জন্য তার সম্মতি চান। আপনি যদি ক্রমাগত এই ত্রুটিটি দেখতে পান, তবে নিশ্চিত করুন যে আপনার অ্যাপ্লিকেশনটি সঠিকভাবে কনফিগার করা হয়েছে এবং আপনি আপনার অনুরোধে সঠিক টোকেন ও প্যারামিটার ব্যবহার করছেন। অন্যথায়, ব্যবহারকারীর অ্যাকাউন্টটি মুছে ফেলা বা নিষ্ক্রিয় করা হয়ে থাকতে পারে।
redirect_uri_mismatch
অনুমোদন অনুরোধে পাঠানো redirect_uri টি OAuth ক্লায়েন্ট আইডির জন্য কোনো অনুমোদিত রিডাইরেক্ট URI-এর সাথে মেলে না। Google Cloud Console-এর Clients পৃষ্ঠায় অনুমোদিত রিডাইরেক্ট URI-গুলো পর্যালোচনা করুন।
প্রদত্ত redirect_uri ক্লায়েন্টের ধরণটির জন্য অবৈধ হতে পারে।
redirect_uri প্যারামিটারটি OAuth আউট-অফ-ব্যান্ড (OOB) ফ্লো-কে নির্দেশ করতে পারে, যা বাতিল করা হয়েছে এবং এখন আর সমর্থিত নয়। আপনার ইন্টিগ্রেশন আপডেট করতে মাইগ্রেশন গাইডটি দেখুন।
invalid_request
আপনার করা অনুরোধটিতে কোনো সমস্যা ছিল। এর বেশ কয়েকটি কারণ থাকতে পারে:
- অনুরোধটি সঠিকভাবে বিন্যাস করা হয়নি।
- অনুরোধটিতে প্রয়োজনীয় প্যারামিটার অনুপস্থিত ছিল।
- অনুরোধটিতে এমন একটি অনুমোদন পদ্ধতি ব্যবহার করা হয়েছে যা গুগল সমর্থন করে না। আপনার OAuth ইন্টিগ্রেশনটি একটি প্রস্তাবিত ইন্টিগ্রেশন পদ্ধতি ব্যবহার করছে কিনা তা যাচাই করুন।
- রিডাইরেক্ট ইউআরআই-এর জন্য একটি অসমর্থিত কাস্টম স্কিম ব্যবহার করা হয়েছে। আপনি যদি অ্যান্ড্রয়েড বা ক্রোম অ্যাপে ‘কাস্টম ইউআরআই স্কিম সমর্থিত নয়’ এই ত্রুটি বার্তাটি দেখতে পান, তাহলে কাস্টম ইউআরআই স্কিমের বিকল্পগুলো সম্পর্কে আরও জানুন ।
ধাপ ৪: OAuth 2.0 সার্ভারের প্রতিক্রিয়া পরিচালনা করুন
আপনার অ্যাপ্লিকেশনটি যে পদ্ধতিতে অনুমোদনের প্রতিক্রিয়া গ্রহণ করে, তা নির্ভর করে এটি যে রিডাইরেক্ট ইউআরআই স্কিম ব্যবহার করে তার উপর। স্কিম নির্বিশেষে, প্রতিক্রিয়াটিতে একটি অনুমোদন কোড ( code ) অথবা একটি ত্রুটি ( error ) থাকবে। উদাহরণস্বরূপ, error=access_denied নির্দেশ করে যে ব্যবহারকারী অনুরোধটি প্রত্যাখ্যান করেছেন।
যদি ব্যবহারকারী আপনার অ্যাপ্লিকেশনে অ্যাক্সেসের অনুমতি দেন, তাহলে আপনি পরবর্তী ধাপে বর্ণিত পদ্ধতি অনুযায়ী অথরাইজেশন কোডটির বিনিময়ে একটি অ্যাক্সেস টোকেন এবং একটি রিফ্রেশ টোকেন পেতে পারেন।
ধাপ ৫: রিফ্রেশ এবং অ্যাক্সেস টোকেনের জন্য অনুমোদন কোড বিনিময় করুন
অনুমোদন কোডের বিনিময়ে অ্যাক্সেস টোকেন পেতে, https://oauth2.googleapis.com/token এন্ডপয়েন্টটি কল করুন এবং নিম্নলিখিত প্যারামিটারগুলো সেট করুন:
| ক্ষেত্র | |
|---|---|
client_id | ক্লাউড কনসোল ক্লায়েন্টস পৃষ্ঠা থেকে ক্লায়েন্ট আইডিটি পাওয়া গেছে। |
client_secret | ঐচ্ছিক ক্লাউড কনসোল ক্লায়েন্টস পৃষ্ঠা থেকে ক্লায়েন্ট সিক্রেটটি পাওয়া গেছে। |
code | প্রাথমিক অনুরোধ থেকে প্রাপ্ত অনুমোদন কোড। |
code_verifier | ধাপ ১- এ আপনার তৈরি করা কোড ভেরিফায়ার। |
grant_type | OAuth 2.0 স্পেসিফিকেশনে সংজ্ঞায়িত নিয়ম অনুযায়ী , এই ফিল্ডের মান অবশ্যই authorization_code এ সেট করতে হবে। |
redirect_uri | প্রদত্ত client_id জন্য ক্লাউড কনসোল ক্লায়েন্টস পৃষ্ঠায় আপনার প্রোজেক্টের জন্য তালিকাভুক্ত রিডাইরেক্ট URI-গুলোর মধ্যে একটি। |
নিম্নলিখিত কোড স্নিপেটটি একটি নমুনা অনুরোধ দেখাচ্ছে:
POST /token HTTP/1.1 Host: oauth2.googleapis.com Content-Type: application/x-www-form-urlencoded code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7& client_id=your_client_id& redirect_uri=http://127.0.0.1:9004& grant_type=authorization_code
এই অনুরোধের জবাবে গুগল একটি JSON অবজেক্ট ফেরত দেয়, যেটিতে একটি স্বল্পস্থায়ী অ্যাক্সেস টোকেন এবং একটি রিফ্রেশ টোকেন থাকে।
প্রতিক্রিয়াটিতে নিম্নলিখিত ক্ষেত্রগুলি রয়েছে:
| ক্ষেত্র | |
|---|---|
access_token | যে টোকেনটি আপনার অ্যাপ্লিকেশন একটি গুগল এপিআই অনুরোধ অনুমোদন করার জন্য পাঠায়। |
expires_in | অ্যাক্সেস টোকেনটির অবশিষ্ট মেয়াদ সেকেন্ডে। |
id_token | দ্রষ্টব্য: এই প্রপার্টিটি শুধুমাত্র তখনই ফেরত দেওয়া হয়, যদি আপনার অনুরোধে openid , profile , বা email মতো কোনো আইডেন্টিটি স্কোপ অন্তর্ভুক্ত থাকে। এর ভ্যালুটি হলো একটি JSON Web Token (JWT), যাতে ব্যবহারকারীর ডিজিটালভাবে স্বাক্ষরিত পরিচয় সংক্রান্ত তথ্য থাকে। |
refresh_token | একটি টোকেন যা ব্যবহার করে আপনি একটি নতুন অ্যাক্সেস টোকেন পেতে পারেন। রিফ্রেশ টোকেনগুলো ততক্ষণ পর্যন্ত বৈধ থাকে যতক্ষণ না ব্যবহারকারী অ্যাক্সেস প্রত্যাহার করে নেয় অথবা রিফ্রেশ টোকেনটির মেয়াদ শেষ হয়ে যায়। মনে রাখবেন যে, ইনস্টল করা অ্যাপ্লিকেশনগুলোর জন্য সর্বদা রিফ্রেশ টোকেন ফেরত দেওয়া হয়। |
refresh_token_expires_in | রিফ্রেশ টোকেনের অবশিষ্ট মেয়াদ সেকেন্ডে। এই মানটি শুধুমাত্র তখনই সেট করা হয় যখন ব্যবহারকারী সময়-ভিত্তিক অ্যাক্সেসের অনুমতি দেন। |
scope | access_token দ্বারা প্রদত্ত অ্যাক্সেসের পরিধি, যা স্পেস দ্বারা বিভক্ত এবং কেস-সেনসিটিভ স্ট্রিং-এর একটি তালিকা হিসাবে প্রকাশ করা হয়। |
token_type | ফেরত আসা টোকেনের ধরণ। বর্তমানে, এই ফিল্ডের মান সর্বদা Bearer এ সেট করা থাকে। |
নিম্নলিখিত কোড স্নিপেটটি একটি নমুনা প্রতিক্রিয়া দেখাচ্ছে:
{ "access_token": "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in": 3920, "token_type": "Bearer", "scope": "https://www.googleapis.com/auth/yt-analytics.readonly https://www.googleapis.com/auth/calendar.readonly", "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI" }
ধাপ ৬: ব্যবহারকারীরা কোন কোন স্কোপ মঞ্জুর করেছেন তা যাচাই করুন
একাধিক অনুমতি (স্কোপ) অনুরোধ করার সময়, ব্যবহারকারীরা আপনার অ্যাপকে সেগুলোর সবগুলোতে অ্যাক্সেস নাও দিতে পারেন। আপনার অ্যাপকে অবশ্যই যাচাই করতে হবে যে কোন স্কোপগুলো আসলে মঞ্জুর করা হয়েছে এবং কিছু অনুমতি প্রত্যাখ্যান করা হলে পরিস্থিতিটি সুষ্ঠুভাবে সামাল দিতে হবে; সাধারণত, সেই প্রত্যাখ্যান করা স্কোপগুলোর উপর নির্ভরশীল ফিচারগুলোকে নিষ্ক্রিয় করার মাধ্যমে এটি করা হয়।
তবে, এর ব্যতিক্রমও আছে। যেসব গুগল ওয়ার্কস্পেস এন্টারপ্রাইজ অ্যাপে ডোমেন-ব্যাপী কর্তৃত্ব অর্পণ করা আছে, অথবা যেগুলোকে 'বিশ্বস্ত' (Trusted) হিসেবে চিহ্নিত করা হয়েছে, সেগুলো সুনির্দিষ্ট অনুমতির সম্মতি স্ক্রিনটি এড়িয়ে যায়। এই অ্যাপগুলোর ক্ষেত্রে, ব্যবহারকারীরা সুনির্দিষ্ট অনুমতির সম্মতি স্ক্রিনটি দেখতে পাবেন না। এর পরিবর্তে, আপনার অ্যাপটি অনুরোধ করা সমস্ত স্কোপ পাবে অথবা কোনোটিই পাবে না।
আরও বিস্তারিত তথ্যের জন্য, কীভাবে সূক্ষ্ম অনুমতি পরিচালনা করতে হয় তা দেখুন।
ব্যবহারকারী আপনার অ্যাপ্লিকেশনকে কোনো নির্দিষ্ট স্কোপে অ্যাক্সেস দিয়েছেন কিনা তা যাচাই করতে, অ্যাক্সেস টোকেন রেসপন্সের scope ফিল্ডটি পরীক্ষা করুন। অ্যাক্সেস_টোকেন দ্বারা প্রদত্ত অ্যাক্সেসের স্কোপগুলো স্পেস দ্বারা বিভক্ত এবং কেস-সেনসিটিভ স্ট্রিংয়ের একটি তালিকা হিসাবে প্রকাশ করা হয়।
উদাহরণস্বরূপ, নিম্নলিখিত নমুনা অ্যাক্সেস টোকেন প্রতিক্রিয়াটি নির্দেশ করে যে ব্যবহারকারী আপনার অ্যাপ্লিকেশনকে শুধুমাত্র-পঠ্য ড্রাইভ অ্যাক্টিভিটি এবং ক্যালেন্ডার ইভেন্টগুলির অনুমতি প্রদান করেছেন:
{ "access_token": "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in": 3920, "token_type": "Bearer", "scope": "https://www.googleapis.com/auth/yt-analytics.readonly https://www.googleapis.com/auth/calendar.readonly", "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI" }
গুগল এপিআই কল করুন
আপনার অ্যাপ্লিকেশন একটি অ্যাক্সেস টোকেন পাওয়ার পর, যদি এপিআই-এর জন্য প্রয়োজনীয় অ্যাক্সেসের সুযোগ(গুলি) মঞ্জুর করা হয়ে থাকে, তবে আপনি একটি নির্দিষ্ট ব্যবহারকারী অ্যাকাউন্টের পক্ষ থেকে একটি গুগল এপিআই-তে কল করার জন্য টোকেনটি ব্যবহার করতে পারেন। এটি করার জন্য, এপিআই-তে করা অনুরোধে একটি access_token কোয়েরি প্যারামিটার অথবা একটি Authorization HTTP হেডার Bearer ভ্যালু অন্তর্ভুক্ত করে অ্যাক্সেস টোকেনটি যোগ করুন। যখন সম্ভব, HTTP হেডার ব্যবহার করা শ্রেয়, কারণ কোয়েরি স্ট্রিংগুলো সার্ভার লগে দৃশ্যমান হওয়ার প্রবণতা থাকে। বেশিরভাগ ক্ষেত্রে আপনি গুগল এপিআই-তে আপনার কলগুলো সেট আপ করার জন্য একটি ক্লায়েন্ট লাইব্রেরি ব্যবহার করতে পারেন (উদাহরণস্বরূপ, ইউটিউব অ্যানালিটিক্স এপিআই-তে কল করার সময়)।
উল্লেখ্য যে, ইউটিউব অ্যানালিটিক্স এপিআই সার্ভিস অ্যাকাউন্ট ফ্লো সমর্থন করে না। ইউটিউব রিপোর্টিং এপিআই শুধুমাত্র সেইসব ইউটিউব কন্টেন্ট মালিকদের জন্য সার্ভিস অ্যাকাউন্ট সমর্থন করে, যারা একাধিক ইউটিউব চ্যানেলের মালিক এবং সেগুলো পরিচালনা করেন, যেমন রেকর্ড লেবেল এবং মুভি স্টুডিও।
আপনি OAuth 2.0 প্লেগ্রাউন্ডে সমস্ত গুগল এপিআই ব্যবহার করে দেখতে এবং সেগুলোর পরিধি দেখতে পারেন।
HTTP GET উদাহরণ
Authorization: Bearer HTTP হেডার ব্যবহার করে reports.query এন্ডপয়েন্টে (ইউটিউব অ্যানালিটিক্স এপিআই) একটি কল নিম্নলিখিতের মতো দেখতে হতে পারে। মনে রাখবেন যে আপনাকে আপনার নিজস্ব অ্যাক্সেস টোকেন নির্দিষ্ট করতে হবে:
GET /youtube/analytics/v1/reports?ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views HTTP/1.1 Host: www.googleapis.com Authorization: Bearer access_token
এখানে access_token কোয়েরি স্ট্রিং প্যারামিটার ব্যবহার করে প্রমাণীকৃত ব্যবহারকারীর জন্য একই API-তে একটি কল দেওয়া হলো:
GET https://www.googleapis.com/youtube/analytics/v1/reports?access_token=access_token&ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views
curl উদাহরণ
আপনি curl কমান্ড-লাইন অ্যাপ্লিকেশন দিয়ে এই কমান্ডগুলো পরীক্ষা করতে পারেন। এখানে একটি উদাহরণ দেওয়া হলো যেখানে HTTP হেডার অপশন (পছন্দনীয়) ব্যবহার করা হয়েছে:
curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/analytics/v1/reports?ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views
অথবা, বিকল্পভাবে, কোয়েরি স্ট্রিং প্যারামিটার বিকল্পটি:
curl https://www.googleapis.com/youtube/analytics/v1/reports?access_token=access_token&ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views
একটি অ্যাক্সেস টোকেন রিফ্রেশ করুন
অ্যাক্সেস টোকেন পর্যায়ক্রমে মেয়াদোত্তীর্ণ হয়ে যায় এবং সংশ্লিষ্ট API অনুরোধের জন্য অকার্যকর ক্রেডেনশিয়াল হয়ে পড়ে। যদি আপনি টোকেনটির সাথে যুক্ত স্কোপগুলিতে অফলাইন অ্যাক্সেসের অনুরোধ করে থাকেন, তবে ব্যবহারকারীর অনুমতি না চেয়েই (এমনকি ব্যবহারকারী উপস্থিত না থাকলেও) আপনি অ্যাক্সেস টোকেনটি রিফ্রেশ করতে পারেন।
অ্যাক্সেস টোকেন রিফ্রেশ করতে, আপনার অ্যাপ্লিকেশনটি গুগলের অথরাইজেশন সার্ভারে ( https://oauth2.googleapis.com/token ) একটি HTTPS POST রিকোয়েস্ট পাঠায়, যাতে নিম্নলিখিত প্যারামিটারগুলো অন্তর্ভুক্ত থাকে:
| ক্ষেত্র | |
|---|---|
client_id | এপিআই কনসোল থেকে ক্লায়েন্ট আইডিটি পাওয়া গেছে। |
client_secret | ঐচ্ছিক এপিআই কনসোল থেকে ক্লায়েন্ট সিক্রেট পাওয়া যায়। (অ্যান্ড্রয়েড, আইওএস বা ক্রোম অ্যাপ্লিকেশন হিসেবে নিবন্ধিত ক্লায়েন্টদের অনুরোধের ক্ষেত্রে |
grant_type | OAuth 2.0 স্পেসিফিকেশনে সংজ্ঞায়িত নিয়ম অনুযায়ী, এই ফিল্ডের মান অবশ্যই refresh_token এ সেট করতে হবে। |
refresh_token | অনুমোদন কোড বিনিময়ের মাধ্যমে রিফ্রেশ টোকেনটি ফেরত এসেছে। |
নিম্নলিখিত কোড স্নিপেটটি একটি নমুনা অনুরোধ দেখাচ্ছে:
POST /token HTTP/1.1 Host: oauth2.googleapis.com Content-Type: application/x-www-form-urlencoded client_id=your_client_id& refresh_token=refresh_token& grant_type=refresh_token
যতক্ষণ পর্যন্ত ব্যবহারকারী অ্যাপ্লিকেশনটিতে প্রদত্ত অ্যাক্সেস প্রত্যাহার না করেন, ততক্ষণ টোকেন সার্ভার একটি JSON অবজেক্ট ফেরত দেয়, যাতে একটি নতুন অ্যাক্সেস টোকেন থাকে। নিম্নলিখিত কোড স্নিপেটটি একটি নমুনা প্রতিক্রিয়া দেখাচ্ছে:
{ "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" }
মনে রাখবেন যে, ইস্যু করা রিফ্রেশ টোকেনের সংখ্যার উপর সীমাবদ্ধতা রয়েছে; প্রতিটি ক্লায়েন্ট/ব্যবহারকারী সমন্বয়ের জন্য একটি সীমা এবং সমস্ত ক্লায়েন্ট জুড়ে প্রতিটি ব্যবহারকারীর জন্য আরেকটি সীমা রয়েছে। আপনার রিফ্রেশ টোকেনগুলো দীর্ঘমেয়াদী স্টোরেজে সংরক্ষণ করা উচিত এবং যতক্ষণ সেগুলো বৈধ থাকে, ততক্ষণ ব্যবহার করা চালিয়ে যাওয়া উচিত। যদি আপনার অ্যাপ্লিকেশন খুব বেশি রিফ্রেশ টোকেনের জন্য অনুরোধ করে, তবে এটি এই সীমাগুলোর সম্মুখীন হতে পারে, সেক্ষেত্রে পুরোনো রিফ্রেশ টোকেনগুলো কাজ করা বন্ধ করে দেবে।
টোকেন প্রত্যাহার
কিছু ক্ষেত্রে একজন ব্যবহারকারী কোনো অ্যাপ্লিকেশনকে দেওয়া অ্যাক্সেস প্রত্যাহার করতে চাইতে পারেন। ব্যবহারকারী অ্যাকাউন্ট সেটিংস-এ গিয়ে অ্যাক্সেস প্রত্যাহার করতে পারেন। আরও তথ্যের জন্য, আপনার অ্যাকাউন্টে অ্যাক্সেস থাকা তৃতীয় পক্ষের সাইট ও অ্যাপস সম্পর্কিত সাপোর্ট ডকুমেন্টের ‘সাইট বা অ্যাপের অ্যাক্সেস সরান’ অংশটি দেখুন।
কোনো অ্যাপ্লিকেশনের পক্ষে প্রোগ্রাম্যাটিকভাবে তাকে দেওয়া অ্যাক্সেস প্রত্যাহার করাও সম্ভব। প্রোগ্রাম্যাটিক প্রত্যাহার সেইসব ক্ষেত্রে গুরুত্বপূর্ণ যেখানে একজন ব্যবহারকারী আনসাবস্ক্রাইব করেন, কোনো অ্যাপ্লিকেশন সরিয়ে ফেলেন, অথবা কোনো অ্যাপের জন্য প্রয়োজনীয় এপিআই রিসোর্স উল্লেখযোগ্যভাবে পরিবর্তিত হয়। অন্য কথায়, অপসারণ প্রক্রিয়ার একটি অংশ হিসেবে অ্যাপ্লিকেশনটিকে পূর্বে দেওয়া অনুমতিগুলো মুছে ফেলা নিশ্চিত করার জন্য একটি এপিআই অনুরোধ অন্তর্ভুক্ত থাকতে পারে।
প্রোগ্রামের মাধ্যমে একটি টোকেন বাতিল করতে, আপনার অ্যাপ্লিকেশনটি 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 ফেরত দেওয়া হয়।
অ্যাপ পুনঃনির্দেশ পদ্ধতি
কাস্টম ইউআরআই স্কিম
কাস্টম ইউআরআই স্কিম হলো ডিপলিংকিং-এর একটি রূপ, যা আপনার অ্যাপ খোলার জন্য একটি বিশেষভাবে সংজ্ঞায়িত স্কিম ব্যবহার করে।
ক্রোম অ্যাপে কাস্টম ইউআরআই স্কিম ব্যবহার করার বিকল্প
Chrome Identity API ব্যবহার করুন, যা OAuth 2.0 রেসপন্স সরাসরি আপনার অ্যাপে পৌঁছে দেয় এবং এর ফলে রিডাইরেক্ট URI-এর প্রয়োজন হয় না।
লুপব্যাক আইপি অ্যাড্রেস (ম্যাকওএস, লিনাক্স, উইন্ডোজ ডেস্কটপ)
এই URL ব্যবহার করে অনুমোদন কোড পেতে হলে, আপনার অ্যাপ্লিকেশনটিকে অবশ্যই স্থানীয় ওয়েব সার্ভারে লিসেনিং অবস্থায় থাকতে হবে। এটি অনেক প্ল্যাটফর্মে সম্ভব হলেও, সব প্ল্যাটফর্মে নয়। তবে, যদি আপনার প্ল্যাটফর্ম এটি সমর্থন করে, তাহলে অনুমোদন কোড পাওয়ার জন্য এটিই প্রস্তাবিত পদ্ধতি।
আপনার অ্যাপ যখন অনুমোদনের প্রতিক্রিয়া পায়, সর্বোত্তম ব্যবহারযোগ্যতার জন্য এটির এমন একটি HTML পৃষ্ঠা প্রদর্শন করা উচিত যা ব্যবহারকারীকে ব্রাউজার বন্ধ করে আপনার অ্যাপে ফিরে আসতে নির্দেশ দেয়।
| প্রস্তাবিত ব্যবহার | macOS, Linux, এবং Windows ডেস্কটপ অ্যাপস (কিন্তু ইউনিভার্সাল উইন্ডোজ প্ল্যাটফর্ম নয়) |
| ফর্ম মান | অ্যাপ্লিকেশন টাইপটি ডেস্কটপ অ্যাপ হিসেবে সেট করুন। |
ম্যানুয়াল কপি/পেস্ট (অপ্রচলিত)
আপনার অ্যাপগুলি সুরক্ষিত রাখুন
ক্রোমের জন্য অ্যাপের মালিকানা যাচাই করুন
অ্যাপ ছদ্মবেশের ঝুঁকি কমাতে আপনি আপনার অ্যাপ্লিকেশনের মালিকানা যাচাই করতে পারেন।
যাচাইকরণ প্রক্রিয়াটি সম্পন্ন করতে, আপনাকে আপনার ক্রোম ওয়েব স্টোর ডেভেলপার অ্যাকাউন্ট ব্যবহার করতে হবে। সফল যাচাইকরণের জন্য নিম্নলিখিত শর্তগুলো অবশ্যই পূরণ করতে হবে:
- আপনি যে Chrome Extension OAuth ক্লায়েন্টের জন্য যাচাইকরণ সম্পন্ন করছেন, তার আইটেম আইডির সাথে একই আইটেম আইডি সহ Chrome Web Store ডেভেলপার ড্যাশবোর্ডে আপনার একটি নিবন্ধিত আইটেম থাকতে হবে।
- আপনাকে অবশ্যই ক্রোম ওয়েব স্টোর আইটেমটির প্রকাশক হতে হবে। ক্রোম ওয়েব স্টোর ডেভেলপার ড্যাশবোর্ডে অ্যাক্সেস ম্যানেজমেন্ট সম্পর্কে আরও জানুন ।
ক্রোম এক্সটেনশন ক্লায়েন্টের 'অ্যাপের মালিকানা যাচাই করুন' (Verify App Ownership) বিভাগে, যাচাইকরণ প্রক্রিয়াটি সম্পন্ন করতে 'মালিকানা যাচাই করুন' (Verify Ownership) বোতামটিতে ক্লিক করুন।
দ্রষ্টব্য: আপনার অ্যাকাউন্টে প্রবেশাধিকার দেওয়ার পর যাচাইকরণ প্রক্রিয়াটি সম্পন্ন করার আগে কয়েক মিনিট অপেক্ষা করুন।
যাচাইকরণ সফল হলে, যাচাইকরণ প্রক্রিয়ার সাফল্য নিশ্চিত করতে একটি বিজ্ঞপ্তি প্রদর্শিত হবে। অন্যথায়, একটি ত্রুটির বার্তা দেখানো হবে।
ব্যর্থ যাচাইকরণ ঠিক করতে, নিম্নলিখিতগুলি চেষ্টা করুন:
- নিশ্চিত করুন যে, আপনি যে Chrome Extension OAuth ক্লায়েন্টের জন্য যাচাইকরণ সম্পন্ন করছেন, তার আইটেম আইডির সাথে একই আইটেম আইডি সহ Chrome Web Store ডেভেলপার ড্যাশবোর্ডে একটি নিবন্ধিত আইটেম রয়েছে।
- নিশ্চিত করুন যে আপনি অ্যাপটির একজন পাবলিশার, অর্থাৎ, আপনাকে অবশ্যই অ্যাপটির স্বতন্ত্র পাবলিশার অথবা অ্যাপটির পাবলিশার গ্রুপের সদস্য হতে হবে। Chrome Web Store ডেভেলপার ড্যাশবোর্ডে অ্যাক্সেস ম্যানেজমেন্ট সম্পর্কে আরও জানুন ।
- আপনি যদি এইমাত্র আপনার গ্রুপ পাবলিশার তালিকা আপডেট করে থাকেন, তাহলে Chrome Web Store ডেভেলপার ড্যাশবোর্ডে গ্রুপ পাবলিশার সদস্য তালিকাটি সিঙ্ক হয়েছে কিনা তা যাচাই করুন। আপনার পাবলিশার সদস্য তালিকা সিঙ্ক করার বিষয়ে আরও জানুন ।
অ্যাপ চেক (শুধুমাত্র iOS-এর জন্য)
অ্যাপ চেক ফিচারটি অ্যাপলের অ্যাপ অ্যাটেস্ট সার্ভিস ব্যবহার করে যাচাই করে যে, গুগল OAuth 2.0 এন্ডপয়েন্টে করা অনুরোধগুলো আপনার আসল অ্যাপ্লিকেশন থেকেই আসছে কি না। এর মাধ্যমে এটি আপনার iOS অ্যাপ্লিকেশনগুলোকে অননুমোদিত ব্যবহার থেকে সুরক্ষিত রাখতে সাহায্য করে। এটি অ্যাপ ছদ্মবেশের ঝুঁকি কমাতে সহায়ক।
আপনার iOS ক্লায়েন্টের জন্য অ্যাপ চেক সক্রিয় করুন
আপনার iOS ক্লায়েন্টের জন্য অ্যাপ চেক সফলভাবে সক্রিয় করতে নিম্নলিখিত শর্তগুলি অবশ্যই পূরণ করতে হবে:- আপনাকে আপনার iOS ক্লায়েন্টের জন্য একটি টিম আইডি নির্দিষ্ট করতে হবে।
- আপনার বান্ডেল আইডিতে ওয়াইল্ডকার্ড ব্যবহার করা যাবে না, কারণ এটি একাধিক অ্যাপকে নির্দেশ করতে পারে। এর অর্থ হলো, বান্ডেল আইডিতে অ্যাস্টারিস্ক (*) চিহ্নটি অন্তর্ভুক্ত করা যাবে না।
After enabling App Check, you will start seeing metrics related to OAuth requests from your client in the edit view of the OAuth client. Requests from unverified sources won't be blocked until you enforce App Check . The information in the metrics monitoring page can help you determine when to start enforcement.
You might see errors related to the App Check feature when enabling App Check for your iOS app. To fix these errors, try the following:
- Verify that the bundle ID and team ID you specified are valid.
- Verify that you are not using a wildcard for the bundle ID.
Enforce App Check for your iOS Client
Enabling App Check for your app does not automatically block unrecognized requests. To enforce this protection, go to the edit view of your iOS client. There, you will see App Check metrics to the right of the page under the Google Identity for iOS section. The metrics include the following information:- Number of verified requests - requests that have a valid App Check token. After you enable App Check enforcement, only requests in this category will succeed.
- Number of unverified requests: likely outdated client requests - requests missing an App Check token; these request may be from an older version of your app that doesn't include an App Check implementation.
- Number of unverified requests: unknown origin requests - requests missing an App Check token that don't look like they are coming from your app.
- Number of unverified requests: invalid requests - requests with an invalid App Check token, which may be from an inauthentic client attempting to impersonate your app, or from emulated environments.
To enforce App Check, click the ENFORCE button and confirm your choice. Once enforcement is active, all unverified requests from your client will be rejected.
Note : after you enable enforcement, it can take up to 15 minutes for the changes to take effect.
Unenforce App Check for your iOS Client
Unenforcing App Check for your app will stop enforcement and will allow all requests from your client to Google OAuth 2.0 endpoints, including unverified requests.
To unenforce App Check for your iOS client, navigate to the edit view of the iOS client and click the UNENFORCE button and confirm your choice.
Note : after unenforcing App Check, it can take up to 15 minutes for the changes to take effect.
Disable App Check for your iOS Client
Disabling App Check for your app will stop all App Check monitoring and enforcement . Consider unenforcing App Check instead so you can continue monitoring metrics for your client.
To disable App Check for your iOS client, navigate to the edit view of the iOS client and turn off the Protect your OAuth client from abuse with Firebase App Check toggle button.
Note : after disabling App Check, it can take up to 15 minutes for the changes to take effect.
Time-based access
Time-based access allows a user to grant your app access to their data for a limited duration to complete an action. Time-based access is available in select Google products during the consent flow, giving users the option to grant access for a limited period of time. An example is the Data Portability API which enables a one-time transfer of data.
When a user grants your application time-based access, the refresh token will expire after the specified duration. Note that refresh tokens may be invalidated earlier under specific circumstances; see these cases for details. The refresh_token_expires_in field returned in the authorization code exchange response represents the time remaining until the refresh token expires in such cases.
Further Reading
The IETF Best Current Practice OAuth 2.0 for Native Apps establishes many of the best practices documented here.
Implement Cross-Account Protection
An additional step you should take to protect your users' accounts is implementing Cross-Account Protection by utilizing Google's Cross-Account Protection Service. This service lets you subscribe to security event notifications which provide information to your application about major changes to the user account. You can then use the information to take action depending on how you decide to respond to events.
Some examples of the event types sent to your app by Google's Cross-Account Protection Service are:
-
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
See the Protect user accounts with Cross-Account Protection page for more information on how to implement Cross Account Protection and for the full list of available events.