iOS ও ডেস্কটপ অ্যাপের জন্য OAuth 2.0

মনে রাখবেন: আপনি OAuth 2.0-এর ব্যাপারে নতুন হলে, শুরু করার আগে OAuth 2.0 ওভারভিউ পড়ে নেওয়ার সাজেশন আমরা দিই। ওভারভিউতে Google-এর মাধ্যমে কাজ করে এমন OAuth 2.0 ফ্লোর সারসংক্ষেপ দেওয়া আছে, যা আপনার অ্যাপ্লিকেশনের জন্য সঠিক ফ্লো বেছে নিয়েছেন কিনা তা নিশ্চিত করতে সাহায্য করতে পারে।

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

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

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

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

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

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

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

পূর্বশর্ত

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

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

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

1. Google API Console-এ API লাইব্রেরি খুলুন।
2. প্রম্পট করা হলে, কোনও প্রোজেক্ট বেছে নিন অথবা নতুন একটি তৈরি করুন।
3. API লাইব্রেরিতে প্রোডাক্ট ফ্যামিলি ও জনপ্রিয়তার ভিত্তিতে গ্রুপ করা সব উপলভ্য API-এর তালিকা থাকে। আপনি যে API চালু করতে চান সেটি তালিকায় দেখতে না পেলে, সার্চ করে সেটি খুঁজে নিন অথবা যে প্রোডাক্ট ফ্যামিলির অন্তর্গত সেটিতে সব দেখুন বিকল্পে ক্লিক করুন।
4. আপনি যে API চালু করতে চান সেটি বেছে নিন, তারপর চালু করুন বোতামে ক্লিক করুন।
5. বলা হলে, বিলিং চালু করুন।
6. প্রম্পট করা হলে, API-এর পরিষেবার শর্তাবলী পড়ে তাতে সম্মতি দিন।

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

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

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

iOS

1. iOS অ্যাপ্লিকেশনের ধরন বেছে নিন।
2. OAuth ক্লায়েন্টের নাম লিখুন। ক্লায়েন্টকে শনাক্ত করার জন্য এই নাম আপনার প্রজেক্টের ক্লায়েন্ট পৃষ্ঠায় দেখানো হয়।
3. আপনার অ্যাপের বান্ডিল শনাক্তকারী লিখুন। বান্ডিল আইডি হল আপনার অ্যাপের তথ্য প্রপার্টি তালিকা রিসোর্স ফাইলের (info.plist) CFBundleIdentifier কী-এর ভ্যালু। ভ্যালু সাধারণত Xcode প্রজেক্ট এডিটরের সাধারণ প্যানেল বা সাইনিং ও ক্যাপাবিলিটি প্যানেলে দেখানো হয়। এছাড়াও, বান্ডেল আইডিটি Apple-এর App Store Connect সাইটে অ্যাপের তথ্য পৃষ্ঠার সাধারণ তথ্য বিভাগে দেখানো হয়।

   আপনার অ্যাপের জন্য সঠিক বান্ডেল আইডি ব্যবহার করছেন কিনা তা কনফার্ম করুন, কারণ আপনি App Check ফিচার ব্যবহার করলে এটি পরিবর্তন করতে পারবেন না।

4. (ঐচ্ছিক)

   অ্যাপটি 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

5. (ঐচ্ছিক)

   আপনার টিম আইডি লিখুন। আরও তথ্যের জন্য Apple Developer অ্যাকাউন্ট ডকুমেন্টেশনে আপনার টিম আইডি খুঁজে দেখুন ।

   মনে রাখবেন: আপনার ক্লায়েন্টের জন্য App Check চালু করলে, টিম আইডি ফিল্ড পূরণ করতে হবে।
6. (ঐচ্ছিক)

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

7. তৈরি করুন বিকল্পে ক্লিক করুন।

UWP

1. ইউনিভার্সাল উইন্ডোজ প্ল্যাটফর্ম অ্যাপ্লিকেশন ধরন বেছে নিন।
2. OAuth ক্লায়েন্টের নাম লিখুন। ক্লায়েন্টকে শনাক্ত করতে আপনার প্রোজেক্টের নাম দেখানো হয়।
3. আপনার অ্যাপের ১২-অক্ষরের Microsoft Store আইডি লিখুন। আপনি এই ভ্যালু Microsoft পার্টনার সেন্টার-এ অ্যাপ ম্যানেজমেন্ট বিভাগের অ্যাপ আইডেন্টিটি পৃষ্ঠায় খুঁজে পাবেন।
4. তৈরি করুন বিকল্পে ক্লিক করুন।

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 অনুমোদন প্রয়োগ করা শুরু করার আগে, আমরা সাজেস্ট করি যে আপনার অ্যাপকে অ্যাক্সেস করার জন্য যেসব স্কোপের অনুমতি নিতে হবে সেগুলি শনাক্ত করুন।

মনে রাখবেন: ইনস্টল করা অ্যাপ বা ডিভাইসের ক্ষেত্রে ইনক্রিমেন্টাল অথরাইজেশন কাজ করে না।

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-এর থেকে আলাদা। মনে রাখবেন : কাস্টম URI স্কিমগুলি Android এবং Chrome অ্যাপে আর কাজ করে না। কাস্টম স্কিমের বিকল্প সম্পর্কে আরও জানুন। লুপব্যাক IP অ্যাড্রেস http://127.0.0.1:port অথবা http://[::1]:port প্রাসঙ্গিক লুপব্যাক IP অ্যাড্রেসের জন্য আপনার প্ল্যাটফর্মে কোয়েরি করুন এবং উপলভ্য র‍্যান্ডম পোর্টে HTTP লিসনার শুরু করুন। আপনার অ্যাপ যে আসল পোর্ট নম্বরে শোনে সেটি দিয়ে port পরিবর্তন করুন। মনে রাখবেন, মোবাইল অ্যাপে লুপব্যাক IP অ্যাড্রেস রিডাইরেক্ট বিকল্পের জন্য সহায়তা বন্ধ করে দেওয়া হয়েছে।
response_type	আবশ্যক Google OAuth 2.0 এন্ডপয়েন্ট অনুমোদন কোড রিটার্ন করে কিনা তা নির্ধারণ করে। ইনস্টল করা অ্যাপ্লিকেশনের জন্য প্যারামিটার ভ্যালু code হিসেবে সেট করুন।
scope	আবশ্যক একটি স্পেস-ডিলিমিটেড স্কোপের তালিকা যা সেইসব রিসোর্সকে শনাক্ত করে যেগুলি আপনার অ্যাপ্লিকেশন ব্যবহারকারীর হয়ে অ্যাক্সেস করতে পারে। এইসব ভ্যালু সম্মতি সংক্রান্ত স্ক্রিনকে জানায় যে Google ব্যবহারকারীকে কী দেখায়। স্কোপ আপনার অ্যাপ্লিকেশনকে শুধুমাত্র প্রয়োজনীয় রিসোর্স অ্যাক্সেস করার অনুরোধ করতে দেয় এবং ব্যবহারকারীদের আপনার অ্যাপ্লিকেশনকে দেওয়া অ্যাক্সেসের পরিমাণ নিয়ন্ত্রণ করতে দেয়। তাই, অনুরোধ করা স্কোপের সংখ্যা এবং ব্যবহারকারীর সম্মতি পাওয়ার সম্ভাবনার মধ্যে বিপরীত সম্পর্ক রয়েছে।
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-এর নমুনা দেখায়।

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

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

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 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=email%20profile&
 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 সাইন-ইন বা OpenID Foundation-এর iOS-এর জন্য AppAuth।

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

org_internal

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

deleted_client

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

invalid_grant

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

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

redirect_uri_mismatch

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

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

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

invalid_request

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

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

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

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

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

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

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

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

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

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

নিম্নলিখিত স্নিপেট একটি নমুনা অনুরোধ দেখায়:

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

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

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

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

1. EC P-256 কী পেয়ার জেনারেট করুন:

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

2. 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"
     }
   }

3. 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".
4. প্রমাণে স্বাক্ষর করুন:

   এনকোড করা হেডার ও পেলোডকে একটি ফুলস্টপ (.) দিয়ে কনক্যাটেনেট করুন, তারপর ES256 ব্যবহার করে আপনার প্রাইভেট কী দিয়ে ফলাফল সাইন করুন। মনে রাখবেন, JWS -এর জন্য স্বাক্ষরকে র R | S কনক্যাটেনেটেড ফর্ম্যাটে (P-256-এর জন্য ৬৪ বাইট) থাকতে হবে। সরাসরি OpenSSL ব্যবহার করলে, আপনাকে অবশ্যই ডিফল্ট ASN.1 DER-এনকোডেড সিগনেচারকে এই র ফর্ম্যাটে কনভার্ট করতে হবে।

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

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

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

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

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

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

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

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

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

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

মনে রাখবেন: আপনার অ্যাপ্লিকেশনকে উত্তরে অন্তর্ভুক্ত যেকোনও শনাক্ত না করা ফিল্ড এড়িয়ে যেতে হবে।

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

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

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

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

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

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

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

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

Google API কল করুন

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

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

HTTP GET-এর উদাহরণ

Authorization: Bearer HTTP হেডার ব্যবহার করে drive.files এন্ডপয়েন্টে (Drive Files API) কল করলে তা নিম্নলিখিত উদাহরণের মতো দেখতে হতে পারে। মনে রাখবেন যে আপনাকে নিজের অ্যাক্সেস টোকেন উল্লেখ করতে হবে:

GET /drive/v2/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

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

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

curlটি উদাহরণ

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

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

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

curl https://www.googleapis.com/drive/v2/files?access_token=access_token

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

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

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

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

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

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

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

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

client_id=your_client_id&
refresh_token=refresh_token&
grant_type=refresh_token

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

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

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

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

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

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

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

টোকেন তুলে নেওয়া

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

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

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

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

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

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

গুরুত্বপূর্ণ পয়েন্ট: প্রত্যাহার করার ফলে কোনও প্রোজেক্টে আগে মঞ্জুর করা সমস্ত OAuth 2.0 স্কোপ সরিয়ে দেওয়া হয়, যার ফলে সেই প্রোজেক্টের অধীনে রেজিস্টার করা সমস্ত ক্লায়েন্টের জন্য ইস্যু করা যেকোনও অ্যাক্সেস বা রিফ্রেশ টোকেন বাতিল হয়ে যায়।

মনে রাখবেন: প্রত্যাহার করার অনুরোধের উত্তর পাওয়ার পরে, প্রত্যাহার করার প্রক্রিয়া সম্পূর্ণ হতে কিছুটা সময় লাগতে পারে।

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

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

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

গুরুত্বপূর্ণ: অ্যাপ ছদ্মবেশীতা সংক্রান্ত ঝুঁকির কারণে কাস্টম URI স্কিমগুলি আর কাজ করে না।

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

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

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

গুরুত্বপূর্ণ: লুপব্যাক IP অ্যাড্রেস রিডাইরেক্ট বিকল্পটি Android, Chrome অ্যাপ এবং iOS OAuth ক্লায়েন্ট টাইপের জন্য আর কাজ করে না। কাজ করে এমন বিকল্পে কীভাবে মাইগ্রেট করবেন সেই সংক্রান্ত নির্দেশাবলীর জন্য লুপব্যাক IP অ্যাড্রেস মাইগ্রেশন গাইড পর্যালোচনা করুন।

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

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

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

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

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

গুরুত্বপূর্ণ: ম্যানুয়াল কপি/পেস্ট বিকল্প, যাকে আউট-অফ-ব্যান্ড (OOB) রিডাইরেক্ট পদ্ধতিও বলা হয়, সেটি আর কাজ করে না। নিরাপদ বিকল্পে কীভাবে মাইগ্রেট করবেন সেই সংক্রান্ত নির্দেশাবলীর জন্য OOB মাইগ্রেশন গাইড পর্যালোচনা করুন।

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

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

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

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

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

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

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

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

যাচাইকরণ সম্পূর্ণ না হলে, নিম্নলিখিত ধাপগুলি অনুসরণ করুন:

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

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

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

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

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

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

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

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

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

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

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

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

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

• যাচাই করা অনুরোধের সংখ্যা - যেসব অনুরোধে সঠিক 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 এনফোর্স না করার কথা বিবেচনা করুন, যাতে আপনি ক্লায়েন্টের জন্য মেট্রিক মনিটর করা চালিয়ে যেতে পারেন।

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

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

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

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

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

আরও পড়ুন

IETF-এর বর্তমান সেরা পদ্ধতি নেটিভ অ্যাপের জন্য OAuth 2.0 এখানে উল্লেখ করা অনেক সেরা পদ্ধতি প্রতিষ্ঠা করে।

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

আপনার ব্যবহারকারীদের অ্যাকাউন্ট সুরক্ষিত রাখতে, আপনাকে যে অতিরিক্ত পদক্ষেপ নিতে হবে তা হল 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

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