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

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

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

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

বিকল্প

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

আপনি যদি শুধুমাত্র ব্যবহারকারীদের তাদের Google অ্যাকাউন্ট দিয়ে সাইন ইন করাতে চান এবং ব্যবহারকারীর প্রাথমিক প্রোফাইল তথ্য পেতে JWT ID টোকেন ব্যবহার করতে চান, তাহলে “টিভি এবং সীমিত ইনপুট ডিভাইসে সাইন-ইন” দেখুন।

পূর্বশর্ত

আপনার প্রোজেক্টের জন্য এপিআই (API) সক্রিয় করুন

যে কোনো অ্যাপ্লিকেশন যা গুগল এপিআই কল করে, তাকে এপিআই কনসোলে সেই এপিআইগুলো সক্রিয় করতে হবে।

আপনার প্রোজেক্টের জন্য একটি API সক্রিয় করতে:

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

অনুমোদনের প্রমাণপত্র তৈরি করুন

যে কোনো অ্যাপ্লিকেশন যা গুগল এপিআই (Google API) অ্যাক্সেস করার জন্য OAuth 2.0 ব্যবহার করে, সেটির অবশ্যই এমন অনুমোদন ক্রেডেনশিয়াল (authorization credentials) থাকতে হবে যা গুগলের OAuth 2.0 সার্ভারের কাছে অ্যাপ্লিকেশনটিকে শনাক্ত করে। নিম্নলিখিত ধাপগুলোতে আপনার প্রোজেক্টের জন্য ক্রেডেনশিয়াল তৈরি করার পদ্ধতি ব্যাখ্যা করা হয়েছে। এরপর আপনার অ্যাপ্লিকেশনগুলো সেই ক্রেডেনশিয়াল ব্যবহার করে আপনার প্রোজেক্টের জন্য সক্রিয় করা এপিআইগুলো অ্যাক্সেস করতে পারবে।

  1. ক্লায়েন্ট পৃষ্ঠায় যান।
  2. ক্লায়েন্ট তৈরি করুন -এ ক্লিক করুন।
  3. টিভি এবং সীমিত ইনপুট ডিভাইস অ্যাপ্লিকেশনের ধরণ নির্বাচন করুন।
  4. আপনার OAuth 2.0 ক্লায়েন্টের নাম দিন এবং তৈরি করুন-এ ক্লিক করুন।

অ্যাক্সেসের পরিধি শনাক্ত করুন

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

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

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

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

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

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

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

ব্যবহারকারী একটি আলাদা ডিভাইসে লগ ইন করেন, যেটিতে একটি ব্রাউজার আছে।

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

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

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

প্যারামিটার
client_id প্রয়োজনীয়

আপনার অ্যাপ্লিকেশনের ক্লায়েন্ট আইডি। আপনি এই মানটি ক্লাউড কনসোল ক্লায়েন্টস পৃষ্ঠায় খুঁজে পাবেন।

scope প্রয়োজনীয়

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

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

উদাহরণ

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

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

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

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

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

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

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

এই কোডটি অ্যাপ চালনাকারী ডিভাইসটিকে নিরাপদে নির্ধারণ করতে সাহায্য করে যে ব্যবহারকারী অ্যাক্সেস মঞ্জুর করেছেন নাকি প্রত্যাখ্যান করেছেন।

expires_in device_code এবং user_code কতক্ষণ (সেকেন্ডে) বৈধ থাকবে। যদি এই সময়ের মধ্যে ব্যবহারকারী অনুমোদন প্রক্রিয়াটি সম্পন্ন না করেন এবং আপনার ডিভাইসটিও ব্যবহারকারীর সিদ্ধান্ত সম্পর্কে তথ্য সংগ্রহের জন্য পোল না করে, তাহলে আপনাকে এই প্রক্রিয়াটি ধাপ ১ থেকে পুনরায় শুরু করতে হতে পারে।
interval পোলিং অনুরোধগুলির মধ্যে আপনার ডিভাইসটি কতক্ষণ (সেকেন্ডে) অপেক্ষা করবে। উদাহরণস্বরূপ, যদি মানটি 5 হয়, তাহলে আপনার ডিভাইসটি প্রতি পাঁচ সেকেন্ডে গুগলের অনুমোদন সার্ভারে একটি পোলিং অনুরোধ পাঠাবে। আরও বিস্তারিত জানতে ধাপ 3 দেখুন।
user_code একটি কেস-সেনসিটিভ ভ্যালু, যা গুগলকে শনাক্ত করে যে অ্যাপ্লিকেশনটি কোন কোন স্কোপে অ্যাক্সেসের জন্য অনুরোধ করছে। আপনার ইউজার ইন্টারফেস ব্যবহারকারীকে আরও উন্নত ইনপুট সুবিধা সম্পন্ন একটি আলাদা ডিভাইসে এই ভ্যালুটি প্রবেশ করানোর জন্য নির্দেশ দেবে। এরপর, আপনার অ্যাপ্লিকেশনে অ্যাক্সেস দেওয়ার জন্য ব্যবহারকারীকে অনুরোধ করার সময়, গুগল এই ভ্যালুটি ব্যবহার করে সঠিক স্কোপ সেটটি প্রদর্শন করে।
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"
}

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

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

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

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

  • user_code
    • user_code অবশ্যই এমন একটি ফিল্ডে প্রদর্শন করতে হবে যা ১৫টি 'W' আকারের অক্ষর ধারণ করতে পারে। অন্য কথায়, যদি আপনি WWWWWWWWWWWWWWW কোডটি সঠিকভাবে প্রদর্শন করতে পারেন, তাহলে আপনার UI বৈধ, এবং আপনার UI-তে user_code কীভাবে প্রদর্শিত হয় তা পরীক্ষা করার সময় আমরা এই স্ট্রিং ভ্যালুটি ব্যবহার করার পরামর্শ দিই।
    • user_code কেস-সেনসিটিভ এবং এটিকে কোনোভাবেই পরিবর্তন করা উচিত নয়, যেমন কেস পরিবর্তন করা বা অন্য কোনো ফরম্যাটিং ক্যারেক্টার যোগ করা।
  • verification_url
    • যে স্থানে আপনি verification_url প্রদর্শন করবেন, সেই স্থানটি অবশ্যই ৪০ অক্ষর দীর্ঘ একটি URL স্ট্রিং ধারণ করার জন্য যথেষ্ট প্রশস্ত হতে হবে।
    • You should not modify the verification_url in any way, except to optionally remove the scheme for display. If you do plan to strip off the scheme (eg https:// ) from the URL for display reasons, be sure your app can handle both http and https variants.

ধাপ ৪: গুগলের অনুমোদন সার্ভারকে পোল করুন

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

অনুরোধকারী ডিভাইসটি ততক্ষণ পর্যন্ত পোলিং অনুরোধ পাঠাতে থাকবে যতক্ষণ না এটি ব্যবহারকারীর অ্যাক্সেস অনুরোধে সাড়া দেওয়ার ইঙ্গিতবাহী কোনো প্রতিক্রিয়া পায়, অথবা যতক্ষণ না ধাপ ২- এ প্রাপ্ত device_code এবং user_code মেয়াদ শেষ হয়ে যায়। ধাপ ২-এ ফেরত আসা interval টি অনুরোধগুলোর মধ্যে অপেক্ষা করার সময়কাল (সেকেন্ডে) নির্দিষ্ট করে।

পোল করার জন্য এন্ডপয়েন্টের ইউআরএল হলো https://oauth2.googleapis.com/token । পোলিং অনুরোধটিতে নিম্নলিখিত প্যারামিটারগুলো রয়েছে:

প্যারামিটার
client_id আপনার অ্যাপ্লিকেশনের ক্লায়েন্ট আইডি। আপনি এই মানটি ক্লাউড কনসোল ক্লায়েন্টস পৃষ্ঠায় খুঁজে পাবেন।
client_secret প্রদত্ত client_id জন্য ক্লায়েন্ট সিক্রেট। আপনি এই মানটি ক্লাউড কনসোল ক্লায়েন্টস পৃষ্ঠায় খুঁজে পেতে পারেন।
device_code ধাপ ২- এ অনুমোদন সার্ভার দ্বারা ফেরত দেওয়া device_code ।
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

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

নিচের ছবিতে এমন একটি পৃষ্ঠা দেখানো হয়েছে, যা ব্যবহারকারীরা ধাপ ৩- এ আপনার দেখানো verification_url এ গেলে দেখতে পান:

কোড প্রবেশ করিয়ে একটি ডিভাইস সংযুক্ত করুন

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

ডিভাইস ক্লায়েন্টের জন্য সম্মতি স্ক্রিনের উদাহরণ

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

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

প্রবেশাধিকার মঞ্জুর করা হয়েছে

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

এক্ষেত্রে, এপিআই রেসপন্সে নিম্নলিখিত ফিল্ডগুলো থাকে:

ক্ষেত্র
access_token যে টোকেনটি আপনার অ্যাপ্লিকেশন একটি গুগল এপিআই অনুরোধ অনুমোদন করার জন্য পাঠায়।
expires_in অ্যাক্সেস টোকেনটির অবশিষ্ট মেয়াদ সেকেন্ডে।
refresh_token একটি টোকেন যা ব্যবহার করে আপনি একটি নতুন অ্যাক্সেস টোকেন পেতে পারেন। রিফ্রেশ টোকেনগুলো ততক্ষণ পর্যন্ত বৈধ থাকে যতক্ষণ না ব্যবহারকারী অ্যাক্সেস প্রত্যাহার করে নেয় অথবা রিফ্রেশ টোকেনটির মেয়াদ শেষ হয়ে যায়। মনে রাখবেন, ডিভাইসগুলোর জন্য রিফ্রেশ টোকেন সর্বদা ফেরত দেওয়া হয়।
refresh_token_expires_in রিফ্রেশ টোকেনের অবশিষ্ট মেয়াদ সেকেন্ডে। এই মানটি শুধুমাত্র তখনই সেট করা হয় যখন ব্যবহারকারী সময়-ভিত্তিক অ্যাক্সেসের অনুমতি দেন।
scope The scopes of access granted by the access_token expressed as a list of space-delimited, case-sensitive strings.
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 Workspace অ্যাডমিনিস্ট্রেটরের নীতিমালার কারণে Google অ্যাকাউন্টটি অনুরোধ করা এক বা একাধিক স্কোপ অনুমোদন করতে পারছে না। আপনার OAuth ক্লায়েন্ট আইডিতে স্পষ্টভাবে অ্যাক্সেস মঞ্জুর না করা পর্যন্ত একজন অ্যাডমিনিস্ট্রেটর কীভাবে স্কোপগুলিতে অ্যাক্সেস সীমাবদ্ধ করতে পারেন, সে সম্পর্কে আরও তথ্যের জন্য "Control which third-party & internal apps access Google Workspace data" শীর্ষক Google Workspace অ্যাডমিন হেল্প আর্টিকেলটি দেখুন।
invalid_client 401

OAuth ক্লায়েন্টটি খুঁজে পাওয়া যায়নি। উদাহরণস্বরূপ, client_id প্যারামিটারের মান অবৈধ হলে এই ত্রুটিটি ঘটে।

OAuth ক্লায়েন্টের ধরনটি ভুল। নিশ্চিত করুন যে ক্লায়েন্ট আইডির জন্য অ্যাপ্লিকেশনের ধরনটি টিভি এবং সীমিত ইনপুট ডিভাইস (TVs and Limited Input devices) হিসেবে সেট করা আছে।

invalid_grant 400 code প্যারামিটারের মানটি অবৈধ, ইতিমধ্যে ব্যবহৃত হয়েছে অথবা পার্স করা যাচ্ছে না।
unsupported_grant_type 400 grant_type প্যারামিটারের মানটি অবৈধ।
org_internal 403 অনুরোধে থাকা OAuth ক্লায়েন্ট আইডিটি একটি প্রকল্পের অংশ, যা একটি নির্দিষ্ট Google Cloud Organization- এর Google অ্যাকাউন্টগুলিতে অ্যাক্সেস সীমিত করে। আপনার OAuth অ্যাপ্লিকেশনের জন্য ব্যবহারকারীর প্রকারের কনফিগারেশন নিশ্চিত করুন।

গুগল এপিআই কল করা

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

আপনি OAuth 2.0 প্লেগ্রাউন্ডে সমস্ত গুগল এপিআই ব্যবহার করে দেখতে এবং সেগুলোর পরিধি দেখতে পারেন।

HTTP GET উদাহরণ

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

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

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

ক্ষেত্র
client_id এপিআই কনসোল থেকে ক্লায়েন্ট আইডিটি পাওয়া গেছে।
client_secret ঐচ্ছিক

এপিআই কনসোল থেকে ক্লায়েন্ট সিক্রেটটি পাওয়া গেছে।

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

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

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

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

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

প্রোগ্রামের মাধ্যমে একটি টোকেন বাতিল করতে, আপনার অ্যাপ্লিকেশনটি 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 ফ্লো শুধুমাত্র নিম্নলিখিত স্কোপগুলির জন্য সমর্থিত:

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

  • email
  • openid
  • profile

ড্রাইভ এপিআই

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

ইউটিউব এপিআই

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

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

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

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

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

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

গুগলের ক্রস-অ্যাকাউন্ট প্রোটেকশন সার্ভিস দ্বারা আপনার অ্যাপে পাঠানো ইভেন্ট টাইপগুলোর কিছু উদাহরণ হলো:

  • 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

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