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

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

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

ব্যবহারকারীর মেশিনে ডেস্কটপ অ্যাপ্লিকেশন লোকালি ইনস্টল করা হয় (যেমন স্ট্যান্ডঅ্যালোন ডেস্কটপ সফ্টওয়্যার, ডেভেলপার 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. YouTube Data API খুঁজে পেতে ও চালু করতে লাইব্রেরি পৃষ্ঠা ব্যবহার করুন। আপনার অ্যাপ্লিকেশন ব্যবহার করবে এমন অন্য কোনও API খুঁজুন এবং সেগুলিও চালু করুন।

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

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

1. ক্লায়েন্ট পৃষ্ঠায় যান।
2. ক্লায়েন্ট তৈরি করুন বিকল্পে ক্লিক করুন।
3. ডেস্কটপ অ্যাপ অ্যাপ্লিকেশনের ধরন বেছে নিন।
4. নাম ফিল্ডে, OAuth ক্লায়েন্টের জন্য একটি নাম লিখুন। ক্লায়েন্টকে শনাক্ত করতে আপনার প্রোজেক্টের ক্লায়েন্ট পৃষ্ঠায় এই নাম দেখানো হয়।
5. তৈরি করুন বিকল্পে ক্লিক করুন।

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

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

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

OAuth 2.0 অনুমোদন প্রয়োগ করা শুরু করার আগে, আমরা সাজেস্ট করি যে আপনি সেইসব স্কোপ শনাক্ত করুন যেগুলি অ্যাক্সেস করার জন্য আপনার অ্যাপের অনুমতি প্রয়োজন হবে।

YouTube Data API v3 নিম্নলিখিত স্কোপ ব্যবহার করে:

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] / "-" / "." / "_" / "~" অসংরক্ষিত অক্ষর ব্যবহার করে, যার ন্যূনতম দৈর্ঘ্য ৪৩টি অক্ষর এবং সর্বাধিক দৈর্ঘ্য ১২৮টি অক্ষর।

কোড যাচাইকারীর কাছে পর্যাপ্ত এনট্রপি থাকতে হবে যাতে ভ্যালু অনুমান করা অবাস্তব হয়।

কোড চ্যালেঞ্জ তৈরি করুন

কোড চ্যালেঞ্জ তৈরি করার দুটি পদ্ধতি কাজ করে।

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) কানেকশন প্রত্যাখ্যান করে।

ইনস্টল করা অ্যাপ্লিকেশনের জন্য অনুমোদন সার্ভার নিম্নলিখিত কোয়েরি স্ট্রিং প্যারামিটার সমর্থন করে:

নমুনা অনুমোদন URL

নিচের ট্যাবগুলি বিভিন্ন রিডাইরেক্ট URI বিক��্পের জন্য স্যাম্পেল অথরাইজেশন URL দেখায়।

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

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.force-ssl&
 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.force-ssl&
 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 সার্ভার থেকে উত্তরের জন্য অপেক্ষা করে যা থেকে বোঝা যায় যে কোনও অ্যাক্সেস দেওয়া হয়েছে কিনা। সেই উত্তরটি নিম্নলিখিত ধাপে ব্যাখ্যা করা হয়েছে।

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

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

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

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

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

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

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

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

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 অবজেক্ট পাঠায় যাতে অল্প সময়ের জন্য অ্যাক্সেস টোকেন এবং রিফ্রেশ টোকেন থাকে।

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

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 https://www.googleapis.com/auth/calendar.readonly",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

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

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

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

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

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

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

  {
    "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
    "expires_in": 3920,
    "token_type": "Bearer",
    "scope": "https://www.googleapis.com/auth/youtube.force-ssl 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-তে কল সেট-আপ করার জন্য ক্লায়েন্ট লাইব্রেরি ব্যবহার করতে পারেন (যেমন, YouTube লাইভ স্ট্রিমিং API কল করার সময়)।

মনে রাখবেন যে YouTube লাইভ স্ট্রিমিং API-তে পরিষেবা অ্যাকাউন্ট ফ্লো কাজ করে না। যেহেতু YouTube অ্যাকাউন্টের সাথে কোনও পরিষেবা অ্যাকাউন্ট লিঙ্ক করার কোনও উপায় নেই, তাই এই ফ্লোয়ের মাধ্যমে অনুরোধ অনুমোদনের চেষ্টা করলে NoLinkedYouTubeAccount সমস্যা দেখা দেবে।

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

HTTP GET-এর উদাহরণ

Authorization: Bearer HTTP হেডার ব্যবহার করে liveBroadcasts.list এন্ডপয়েন্টে (YouTube লাইভ স্ট্রিমিং API) করা কল নিম্নলিখিত উদাহরণের মতো দেখতে হতে পারে। মনে রাখবেন, আপনাকে নিজের অ্যাক্সেস টোকেন উল্লেখ করতে হবে:

GET /youtube/v3/liveBroadcasts?part=id%2Csnippet&mine=true HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

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

GET https://www.googleapis.com/youtube/v3/liveBroadcasts?access_token=access_token&part=id%2Csnippet&mine=true

curlটি উদাহরণ

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

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/v3/liveBroadcasts?part=id%2Csnippet&mine=true

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

curl https://www.googleapis.com/youtube/v3/liveBroadcasts?access_token=access_token&part=id%2Csnippet&mine=true

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

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

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

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

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

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-এর সাথে একটি সমস্যা কোড পাঠানো হয়।

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

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

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

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

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

আরও পড়ুন

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