এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

মোবাইল এবং ডেস্কটপ অ্যাপের জন্য OAuth 2.0

এই ডকুমেন্টে ব্যাখ্যা করা হয়েছে যে ফোন, ট্যাবলেট এবং কম্পিউটারের মতো ডিভাইসে ইনস্টল করা অ্যাপ্লিকেশনগুলি কীভাবে YouTube Analytics API বা YouTube Reporting API-তে অ্যাক্সেস অনুমোদনের জন্য Google-এর OAuth 2.0 এন্ডপয়েন্ট ব্যবহার করে।

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

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

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

লাইব্রেরি এবং নমুনা

iOS অ্যাপের জন্য আমরা Sign In With Google iOS SDK এর সর্বশেষ সংস্করণ ব্যবহার করার পরামর্শ দিচ্ছি। SDK ব্যবহারকারীর অনুমোদন পরিচালনা করে এবং এই নির্দেশিকায় বর্ণিত নিম্ন-স্তরের প্রোটোকলের তুলনায় এটি বাস্তবায়ন করা সহজ।

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

পূর্বশর্ত

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

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

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

Open the API Library মধ্যে Google API Console.
If prompted, select a project, or create a new one.
YouTube Analytics API এবং YouTube Reporting API খুঁজে বের করতে এবং সক্ষম করতে লাইব্রেরি পৃষ্ঠাটি ব্যবহার করুন। YouTube Analytics ডেটা পুনরুদ্ধার করে এমন অনেক অ্যাপ্লিকেশন YouTube Data API-এর সাথেও ইন্টারফেস করে। আপনার অ্যাপ্লিকেশন ব্যবহার করবে এমন অন্য কোনও API খুঁজুন এবং সেগুলিও সক্ষম করুন।

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

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

Go to the Clients page.
ক্লায়েন্ট তৈরি করুন ক্লিক করুন।
নিম্নলিখিত বিভাগগুলিতে Google এর অনুমোদন সার্ভার যে ধরণের ক্লায়েন্ট সমর্থন করে তা বর্ণনা করা হয়েছে। আপনার অ্যাপ্লিকেশনের জন্য প্রস্তাবিত ক্লায়েন্ট ধরণেরটি চয়ন করুন, আপনার OAuth ক্লায়েন্টের নাম দিন এবং ফর্মের অন্যান্য ক্ষেত্রগুলি যথাযথভাবে সেট করুন।

আইওএস

iOS অ্যাপ্লিকেশনের ধরণ নির্বাচন করুন।
OAuth ক্লায়েন্টের জন্য একটি নাম লিখুন। এই নামটি আপনার প্রকল্পের Clients page ক্লায়েন্টকে সনাক্ত করতে।
আপনার অ্যাপের জন্য বান্ডেল আইডেন্টিফায়ার লিখুন। বান্ডেল আইডি হল আপনার অ্যাপের তথ্য সম্পত্তি তালিকা রিসোর্স ফাইল ( info.plist ) এর CFBundleIdentifier কী এর মান। মানটি সাধারণত Xcode প্রজেক্ট এডিটরের জেনারেল প্যানে অথবা সাইনিং এবং ক্যাপাবিলিটিস প্যানে প্রদর্শিত হয়। অ্যাপলের অ্যাপ স্টোর কানেক্ট সাইটে অ্যাপের অ্যাপ তথ্য পৃষ্ঠার জেনারেল ইনফরমেশন বিভাগেও বান্ডেল আইডি প্রদর্শিত হয়।
আপনার অ্যাপের জন্য সঠিক বান্ডেল আইডি ব্যবহার করছেন কিনা তা নিশ্চিত করুন, কারণ আপনি যদি অ্যাপ চেক বৈশিষ্ট্যটি ব্যবহার করেন তবে এটি পরিবর্তন করতে পারবেন না।
(ঐচ্ছিক)
যদি অ্যাপটি অ্যাপলের অ্যাপ স্টোরে প্রকাশিত হয়, তাহলে আপনার অ্যাপের অ্যাপ স্টোর আইডি লিখুন। স্টোর আইডি হল প্রতিটি অ্যাপল অ্যাপ স্টোর URL-এ অন্তর্ভুক্ত একটি সংখ্যাসূচক স্ট্রিং।
1. আপনার iOS বা iPadOS ডিভাইসে Apple App Store অ্যাপটি খুলুন।
2. আপনার অ্যাপটি খুঁজুন।
3. শেয়ার বোতামটি নির্বাচন করুন (বর্গাকার এবং তীরচিহ্ন উপরের দিকে)।
4. লিঙ্ক কপি করুন নির্বাচন করুন।
5. লিঙ্কটি একটি টেক্সট এডিটরে পেস্ট করুন। অ্যাপ স্টোর আইডি হল URL এর শেষ অংশ।
  উদাহরণ: https://apps.apple.com/app/google/id 284815942
(ঐচ্ছিক)
আপনার টিম আইডি লিখুন। আরও তথ্যের জন্য অ্যাপল ডেভেলপার অ্যাকাউন্ট ডকুমেন্টেশনে আপনার টিম আইডি সনাক্ত করুন দেখুন।
দ্রষ্টব্য: আপনার ক্লায়েন্টের জন্য অ্যাপ চেক সক্ষম করলে টিম আইডি ফিল্ডটি প্রয়োজন।
(ঐচ্ছিক)
আপনার iOS অ্যাপের জন্য অ্যাপ চেক সক্ষম করুন। যখন আপনি অ্যাপ চেক সক্ষম করেন, তখন আপনার OAuth ক্লায়েন্ট থেকে আসা OAuth 2.0 অনুরোধগুলি আসল কিনা এবং আপনার অ্যাপ থেকে এসেছে তা যাচাই করার জন্য Apple এর অ্যাপ অ্যাটেস্ট পরিষেবা ব্যবহার করা হয়। এটি অ্যাপের ছদ্মবেশ ধারণের ঝুঁকি কমাতে সাহায্য করে। আপনার iOS অ্যাপের জন্য অ্যাপ চেক সক্ষম করার বিষয়ে আরও জানুন ।
তৈরি করুন ক্লিক করুন।

ইউডব্লিউপি

ইউনিভার্সাল উইন্ডোজ প্ল্যাটফর্ম অ্যাপ্লিকেশন টাইপ নির্বাচন করুন।
OAuth ক্লায়েন্টের জন্য একটি নাম লিখুন। এই নামটি আপনার প্রকল্পের Clients page ক্লায়েন্টকে সনাক্ত করতে।
আপনার অ্যাপের ১২-অক্ষরের Microsoft Store ID লিখুন। আপনি এই মানটি Microsoft Partner Center- এ অ্যাপ ম্যানেজমেন্ট বিভাগে অ্যাপ পরিচয় পৃষ্ঠায় খুঁজে পেতে পারেন।
তৈরি করুন ক্লিক করুন।

UWP অ্যাপের জন্য, আপনার অ্যাপ্লিকেশনের অনন্য প্যাকেজ সিকিউরিটি আইডেন্টিফায়ার (SID) ব্যবহার করে রিডাইরেক্ট URI তৈরি করা হয়। আপনি আপনার ভিজ্যুয়াল স্টুডিও প্রজেক্টের মধ্যে Package.appxmanifest ফাইলে আপনার অ্যাপের Package SID খুঁজে পেতে পারেন।

যখন আপনি Google Cloud Console-এ আপনার ক্লায়েন্ট আইডি তৈরি করবেন, তখন আপনাকে আপনার প্যাকেজ SID-এর ছোট হাতের মান ব্যবহার করে নিম্নলিখিত ফর্ম্যাটে রিডাইরেক্ট URI নির্দিষ্ট করতে হবে:

ms-app://YOUR_APP_PACKAGE_SID

দ্রষ্টব্য: OAuth 2.0 রিডাইরেক্ট সঠিকভাবে কাজ করার জন্য ms-app:// স্কিমটি প্রয়োজন। এই স্কিমটি প্রোটোকল অ্যাক্টিভেশনের জন্য ব্যবহৃত হয়, যা অপারেটিং সিস্টেমকে আপনার অ্যাপ্লিকেশন চালু করতে এবং ব্যবহারকারী ব্রাউজারে প্রমাণীকরণের পরে Google থেকে অনুমোদনের প্রতিক্রিয়া সরবরাহ করতে দেয়।

UWP অ্যাপের জন্য, কাস্টম URI স্কিম 39 অক্ষরের বেশি হতে পারে না, যেমনটি Microsoft ডকুমেন্টেশনে উল্লেখ করা হয়েছে।

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

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

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

YouTube Analytics API নিম্নলিখিত স্কোপ ব্যবহার করে:

ব্যাপ্তি	বর্ণনা
`https://www. googleapis. com/ auth/ youtube`	আপনার YouTube অ্যাকাউন্ট পরিচালনা করুন
`https://www. googleapis. com/ auth/ youtube. readonly`	আপনার YouTube অ্যাকাউন্ট দেখুন
`https://www. googleapis. com/ auth/ youtubepartner`	YouTube-এ আপনার সম্পদ এবং সংশ্লিষ্ট বিষয়বস্তু দেখুন ও পরিচালনা করুন
`https://www. googleapis. com/ auth/ yt-analytics-monetary. readonly`	আপনার YouTube সামগ্রীর জন্য আর্থিক এবং অ-আর্থিক YouTube বিশ্লেষণ প্রতিবেদনগুলি দেখুন৷
`https://www. googleapis. com/ auth/ yt-analytics. readonly`	আপনার YouTube সামগ্রীর জন্য YouTube বিশ্লেষণ প্রতিবেদনগুলি দেখুন৷

YouTube রিপোর্টিং API নিম্নলিখিত স্কোপ ব্যবহার করে:

ব্যাপ্তি	বর্ণনা
`https://www. googleapis. com/ auth/ yt-analytics-monetary. readonly`	আপনার YouTube সামগ্রীর জন্য আর্থিক এবং অ-আর্থিক YouTube বিশ্লেষণ প্রতিবেদনগুলি দেখুন৷
`https://www. googleapis. com/ auth/ yt-analytics. readonly`	আপনার YouTube সামগ্রীর জন্য YouTube বিশ্লেষণ প্রতিবেদনগুলি দেখুন৷

OAuth 2.0 API Scopes ডকুমেন্টে এমন স্কোপের একটি সম্পূর্ণ তালিকা রয়েছে যা আপনি Google API অ্যাক্সেস করতে ব্যবহার করতে পারেন।

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

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

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

ধাপ ১: একটি কোড যাচাইকারী তৈরি করুন এবং চ্যালেঞ্জ করুন

ইনস্টল করা অ্যাপের প্রবাহকে আরও নিরাপদ করার জন্য গুগল প্রুফ কী ফর কোড এক্সচেঞ্জ (PKCE) প্রোটোকল সমর্থন করে। প্রতিটি অনুমোদনের অনুরোধের জন্য একটি অনন্য কোড যাচাইকারী তৈরি করা হয় এবং এর রূপান্তরিত মান, যাকে "code_challenge" বলা হয়, অনুমোদনের কোডটি পাওয়ার জন্য অনুমোদন সার্ভারে পাঠানো হয়।

কোড যাচাইকারী তৈরি করুন

একটি code_verifier হল একটি উচ্চ-এনট্রপি ক্রিপ্টোগ্রাফিক র‍্যান্ডম স্ট্রিং যা অসংরক্ষিত অক্ষর [AZ] / [az] / [0-9] / "-" / "." / "_" / "~" ব্যবহার করে, যার দৈর্ঘ্য সর্বনিম্ন 43 অক্ষর এবং সর্বোচ্চ 128 অক্ষর।

কোড যাচাইকারীতে পর্যাপ্ত এনট্রপি থাকা উচিত যাতে মান অনুমান করা অসম্ভব হয়ে পড়ে।

কোড চ্যালেঞ্জ তৈরি করুন

কোড চ্যালেঞ্জ তৈরির দুটি পদ্ধতি সমর্থিত।

কোড চ্যালেঞ্জ জেনারেশন পদ্ধতি
S256 (প্রস্তাবিত)	কোড চ্যালেঞ্জ হল কোড যাচাইকারীর Base64URL (কোনও প্যাডিং ছাড়াই) এনকোডেড SHA256 হ্যাশ। `code_challenge` = BASE64URL-ENCODE(SHA256(ASCII(`code_verifier`)))
সরল	কোড চ্যালেঞ্জের মান উপরে তৈরি কোড যাচাইকারীর মান অনুসারে। `code_challenge` = `code_verifier`

ধাপ ২: Google এর OAuth 2.0 সার্ভারে একটি অনুরোধ পাঠান

ব্যবহারকারীর অনুমোদন পেতে, https://accounts.google.com/o/oauth2/v2/auth ঠিকানায় Google এর অনুমোদন সার্ভারে একটি অনুরোধ পাঠান। এই এন্ডপয়েন্টটি সক্রিয় সেশন লুকআপ পরিচালনা করে, ব্যবহারকারীকে প্রমাণীকরণ করে এবং ব্যবহারকারীর সম্মতি গ্রহণ করে। এন্ডপয়েন্টটি শুধুমাত্র SSL এর মাধ্যমে অ্যাক্সেসযোগ্য এবং এটি HTTP (নন-SSL) সংযোগগুলি প্রত্যাখ্যান করে।

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

পরামিতি

client_id

প্রয়োজনীয়

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

redirect_uri

প্রয়োজনীয়

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

মানটি অবশ্যই OAuth 2.0 ক্লায়েন্টের জন্য অনুমোদিত পুনর্নির্দেশ URI গুলির একটির সাথে হুবহু মিলতে হবে, যা আপনি আপনার ক্লায়েন্টের Cloud ConsoleClients page. যদি এই মানটি কোনও অনুমোদিত URI-এর সাথে না মেলে, তাহলে আপনি একটি redirect_uri_mismatch ত্রুটি পাবেন।

টেবিলটি প্রতিটি পদ্ধতির জন্য উপযুক্ত redirect_uri প্যারামিটার মান দেখায়:

redirect_uri মান

কাস্টম URI স্কিম

com.example.app : redirect_uri_path

অথবা

com.googleusercontent.apps.123 : redirect_uri_path

com.example.app হল আপনার নিয়ন্ত্রণাধীন একটি ডোমেনের বিপরীত DNS নোটেশন। কাস্টম স্কিমে বৈধ হওয়ার জন্য একটি সময়কাল থাকতে হবে।
com.googleusercontent.apps.123 হল ক্লায়েন্ট আইডির বিপরীত DNS নোটেশন।
redirect_uri_path হল একটি ঐচ্ছিক পাথ কম্পোনেন্ট, যেমন /oauth2redirect । মনে রাখবেন যে পাথটি একটি একক স্ল্যাশ দিয়ে শুরু হওয়া উচিত, যা নিয়মিত HTTP URL থেকে আলাদা।

লুপব্যাক আইপি ঠিকানা

http://127.0.0.1: port অথবা http://[::1]: port

আপনার প্ল্যাটফর্ম থেকে প্রাসঙ্গিক লুপব্যাক আইপি ঠিকানাটি অনুসন্ধান করুন এবং একটি র‍্যান্ডম উপলব্ধ পোর্টে একটি HTTP লিসেনার শুরু করুন। আপনার অ্যাপ যে পোর্ট নম্বরটি শোনে তার সাথে port প্রতিস্থাপন করুন।

মনে রাখবেন যে মোবাইল অ্যাপে লুপব্যাক আইপি অ্যাড্রেস রিডাইরেক্ট অপশনের জন্য সমর্থন DEPRECATED ।

response_type

প্রয়োজনীয়

Google OAuth 2.0 এন্ডপয়েন্ট কোনও অনুমোদন কোড ফেরত দেয় কিনা তা নির্ধারণ করে।

ইনস্টল করা অ্যাপ্লিকেশনের জন্য প্যারামিটার মান code সেট করুন।

scope

প্রয়োজনীয়

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

YouTube Analytics API নিম্নলিখিত স্কোপ ব্যবহার করে:

ব্যাপ্তি	বর্ণনা
`https://www. googleapis. com/ auth/ youtube`	আপনার YouTube অ্যাকাউন্ট পরিচালনা করুন
`https://www. googleapis. com/ auth/ youtube. readonly`	আপনার YouTube অ্যাকাউন্ট দেখুন
`https://www. googleapis. com/ auth/ youtubepartner`	YouTube-এ আপনার সম্পদ এবং সংশ্লিষ্ট বিষয়বস্তু দেখুন ও পরিচালনা করুন
`https://www. googleapis. com/ auth/ yt-analytics-monetary. readonly`	আপনার YouTube সামগ্রীর জন্য আর্থিক এবং অ-আর্থিক YouTube বিশ্লেষণ প্রতিবেদনগুলি দেখুন৷
`https://www. googleapis. com/ auth/ yt-analytics. readonly`	আপনার YouTube সামগ্রীর জন্য YouTube বিশ্লেষণ প্রতিবেদনগুলি দেখুন৷

YouTube রিপোর্টিং API নিম্নলিখিত স্কোপ ব্যবহার করে:

ব্যাপ্তি	বর্ণনা
`https://www. googleapis. com/ auth/ yt-analytics-monetary. readonly`	আপনার YouTube সামগ্রীর জন্য আর্থিক এবং অ-আর্থিক YouTube বিশ্লেষণ প্রতিবেদনগুলি দেখুন৷
`https://www. googleapis. com/ auth/ yt-analytics. readonly`	আপনার YouTube সামগ্রীর জন্য YouTube বিশ্লেষণ প্রতিবেদনগুলি দেখুন৷

OAuth 2.0 API Scopes ডকুমেন্টে Google API অ্যাক্সেস করার জন্য আপনি যে স্কোপগুলি ব্যবহার করতে পারেন তার একটি সম্পূর্ণ তালিকা রয়েছে।

code_challenge

প্রস্তাবিত

একটি এনকোডেড code_verifier নির্দিষ্ট করে যা অনুমোদন কোড বিনিময়ের সময় সার্ভার-সাইড চ্যালেঞ্জ হিসেবে ব্যবহৃত হবে। আরও তথ্যের জন্য কোড চ্যালেঞ্জ তৈরি করুন দেখুন।

code_challenge_method

প্রস্তাবিত

অনুমোদন কোড বিনিময়ের সময় ব্যবহৃত code_verifier এনকোডিং করার জন্য কোন পদ্ধতি ব্যবহার করা হয়েছিল তা নির্দিষ্ট করে। এই প্যারামিটারটি code_challenge প্যারামিটারের সাথে ব্যবহার করা আবশ্যক। code_challenge_method এর মান ডিফল্টভাবে plain হিসেবে গণ্য হবে যদি code_challenge অন্তর্ভুক্ত অনুরোধে উপস্থিত না থাকে। এই প্যারামিটারের জন্য শুধুমাত্র সমর্থিত মান হল S256 অথবা plain ।

state

প্রস্তাবিত

আপনার অনুমোদনের অনুরোধ এবং অনুমোদন সার্ভারের প্রতিক্রিয়ার মধ্যে অবস্থা বজায় রাখার জন্য আপনার অ্যাপ্লিকেশন যে স্ট্রিং মান ব্যবহার করে তা নির্দিষ্ট করে। ব্যবহারকারী আপনার অ্যাপ্লিকেশনের অ্যাক্সেস অনুরোধে সম্মতি দেওয়ার বা প্রত্যাখ্যান করার পরে সার্ভারটি redirect_uri এর URL ফ্র্যাগমেন্ট আইডেন্টিফায়ার ( # ) তে name=value জোড়া হিসাবে আপনার পাঠানো সঠিক মানটি ফেরত দেয়।

আপনি এই প্যারামিটারটি বিভিন্ন উদ্দেশ্যে ব্যবহার করতে পারেন, যেমন আপনার অ্যাপ্লিকেশনের সঠিক রিসোর্সে ব্যবহারকারীকে নির্দেশ করা, ননসেস পাঠানো এবং ক্রস-সাইট রিকোয়েস্ট ফোরজির প্রশমন করা। যেহেতু আপনার redirect_uri অনুমান করা যেতে পারে, তাই একটি state মান ব্যবহার করলে আপনার আশ্বাস বৃদ্ধি পেতে পারে যে একটি ইনকামিং সংযোগ একটি প্রমাণীকরণ অনুরোধের ফলাফল। যদি আপনি একটি র্যান্ডম স্ট্রিং তৈরি করেন বা একটি কুকির হ্যাশ বা অন্য কোনও মানের এনকোড করেন যা ক্লায়েন্টের অবস্থা ক্যাপচার করে, তাহলে আপনি প্রতিক্রিয়াটি যাচাই করতে পারেন যাতে অতিরিক্তভাবে নিশ্চিত করা যায় যে অনুরোধ এবং প্রতিক্রিয়া একই ব্রাউজারে উৎপন্ন হয়েছে, যা ক্রস-সাইট রিকোয়েস্ট ফোরজির মতো আক্রমণের বিরুদ্ধে সুরক্ষা প্রদান করে। একটি state টোকেন কীভাবে তৈরি এবং নিশ্চিত করতে হয় তার উদাহরণের জন্য OpenID Connect ডকুমেন্টেশন দেখুন।

গুরুত্বপূর্ণ: OAuth ক্লায়েন্টকে অবশ্যই OAuth2 স্পেসিফিকেশনে উল্লেখিত CSRF প্রতিরোধ করতে হবে। এটি অর্জনের একটি উপায় হল state প্যারামিটার ব্যবহার করে আপনার অনুমোদনের অনুরোধ এবং অনুমোদন সার্ভারের প্রতিক্রিয়ার মধ্যে অবস্থা বজায় রাখা।

login_hint

ঐচ্ছিক

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

প্যারামিটারের মানটি একটি ইমেল ঠিকানা বা sub আইডেন্টিফায়ারে সেট করুন, যা ব্যবহারকারীর গুগল আইডির সমতুল্য।

দ্রষ্টব্য: ইনস্টল করা অ্যাপগুলির সাথে ক্রমবর্ধমান অনুমোদন সমর্থিত নয় কারণ ক্লায়েন্ট client_secret গোপন রাখতে পারে না।

নমুনা অনুমোদনের URL গুলি

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

প্রতিটি URL এমন একটি স্কোপে অ্যাক্সেসের অনুরোধ করে যা ব্যবহারকারীর YouTube Analytics রিপোর্ট পুনরুদ্ধার করার জন্য অ্যাক্সেসের অনুমতি দেয়।

redirect_uri প্যারামিটারের মান ছাড়া URL গুলি অভিন্ন। URL গুলিতে প্রয়োজনীয় response_type এবং client_id প্যারামিটারের পাশাপাশি ঐচ্ছিক state প্যারামিটারও থাকে। প্রতিটি URL তে পঠনযোগ্যতার জন্য লাইন ব্রেক এবং স্পেস থাকে।

কাস্টম URI স্কিম

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyt-analytics.readonly&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=com.example.app%3A/oauth2redirect&
 client_id=client_id

লুপব্যাক আইপি ঠিকানা

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyt-analytics.readonly&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=http%3A//127.0.0.1%3A9004&
 client_id=client_id

ধাপ ৩: গুগল ব্যবহারকারীর কাছ থেকে সম্মতির অনুরোধ জানায়

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

আপনার অ্যাপ্লিকেশনটিকে এই পর্যায়ে কিছু করার প্রয়োজন নেই কারণ এটি Google এর OAuth 2.0 সার্ভার থেকে কোনও অ্যাক্সেস মঞ্জুর করা হয়েছে কিনা তা নির্দেশ করে প্রতিক্রিয়ার জন্য অপেক্ষা করে। সেই প্রতিক্রিয়াটি নিম্নলিখিত ধাপে ব্যাখ্যা করা হয়েছে।

ত্রুটি

Google এর OAuth 2.0 অনুমোদনের শেষ বিন্দুতে অনুরোধ করলে প্রত্যাশিত প্রমাণীকরণ এবং অনুমোদন প্রবাহের পরিবর্তে ব্যবহারকারী-মুখী ত্রুটি বার্তা প্রদর্শিত হতে পারে। সাধারণ ত্রুটি কোড এবং প্রস্তাবিত সমাধানগুলি হল:

`admin_policy_enforced`

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

`disallowed_useragent`

অনুমোদনের শেষ বিন্দুটি একটি এমবেডেড ব্যবহারকারী-এজেন্টের ভিতরে প্রদর্শিত হয় যা Google এর OAuth 2.0 নীতি দ্বারা অনুমোদিত নয়।

iOS এবং macOS ডেভেলপাররা WKWebView এ অনুমোদনের অনুরোধ খোলার সময় এই ত্রুটির সম্মুখীন হতে পারেন। ডেভেলপারদের পরিবর্তে iOS লাইব্রেরি ব্যবহার করা উচিত যেমন iOS-এর জন্য Google Sign-In অথবা iOS-এর জন্য OpenID Foundation-এর AppAuth ।

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

`org_internal`

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

`deleted_client`

অনুরোধটি করার জন্য ব্যবহৃত OAuth ক্লায়েন্টটি মুছে ফেলা হয়েছে। অব্যবহৃত ক্লায়েন্টের ক্ষেত্রে মুছে ফেলা ম্যানুয়ালি বা স্বয়ংক্রিয়ভাবে ঘটতে পারে। মুছে ফেলা ক্লায়েন্টগুলি মুছে ফেলার 30 দিনের মধ্যে পুনরুদ্ধার করা যেতে পারে। আরও জানুন ।

`invalid_grant`

যদি আপনি একটি কোড যাচাইকারী এবং চ্যালেঞ্জ ব্যবহার করেন, তাহলে code_callenge প্যারামিটারটি অবৈধ বা অনুপস্থিত। নিশ্চিত করুন যে code_challenge প্যারামিটারটি সঠিকভাবে সেট করা আছে।

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

`redirect_uri_mismatch`

অনুমোদনের অনুরোধে পাস করা redirect_uri OAuth ক্লায়েন্ট আইডির জন্য অনুমোদিত পুনর্নির্দেশ URI-এর সাথে মেলে না। অনুমোদিত পুনর্নির্দেশ URI গুলি পর্যালোচনা করুন Google Cloud ConsoleClients page.

পাস করা redirect_uri ক্লায়েন্ট ধরণের জন্য অবৈধ হতে পারে।

redirect_uri প্যারামিটারটি OAuth আউট-অফ-ব্যান্ড (OOB) ফ্লোকে নির্দেশ করতে পারে যা বন্ধ করে দেওয়া হয়েছে এবং আর সমর্থিত নয়। আপনার ইন্টিগ্রেশন আপডেট করতে মাইগ্রেশন গাইডটি দেখুন।

`invalid_request`

আপনার অনুরোধে কিছু সমস্যা ছিল। এটি বিভিন্ন কারণে হতে পারে:

অনুরোধটি সঠিকভাবে ফর্ম্যাট করা হয়নি।
অনুরোধটিতে প্রয়োজনীয় প্যারামিটার অনুপস্থিত ছিল
অনুরোধটি এমন একটি অনুমোদন পদ্ধতি ব্যবহার করে যা Google সমর্থন করে না। আপনার OAuth ইন্টিগ্রেশনটি একটি প্রস্তাবিত ইন্টিগ্রেশন পদ্ধতি ব্যবহার করে তা যাচাই করুন।
রিডাইরেক্ট uri-এর জন্য একটি অসমর্থিত কাস্টম স্কিম ব্যবহার করা হয়েছে। যদি আপনি "Custom URI স্কিম Android বা Chrome অ্যাপে সমর্থিত নয়" ত্রুটি বার্তাটি দেখতে পান, তাহলে কাস্টম URI স্কিম বিকল্পগুলি সম্পর্কে আরও জানুন ।

ধাপ ৪: OAuth 2.0 সার্ভারের প্রতিক্রিয়া পরিচালনা করুন

আপনার অ্যাপ্লিকেশনটি যেভাবে অনুমোদনের প্রতিক্রিয়া পাবে তা নির্ভর করে এটি কোন রিডাইরেক্ট URI স্কিমে ব্যবহার করে তার উপর। স্কিম যাই হোক না কেন, প্রতিক্রিয়াটিতে হয় একটি অনুমোদন কোড ( code ) থাকবে অথবা একটি ত্রুটি ( error ) থাকবে। উদাহরণস্বরূপ, error=access_denied নির্দেশ করে যে ব্যবহারকারী অনুরোধটি প্রত্যাখ্যান করেছেন।

যদি ব্যবহারকারী আপনার অ্যাপ্লিকেশনে অ্যাক্সেস মঞ্জুর করে, তাহলে আপনি পরবর্তী ধাপে বর্ণিত পদ্ধতিতে একটি অ্যাক্সেস টোকেন এবং একটি রিফ্রেশ টোকেনের জন্য অনুমোদন কোড বিনিময় করতে পারেন।

ধাপ ৫: রিফ্রেশ এবং অ্যাক্সেস টোকেনের জন্য অনুমোদন কোড বিনিময় করুন

একটি অ্যাক্সেস টোকেনের জন্য একটি অনুমোদন কোড বিনিময় করতে, https://oauth2.googleapis.com/token এন্ডপয়েন্টে কল করুন এবং নিম্নলিখিত পরামিতিগুলি সেট করুন:

ক্ষেত্র
`client_id`	থেকে প্রাপ্ত ক্লায়েন্ট আইডি Cloud ConsoleClients page.
`client_secret`	ঐচ্ছিক ক্লায়েন্টের গোপন তথ্য যা থেকে প্রাপ্ত Cloud ConsoleClients page.
`code`	প্রাথমিক অনুরোধ থেকে অনুমোদন কোডটি ফিরে এসেছে।
`code_verifier`	ধাপ ১ এ আপনার তৈরি কোড যাচাইকারী।
`grant_type`	OAuth 2.0 স্পেসিফিকেশনে সংজ্ঞায়িত হিসাবে , এই ক্ষেত্রের মান `authorization_code` এ সেট করা আবশ্যক।
`redirect_uri`	আপনার প্রকল্পের জন্য তালিকাভুক্ত পুনঃনির্দেশ URI গুলির মধ্যে একটি Cloud ConsoleClients page প্রদত্ত `client_id` এর জন্য।

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

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

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your_client_id&
redirect_uri=http://127.0.0.1:9004&
grant_type=authorization_code

গুগল এই অনুরোধের জবাবে একটি JSON অবজেক্ট ফেরত দেয় যাতে একটি স্বল্পস্থায়ী অ্যাক্সেস টোকেন এবং একটি রিফ্রেশ টোকেন থাকে।

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

ক্ষেত্র
`access_token`	আপনার অ্যাপ্লিকেশনটি একটি Google API অনুরোধ অনুমোদনের জন্য যে টোকেনটি পাঠায়।
`expires_in`	অ্যাক্সেস টোকেনের অবশিষ্ট জীবনকাল সেকেন্ডে।
`id_token`	দ্রষ্টব্য: এই বৈশিষ্ট্যটি কেবল তখনই ফেরত দেওয়া হবে যদি আপনার অনুরোধে `openid` , `profile` , অথবা `email` এর মতো কোনও পরিচয় স্কোপ অন্তর্ভুক্ত থাকে। মানটি হল একটি JSON ওয়েব টোকেন (JWT) যাতে ব্যবহারকারী সম্পর্কে ডিজিটালি স্বাক্ষরিত পরিচয় তথ্য থাকে।
`refresh_token`	একটি টোকেন যা ব্যবহার করে আপনি একটি নতুন অ্যাক্সেস টোকেন পেতে পারেন। ব্যবহারকারী অ্যাক্সেস প্রত্যাহার না করা পর্যন্ত অথবা রিফ্রেশ টোকেনের মেয়াদ শেষ না হওয়া পর্যন্ত রিফ্রেশ টোকেনগুলি বৈধ থাকবে। মনে রাখবেন যে ইনস্টল করা অ্যাপ্লিকেশনগুলির জন্য রিফ্রেশ টোকেনগুলি সর্বদা ফেরত দেওয়া হয়।
`refresh_token_expires_in`	রিফ্রেশ টোকেনের অবশিষ্ট জীবনকাল সেকেন্ডে। এই মানটি কেবল তখনই সেট করা হয় যখন ব্যবহারকারী সময়-ভিত্তিক অ্যাক্সেস মঞ্জুর করে।
`scope`	`access_token` দ্বারা প্রদত্ত অ্যাক্সেসের সুযোগগুলি স্থান-বিভাজিত, কেস-সংবেদনশীল স্ট্রিংগুলির তালিকা হিসাবে প্রকাশ করা হয়।
`token_type`	টোকেনের ধরণটি ফিরে এসেছে। এই সময়ে, এই ক্ষেত্রের মান সর্বদা `Bearer` এ সেট করা থাকে।

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

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

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "token_type": "Bearer",
  "scope": "https://www.googleapis.com/auth/yt-analytics.readonly https://www.googleapis.com/auth/calendar.readonly",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

ধাপ ৬: ব্যবহারকারীরা কোন স্কোপগুলি মঞ্জুর করেছেন তা পরীক্ষা করুন

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

তবে, ব্যতিক্রম আছে। ডোমেন-ওয়াইড ডেলিগেশন অফ অথরিটি সহ Google Workspace Enterprise অ্যাপ, অথবা Trusted হিসেবে চিহ্নিত অ্যাপ, গ্রানুলার অনুমতি সম্মতি স্ক্রিনকে বাইপাস করে। এই অ্যাপগুলির জন্য, ব্যবহারকারীরা গ্রানুলার অনুমতি সম্মতি স্ক্রিন দেখতে পাবেন না। পরিবর্তে, আপনার অ্যাপ হয় সমস্ত অনুরোধ করা স্কোপ পাবে, অথবা কোনওটিই পাবে না।

আরও বিস্তারিত তথ্যের জন্য, কীভাবে গ্রানুলার অনুমতিগুলি পরিচালনা করবেন তা দেখুন।

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

উদাহরণস্বরূপ, নিম্নলিখিত নমুনা অ্যাক্সেস টোকেন প্রতিক্রিয়া ইঙ্গিত দেয় যে ব্যবহারকারী আপনার অ্যাপ্লিকেশনটিকে কেবল পঠনযোগ্য ড্রাইভ কার্যকলাপ এবং ক্যালেন্ডার ইভেন্ট অনুমতিগুলিতে অ্যাক্সেস দিয়েছেন:

  {
    "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
    "expires_in": 3920,
    "token_type": "Bearer",
    "scope": "https://www.googleapis.com/auth/yt-analytics.readonly https://www.googleapis.com/auth/calendar.readonly",
    "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
  }

গুগল এপিআই-তে কল করুন

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

মনে রাখবেন যে YouTube Analytics API পরিষেবা অ্যাকাউন্ট প্রবাহ সমর্থন করে না। YouTube রিপোর্টিং API শুধুমাত্র সেই YouTube কন্টেন্ট মালিকদের জন্য পরিষেবা অ্যাকাউন্ট সমর্থন করে যারা রেকর্ড লেবেল এবং মুভি স্টুডিওর মতো একাধিক YouTube চ্যানেলের মালিক এবং পরিচালনা করেন।

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

HTTP GET উদাহরণ

Authorization: Bearer HTTP হেডার ব্যবহার করে reports.query এন্ডপয়েন্টে (YouTube Analytics API) একটি কল নিম্নলিখিতটির মতো দেখতে পারে। মনে রাখবেন যে আপনাকে নিজের অ্যাক্সেস টোকেন নির্দিষ্ট করতে হবে:

GET /youtube/analytics/v1/reports?ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

access_token কোয়েরি স্ট্রিং প্যারামিটার ব্যবহার করে প্রমাণিত ব্যবহারকারীর জন্য একই API-তে একটি কল এখানে দেওয়া হল:

GET https://www.googleapis.com/youtube/analytics/v1/reports?access_token=access_token&ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views

`curl` উদাহরণ

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

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/analytics/v1/reports?ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views

অথবা, বিকল্পভাবে, কোয়েরি স্ট্রিং প্যারামিটার বিকল্প:

curl https://www.googleapis.com/youtube/analytics/v1/reports?access_token=access_token&ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views

একটি অ্যাক্সেস টোকেন রিফ্রেশ করুন

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

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

ক্ষেত্র
`client_id`	থেকে প্রাপ্ত ক্লায়েন্ট আইডি API Console.
`client_secret`	ঐচ্ছিক ক্লায়েন্টের গোপন তথ্য যা থেকে প্রাপ্ত API Console. ( `client_secret` অ্যান্ড্রয়েড, iOS, অথবা Chrome অ্যাপ্লিকেশন হিসেবে নিবন্ধিত ক্লায়েন্টদের অনুরোধের ক্ষেত্রে প্রযোজ্য নয়।)
`grant_type`	OAuth 2.0 স্পেসিফিকেশনে সংজ্ঞায়িত হিসাবে, এই ক্ষেত্রের মান `refresh_token` এ সেট করা আবশ্যক।
`refresh_token`	অনুমোদন কোড এক্সচেঞ্জ থেকে রিফ্রেশ টোকেনটি ফিরে এসেছে।

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

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

client_id=your_client_id&
refresh_token=refresh_token&
grant_type=refresh_token

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

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

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

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

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

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

প্রোগ্রাম্যাটিকভাবে একটি টোকেন প্রত্যাহার করতে, আপনার অ্যাপ্লিকেশনটি https://oauth2.googleapis.com/revoke এ একটি অনুরোধ করে এবং টোকেনটিকে একটি প্যারামিটার হিসাবে অন্তর্ভুক্ত করে:

curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
        https://oauth2.googleapis.com/revoke?token={token}

টোকেনটি একটি অ্যাক্সেস টোকেন অথবা একটি রিফ্রেশ টোকেন হতে পারে। যদি টোকেনটি একটি অ্যাক্সেস টোকেন হয় এবং এর সাথে সম্পর্কিত একটি রিফ্রেশ টোকেন থাকে, তাহলে রিফ্রেশ টোকেনটিও প্রত্যাহার করা হবে।

যদি প্রত্যাহার সফলভাবে প্রক্রিয়া করা হয়, তাহলে প্রতিক্রিয়ার HTTP স্থিতি কোড 200 হবে। ত্রুটির অবস্থার জন্য, একটি HTTP স্থিতি কোড 400 একটি ত্রুটি কোড সহ ফেরত পাঠানো হয়।

অ্যাপ রিডাইরেক্ট পদ্ধতি

কাস্টম URI স্কিম

কাস্টম URI স্কিম হল একধরনের ডিপলিংক যা আপনার অ্যাপ খোলার জন্য একটি কাস্টম-সংজ্ঞায়িত স্কিম ব্যবহার করে।

Chrome অ্যাপে কাস্টম URI স্কিম ব্যবহারের বিকল্প

Chrome Identity API ব্যবহার করুন যা আপনার অ্যাপে সরাসরি OAuth 2.0 প্রতিক্রিয়া সরবরাহ করে, যার ফলে পুনর্নির্দেশ URI-এর প্রয়োজন হয় না।

লুপব্যাক আইপি ঠিকানা (ম্যাকোস, লিনাক্স, উইন্ডোজ ডেস্কটপ)

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

যখন আপনার অ্যাপটি অনুমোদনের প্রতিক্রিয়া পাবে, তখন সর্বোত্তম ব্যবহারযোগ্যতার জন্য এটি একটি HTML পৃষ্ঠা প্রদর্শন করে প্রতিক্রিয়া জানাবে যা ব্যবহারকারীকে ব্রাউজারটি বন্ধ করে আপনার অ্যাপে ফিরে যেতে নির্দেশ দেবে।

প্রস্তাবিত ব্যবহার	ম্যাকওএস, লিনাক্স এবং উইন্ডোজ ডেস্কটপ (কিন্তু ইউনিভার্সাল উইন্ডোজ প্ল্যাটফর্ম নয়) অ্যাপস
ফর্ম মান	অ্যাপ্লিকেশনের ধরণটি ডেস্কটপ অ্যাপে সেট করুন।

দ্রষ্টব্য: লুপব্যাক আইপি ঠিকানা সম্পর্কে আরও তথ্যের জন্য redirect_uri প্যারামিটার সংজ্ঞাটি দেখুন। লুপব্যাক আইপির পরিবর্তে localhost ব্যবহার করাও সম্ভব, তবে এই কনফিগারেশনটি ক্লায়েন্ট ফায়ারওয়ালগুলির সাথে সমস্যা তৈরি করতে পারে। বেশিরভাগ, কিন্তু সব নয়, ফায়ারওয়াল লুপব্যাক যোগাযোগের অনুমতি দেয়।

ম্যানুয়াল কপি/পেস্ট (অবঞ্চিত)

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

Chrome এর জন্য অ্যাপের মালিকানা যাচাই করুন

অ্যাপের ছদ্মবেশ ধারণের ঝুঁকি কমাতে আপনি আপনার অ্যাপ্লিকেশনের মালিকানা যাচাই করতে পারেন।

যাচাইকরণ প্রক্রিয়াটি সম্পূর্ণ করতে, আপনাকে আপনার Chrome ওয়েব স্টোর ডেভেলপার অ্যাকাউন্ট ব্যবহার করতে হবে। সফল যাচাইকরণের জন্য নিম্নলিখিত প্রয়োজনীয়তাগুলি পূরণ করতে হবে:

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

Chrome এক্সটেনশন ক্লায়েন্টের "অ্যাপ মালিকানা যাচাই করুন" বিভাগে, যাচাইকরণ প্রক্রিয়াটি সম্পূর্ণ করতে "মালিকানা যাচাই করুন" বোতামে ক্লিক করুন।

দ্রষ্টব্য: আপনার অ্যাকাউন্টে অ্যাক্সেস দেওয়ার পর যাচাইকরণ প্রক্রিয়াটি সম্পন্ন করার আগে কয়েক মিনিট অপেক্ষা করুন।

যাচাইকরণ সফল হলে, যাচাইকরণ প্রক্রিয়ার সাফল্য নিশ্চিত করার জন্য একটি বিজ্ঞপ্তি প্রদর্শিত হবে। অন্যথায়, একটি ত্রুটি প্রম্পট দেখানো হবে।

ব্যর্থ যাচাইকরণ ঠিক করতে, নিম্নলিখিতগুলি চেষ্টা করে দেখুন:

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

অ্যাপ চেক (শুধুমাত্র iOS)

অ্যাপ চেক বৈশিষ্ট্যটি আপনার iOS অ্যাপ্লিকেশনগুলিকে অননুমোদিত ব্যবহার থেকে রক্ষা করতে সাহায্য করে, অ্যাপলের অ্যাপ অ্যাটেস্ট পরিষেবা ব্যবহার করে যাচাই করে যে Google OAuth 2.0 এন্ডপয়েন্টে করা অনুরোধগুলি আপনার খাঁটি অ্যাপ্লিকেশনগুলি থেকে এসেছে। এটি অ্যাপের ছদ্মবেশ ধারণের ঝুঁকি কমাতে সাহায্য করে।

আপনার iOS ক্লায়েন্টের জন্য অ্যাপ চেক সক্ষম করুন

আপনার iOS ক্লায়েন্টের জন্য অ্যাপ চেক সফলভাবে সক্ষম করতে নিম্নলিখিত প্রয়োজনীয়তাগুলি পূরণ করতে হবে:

আপনার iOS ক্লায়েন্টের জন্য আপনাকে অবশ্যই একটি টিম আইডি নির্দিষ্ট করতে হবে।
আপনার বান্ডেল আইডিতে ওয়াইল্ডকার্ড ব্যবহার করা উচিত নয় কারণ এটি একাধিক অ্যাপে সমাধান করতে পারে। এর অর্থ হল বান্ডেল আইডিতে তারকাচিহ্ন (*) চিহ্ন থাকা উচিত নয়।

সতর্কতা: অ্যাপ চেক সক্ষম করা থাকলে, নতুন ক্লায়েন্ট তৈরি না করে আপনি আপনার OAuth ক্লায়েন্ট বান্ডেল আইডি সম্পাদনা করতে পারবেন না। আপনার iOS ক্লায়েন্ট তৈরি করার আগে বা অ্যাপ চেক সক্ষম করার আগে, আপনি সঠিক বান্ডেল আইডি ব্যবহার করছেন কিনা তা যাচাই করুন। যদি আপনি পুনঃনির্দেশ URI হিসাবে বান্ডেল আইডি ব্যবহার করেন তবে বিদ্যমান প্রকল্পের জন্য আপনার বান্ডেল আইডি আপডেট করার ফলে আপনার অ্যাপ ব্যবহারকারীদের জন্য একটি সমস্যা হতে পারে।

অ্যাপ চেক সক্ষম করতে, আপনার iOS ক্লায়েন্টের সম্পাদনা ভিউতে "Firebase অ্যাপ চেকের মাধ্যমে অপব্যবহার থেকে আপনার OAuth ক্লায়েন্টকে রক্ষা করুন" টগল বোতামটি চালু করুন।

After enabling App Check, you will start seeing metrics related to OAuth requests from your client in the edit view of the OAuth client. Requests from unverified sources won't be blocked until you enforce App Check . The information in the metrics monitoring page can help you determine when to start enforcement.

You might see errors related to the App Check feature when enabling App Check for your iOS app. To fix these errors, try the following:

Verify that the bundle ID and team ID you specified are valid.
Verify that you are not using a wildcard for the bundle ID.

Enforce App Check for your iOS Client

Enabling App Check for your app does not automatically block unrecognized requests. To enforce this protection, go to the edit view of your iOS client. There, you will see App Check metrics to the right of the page under the Google Identity for iOS section. The metrics include the following information:

Number of verified requests - requests that have a valid App Check token. After you enable App Check enforcement, only requests in this category will succeed.
Number of unverified requests: likely outdated client requests - requests missing an App Check token; these request may be from an older version of your app that doesn't include an App Check implementation.
Number of unverified requests: unknown origin requests - requests missing an App Check token that don't look like they are coming from your app.
Number of unverified requests: invalid requests - requests with an invalid App Check token, which may be from an inauthentic client attempting to impersonate your app, or from emulated environments.

Review these metrics to understand how enforcing App Check will affect your users.

To enforce App Check, click the ENFORCE button and confirm your choice. Once enforcement is active, all unverified requests from your client will be rejected.

Note : after you enable enforcement, it can take up to 15 minutes for the changes to take effect.

Unenforce App Check for your iOS Client

Unenforcing App Check for your app will stop enforcement and will allow all requests from your client to Google OAuth 2.0 endpoints, including unverified requests.

To unenforce App Check for your iOS client, navigate to the edit view of the iOS client and click the UNENFORCE button and confirm your choice.

Note : after unenforcing App Check, it can take up to 15 minutes for the changes to take effect.

Disable App Check for your iOS Client

Disabling App Check for your app will stop all App Check monitoring and enforcement . Consider unenforcing App Check instead so you can continue monitoring metrics for your client.

To disable App Check for your iOS client, navigate to the edit view of the iOS client and turn off the Protect your OAuth client from abuse with Firebase App Check toggle button.

Note : after disabling App Check, it can take up to 15 minutes for the changes to take effect.

Time-based access

Time-based access allows a user to grant your app access to their data for a limited duration to complete an action. Time-based access is available in select Google products during the consent flow, giving users the option to grant access for a limited period of time. An example is the Data Portability API which enables a one-time transfer of data.

When a user grants your application time-based access, the refresh token will expire after the specified duration. Note that refresh tokens may be invalidated earlier under specific circumstances; see these cases for details. The refresh_token_expires_in field returned in the authorization code exchange response represents the time remaining until the refresh token expires in such cases.

Implement Cross-Account Protection

An additional step you should take to protect your users' accounts is implementing Cross-Account Protection by utilizing Google's Cross-Account Protection Service. This service lets you subscribe to security event notifications which provide information to your application about major changes to the user account. You can then use the information to take action depending on how you decide to respond to events.

Some examples of the event types sent to your app by Google's Cross-Account Protection Service are:

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

See the Protect user accounts with Cross-Account Protection page for more information on how to implement Cross Account Protection and for the full list of available events.

লাইব্রেরি এবং নমুনা

পূর্বশর্ত

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

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

আইওএস

ইউডব্লিউপি

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

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

ধাপ ১: একটি কোড যাচাইকারী তৈরি করুন এবং চ্যালেঞ্জ করুন

কোড যাচাইকারী তৈরি করুন

কোড চ্যালেঞ্জ তৈরি করুন

ধাপ ২: Google এর OAuth 2.0 সার্ভারে একটি অনুরোধ পাঠান

নমুনা অনুমোদনের URL গুলি

কাস্টম URI স্কিম

লুপব্যাক আইপি ঠিকানা

ধাপ ৩: গুগল ব্যবহারকারীর কাছ থেকে সম্মতির অনুরোধ জানায়

ত্রুটি

admin_policy_enforced

disallowed_useragent

org_internal

deleted_client

invalid_grant

redirect_uri_mismatch

invalid_request

ধাপ ৪: OAuth 2.0 সার্ভারের প্রতিক্রিয়া পরিচালনা করুন

ধাপ ৫: রিফ্রেশ এবং অ্যাক্সেস টোকেনের জন্য অনুমোদন কোড বিনিময় করুন

ধাপ ৬: ব্যবহারকারীরা কোন স্কোপগুলি মঞ্জুর করেছেন তা পরীক্ষা করুন

গুগল এপিআই-তে কল করুন

HTTP GET উদাহরণ

curl উদাহরণ

একটি অ্যাক্সেস টোকেন রিফ্রেশ করুন

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

অ্যাপ রিডাইরেক্ট পদ্ধতি

কাস্টম URI স্কিম

Chrome অ্যাপে কাস্টম URI স্কিম ব্যবহারের বিকল্প

লুপব্যাক আইপি ঠিকানা (ম্যাকোস, লিনাক্স, উইন্ডোজ ডেস্কটপ)

ম্যানুয়াল কপি/পেস্ট (অবঞ্চিত)

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

Chrome এর জন্য অ্যাপের মালিকানা যাচাই করুন

অ্যাপ চেক (শুধুমাত্র iOS)

আপনার iOS ক্লায়েন্টের জন্য অ্যাপ চেক সক্ষম করুন

Enforce App Check for your iOS Client

Unenforce App Check for your iOS Client

Disable App Check for your iOS Client

Time-based access

Further Reading

Implement Cross-Account Protection

`admin_policy_enforced`

`disallowed_useragent`

`org_internal`

`deleted_client`

`invalid_grant`

`redirect_uri_mismatch`

`invalid_request`

`curl` উদাহরণ