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

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

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

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

বিকল্প

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

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

পূর্বশর্ত

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

আপনার আবেদনের জন্য ক্লায়েন্ট আইডি। আপনি এই মান খুঁজে পেতে পারেন API ConsoleCredentials page.

scope প্রয়োজন

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

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

উদাহরণ

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

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

client_id=client_id&scope=email%20profile

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

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

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

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

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

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

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

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

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

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

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

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

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

{
  "error_code": "rate_limit_exceeded"
}

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

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

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

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

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

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

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

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

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

,

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

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

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

বিকল্প

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

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

পূর্বশর্ত

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

আপনার আবেদনের জন্য ক্লায়েন্ট আইডি। আপনি এই মান খুঁজে পেতে পারেন API ConsoleCredentials page.

scope প্রয়োজন

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

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

উদাহরণ

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

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

client_id=client_id&scope=email%20profile

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

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

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

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

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

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

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

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

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

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

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

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

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

{
  "error_code": "rate_limit_exceeded"
}

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

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

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

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

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

ধাপ 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 অ্যাডমিনিস্ট্রেটরের নীতির কারণে অনুরোধ করা এক বা একাধিক স্কোপের অনুমোদন দিতে পারে না। গুগল ওয়ার্কস্পেস অ্যাডমিন সহায়তা নিবন্ধ নিয়ন্ত্রণে দেখুন যা তৃতীয় পক্ষ এবং অভ্যন্তরীণ অ্যাপ্লিকেশনগুলি গুগল ওয়ার্কস্পেস ডেটা অ্যাক্সেস করে কীভাবে কোনও প্রশাসক আপনার ওএথ ক্লায়েন্ট আইডিতে অ্যাক্সেস স্পষ্টভাবে মঞ্জুর না করা পর্যন্ত স্কোপগুলিতে কীভাবে অ্যাক্সেসকে সীমাবদ্ধ করতে পারে সে সম্পর্কে আরও তথ্যের জন্য।
invalid_client 401

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

OAuth ক্লায়েন্টের ধরণটি ভুল। ক্লায়েন্ট আইডির জন্য অ্যাপ্লিকেশন প্রকারটি টিভি এবং সীমিত ইনপুট ডিভাইসে সেট করা আছে তা নিশ্চিত করুন।

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

গুগল এপিআই কল করছে

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

আপনি সমস্ত গুগল এপিআই চেষ্টা করে দেখতে পারেন এবং ওএথ ২.০ খেলার মাঠে তাদের স্কোপগুলি দেখতে পারেন।

Http উদাহরণ পেতে

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

GET /drive/v2/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

access_token ক্যোয়ারী স্ট্রিং প্যারামিটারটি ব্যবহার করে প্রমাণীকরণ করা ব্যবহারকারীর জন্য একই এপিআইয়ের কাছে এখানে একটি কল রয়েছে: 

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

curl উদাহরণ

আপনি এই কমান্ডগুলি curl কমান্ড-লাইন অ্যাপ্লিকেশন দিয়ে পরীক্ষা করতে পারেন। এখানে একটি উদাহরণ যা এইচটিটিপি শিরোনাম বিকল্পটি ব্যবহার করে (পছন্দসই): 

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

একটি অ্যাক্সেস টোকেন রিফ্রেশ করা হচ্ছে

অ্যাক্সেস টোকেনগুলি পর্যায়ক্রমে মেয়াদ শেষ হয়ে যায় এবং সম্পর্কিত এপিআই অনুরোধের জন্য অবৈধ শংসাপত্রগুলিতে পরিণত হয়। আপনি যদি টোকেনের সাথে সম্পর্কিত স্কোপগুলিতে অফলাইন অ্যাক্সেসের জন্য অনুরোধ করেন তবে আপনি অনুমতিের জন্য ব্যবহারকারীকে অনুরোধ না করে একটি অ্যাক্সেস টোকেন রিফ্রেশ করতে পারেন (ব্যবহারকারী উপস্থিত না সহ)।

অ্যাক্সেস টোকেন রিফ্রেশ করতে, আপনার অ্যাপ্লিকেশনটি গুগলের অনুমোদনের সার্ভারে ( https://oauth2.googleapis.com/token ) একটি এইচটিটিপিএস 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&
client_secret=your_client_secret&
refresh_token=refresh_token&
grant_type=refresh_token

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

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "https://www.googleapis.com/auth/drive.metadata.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 । ত্রুটির শর্তগুলির জন্য, একটি এইচটিটিপি স্থিতি কোড 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

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

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

গুগলের ক্রস-অ্যাকাউন্ট সুরক্ষা পরিষেবা দ্বারা আপনার অ্যাপে প্রেরিত ইভেন্টের ধরণের কয়েকটি উদাহরণ হ'ল:

  • 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

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

,

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

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

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

বিকল্প

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

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

পূর্বশর্ত

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

যে কোনও অ্যাপ্লিকেশন যা গুগল এপিআইকে কল করে তাদের মধ্যে সেই এপিআইগুলি সক্ষম করতে হবে API Console.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

আপনার আবেদনের জন্য ক্লায়েন্ট আইডি। আপনি এই মানটি খুঁজে পেতে পারেন API ConsoleCredentials page.

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

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

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

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

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

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

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

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

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

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

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

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

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

জরিপের শেষ পয়েন্টের ইউআরএল হ'ল 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 প্রবেশের পরে এবং যদি ইতিমধ্যে লগ ইন না করা হয়, গুগলে লগ ইন করে, ব্যবহারকারী নীচের প্রদর্শিতগুলির মতো সম্মতি স্ক্রিনটি দেখেন:

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

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

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

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

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

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

ক্ষেত্র
access_token আপনার অ্যাপ্লিকেশনটি গুগল এপিআই অনুরোধ অনুমোদনের জন্য যে টোকেন প্রেরণ করে।
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"
}

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

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

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

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

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

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

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

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

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

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

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

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

ত্রুটি HTTP স্ট্যাটাস কোড বর্ণনা
admin_policy_enforced 400 Google অ্যাকাউন্ট তাদের Google Workspace অ্যাডমিনিস্ট্রেটরের নীতির কারণে অনুরোধ করা এক বা একাধিক স্কোপের অনুমোদন দিতে পারে না। গুগল ওয়ার্কস্পেস অ্যাডমিন সহায়তা নিবন্ধ নিয়ন্ত্রণে দেখুন যা তৃতীয় পক্ষ এবং অভ্যন্তরীণ অ্যাপ্লিকেশনগুলি গুগল ওয়ার্কস্পেস ডেটা অ্যাক্সেস করে কীভাবে কোনও প্রশাসক আপনার ওএথ ক্লায়েন্ট আইডিতে অ্যাক্সেস স্পষ্টভাবে মঞ্জুর না করা পর্যন্ত স্কোপগুলিতে কীভাবে অ্যাক্সেসকে সীমাবদ্ধ করতে পারে সে সম্পর্কে আরও তথ্যের জন্য।
invalid_client 401

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

OAuth ক্লায়েন্টের ধরণটি ভুল। ক্লায়েন্ট আইডির জন্য অ্যাপ্লিকেশন প্রকারটি টিভি এবং সীমিত ইনপুট ডিভাইসে সেট করা আছে তা নিশ্চিত করুন।

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

গুগল এপিআই কল করছে

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

আপনি সমস্ত গুগল এপিআই চেষ্টা করে দেখতে পারেন এবং ওএথ ২.০ খেলার মাঠে তাদের স্কোপগুলি দেখতে পারেন।

Http উদাহরণ পেতে

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

GET /drive/v2/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

access_token ক্যোয়ারী স্ট্রিং প্যারামিটারটি ব্যবহার করে প্রমাণীকরণ করা ব্যবহারকারীর জন্য একই এপিআইয়ের কাছে এখানে একটি কল রয়েছে: 

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

curl উদাহরণ

আপনি এই কমান্ডগুলি curl কমান্ড-লাইন অ্যাপ্লিকেশন দিয়ে পরীক্ষা করতে পারেন। এখানে একটি উদাহরণ যা এইচটিটিপি শিরোনাম বিকল্পটি ব্যবহার করে (পছন্দসই): 

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

একটি অ্যাক্সেস টোকেন রিফ্রেশ করা হচ্ছে

অ্যাক্সেস টোকেনগুলি পর্যায়ক্রমে মেয়াদ শেষ হয়ে যায় এবং সম্পর্কিত এপিআই অনুরোধের জন্য অবৈধ শংসাপত্রগুলিতে পরিণত হয়। আপনি যদি টোকেনের সাথে সম্পর্কিত স্কোপগুলিতে অফলাইন অ্যাক্সেসের জন্য অনুরোধ করেন তবে আপনি অনুমতিের জন্য ব্যবহারকারীকে অনুরোধ না করে একটি অ্যাক্সেস টোকেন রিফ্রেশ করতে পারেন (ব্যবহারকারী উপস্থিত না সহ)।

অ্যাক্সেস টোকেন রিফ্রেশ করতে, আপনার অ্যাপ্লিকেশনটি গুগলের অনুমোদনের সার্ভারে ( https://oauth2.googleapis.com/token ) একটি এইচটিটিপিএস 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&
client_secret=your_client_secret&
refresh_token=refresh_token&
grant_type=refresh_token

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

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "https://www.googleapis.com/auth/drive.metadata.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 । ত্রুটির শর্তগুলির জন্য, একটি এইচটিটিপি স্থিতি কোড 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

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

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

গুগলের ক্রস-অ্যাকাউন্ট সুরক্ষা পরিষেবা দ্বারা আপনার অ্যাপে প্রেরিত ইভেন্টের ধরণের কয়েকটি উদাহরণ হ'ল:

  • 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

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