টিভি এবং লিমিটেড-ইনপুট ডিভাইস অ্যাপ্লিকেশনের জন্য 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 Consoleএ সেই APIগুলি সক্ষম করতে হবে।

আপনার প্রকল্পের জন্য একটি 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 উভয় রূপই পরিচালনা করতে পারে।

ধাপ 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",
  "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