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

এই ডকুমেন্ট থেকে জানা যায় যে কীভাবে ডেস্কটপ অ্যাপ্লিকেশন (যেমন, Windows, macOS বা Linux-এ চলা অ্যাপ্লিকেশন অথবা কমান্ড-লাইন ইন্টারফেস (CLI) টুল) Google API-তে অ্যাক্সেস অনুমোদন করার জন্য Google-এর OAuth 2.0 এন্ডপয়েন্ট ব্যবহার করে।

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

ডেস্কটপ অ্যাপ্লিকেশন ব্যবহারকারীর মেশিনে লোকালি ইনস্টল করা হয় (যেমন স্ট্যান্ডঅ্যালোন ডেস্কটপ সফ্টওয়্যার, ডেভেলপার CLI টুল, ব্যাকগ্রাউন্ড সিঙ্ক ইউটিলিটি বা স্ক্রিপ্ট)। এইসব অ্যাপ যেহেতু আলাদা আলাদা ডিভাইসে ডিস্ট্রিবিউট করা হয়, তাই ধরে নেওয়া হয় যে এইসব অ্যাপ কোনও তথ্য গোপন রাখতে পারে না (এগুলি পাবলিক ক্লায়েন্ট)। ব্যবহারকারী অ্যাপের সাথে অ্যাক্টিভভাবে ইন্টার‍্যাক্ট করার সময় অথবা অ্যাপ ব্যাকগ্রাউন্ডে চলার সময় তারা Google API অ্যাক্সেস করতে পারবেন।

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

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

ডেস্কটপ অ্যাপ্লিকেশনের জন্য OAuth 2.0 প্রয়োগ করার সময় আপনার প্রোগ্রামিং ল্যাঙ্গুয়েজের (যেমন, Python, Java, Node.js, Go, .NET) জন্য Google API ক্লায়েন্ট লাইব্রেরি ব্যবহার করার সাজেশন আমরা দিই। ক্লায়েন্ট লাইব্রেরি ব্যবহারকারীর অনুমোদন ও টোকেন ম্যানেজমেন্টের কাজ করে, যার ফলে লোয়ার-লেভেল HTTP/REST এন্ডপয়েন্ট সরাসরি ব্যবহার করার তুলনায় বাস্তবায়ন করা সহজ হয় এবং ভুল হওয়ার সম্ভাবনা কমে যায়।

মোবাইল অ্যাপের জন্য, Android এবং iOS অনুমোদনের গাইড দেখুন।

সিস্টেম ব্রাউজার কাজ করে না বা ইনপুট দেওয়ার সীমিত ক্ষমতা আছে এমন ডিভাইসে চলা অ্যাপের জন্য, যেমন টিভি, গেম কনসোল, ক্যামেরা বা প্রিন্টার, টিভি ও ডিভাইসের জন্য 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. ডেস্কটপ অ্যাপ অ্যাপ্লিকেশনের ধরন বেছে নিন।
  4. নাম ফিল্ডে, OAuth ক্লায়েন্টের জন্য একটি নাম লিখুন। ক্লায়েন্টকে শনাক্ত করার জন্য এই নাম আপনার প্রোজেক্টের ক্লায়েন্ট পৃষ্ঠায় দেখানো হয়।
  5. তৈরি করুন বিকল্পে ক্লিক করুন।

আপনার ক্লায়েন্ট আইডি ও ক্লায়েন্ট সিক্রেট তৈরি করা হয়েছে এবং Google Cloud কনসোলে দেখানো হয়েছে। ডেস্কটপ অ্যাপ হল পাবলিক ক্লায়েন্ট এবং এটি গোপনীয়তা বজায় রাখতে পারে না। অনুমোদন কোডের জন্য অনুরোধ করার সময় সবসময় PKCE (প্রুফ কী ফর কোড এক্সচেঞ্জ) ব্যবহার করুন।

অ্যাক্সেস স্কোপ শনাক্ত করা

স্কোপ আপনার অ্যাপ্লিকেশনকে শুধুমাত্র প্রয়োজনীয় রিসোর্স অ্যাক্সেস করার অনুরোধ করতে দেয় এবং ব্যবহারকারীদের আপনার অ্যাপ্লিকেশনকে দেওয়া অ্যাক্সেসের পরিমাণ নিয়ন্ত্রণ করতে দেয়। তাই, অনুরোধ করা স্কোপের সংখ্যা এবং ব্যবহারকারীর সম্মতি পাওয়ার সম্ভাবনার মধ্যে বিপরীত সম্পর্ক থাকতে পারে।

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-এর থেকে আলাদা।
লুপব্যাক 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 ডকুমেন্টেশন দেখুন।
login_hint ঐচ্ছিক

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

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

নমুনা অনুমোদন 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 Sign-In বা OpenID Foundation-এর iOS-এর জন্য AppAuth।

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

org_internal

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

deleted_client

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

invalid_grant

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

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

redirect_uri_mismatch

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

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

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

invalid_request

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

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

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

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

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

ধাপ ৫: রিফ্রেশ ও অ্যাক্সেস টোকেনের জন্য অথরাইজেশন কোড এক্সচেঞ্জ করুন

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

ফিল্ড
client_id Cloud Console-এর ক্লায়েন্ট পৃষ্ঠা থেকে ক্লায়েন্ট আইডি পাওয়া গেছে।
client_secret ঐচ্ছিক

Cloud Console-এর ক্লায়েন্ট পৃষ্ঠা থেকে পাওয়া ক্লায়েন্ট সিক্রেট।
code প্রাথমিক অনুরোধ থেকে অথরাইজেশন কোড ফিরে এসেছে।
code_verifier ধাপ ১-এ আপনার তৈরি করা কোড ভেরিফায়ার।
grant_type OAuth 2.0 স্পেসিফিকেশনে যেমন উল্লেখ করা আছে, এই ফিল্ডের ভ্যালু অবশ্যই authorization_code হিসেবে সেট করতে হবে।
redirect_uri প্রদত্ত 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 কল করার সময়) DPoP প্রমাণের nonce দাবিতে এটি অন্তর্ভুক্ত করতে হবে। এই আগে থেকে ইস্যু করা ননস ব্যবহার করে, আপনি পরবর্তী অনুরোধে অতিরিক্ত রাউন্ড-ট্রিপ ব্যর্থতা (use_dpop_nonce) এড়াতে পারবেন।

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

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

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

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

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

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

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

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

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

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

ব্যবহারকারী আপনার অ্যাপ্লিকেশনকে কোনও নির্দিষ্ট স্কোপে অ্যাক্সেস দিয়েছেন কিনা তা চেক করতে, অ্যাক্সেস টোকেন রেসপন্সে scope ফিল্ডটি পরীক্ষা করুন। 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

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

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 হেডারও পাঠাতে পারে; যদি পাঠানো হয়, তাহলে আপনার ক্লায়েন্টকে অবশ্যই এই ননস ক্যাশে করতে হবে এবং পরবর্তী অনুরোধে DPoP প্রমাণের nonce দাবিতে এটি অন্তর্ভুক্ত করতে হবে।

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

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

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

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

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

টোকেন প্রত্যাহার

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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-এ গ্রুপ প্রকাশক মেম্বারশিপ তালিকা সিঙ্ক করা হয়েছে কিনা তা যাচাই করুন। আপনার প্রকাশকের মেম্বারশিপ তালিকা সিঙ্ক করার ব্যাপারে আরও জানুন।

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

সময়-ভিত্তিক অ্যাক্সেস কোনও ব্যবহারকারীকে সীমিত সময়ের জন্য আপনার অ্যাপকে তার ডেটা অ্যাক্সেস করার অনুমতি দিতে দেয় যাতে কোনও অ্যাকশন সম্পূর্ণ করা যায়। সম্মতি ফ্লো চলাকালীন বেছে নেওয়া 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

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