টিভি এবং সীমিত-ইনপুট ডিভাইস অ্যাপ্লিকেশনের জন্য 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 ID টোকেন ব্যবহার করতে চান, তাহলে 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 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" \
         /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 স্ট্যাটাস কোড বর্ণনা
invalid_client 401 OAuth ক্লায়েন্ট খুঁজে পাওয়া যায়নি. উদাহরণস্বরূপ, client_id প্যারামিটার মান অবৈধ হলে এই ত্রুটিটি ঘটে।
invalid_grant 400 code প্যারামিটার মান অবৈধ।
unsupported_grant_type 400 grant_type প্যারামিটার মানটি অবৈধ।

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