এই ডকুমেন্টটিতে ব্যাখ্যা করা হয়েছে যে, ফোন, ট্যাবলেট এবং কম্পিউটারের মতো ডিভাইসে ইনস্টল করা অ্যাপ্লিকেশনগুলি কীভাবে ইউটিউব ডেটা এপিআই-তে অ্যাক্সেস অনুমোদন করার জন্য গুগলের OAuth 2.0 এন্ডপয়েন্টগুলি ব্যবহার করে।
OAuth 2.0 ব্যবহারকারীদের ইউজারনেম, পাসওয়ার্ড এবং অন্যান্য তথ্য গোপন রেখে কোনো অ্যাপ্লিকেশনের সাথে নির্দিষ্ট ডেটা শেয়ার করার সুযোগ দেয়। উদাহরণস্বরূপ, কোনো অ্যাপ্লিকেশন একজন ব্যবহারকারীর ইউটিউব চ্যানেলে ভিডিও আপলোড করার অনুমতি পেতে OAuth 2.0 ব্যবহার করতে পারে।
ইনস্টল করা অ্যাপগুলো আলাদা আলাদা ডিভাইসে বিতরণ করা হয় এবং ধরে নেওয়া হয় যে এই অ্যাপগুলো গোপনীয় তথ্য রক্ষা করতে পারে না। ব্যবহারকারী অ্যাপটিতে উপস্থিত থাকা অবস্থায় অথবা অ্যাপটি ব্যাকগ্রাউন্ডে চলার সময়েও এগুলো গুগল এপিআই (Google API) অ্যাক্সেস করতে পারে।
এই অনুমোদন প্রক্রিয়াটি ওয়েব সার্ভার অ্যাপ্লিকেশনগুলির জন্য ব্যবহৃত প্রক্রিয়ার অনুরূপ। প্রধান পার্থক্য হলো, ইনস্টল করা অ্যাপগুলিকে অবশ্যই সিস্টেম ব্রাউজার খুলতে হবে এবং গুগলের অনুমোদন সার্ভার থেকে আসা প্রতিক্রিয়াগুলি পরিচালনা করার জন্য একটি স্থানীয় রিডাইরেক্ট ইউআরআই সরবরাহ করতে হবে।
লাইব্রেরি এবং নমুনা
iOS অ্যাপের জন্য আমরা ‘Sign In With Google iOS SDK’- এর সর্বশেষ সংস্করণটি ব্যবহার করার পরামর্শ দিই। এই SDK ব্যবহারকারীর অনুমোদন পরিচালনা করে এবং এই নির্দেশিকায় বর্ণিত নিম্ন-স্তরের প্রোটোকলের চেয়ে এটি প্রয়োগ করা সহজতর।
যেসব ডিভাইসে সিস্টেম ব্রাউজার সাপোর্ট করে না অথবা যেগুলোর ইনপুট ক্ষমতা সীমিত, যেমন টিভি, গেম কনসোল, ক্যামেরা বা প্রিন্টার, সেগুলোতে চালিত অ্যাপের জন্য ‘টিভি ও ডিভাইসের জন্য OAuth 2.0’ অথবা ‘টিভি এবং সীমিত ইনপুট ডিভাইসে সাইন-ইন’ দেখুন।
পূর্বশর্ত
আপনার প্রোজেক্টের জন্য এপিআই (API) সক্রিয় করুন
যে কোনো অ্যাপ্লিকেশন যা গুগল এপিআই কল করে, তাকে এপিআই কনসোলে সেই এপিআইগুলো সক্রিয় করতে হবে।
আপনার প্রোজেক্টের জন্য একটি API সক্রিয় করতে:
- গুগল এপিআই কনসোলে এপিআই লাইব্রেরিটি খুলুন ।
- অনুরোধ করা হলে, একটি প্রজেক্ট নির্বাচন করুন অথবা নতুন একটি তৈরি করুন।
- লাইব্রেরি পৃষ্ঠা ব্যবহার করে ইউটিউব ডেটা এপিআই (YouTube Data 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 অথরাইজেশন প্রয়োগ করা শুরু করার আগে, আমরা আপনাকে সেই স্কোপগুলি চিহ্নিত করার পরামর্শ দিই যেগুলিতে আপনার অ্যাপের অ্যাক্সেসের জন্য অনুমতির প্রয়োজন হবে।
ইউটিউব ডেটা এপিআই 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 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 | প্রয়োজনীয় স্পেস দিয়ে আলাদা করা স্কোপগুলোর একটি তালিকা, যা সেই রিসোর্সগুলোকে শনাক্ত করে যেগুলো আপনার অ্যাপ্লিকেশন ব্যবহারকারীর পক্ষ থেকে অ্যাক্সেস করতে পারে। এই মানগুলো গুগল কর্তৃক ব্যবহারকারীকে দেখানো সম্মতি স্ক্রিনটিকে তথ্যসমৃদ্ধ করে। স্কোপ আপনার অ্যাপ্লিকেশনকে শুধুমাত্র প্রয়োজনীয় রিসোর্সগুলিতে অ্যাক্সেসের অনুরোধ করার সুযোগ দেয় এবং একই সাথে ব্যবহারকারীদেরকে আপনার অ্যাপ্লিকেশনকে দেওয়া অ্যাক্সেসের পরিমাণ নিয়ন্ত্রণ করতে সক্ষম করে। সুতরাং, অনুরোধ করা স্কোপের সংখ্যা এবং ব্যবহারকারীর সম্মতি পাওয়ার সম্ভাবনার মধ্যে একটি বিপরীত সম্পর্ক রয়েছে। ইউটিউব ডেটা এপিআই v3 নিম্নলিখিত স্কোপগুলি ব্যবহার করে:
OAuth 2.0 API Scopes ডকুমেন্টটিতে সেই সমস্ত স্কোপের একটি সম্পূর্ণ তালিকা দেওয়া আছে যা আপনি গুগল এপিআই অ্যাক্সেস করতে ব্যবহার করতে পারেন। | ||||||||||||||||
code_challenge | সুপারিশকৃত একটি এনকোডেড | ||||||||||||||||
code_challenge_method | সুপারিশকৃত অনুমোদন কোড বিনিময়ের সময় ব্যবহৃত হবে এমন একটি | ||||||||||||||||
state | সুপারিশকৃত এটি এমন যেকোনো স্ট্রিং ভ্যালু নির্দিষ্ট করে যা আপনার অ্যাপ্লিকেশনটি আপনার অথরাইজেশন রিকোয়েস্ট এবং অথরাইজেশন সার্ভারের রেসপন্সের মধ্যবর্তী অবস্থা (state) বজায় রাখতে ব্যবহার করে। ব্যবহারকারী আপনার অ্যাপ্লিকেশনের অ্যাক্সেস রিকোয়েস্টে সম্মতি বা অস্বীকৃতি জানানোর পর, সার্ভারটি আপনি এই প্যারামিটারটি বিভিন্ন উদ্দেশ্যে ব্যবহার করতে পারেন, যেমন ব্যবহারকারীকে আপনার অ্যাপ্লিকেশনের সঠিক রিসোর্সে নির্দেশ করা, ননস (nonce) পাঠানো এবং ক্রস-সাইট রিকোয়েস্ট ফোরজারি প্রতিরোধ করা। যেহেতু আপনার | ||||||||||||||||
login_hint | ঐচ্ছিক আপনার অ্যাপ্লিকেশনটি যদি জানে কোন ব্যবহারকারী প্রমাণীকরণের চেষ্টা করছেন, তবে এটি গুগল অথেনটিকেশন সার্ভারকে একটি ইঙ্গিত দেওয়ার জন্য এই প্যারামিটারটি ব্যবহার করতে পারে। সার্ভারটি এই ইঙ্গিত ব্যবহার করে সাইন-ইন ফর্মের ইমেল ফিল্ডটি আগে থেকে পূরণ করে অথবা উপযুক্ত মাল্টি-লগইন সেশনটি নির্বাচন করে লগইন প্রক্রিয়াকে সহজ করে তোলে। প্যারামিটারের মান হিসেবে একটি ইমেল অ্যাড্রেস বা | ||||||||||||||||
নমুনা অনুমোদন ইউআরএল
নিচের ট্যাবগুলোতে বিভিন্ন রিডাইরেক্ট ইউআরআই অপশনের জন্য নমুনা অথরাইজেশন ইউআরএল দেখানো হয়েছে।
প্রতিটি ইউআরএল এমন একটি স্কোপে অ্যাক্সেসের অনুরোধ করে, যা ব্যবহারকারীর ইউটিউব অ্যাকাউন্ট দেখার অনুমতি দেয়। 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%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
লুপব্যাক আইপি ঠিকানা
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
ধাপ ৩: গুগল ব্যবহারকারীর কাছে সম্মতি চায়
এই ধাপে, ব্যবহারকারী আপনার অ্যাপ্লিকেশনকে অনুরোধ করা অ্যাক্সেস দেবেন কিনা, সেই সিদ্ধান্ত নেন। এই পর্যায়ে, গুগল একটি সম্মতি উইন্ডো প্রদর্শন করে, যেখানে আপনার অ্যাপ্লিকেশনের নাম, ব্যবহারকারীর অনুমোদন ক্রেডেনশিয়াল ব্যবহার করে যে গুগল এপিআই পরিষেবাগুলিতে অ্যাক্সেসের অনুমতি চাওয়া হচ্ছে তার নাম এবং যে অ্যাক্সেসের পরিধিগুলো মঞ্জুর করা হবে তার একটি সারসংক্ষেপ দেখানো হয়। এরপর ব্যবহারকারী আপনার অ্যাপ্লিকেশনের অনুরোধ করা এক বা একাধিক পরিধিতে অ্যাক্সেস মঞ্জুর করতে সম্মতি দিতে পারেন অথবা অনুরোধটি প্রত্যাখ্যান করতে পারেন।
এই পর্যায়ে আপনার অ্যাপ্লিকেশনের কিছু করার প্রয়োজন নেই, কারণ এটি গুগলের 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-গুলোর মধ্যে একটি। |
যদিও DPoP-এর ব্যবহার ঐচ্ছিক, বর্ধিত নিরাপত্তার জন্য এটি সুপারিশ করা হয়। DPoP-এর নিরাপত্তা নির্ভর করে প্রাইভেট কী-টি একটিমাত্র ডিভাইসে সীমাবদ্ধ থাকার উপর; আমরা এটিকে এমনভাবে সংরক্ষণ করার সুপারিশ করি যাতে এটি ডিভাইস থেকে বাইরে কপি করা না যায়, উদাহরণস্বরূপ TPM, Secure Enclave, বা অন্যান্য হার্ডওয়্যার-সমর্থিত কীস্টোর ব্যবহার করে। 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) পেয়ে থাকেন, তবে আপনাকে অবশ্যই সেই ননস মানটি একটি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 nonce-এর প্রয়োজন হয়, যেমন একটি রিফ্রেশ টোকেন এক্সচেঞ্জের সময়, এবং DPoP প্রুফে কোনো nonce ক্লেইম অনুপস্থিত থাকে, অথবা nonce-এর মান সার্ভারের কাছে অগ্রহণযোগ্য হয় (যেমন, এটি মেয়াদোত্তীর্ণ, ইতিমধ্যে ব্যবহৃত, বা ভুল), তাহলে Google একটি use_dpop_nonce এরর কোডের সাথে একটি DPoP-Nonce HTTP হেডার রিটার্ন করে, যাতে একটি নতুন nonce থাকে যা আপনি পরবর্তী অনুরোধে ব্যবহার করতে পারেন। অন্যান্য ব্যর্থতার ক্ষেত্রে invalid_grant রিটার্ন হতে পারে।
এই অনুরোধের জবাবে গুগল একটি JSON অবজেক্ট ফেরত পাঠায়, যেটিতে একটি স্বল্পস্থায়ী অ্যাক্সেস টোকেন এবং একটি রিফ্রেশ টোকেন থাকে।
প্রতিক্রিয়াটিতে নিম্নলিখিত ক্ষেত্রগুলি রয়েছে:
| ক্ষেত্র | |
|---|---|
access_token | যে টোকেনটি আপনার অ্যাপ্লিকেশন একটি গুগল এপিআই অনুরোধ অনুমোদন করার জন্য পাঠায়। |
expires_in | অ্যাক্সেস টোকেনটির অবশিষ্ট মেয়াদ সেকেন্ডে। |
id_token | দ্রষ্টব্য: এই প্রপার্টিটি শুধুমাত্র তখনই ফেরত দেওয়া হয়, যদি আপনার অনুরোধে openid , profile , বা email মতো কোনো আইডেন্টিটি স্কোপ অন্তর্ভুক্ত থাকে। এর ভ্যালুটি হলো একটি JSON Web Token (JWT), যাতে ব্যবহারকারীর ডিজিটালভাবে স্বাক্ষরিত পরিচয় সংক্রান্ত তথ্য থাকে। |
refresh_token | একটি টোকেন যা ব্যবহার করে আপনি একটি নতুন অ্যাক্সেস টোকেন পেতে পারেন। রিফ্রেশ টোকেন ততক্ষণ পর্যন্ত বৈধ থাকে যতক্ষণ না ব্যবহারকারী অ্যাক্সেস প্রত্যাহার করে নেয় অথবা টোকেনটির মেয়াদ শেষ হয়ে যায়। যদি DPoP ব্যবহার করা হয়ে থাকে, তবে রিফ্রেশ টোকেনটি DPoP প্রুফে স্বাক্ষর করতে ব্যবহৃত প্রাইভেট কী-এর সাথে সংযুক্ত থাকে। মনে রাখবেন যে, ইনস্টল করা অ্যাপ্লিকেশনগুলির জন্য সর্বদা রিফ্রেশ টোকেন ফেরত দেওয়া হয়। |
refresh_token_expires_in | রিফ্রেশ টোকেনের অবশিষ্ট মেয়াদ সেকেন্ডে। এই মানটি শুধুমাত্র তখনই সেট করা হয় যখন ব্যবহারকারী সময়-ভিত্তিক অ্যাক্সেসের অনুমতি দেন। |
scope | access_token দ্বারা প্রদত্ত অ্যাক্সেসের পরিধি, যা স্পেস দ্বারা বিভক্ত এবং কেস-সেনসিটিভ স্ট্রিং-এর একটি তালিকা হিসাবে প্রকাশ করা হয়। |
token_type | ফেরত আসা টোকেনের ধরন। DPoP ব্যবহার করা হলেও এই মান সর্বদা Bearer হয়। |
নিম্নলিখিত কোড স্নিপেটটি 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"
}ধাপ ৬: ব্যবহারকারীরা কোন কোন স্কোপ মঞ্জুর করেছেন তা যাচাই করুন
একাধিক অনুমতি (স্কোপ) অনুরোধ করার সময়, ব্যবহারকারীরা আপনার অ্যাপকে সেগুলোর সবগুলোতে অ্যাক্সেস নাও দিতে পারেন। আপনার অ্যাপকে অবশ্যই যাচাই করতে হবে যে কোন স্কোপগুলো আসলে মঞ্জুর করা হয়েছে এবং কিছু অনুমতি প্রত্যাখ্যান করা হলে পরিস্থিতিটি সুষ্ঠুভাবে সামাল দিতে হবে; সাধারণত, সেই প্রত্যাখ্যান করা স্কোপগুলোর উপর নির্ভরশীল ফিচারগুলোকে নিষ্ক্রিয় করার মাধ্যমে এটি করা হয়।
তবে, এর ব্যতিক্রমও আছে। যেসব গুগল ওয়ার্কস্পেস এন্টারপ্রাইজ অ্যাপে ডোমেন-ব্যাপী কর্তৃত্ব অর্পণ করা আছে, অথবা যেগুলোকে 'বিশ্বস্ত' (Trusted) হিসেবে চিহ্নিত করা হয়েছে, সেগুলো সুনির্দিষ্ট অনুমতির সম্মতি স্ক্রিনটি এড়িয়ে যায়। এই অ্যাপগুলোর ক্ষেত্রে, ব্যবহারকারীরা সুনির্দিষ্ট অনুমতির সম্মতি স্ক্রিনটি দেখতে পাবেন না। এর পরিবর্তে, আপনার অ্যাপটি অনুরোধ করা সমস্ত স্কোপ পাবে অথবা কোনোটিই পাবে না।
আরও বিস্তারিত তথ্যের জন্য, কীভাবে সূক্ষ্ম অনুমতি পরিচালনা করতে হয় তা দেখুন।
ব্যবহারকারী আপনার অ্যাপ্লিকেশনকে কোনো নির্দিষ্ট স্কোপে অ্যাক্সেস দিয়েছেন কিনা তা যাচাই করতে, অ্যাক্সেস টোকেন রেসপন্সের scope ফিল্ডটি পরীক্ষা করুন। অ্যাক্সেস_টোকেন দ্বারা প্রদত্ত অ্যাক্সেসের স্কোপগুলো স্পেস দ্বারা বিভক্ত এবং কেস-সেনসিটিভ স্ট্রিংয়ের একটি তালিকা হিসাবে প্রকাশ করা হয়।
উদাহরণস্বরূপ, নিম্নলিখিত নমুনা অ্যাক্সেস টোকেন প্রতিক্রিয়াটি নির্দেশ করে যে ব্যবহারকারী আপনার অ্যাপ্লিকেশনকে তার ইউটিউব ভিডিও, রেটিং, মন্তব্য এবং ক্যাপশন দেখতে, সম্পাদনা করতে এবং স্থায়ীভাবে মুছে ফেলার অনুমতি দিয়েছেন:
{ "access_token": "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in": 3920, "token_type": "Bearer", "scope": "https://www.googleapis.com/auth/youtube.force-ssl", "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI" }
গুগল এপিআই কল করুন
আপনার অ্যাপ্লিকেশন একটি অ্যাক্সেস টোকেন পাওয়ার পর, যদি এপিআই-এর জন্য প্রয়োজনীয় অ্যাক্সেসের সুযোগ(গুলি) মঞ্জুর করা হয়ে থাকে, তবে আপনি একটি নির্দিষ্ট ব্যবহারকারী অ্যাকাউন্টের পক্ষ থেকে একটি গুগল এপিআই-তে কল করার জন্য টোকেনটি ব্যবহার করতে পারেন। এটি করার জন্য, এপিআই-তে করা অনুরোধে একটি access_token কোয়েরি প্যারামিটার অথবা একটি Authorization HTTP হেডার Bearer ভ্যালু অন্তর্ভুক্ত করে অ্যাক্সেস টোকেনটি যোগ করুন। যখন সম্ভব, HTTP হেডার ব্যবহার করা শ্রেয়, কারণ কোয়েরি স্ট্রিংগুলো সার্ভার লগে দৃশ্যমান হওয়ার প্রবণতা থাকে। বেশিরভাগ ক্ষেত্রে আপনি গুগল এপিআই-তে আপনার কলগুলো সেট আপ করার জন্য একটি ক্লায়েন্ট লাইব্রেরি ব্যবহার করতে পারেন (উদাহরণস্বরূপ, ইউটিউব ডেটা এপিআই-তে কল করার সময়)।
উল্লেখ্য যে, ইউটিউব ডেটা এপিআই শুধুমাত্র সেইসব ইউটিউব কন্টেন্ট মালিকদের সার্ভিস অ্যাকাউন্ট সমর্থন করে, যারা একাধিক ইউটিউব চ্যানেলের মালিক ও পরিচালক, যেমন রেকর্ড লেবেল এবং মুভি স্টুডিও।
আপনি OAuth 2.0 প্লেগ্রাউন্ডে সমস্ত গুগল এপিআই ব্যবহার করে দেখতে এবং সেগুলোর পরিধি দেখতে পারেন।
HTTP GET উদাহরণ
Authorization: Bearer HTTP হেডার ব্যবহার করে youtube.channels এন্ডপয়েন্টে (ইউটিউব ডেটা এপিআই) করা একটি কল নিচের মতো দেখতে হতে পারে। মনে রাখবেন, আপনাকে আপনার নিজস্ব অ্যাক্সেস টোকেন উল্লেখ করতে হবে:
GET /youtube/v3/channels?part=snippet&mine=true HTTP/1.1 Host: www.googleapis.com Authorization: Bearer access_token
এখানে access_token কোয়েরি স্ট্রিং প্যারামিটার ব্যবহার করে প্রমাণীকৃত ব্যবহারকারীর জন্য একই API-তে একটি কল দেওয়া হলো:
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 অনুরোধের জন্য অকার্যকর ক্রেডেনশিয়াল হয়ে পড়ে। যদি আপনি টোকেনটির সাথে যুক্ত স্কোপগুলিতে অফলাইন অ্যাক্সেসের অনুরোধ করে থাকেন, তবে ব্যবহারকারীর অনুমতি না চেয়েই (এমনকি ব্যবহারকারী উপস্থিত না থাকলেও) আপনি অ্যাক্সেস টোকেনটি রিফ্রেশ করতে পারেন।
অ্যাক্সেস টোকেন রিফ্রেশ করতে, আপনার অ্যাপ্লিকেশনটি গুগলের অথরাইজেশন সার্ভারে ( https://oauth2.googleapis.com/token ) একটি HTTPS POST রিকোয়েস্ট পাঠায়, যার রিকোয়েস্ট বডিতে নিম্নলিখিত প্যারামিটারগুলো অন্তর্ভুক্ত থাকে:
| নাম | মূল্য |
|---|---|
client_id | এপিআই কনসোল থেকে ক্লায়েন্ট আইডিটি পাওয়া গেছে। |
client_secret | ঐচ্ছিক এপিআই কনসোল থেকে ক্লায়েন্ট সিক্রেট পাওয়া যায়। (অ্যান্ড্রয়েড, আইওএস বা ক্রোম অ্যাপ্লিকেশন হিসেবে নিবন্ধিত ক্লায়েন্টদের অনুরোধের ক্ষেত্রে |
grant_type | OAuth 2.0 স্পেসিফিকেশনে সংজ্ঞায়িত নিয়ম অনুযায়ী, এই ফিল্ডের মান অবশ্যই refresh_token এ সেট করতে হবে। |
refresh_token | অনুমোদন কোড বিনিময়ের মাধ্যমে রিফ্রেশ টোকেনটি ফেরত এসেছে। |
যদিও DPoP-এর ব্যবহার ঐচ্ছিক, বর্ধিত নিরাপত্তার জন্য এটি সুপারিশ করা হয়। একটি রিফ্রেশ টোকেনের সাথে DPoP ব্যবহার করতে, আপনার অ্যাপ্লিকেশনকে টোকেন এন্ডপয়েন্টে প্রতিটি অনুরোধের জন্য একটি নতুন, অনন্য DPoP প্রুফ JWT তৈরি করতে হবে। এই প্রুফটি অবশ্যই সেই একই প্রাইভেট কী দিয়ে স্বাক্ষরিত হতে হবে যা প্রাথমিক অনুমোদন কোড বিনিময়ের সময় ব্যবহৃত হয়েছিল। আপনার অ্যাপ্লিকেশনটি একটি HTTP অনুরোধ হেডার হিসাবে প্রুফটি যুক্ত করে।
| হেডার | প্রয়োজনীয় | বর্ণনা |
|---|---|---|
DPoP | ঐচ্ছিক | একটি DPoP প্রুফ হলো একটি JWT যা একটি প্রাইভেট কী-এর অধিকার প্রমাণ করে। এটি একটি হেডার, কোনো প্যারামিটার নয়। যদি এটি প্রদান করা হয়, তবে ফেরত আসা টোকেনগুলো এই কী-এর সাথে আবদ্ধ হয়। প্রতিটি অনুরোধের জন্য একটি নতুন, অনন্য প্রুফ তৈরি করতে হবে এবং এতে অবশ্যই অনুরোধের সাথে মেলে এমন htm (HTTP মেথড) এবং htu (HTTP URI) ক্লেইম অন্তর্ভুক্ত থাকতে হবে। |
নিম্নলিখিত কোড স্নিপেটটি একটি নমুনা অনুরোধ দেখাচ্ছে:
POST /token HTTP/1.1 Host: oauth2.googleapis.com Content-Type: application/x-www-form-urlencoded DPoP: DPOP_PROOF_JWT client_id=your_client_id& refresh_token=refresh_token& grant_type=refresh_token
রিফ্রেশ টোকেনের সাথে DPoP ব্যবহার করতে হলে, আপনাকে অনুরোধটির জন্য একটি নতুন, অনন্য DPoP প্রুফ JWT তৈরি করতে হবে। কী পেয়ার তৈরি এবং JWT নির্মাণের ধাপে ধাপে নির্দেশাবলীর জন্য “Construct a DPoP proof” দেখুন।
একটি নতুন অ্যাক্সেস টোকেন সম্বলিত 200 OK রেসপন্স একটি সফল আদান-প্রদান নির্দেশ করে। যখন DPoP ব্যবহার করা হয়, তখন token_type হয় Bearer । একটি সফল রেসপন্স নিশ্চিত করে যে রিফ্রেশ টোকেনের জন্য DPoP প্রুফটি গৃহীত হয়েছে। Google রেসপন্সে একটি নতুন DPoP-Nonce HTTP হেডারও ফেরত দিতে পারে; যদি এটি ফেরত আসে, তবে আপনার ক্লায়েন্টকে অবশ্যই এই নন্সটি ক্যাশ করতে হবে এবং পরবর্তী অনুরোধগুলিতে DPoP প্রুফের nonce ক্লেইমে এটি অন্তর্ভুক্ত করতে হবে।
DPoP হেডার অনুপস্থিত, অবৈধ বা ভুল কী ব্যবহার করা হলে এক্সচেঞ্জ ব্যর্থ হয়। নির্দিষ্ট DPoP ত্রুটি কোড এবং ননস (nonce) পরিচালনার বিষয়ে বিস্তারিত জানতে, 'ব্যর্থ এক্সচেঞ্জ' (Failed exchange) দেখুন।
নিম্নলিখিত কোড স্নিপেটটি 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"
}মনে রাখবেন যে, ইস্যু করা রিফ্রেশ টোকেনের সংখ্যার উপর সীমাবদ্ধতা রয়েছে; প্রতিটি ক্লায়েন্ট/ব্যবহারকারী সমন্বয়ের জন্য একটি সীমা এবং সমস্ত ক্লায়েন্ট জুড়ে প্রতিটি ব্যবহারকারীর জন্য আরেকটি সীমা রয়েছে। আপনার রিফ্রেশ টোকেনগুলো দীর্ঘমেয়াদী স্টোরেজে সংরক্ষণ করা উচিত এবং যতক্ষণ সেগুলো বৈধ থাকে, ততক্ষণ ব্যবহার করা চালিয়ে যাওয়া উচিত। যদি আপনার অ্যাপ্লিকেশন খুব বেশি রিফ্রেশ টোকেনের জন্য অনুরোধ করে, তবে এটি এই সীমাগুলোর সম্মুখীন হতে পারে, সেক্ষেত্রে পুরোনো রিফ্রেশ টোকেনগুলো কাজ করা বন্ধ করে দেবে।
টোকেন প্রত্যাহার
কিছু ক্ষেত্রে একজন ব্যবহারকারী কোনো অ্যাপ্লিকেশনকে দেওয়া অ্যাক্সেস প্রত্যাহার করতে চাইতে পারেন। ব্যবহারকারী অ্যাকাউন্ট সেটিংস-এ গিয়ে অ্যাক্সেস প্রত্যাহার করতে পারেন। আরও তথ্যের জন্য, আপনার অ্যাকাউন্টে অ্যাক্সেস থাকা তৃতীয় পক্ষের সাইট ও অ্যাপস সম্পর্কিত সাপোর্ট ডকুমেন্টের ‘সাইট বা অ্যাপের অ্যাক্সেস সরান’ অংশটি দেখুন।
It is also possible for an application to programmatically revoke the access given to it. Programmatic revocation is important in instances where a user unsubscribes, removes an application, or the API resources required by an app have significantly changed. In other words, part of the removal process can include an API request to ensure the permissions previously granted to the application are removed.
To programmatically revoke a token, your application makes a request to https://oauth2.googleapis.com/revoke and includes the token as a parameter:
curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
https://oauth2.googleapis.com/revoke?token={token}The token can be an access token or a refresh token. If the token is an access token and it has a corresponding refresh token, the refresh token will also be revoked.
If the revocation is successfully processed, then the HTTP status code of the response is 200 . For error conditions, an HTTP status code 400 is returned along with an error code.
App redirect methods
Custom URI scheme
Custom URI schemes are a form of deeplinking that use a custom-defined scheme to open your app.
Alternative to using custom URI schemes on Chrome apps
Use the Chrome Identity API which delivers the OAuth 2.0 response directly to your app, eliminating the need for a redirect URI.
Loopback IP address (macOS, Linux, Windows desktop)
To receive the authorization code using this URL, your application must be listening on the local web server. That is possible on many, but not all, platforms. However, if your platform supports it, this is the recommended mechanism for obtaining the authorization code.
When your app receives the authorization response, for best usability it should respond by displaying an HTML page that instructs the user to close the browser and return to your app.
| Recommended usage | macOS, Linux, and Windows desktop (but not Universal Windows Platform) apps |
| Form values | Set the application type to Desktop app . |
Manual copy/paste (Deprecated)
Protect your apps
Verify app ownership for Chrome
You can verify ownership of your application to reduce the risk of app impersonation.
To complete the verification process, you would use your Chrome Web Store Developer account. The following requirements must be met for a successful verification:
- You must have a registered item in the Chrome Web Store Developer Dashboard with the same item ID as the Chrome Extension OAuth client you are completing the verification for.
- You must be a publisher for the Chrome Web Store item. Learn more about access management in the Chrome Web Store Developer Dashboard.
In the Verify App Ownership section of the Chrome Extension client, click the Verify Ownership button to complete the verification process.
Note: Wait a few minutes before completing the verification process after granting access to your account.
If the verification is successful, a notification will be displayed to confirm the success of the verification process. Otherwise, an error prompt will be shown.
To fix a failed verification, try the following:
- Make sure there is a registered item in the Chrome Web Store Developer Dashboard with the same item ID as the Chrome Extension OAuth client you are completing the verification for.
- Make sure you are a publisher for the app, that is, you must either be the individual publisher of the app or a member of the group publisher of the app. Learn more about access management in the Chrome Web Store Developer Dashboard.
- If you just updated your group publisher list, verify that the group publisher membership list is synced in the Chrome Web Store Developer Dashboard. Learn more about syncing your publisher membership list.
App Check (iOS only)
The App Check feature helps safeguard your iOS applications from unauthorized usage by using Apple's App Attest service to verify that requests made to Google OAuth 2.0 endpoints originate from your authentic applications. This helps to reduce the risk of app impersonation.
Enable App Check for your iOS Client
The following requirements must be met to successfully enable App Check for your iOS client:- You must specify a team ID for your iOS client.
- You must not use a wildcard in your bundle ID since it can resolve to more than one app. This means that the bundle ID must not include the asterisk (*) symbol.
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.
আরও পড়ুন
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.