টিভি এবং লিমিটেড-ইনপুট ডিভাইস অ্যাপ্লিকেশনের জন্য OAuth 2.0

গুরুত্বপূর্ণ নোট: এই OAuth 2.0 ফ্লো সীমিত স্কোপের সেট সমর্থন করে।

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

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

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

বিকল্প

আপনি যদি Android, iOS, macOS, Linux, বা Windows (ইউনিভার্সাল উইন্ডোজ প্ল্যাটফর্ম সহ) এর মতো একটি প্ল্যাটফর্মের জন্য একটি অ্যাপ লিখছেন, যার ব্রাউজারে অ্যাক্সেস এবং সম্পূর্ণ ইনপুট ক্ষমতা রয়েছে, তাহলে মোবাইল এবং ডেস্কটপ অ্যাপ্লিকেশনগুলির জন্য OAuth 2.0 ফ্লো ব্যবহার করুন৷ (আপনার অ্যাপটি গ্রাফিকাল ইন্টারফেস ছাড়াই কমান্ড-লাইন টুল হলেও আপনার সেই প্রবাহটি ব্যবহার করা উচিত।)

আপনি যদি শুধুমাত্র ব্যবহারকারীদের তাদের Google অ্যাকাউন্ট দিয়ে সাইন ইন করতে চান এবং ব্যবহারকারীর মৌলিক তথ্য পেতে JWT আইডি টোকেন ব্যবহার করতে চান, তাহলে TVs এবং Limited Input Devices-এ সাইন-ইন দেখুন।

পূর্বশর্ত

আপনার প্রকল্পের জন্য API সক্ষম করুন

Google API-কে কল করে এমন যেকোনো অ্যাপ্লিকেশনে সেই APIগুলিকে সক্ষম করতে হবে৷ API Console.

আপনার প্রকল্পের জন্য একটি API সক্ষম করতে:

1. Open the API Library মধ্যে Google API Console.
2. If prompted, select a project, or create a new one.
3. দ API Library পণ্য পরিবার এবং জনপ্রিয়তা দ্বারা গোষ্ঠীবদ্ধ সমস্ত উপলব্ধ API তালিকা করে। আপনি যে APIটি সক্ষম করতে চান তা তালিকায় দৃশ্যমান না হলে, এটি খুঁজতে অনুসন্ধান ব্যবহার করুন, অথবা এটি যে পণ্যের পরিবারে রয়েছে তার সমস্ত দেখুন ক্লিক করুন৷
4. আপনি যে APIটি সক্ষম করতে চান তা নির্বাচন করুন, তারপর সক্ষম বোতামটি ক্লিক করুন।
5. If prompted, enable billing.
6. If prompted, read and accept the API's Terms of Service.

অনুমোদনের শংসাপত্র তৈরি করুন

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

1. Go to the Credentials page.
2. ক্রেডেনশিয়াল তৈরি করুন > OAuth ক্লায়েন্ট আইডি ক্লিক করুন।
3. টিভি এবং সীমিত ইনপুট ডিভাইস অ্যাপ্লিকেশন প্রকার নির্বাচন করুন।
4. আপনার OAuth 2.0 ক্লায়েন্টের নাম দিন এবং Create এ ক্লিক করুন।

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

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

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

দ্রষ্টব্য: ইনস্টল করা অ্যাপ বা ডিভাইসের জন্য ক্রমবর্ধমান অনুমোদন সমর্থিত নয়।

ইনস্টল করা অ্যাপ বা ডিভাইসের জন্য অনুমোদিত সুযোগ তালিকা দেখুন।

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

OAuth 2.0 অ্যাক্সেস টোকেন প্রাপ্ত করা

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

1. আপনার অ্যাপ্লিকেশনটি Google-এর অনুমোদন সার্ভারে একটি অনুরোধ পাঠায় যা আপনার অ্যাপ্লিকেশনটি অ্যাক্সেসের অনুমতির অনুরোধ করবে এমন সুযোগগুলি সনাক্ত করে৷
2. সার্ভার পরবর্তী ধাপে ব্যবহৃত বিভিন্ন তথ্যের সাথে সাড়া দেয়, যেমন একটি ডিভাইস কোড এবং একটি ব্যবহারকারী কোড।
3. আপনি এমন তথ্য প্রদর্শন করেন যা ব্যবহারকারী আপনার অ্যাপকে অনুমোদন করার জন্য একটি পৃথক ডিভাইসে প্রবেশ করতে পারে।
4. ব্যবহারকারী আপনার অ্যাপ অনুমোদন করেছে কিনা তা নির্ধারণ করতে আপনার অ্যাপ্লিকেশনটি Google-এর অনুমোদন সার্ভারে পোলিং শুরু করে৷
5. ব্যবহারকারী আরও সমৃদ্ধ ইনপুট ক্ষমতা সহ একটি ডিভাইসে স্যুইচ করে, একটি ওয়েব ব্রাউজার চালু করে, ধাপ 3-এ প্রদর্শিত URL-এ নেভিগেট করে এবং একটি কোড প্রবেশ করে যা ধাপ 3-এও প্রদর্শিত হয়৷ ব্যবহারকারী তখন আপনার অ্যাপ্লিকেশনে অ্যাক্সেস মঞ্জুর (বা অস্বীকার) করতে পারে৷
6. আপনার পোলিং অনুরোধের পরবর্তী প্রতিক্রিয়াতে ব্যবহারকারীর পক্ষ থেকে অনুরোধ অনুমোদন করার জন্য আপনার অ্যাপের প্রয়োজনীয় টোকেনগুলি রয়েছে৷ (যদি ব্যবহারকারী আপনার আবেদনে অ্যাক্সেস প্রত্যাখ্যান করে, প্রতিক্রিয়াটিতে টোকেন থাকে না।)

নীচের চিত্রটি এই প্রক্রিয়াটি চিত্রিত করে:

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

ধাপ 1: ডিভাইস এবং ব্যবহারকারী কোড অনুরোধ

এই ধাপে, আপনার ডিভাইসটি https://oauth2.googleapis.com/device/code এ Google-এর অনুমোদন সার্ভারে একটি HTTP POST অনুরোধ পাঠায়, যা আপনার অ্যাপ্লিকেশানের পাশাপাশি আপনার অ্যাপ্লিকেশান ব্যবহারকারীর অ্যাক্সেস করতে চায় এমন অ্যাক্সেস স্কোপগুলি সনাক্ত করে। পক্ষ থেকে device_authorization_endpoint মেটাডেটা মান ব্যবহার করে আপনার ডিসকভারি ডকুমেন্ট থেকে এই URLটি পুনরুদ্ধার করা উচিত। নিম্নলিখিত HTTP অনুরোধ পরামিতি অন্তর্ভুক্ত করুন:

পরামিতি
client_id	প্রয়োজন আপনার আবেদনের জন্য ক্লায়েন্ট আইডি। আপনি এই মান খুঁজে পেতে পারেন API ConsoleCredentials page.
scope	প্রয়োজন স্কোপের একটি স্থান-সীমাবদ্ধ তালিকা যা ব্যবহারকারীর পক্ষ থেকে আপনার অ্যাপ্লিকেশন অ্যাক্সেস করতে পারে এমন সংস্থানগুলি সনাক্ত করে৷ এই মানগুলি সম্মতি স্ক্রীনকে জানায় যা Google ব্যবহারকারীকে প্রদর্শন করে। ইনস্টল করা অ্যাপ বা ডিভাইসের জন্য অনুমোদিত সুযোগ তালিকা দেখুন। স্কোপগুলি আপনার অ্যাপ্লিকেশনটিকে শুধুমাত্র প্রয়োজনীয় সংস্থানগুলিতে অ্যাক্সেসের অনুরোধ করতে সক্ষম করে এবং ব্যবহারকারীদের তারা আপনার অ্যাপ্লিকেশনটিতে যে পরিমাণ অ্যাক্সেস দেয় তা নিয়ন্ত্রণ করতে সক্ষম করে। সুতরাং, অনুরোধ করা স্কোপের সংখ্যা এবং ব্যবহারকারীর সম্মতি পাওয়ার সম্ভাবনার মধ্যে একটি বিপরীত সম্পর্ক রয়েছে।

উদাহরণ

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

POST /device/code HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=client_id&scope=email%20profile

এই উদাহরণটি একই অনুরোধ পাঠাতে একটি curl কমান্ড দেখায়:

curl -d "client_id=client_id&scope=email%20profile" \
     https://oauth2.googleapis.com/device/code

ধাপ 2: অনুমোদন সার্ভার প্রতিক্রিয়া হ্যান্ডেল

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

সফল প্রতিক্রিয়া

যদি অনুরোধটি বৈধ হয়, তাহলে আপনার প্রতিক্রিয়া একটি JSON অবজেক্ট হবে যার মধ্যে নিম্নলিখিত বৈশিষ্ট্য রয়েছে:

বৈশিষ্ট্য
device_code	একটি মান যা Google অনন্যভাবে অ্যাসাইন করে সেই ডিভাইসটিকে শনাক্ত করার জন্য যেটি অনুমোদনের অনুরোধ করে অ্যাপটি চালায়। ব্যবহারকারী আরও সমৃদ্ধ ইনপুট ক্ষমতা সহ অন্য ডিভাইস থেকে সেই ডিভাইসটিকে অনুমোদন করবে। উদাহরণস্বরূপ, একজন ব্যবহারকারী একটি টিভিতে চলমান একটি অ্যাপ অনুমোদন করতে একটি ল্যাপটপ বা মোবাইল ফোন ব্যবহার করতে পারে৷ এই ক্ষেত্রে, device_code টিভি সনাক্ত করে। এই কোডটি অ্যাপটি চালানো ডিভাইসটিকে নিরাপদে নির্ধারণ করতে দেয় যে ব্যবহারকারী অ্যাক্সেস দিয়েছেন বা অস্বীকার করেছেন।
expires_in	যে device_code এবং user_code বৈধ তা সেকেন্ডে সময়ের দৈর্ঘ্য। যদি, সেই সময়ে, ব্যবহারকারী অনুমোদনের প্রবাহ সম্পূর্ণ না করেন এবং আপনার ডিভাইস ব্যবহারকারীর সিদ্ধান্ত সম্পর্কে তথ্য পুনরুদ্ধার করার জন্য পোলও না করে, তাহলে আপনাকে ধাপ 1 থেকে এই প্রক্রিয়াটি পুনরায় আরম্ভ করতে হতে পারে।
interval	সময় দৈর্ঘ্য, সেকেন্ডের মধ্যে, আপনার ডিভাইসটি পোলিং অনুরোধের মধ্যে অপেক্ষা করবে। উদাহরণস্বরূপ, যদি মান 5 হয়, আপনার ডিভাইসটি প্রতি পাঁচ সেকেন্ডে Google এর অনুমোদন সার্ভারে একটি পোলিং অনুরোধ পাঠাবে। আরও বিস্তারিত জানার জন্য ধাপ 3 দেখুন।
user_code	একটি কেস-সংবেদনশীল মান যা Google-এর কাছে সেই স্কোপগুলিকে শনাক্ত করে যা অ্যাপ্লিকেশনটি অ্যাক্সেসের অনুরোধ করছে৷ আপনার ইউজার ইন্টারফেস ব্যবহারকারীকে আরও সমৃদ্ধ ইনপুট ক্ষমতা সহ একটি পৃথক ডিভাইসে এই মানটি প্রবেশ করার নির্দেশ দেবে। ব্যবহারকারীকে আপনার অ্যাপ্লিকেশনে অ্যাক্সেস দেওয়ার জন্য অনুরোধ করার সময় Google তারপর স্কোপের সঠিক সেট প্রদর্শন করতে মানটি ব্যবহার করে।
verification_url	একটি URL যা ব্যবহারকারীকে অবশ্যই একটি পৃথক ডিভাইসে নেভিগেট করতে হবে, user_code লিখতে এবং আপনার অ্যাপ্লিকেশনে অ্যাক্সেস মঞ্জুর বা অস্বীকার করতে। আপনার ইউজার ইন্টারফেসও এই মান প্রদর্শন করবে।

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

{
  "device_code": "4/4-GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8",
  "user_code": "GQVQ-JKEC",
  "verification_url": "https://www.google.com/device",
  "expires_in": 1800,
  "interval": 5
}

কোটা ছাড়িয়ে গেছে সাড়া

যদি আপনার ডিভাইস কোড অনুরোধগুলি আপনার ক্লায়েন্ট আইডির সাথে যুক্ত কোটা অতিক্রম করে থাকে, তাহলে আপনি নিম্নলিখিত ত্রুটি সহ একটি 403 প্রতিক্রিয়া পাবেন:

{
  "error_code": "rate_limit_exceeded"
}

সেই ক্ষেত্রে, অনুরোধের হার কমাতে একটি ব্যাকঅফ কৌশল ব্যবহার করুন।

ধাপ 3: ব্যবহারকারী কোড প্রদর্শন করুন

ব্যবহারকারীর কাছে ধাপ 2 এ প্রাপ্ত verification_url এবং user_code প্রদর্শন করুন। উভয় মানই US-ASCII অক্ষর সেট থেকে যেকোনো মুদ্রণযোগ্য অক্ষর ধারণ করতে পারে। আপনি ব্যবহারকারীর কাছে যে বিষয়বস্তু প্রদর্শন করবেন সেটি ব্যবহারকারীকে একটি পৃথক ডিভাইসে verification_url এ নেভিগেট করতে এবং user_code লিখতে নির্দেশ দেবে।

নিম্নলিখিত নিয়মগুলি মাথায় রেখে আপনার ইউজার ইন্টারফেস (UI) ডিজাইন করুন:

• user_code
  • user_code অবশ্যই 15 'W' আকারের অক্ষর পরিচালনা করতে পারে এমন একটি ক্ষেত্রে প্রদর্শিত হতে হবে। অন্য কথায়, আপনি যদি WWWWWWWWWWWWWWW কোডটি সঠিকভাবে প্রদর্শন করতে পারেন, তাহলে আপনার UI বৈধ, এবং আমরা আপনার UI-তে user_code প্রদর্শনের উপায় পরীক্ষা করার সময় সেই স্ট্রিং মানটি ব্যবহার করার পরামর্শ দিই।
  • user_code কেস-সংবেদনশীল এবং কোনোভাবেই পরিবর্তন করা উচিত নয়, যেমন কেস পরিবর্তন করা বা অন্যান্য ফরম্যাটিং অক্ষর সন্নিবেশ করানো।
• verification_url
  • আপনি verification_url যে স্থানটি প্রদর্শন করবেন সেটি অবশ্যই 40 অক্ষর দীর্ঘ একটি URL স্ট্রিং পরিচালনা করার জন্য যথেষ্ট প্রশস্ত হতে হবে।
  • প্রদর্শনের জন্য ঐচ্ছিকভাবে স্কিমটি অপসারণ করা ব্যতীত, আপনি কোনোভাবেই verification_url সংশোধন করবেন না। আপনি যদি প্রদর্শনের কারণে ইউআরএল থেকে স্কিমটি (যেমন https:// ) বন্ধ করার পরিকল্পনা করেন, তাহলে নিশ্চিত হন যে আপনার অ্যাপটি http এবং https উভয় প্রকারেরই পরিচালনা করতে পারে।

সতর্কীকরণ: এই দুটি মানই পরিবর্তন সাপেক্ষে, এবং আপনার কোডের উভয় মানকেই হার্ডকোড করা উচিত নয়। একইভাবে, আপনার verification_url থেকে ঐচ্ছিকভাবে স্কিমটি সরানো ছাড়া অন্য কোনো উপায়ে মান পরিবর্তন করা উচিত নয়।

ধাপ 4: পোল Google এর অনুমোদন সার্ভার

যেহেতু ব্যবহারকারী verification_url এ নেভিগেট করতে এবং অ্যাক্সেস মঞ্জুর (বা অস্বীকার) করার জন্য একটি পৃথক ডিভাইস ব্যবহার করবে, তাই অনুরোধকারী ডিভাইসটি স্বয়ংক্রিয়ভাবে সূচিত হয় না যখন ব্যবহারকারী অ্যাক্সেস অনুরোধে সাড়া দেয়। সেই কারণে, ব্যবহারকারী কখন অনুরোধে সাড়া দিয়েছেন তা নির্ধারণ করতে অনুরোধকারী ডিভাইসটিকে Google এর অনুমোদন সার্ভারে পোল করতে হবে।

অনুরোধকারী ডিভাইসটিকে পোলিং অনুরোধ পাঠানো চালিয়ে যেতে হবে যতক্ষণ না এটি একটি প্রতিক্রিয়া না পায় যা নির্দেশ করে যে ব্যবহারকারী অ্যাক্সেস অনুরোধে সাড়া দিয়েছেন বা ধাপ 2 এ প্রাপ্ত device_code এবং user_code মেয়াদ শেষ না হওয়া পর্যন্ত। ধাপ 2 এ ফিরে আসা interval অনুরোধের মধ্যে অপেক্ষা করার জন্য সেকেন্ডে সময়ের পরিমাণ নির্দিষ্ট করে।

পোল করার শেষ পয়েন্টের URL হল https://oauth2.googleapis.com/token । পোলিং অনুরোধে নিম্নলিখিত পরামিতিগুলি রয়েছে:

পরামিতি
client_id	আপনার আবেদনের জন্য ক্লায়েন্ট আইডি। আপনি এই মান খুঁজে পেতে পারেন API ConsoleCredentials page.
client_secret	প্রদত্ত client_id জন্য ক্লায়েন্টের গোপনীয়তা। আপনি এই মান খুঁজে পেতে পারেন API ConsoleCredentials page.
device_code	device_code অনুমোদন সার্ভার দ্বারা 2 ধাপে ফিরে এসেছে।
grant_type	এই মানটি urn:ietf:params:oauth:grant-type:device_code এ সেট করুন।

উদাহরণ

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

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

client_id=client_id&
client_secret=client_secret&
device_code=device_code&
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code

এই উদাহরণটি একই অনুরোধ পাঠাতে একটি curl কমান্ড দেখায়:

curl -d "client_id=client_id&client_secret=client_secret& \
         device_code=device_code& \
         grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code" \
         -H "Content-Type: application/x-www-form-urlencoded" \
         https://oauth2.googleapis.com/token

ধাপ 5: ব্যবহারকারী অ্যাক্সেস অনুরোধে সাড়া দেয়

দ্রষ্টব্য: পূর্ববর্তী ধাপে বর্ণিত অনুমোদন সার্ভারে ভোট দেওয়া ছাড়া এই পর্যায়ে আপনার আবেদনের কিছু করার দরকার নেই।

নিম্নলিখিত চিত্রটি ব্যবহারকারীরা যা দেখেন তার অনুরূপ একটি পৃষ্ঠা দেখায় যখন তারা verification_url এ নেভিগেট করে যা আপনি ধাপ 3 এ প্রদর্শন করেছেন:

user_code প্রবেশ করার পরে এবং, যদি ইতিমধ্যেই লগ-ইন না হয়ে থাকে, Google-এ লগ ইন করার পরে, ব্যবহারকারী নীচে দেখানো একটি মত একটি সম্মতি স্ক্রীন দেখতে পায়:

ধাপ 6: পোলিং অনুরোধের প্রতিক্রিয়াগুলি পরিচালনা করুন

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

অ্যাক্সেস দেওয়া হয়েছে

ব্যবহারকারী যদি ডিভাইসে অ্যাক্সেস দেয় (সম্মতি স্ক্রিনে Allow ক্লিক করে), তাহলে প্রতিক্রিয়াটিতে একটি অ্যাক্সেস টোকেন এবং একটি রিফ্রেশ টোকেন রয়েছে। টোকেনগুলি ব্যবহারকারীর পক্ষ থেকে আপনার ডিভাইসটিকে Google API অ্যাক্সেস করতে সক্ষম করে৷ (প্রতিক্রিয়ার scope বৈশিষ্ট্য ডিভাইসটি কোন APIগুলি অ্যাক্সেস করতে পারে তা নির্ধারণ করে।)

এই ক্ষেত্রে, API প্রতিক্রিয়াতে নিম্নলিখিত ক্ষেত্রগুলি রয়েছে:

ক্ষেত্র
access_token	একটি Google API অনুরোধ অনুমোদন করার জন্য আপনার অ্যাপ্লিকেশন যে টোকেন পাঠায়।
expires_in	সেকেন্ডে অ্যাক্সেস টোকেনের অবশিষ্ট জীবনকাল।
refresh_token	একটি টোকেন যা আপনি একটি নতুন অ্যাক্সেস টোকেন পেতে ব্যবহার করতে পারেন। ব্যবহারকারী অ্যাক্সেস প্রত্যাহার না করা পর্যন্ত রিফ্রেশ টোকেন বৈধ। নোট করুন যে রিফ্রেশ টোকেন সবসময় ডিভাইসের জন্য ফেরত দেওয়া হয়।
scope	access_token দ্বারা প্রদত্ত অ্যাক্সেসের সুযোগগুলি স্থান-সীমাবদ্ধ, কেস-সংবেদনশীল স্ট্রিংগুলির একটি তালিকা হিসাবে প্রকাশ করা হয়েছে।
token_type	টোকেনের ধরন ফিরে এসেছে। এই সময়ে, এই ক্ষেত্রের মান সর্বদা Bearer এ সেট করা থাকে।

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

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "openid https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email",
  "token_type": "Bearer",
  "refresh_token": "1/xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

অ্যাক্সেস টোকেন একটি সীমিত জীবনকাল আছে. যদি আপনার অ্যাপ্লিকেশনটি দীর্ঘ সময়ের জন্য একটি API-তে অ্যাক্সেসের প্রয়োজন হয় তবে এটি একটি নতুন অ্যাক্সেস টোকেন পেতে রিফ্রেশ টোকেন ব্যবহার করতে পারে। যদি আপনার অ্যাপ্লিকেশানের এই ধরনের অ্যাক্সেসের প্রয়োজন হয়, তাহলে এটিকে পরবর্তীতে ব্যবহারের জন্য রিফ্রেশ টোকেন সংরক্ষণ করা উচিত।

অ্যাক্সেস অস্বীকার করা হয়েছে৷

ব্যবহারকারী যদি ডিভাইসে অ্যাক্সেস দিতে অস্বীকার করে, তাহলে সার্ভারের প্রতিক্রিয়ার একটি 403 HTTP প্রতিক্রিয়া স্ট্যাটাস কোড ( Forbidden ) থাকে। প্রতিক্রিয়াতে নিম্নলিখিত ত্রুটি রয়েছে:

{
  "error": "access_denied",
  "error_description": "Forbidden"
}

অনুমোদন মুলতুবি

যদি ব্যবহারকারী এখনও অনুমোদন প্রবাহ সম্পূর্ণ না করে থাকে, তাহলে সার্ভার একটি 428 HTTP প্রতিক্রিয়া স্ট্যাটাস কোড প্রদান করে ( Precondition Required )। প্রতিক্রিয়াতে নিম্নলিখিত ত্রুটি রয়েছে:

{
  "error": "authorization_pending",
  "error_description": "Precondition Required"
}

খুব ঘন ঘন পোলিং

যদি ডিভাইসটি খুব ঘন ঘন পোলিং অনুরোধ পাঠায়, তাহলে সার্ভার একটি 403 HTTP প্রতিক্রিয়া স্ট্যাটাস কোড প্রদান করে ( Forbidden )। প্রতিক্রিয়াতে নিম্নলিখিত ত্রুটি রয়েছে:

{
  "error": "slow_down",
  "error_description": "Forbidden"
}

অন্যান্য ত্রুটি

পোলিং অনুরোধে কোনো প্রয়োজনীয় প্যারামিটার অনুপস্থিত থাকলে বা একটি ভুল প্যারামিটার মান থাকলে অনুমোদন সার্ভারও ত্রুটি ফেরত দেয়। এই অনুরোধগুলিতে সাধারণত একটি 400 ( Bad Request ) বা 401 ( Unauthorized ) HTTP প্রতিক্রিয়া স্ট্যাটাস কোড থাকে। এই ত্রুটিগুলি অন্তর্ভুক্ত:

ত্রুটি	HTTP স্ট্যাটাস কোড	বর্ণনা
admin_policy_enforced	400	Google অ্যাকাউন্ট তাদের Google Workspace অ্যাডমিনিস্ট্রেটরের নীতির কারণে অনুরোধ করা এক বা একাধিক স্কোপের অনুমোদন দিতে পারে না। আপনার OAuth ক্লায়েন্ট আইডি-তে স্পষ্টভাবে অ্যাক্সেস না দেওয়া পর্যন্ত অ্যাডমিনিস্ট্রেটর কীভাবে স্কোপের অ্যাক্সেস সীমাবদ্ধ করতে পারে সে সম্পর্কে আরও তথ্যের জন্য কোন থার্ড-পার্টি এবং অভ্যন্তরীণ অ্যাপগুলি Google Workspace ডেটা অ্যাক্সেস করে তা নিয়ন্ত্রণ করুন Google Workspace অ্যাডমিন সহায়তা নিবন্ধটি দেখুন।
invalid_client	401	OAuth ক্লায়েন্ট খুঁজে পাওয়া যায়নি. উদাহরণস্বরূপ, client_id প্যারামিটার মান অবৈধ হলে এই ত্রুটিটি ঘটে। OAuth ক্লায়েন্টের ধরনটি ভুল। নিশ্চিত করুন যে ক্লায়েন্ট আইডির জন্য অ্যাপ্লিকেশনের ধরনটি টিভি এবং সীমিত ইনপুট ডিভাইসে সেট করা আছে।
invalid_grant	400	code প্যারামিটার মান অবৈধ, ইতিমধ্যে দাবি করা হয়েছে বা পার্স করা যাবে না।
unsupported_grant_type	400	grant_type প্যারামিটার মানটি অবৈধ৷
org_internal	403	অনুরোধে OAuth ক্লায়েন্ট আইডি একটি নির্দিষ্ট Google ক্লাউড সংস্থার Google অ্যাকাউন্টগুলিতে অ্যাক্সেস সীমিত করে এমন একটি প্রকল্পের অংশ৷ আপনার OAuth অ্যাপ্লিকেশনের জন্য ব্যবহারকারীর প্রকার কনফিগারেশন নিশ্চিত করুন।

Google API কল করা হচ্ছে

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

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

HTTP GET উদাহরণ

অনুমোদন ব্যবহার করে drive.files এন্ডপয়েন্টে (ড্রাইভ ফাইল এপিআই) একটি কল Authorization: Bearer HTTP হেডার নিচের মত দেখতে হতে পারে। মনে রাখবেন যে আপনাকে আপনার নিজস্ব অ্যাক্সেস টোকেন নির্দিষ্ট করতে হবে:

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 POST অনুরোধ পাঠায় ( https://oauth2.googleapis.com/token ) যাতে নিম্নলিখিত প্যারামিটারগুলি অন্তর্ভুক্ত থাকে:

ক্ষেত্র
client_id	ক্লায়েন্ট আইডি থেকে প্রাপ্ত API Console.
client_secret	ক্লায়েন্ট সিক্রেট থেকে প্রাপ্ত API Console.
grant_type	OAuth 2.0 স্পেসিফিকেশনে যেমন সংজ্ঞায়িত করা হয়েছে , এই ক্ষেত্রের মান অবশ্যই refresh_token এ সেট করতে হবে।
refresh_token	রিফ্রেশ টোকেন অনুমোদন কোড বিনিময় থেকে ফিরে.

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

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

client_id=your_client_id&
client_secret=your_client_secret&
refresh_token=refresh_token&
grant_type=refresh_token

যতক্ষণ না ব্যবহারকারী অ্যাপ্লিকেশনটিতে দেওয়া অ্যাক্সেস প্রত্যাহার না করে, টোকেন সার্ভার একটি JSON অবজেক্ট ফেরত দেয় যাতে একটি নতুন অ্যাক্সেস টোকেন রয়েছে। নিম্নলিখিত স্নিপেট একটি নমুনা প্রতিক্রিয়া দেখায়:

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

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

একটি টোকেন প্রত্যাহার করা হচ্ছে

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

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

দ্রষ্টব্য: একটি সফল প্রত্যাহার প্রতিক্রিয়া অনুসরণ করে, প্রত্যাহার সম্পূর্ণ কার্যকর হওয়ার আগে কিছু সময় লাগতে পারে৷

অনুমোদিত সুযোগ

ডিভাইসগুলির জন্য OAuth 2.0 ফ্লো শুধুমাত্র নিম্নলিখিত স্কোপের জন্য সমর্থিত:

ওপেনআইডি কানেক্ট , গুগল সাইন-ইন

• email
• openid
• profile

ড্রাইভ API

• https://www.googleapis.com/auth/drive.appdata
• https://www.googleapis.com/auth/drive.file

YouTube API

• https://www.googleapis.com/auth/youtube
• https://www.googleapis.com/auth/youtube.readonly

ক্রস-অ্যাকাউন্ট সুরক্ষা বাস্তবায়ন করা

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

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