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

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

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

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

বিকল্প

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

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

পূর্বশর্ত

আপনার প্রকল্পের জন্য 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টি সক্ষম করতে চান তা যদি তালিকায় দৃশ্যমান না হয়, তাহলে এটি খুঁজে পেতে অনুসন্ধান ব্যবহার করুন, অথবা এটি যে পণ্য পরিবারের অন্তর্ভুক্ত, সেখানে View All এ ক্লিক করুন।
  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 Clients page.
  2. ক্লায়েন্ট তৈরি করুন ক্লিক করুন।
  3. টিভি এবং সীমিত ইনপুট ডিভাইস অ্যাপ্লিকেশনের ধরণ নির্বাচন করুন।
  4. আপনার OAuth 2.0 ক্লায়েন্টের নাম দিন এবং Create এ ক্লিক করুন।

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

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

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

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

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

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

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

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

ব্যবহারকারী একটি পৃথক ডিভাইসে লগ ইন করেন যার একটি ব্রাউজার আছে

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

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

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

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

আপনার আবেদনের ক্লায়েন্ট আইডি। আপনি এই মানটি খুঁজে পেতে পারেন Cloud ConsoleClients 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

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

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

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

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

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

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

expires_in সেকেন্ডে, device_code এবং user_code বৈধ থাকাকালীন সময়কাল। যদি, সেই সময়ের মধ্যে, ব্যবহারকারী অনুমোদনের প্রবাহ সম্পূর্ণ না করে এবং আপনার ডিভাইস ব্যবহারকারীর সিদ্ধান্ত সম্পর্কে তথ্য পুনরুদ্ধারের জন্য ভোট না দেয়, তাহলে আপনাকে ধাপ ১ থেকে এই প্রক্রিয়াটি পুনরায় চালু করতে হতে পারে।
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"
}

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

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

ধাপ ২-এ প্রাপ্ত 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 কোনওভাবেই পরিবর্তন করা উচিত নয়, শুধুমাত্র ঐচ্ছিকভাবে প্রদর্শনের জন্য স্কিমটি সরিয়ে ফেলা ছাড়া। যদি আপনি প্রদর্শনের কারণে URL থেকে স্কিমটি (যেমন https:// ) বাদ দেওয়ার পরিকল্পনা করেন, তাহলে নিশ্চিত করুন যে আপনার অ্যাপটি http এবং https উভয় রূপই পরিচালনা করতে পারে।

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

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

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

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

পরামিতি
client_id আপনার আবেদনের ক্লায়েন্ট আইডি। আপনি এই মানটি খুঁজে পেতে পারেন Cloud ConsoleClients page.
client_secret প্রদত্ত client_id এর জন্য ক্লায়েন্ট গোপনীয়তা। আপনি এই মানটি খুঁজে পেতে পারেন Cloud ConsoleClients page.
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 API অ্যাক্সেস করতে সক্ষম করে। (প্রতিক্রিয়ার scope প্রপার্টি নির্ধারণ করে যে ডিভাইসটি কোন API অ্যাক্সেস করতে পারবে।)

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

ক্ষেত্র
access_token আপনার অ্যাপ্লিকেশনটি একটি Google API অনুরোধ অনুমোদনের জন্য যে টোকেনটি পাঠায়।
expires_in অ্যাক্সেস টোকেনের অবশিষ্ট জীবনকাল সেকেন্ডে।
refresh_token একটি টোকেন যা ব্যবহার করে আপনি একটি নতুন অ্যাক্সেস টোকেন পেতে পারেন। ব্যবহারকারী অ্যাক্সেস প্রত্যাহার না করা পর্যন্ত অথবা রিফ্রেশ টোকেনের মেয়াদ শেষ না হওয়া পর্যন্ত রিফ্রেশ টোকেনগুলি বৈধ থাকবে। মনে রাখবেন যে রিফ্রেশ টোকেনগুলি সর্বদা ডিভাইসের জন্য ফেরত দেওয়া হয়।
refresh_token_expires_in রিফ্রেশ টোকেনের অবশিষ্ট জীবনকাল সেকেন্ডে। এই মানটি কেবল তখনই সেট করা হয় যখন ব্যবহারকারী সময়-ভিত্তিক অ্যাক্সেস মঞ্জুর করে।
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 ক্লায়েন্টের ধরণটি ভুল। ক্লায়েন্ট আইডির জন্য অ্যাপ্লিকেশনের ধরণটি TV এবং Limited Input devices এ সেট করা আছে কিনা তা নিশ্চিত করুন।

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

গুগল এপিআই কল করা হচ্ছে

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

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

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 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&
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 হবে। ত্রুটির অবস্থার জন্য, একটি 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

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

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

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

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

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

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