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

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

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

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

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

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

বিকল্প

মোবাইল অ্যাপের জন্য, আপনি Android বা iOS- এর জন্য Google সাইন-ইন ব্যবহার করতে পছন্দ করতে পারেন। Google সাইন-ইন ক্লায়েন্ট লাইব্রেরিগুলি প্রমাণীকরণ এবং ব্যবহারকারীর অনুমোদন পরিচালনা করে এবং সেগুলি এখানে বর্ণিত নিম্ন-স্তরের প্রোটোকলের চেয়ে সহজতর হতে পারে৷

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

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

এই নথিতে বর্ণিত OAuth 2.0 ফ্লো বাস্তবায়নে সাহায্য করার জন্য আমরা নিম্নলিখিত লাইব্রেরি এবং নমুনাগুলির সুপারিশ করি:

• Android লাইব্রেরির জন্য AppAuth
• iOS লাইব্রেরির জন্য AppAuth
• অ্যাপের জন্য OAuth: Windows নমুনা

পূর্বশর্ত

আপনার প্রকল্পের জন্য 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. নিম্নলিখিত বিভাগগুলি ক্লায়েন্টের প্রকারগুলি বর্ণনা করে যা Google এর অনুমোদন সার্ভার সমর্থন করে৷ আপনার অ্যাপ্লিকেশনের জন্য প্রস্তাবিত ক্লায়েন্টের ধরনটি চয়ন করুন, আপনার OAuth ক্লায়েন্টের নাম দিন এবং ফর্মের অন্যান্য ক্ষেত্রগুলিকে উপযুক্ত হিসাবে সেট করুন৷

অ্যান্ড্রয়েড

1. অ্যান্ড্রয়েড অ্যাপ্লিকেশন প্রকার নির্বাচন করুন.
2. OAuth ক্লায়েন্টের জন্য একটি নাম লিখুন। এই নামটি আপনার প্রকল্পে প্রদর্শিত হয় Credentials page ক্লায়েন্ট সনাক্ত করতে।
3. আপনার অ্যান্ড্রয়েড অ্যাপের প্যাকেজের নাম লিখুন। এই মানটি আপনার অ্যাপ ম্যানিফেস্ট ফাইলের <manifest> উপাদানের package বৈশিষ্ট্যে সংজ্ঞায়িত করা হয়েছে।
4. অ্যাপ ডিস্ট্রিবিউশনের SHA-1 সাইনিং সার্টিফিকেট ফিঙ্গারপ্রিন্ট লিখুন।
   • আপনার অ্যাপ যদি Google Play-এর অ্যাপ সাইনিং ব্যবহার করে, তাহলে Play Console-এর অ্যাপ সাইনিং পৃষ্ঠা থেকে SHA-1 ফিঙ্গারপ্রিন্ট কপি করুন।
   • আপনি যদি আপনার নিজের কীস্টোর এবং সাইনিং কীগুলি পরিচালনা করেন, মানব-পাঠযোগ্য বিন্যাসে শংসাপত্রের তথ্য মুদ্রণ করতে Java এর সাথে অন্তর্ভুক্ত কীটুল ইউটিলিটি ব্যবহার করুন। কীটুল আউটপুটের Certificate fingerprints বিভাগে SHA1 মানটি অনুলিপি করুন। আরও তথ্যের জন্য Android ডকুমেন্টেশনের জন্য Google API-এ আপনার ক্লায়েন্ট প্রমাণীকরণ দেখুন।
5. (ঐচ্ছিক) আপনার Android অ্যাপ্লিকেশনের মালিকানা যাচাই করুন ।
6. তৈরি করুন ক্লিক করুন।

iOS

1. iOS অ্যাপ্লিকেশনের ধরন নির্বাচন করুন।
2. OAuth ক্লায়েন্টের জন্য একটি নাম লিখুন। এই নামটি আপনার প্রকল্পে প্রদর্শিত হয় Credentials page ক্লায়েন্ট সনাক্ত করতে।
3. আপনার অ্যাপের জন্য বান্ডেল শনাক্তকারী লিখুন। বান্ডেল আইডি হল আপনার অ্যাপের তথ্য সম্পত্তি তালিকা রিসোর্স ফাইলে ( info.plist ) CFBundleIdentifier কী-এর মান। মানটি সাধারণত সাধারণ ফলক বা Xcode প্রকল্প সম্পাদকের স্বাক্ষর ও সক্ষমতা ফলকে প্রদর্শিত হয়। অ্যাপলের অ্যাপ স্টোর কানেক্ট সাইটে অ্যাপের জন্য অ্যাপের তথ্য পৃষ্ঠার সাধারণ তথ্য বিভাগে বান্ডেল আইডিও প্রদর্শিত হয়।

   নিশ্চিত করুন যে আপনি আপনার অ্যাপের জন্য সঠিক বান্ডেল আইডি ব্যবহার করছেন, কারণ আপনি অ্যাপ চেক বৈশিষ্ট্যটি ব্যবহার করলে আপনি এটি পরিবর্তন করতে পারবেন না।

4. (ঐচ্ছিক)

   অ্যাপটি অ্যাপলের অ্যাপ স্টোরে প্রকাশিত হলে আপনার অ্যাপের অ্যাপ স্টোর আইডি লিখুন। স্টোর আইডি হল একটি সাংখ্যিক স্ট্রিং যা প্রতিটি Apple App Store URL-এ অন্তর্ভুক্ত।

   1. আপনার iOS বা iPadOS ডিভাইসে Apple App Store অ্যাপটি খুলুন।
   2. আপনার অ্যাপের জন্য অনুসন্ধান করুন.
   3. শেয়ার বোতাম নির্বাচন করুন (বর্গাকার এবং তীর আপ প্রতীক)।
   4. অনুলিপি লিঙ্ক নির্বাচন করুন।
   5. একটি পাঠ্য সম্পাদকে লিঙ্কটি আটকান। অ্যাপ স্টোর আইডি হল ইউআরএলের চূড়ান্ত অংশ।

      উদাহরণ: https://apps.apple.com/app/google/id 284815942

5. (ঐচ্ছিক)

   আপনার টিম আইডি লিখুন। আরও তথ্যের জন্য অ্যাপল ডেভেলপার অ্যাকাউন্ট ডকুমেন্টেশনে আপনার টিম আইডি সনাক্ত করুন দেখুন।

   দ্রষ্টব্য: আপনি যদি আপনার ক্লায়েন্টের জন্য অ্যাপ চেক সক্ষম করেন তবে টিম আইডি ক্ষেত্রটি প্রয়োজন৷
6. (ঐচ্ছিক)

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

7. তৈরি করুন ক্লিক করুন।

UWP

1. ইউনিভার্সাল উইন্ডোজ প্ল্যাটফর্ম অ্যাপ্লিকেশন টাইপ নির্বাচন করুন।
2. OAuth ক্লায়েন্টের জন্য একটি নাম লিখুন। এই নামটি আপনার প্রকল্পে প্রদর্শিত হয় Credentials page ক্লায়েন্ট সনাক্ত করতে।
3. আপনার অ্যাপের 12-অক্ষরের Microsoft স্টোর আইডি লিখুন। আপনি অ্যাপ পরিচালনা বিভাগে অ্যাপ পরিচয় পৃষ্ঠায় Microsoft অংশীদার কেন্দ্রে এই মানটি খুঁজে পেতে পারেন।
4. তৈরি করুন ক্লিক করুন।

UWP অ্যাপের জন্য, কাস্টম URI স্কিমটি 39 অক্ষরের বেশি হতে পারে না।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

পরামিতি
client_id	প্রয়োজন আপনার আবেদনের জন্য ক্লায়েন্ট আইডি। আপনি এই মান খুঁজে পেতে পারেন API ConsoleCredentials page.
redirect_uri	প্রয়োজন Google-এর অনুমোদন সার্ভার কীভাবে আপনার অ্যাপে প্রতিক্রিয়া পাঠায় তা নির্ধারণ করে। ইনস্টল করা অ্যাপগুলির জন্য বেশ কয়েকটি পুনঃনির্দেশ বিকল্প উপলব্ধ রয়েছে এবং আপনি একটি নির্দিষ্ট পুনঃনির্দেশ পদ্ধতির কথা মাথায় রেখে আপনার অনুমোদনের শংসাপত্রগুলি সেট আপ করবেন৷ মানটি অবশ্যই OAuth 2.0 ক্লায়েন্টের জন্য অনুমোদিত রিডাইরেক্ট ইউআরআইগুলির একটির সাথে মিলতে হবে, যা আপনি আপনার ক্লায়েন্টের কনফিগার করেছেন API ConsoleCredentials page. যদি এই মানটি একটি অনুমোদিত URI-এর সাথে মেলে না, তাহলে আপনি একটি redirect_uri_mismatch ত্রুটি পাবেন। নীচের টেবিলটি প্রতিটি পদ্ধতির জন্য উপযুক্ত redirect_uri প্যারামিটার মান দেখায়: redirect_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 থেকে আলাদা। দ্রষ্টব্য : কাস্টম URI স্কিমগুলি আর Chrome অ্যাপগুলিতে সমর্থিত নয় এবং Android এ ডিফল্টরূপে অক্ষম করা হয়৷ অ্যান্ড্রয়েড এবং ক্রোম অ্যাপের জন্য কাস্টম স্কিম বিকল্প সম্পর্কে আরও জানুন । লুপব্যাক আইপি ঠিকানা http://127.0.0.1: port বা http://[::1]: port প্রাসঙ্গিক লুপব্যাক আইপি ঠিকানার জন্য আপনার প্ল্যাটফর্মের অনুসন্ধান করুন এবং একটি এলোমেলো উপলব্ধ পোর্টে একটি HTTP শ্রোতা শুরু করুন৷ প্রকৃত পোর্ট নম্বর দিয়ে port প্রতিস্থাপন করুন যা আপনার অ্যাপটি শুনছে। মনে রাখবেন যে মোবাইল অ্যাপে লুপব্যাক আইপি অ্যাড্রেস রিডাইরেক্ট বিকল্পের জন্য সমর্থন বাতিল করা হয়েছে ।
response_type	প্রয়োজন Google OAuth 2.0 এন্ডপয়েন্ট একটি অনুমোদন কোড প্রদান করে কিনা তা নির্ধারণ করে। ইনস্টল করা অ্যাপ্লিকেশনের জন্য code প্যারামিটার মান সেট করুন।
scope	প্রয়োজন স্কোপের একটি স্থান-সীমাবদ্ধ তালিকা যা ব্যবহারকারীর পক্ষ থেকে আপনার অ্যাপ্লিকেশন অ্যাক্সেস করতে পারে এমন সংস্থানগুলি সনাক্ত করে৷ এই মানগুলি সম্মতি স্ক্রীনকে জানায় যা Google ব্যবহারকারীকে প্রদর্শন করে। স্কোপগুলি আপনার অ্যাপ্লিকেশনটিকে শুধুমাত্র প্রয়োজনীয় সংস্থানগুলিতে অ্যাক্সেসের অনুরোধ করতে সক্ষম করে এবং ব্যবহারকারীদের তারা আপনার অ্যাপ্লিকেশনটিতে যে পরিমাণ অ্যাক্সেস দেয় তা নিয়ন্ত্রণ করতে সক্ষম করে। সুতরাং, অনুরোধ করা স্কোপের সংখ্যা এবং ব্যবহারকারীর সম্মতি পাওয়ার সম্ভাবনার মধ্যে একটি বিপরীত সম্পর্ক রয়েছে।
code_challenge	প্রস্তাবিত একটি এনকোড করা code_verifier নির্দিষ্ট করে যা অনুমোদন কোড বিনিময়ের সময় একটি সার্ভার-সাইড চ্যালেঞ্জ হিসেবে ব্যবহার করা হবে। আরও তথ্যের জন্য উপরে কোড চ্যালেঞ্জ বিভাগ তৈরি করুন দেখুন।
code_challenge_method	প্রস্তাবিত একটি code_verifier এনকোড করতে কোন পদ্ধতি ব্যবহার করা হয়েছিল তা নির্দিষ্ট করে যা অনুমোদন কোড বিনিময়ের সময় ব্যবহার করা হবে। এই প্যারামিটারটি অবশ্যই উপরে বর্ণিত code_challenge প্যারামিটারের সাথে ব্যবহার করা উচিত। code_challenge_method এর মান plain হয়ে যায় যদি অনুরোধে উপস্থিত না থাকে যেটিতে একটি code_challenge অন্তর্ভুক্ত থাকে। এই প্যারামিটারের জন্য শুধুমাত্র সমর্থিত মান হল S256 বা plain ।
state	প্রস্তাবিত আপনার অনুমোদনের অনুরোধ এবং অনুমোদন সার্ভারের প্রতিক্রিয়ার মধ্যে অবস্থা বজায় রাখতে আপনার অ্যাপ্লিকেশন ব্যবহার করে এমন কোনো স্ট্রিং মান নির্দিষ্ট করে। ব্যবহারকারী আপনার অ্যাপ্লিকেশনের অ্যাক্সেস অনুরোধে সম্মতি বা অস্বীকার করার পরে সার্ভারটি সঠিক মানটি ফেরত দেয় যা আপনি একটি name=value pair হিসেবে পাঠান redirect_uri এর URL খণ্ড শনাক্তকারী ( # )। আপনি এই প্যারামিটারটি বিভিন্ন উদ্দেশ্যে ব্যবহার করতে পারেন, যেমন আপনার অ্যাপ্লিকেশনে ব্যবহারকারীকে সঠিক সংস্থানের দিকে নির্দেশ করা, ননসেস পাঠানো এবং ক্রস-সাইট অনুরোধ জালিয়াতি প্রশমিত করা। যেহেতু আপনার redirect_uri অনুমান করা যেতে পারে, একটি state মান ব্যবহার করে আপনার নিশ্চয়তা বৃদ্ধি করতে পারে যে একটি ইনকামিং সংযোগ একটি প্রমাণীকরণ অনুরোধের ফলাফল। আপনি যদি একটি এলোমেলো স্ট্রিং তৈরি করেন বা একটি কুকির হ্যাশ বা ক্লায়েন্টের অবস্থা ক্যাপচার করে এমন অন্য মান এনকোড করেন, তাহলে ক্রস-সাইটের মতো আক্রমণের বিরুদ্ধে সুরক্ষা প্রদান করে অনুরোধ এবং প্রতিক্রিয়া একই ব্রাউজারে উদ্ভূত হয়েছে তা নিশ্চিত করতে আপনি প্রতিক্রিয়া যাচাই করতে পারেন জালিয়াতি অনুরোধ . কিভাবে একটি state টোকেন তৈরি এবং নিশ্চিত করতে হয় তার উদাহরণের জন্য OpenID Connect ডকুমেন্টেশন দেখুন। গুরুত্বপূর্ণ: OAuth ক্লায়েন্টকে অবশ্যই CSRF প্রতিরোধ করতে হবে যেভাবে OAuth2 স্পেসিফিকেশনে বলা হয়েছে। এটি অর্জন করার একটি উপায় হল আপনার অনুমোদনের অনুরোধ এবং অনুমোদন সার্ভারের প্রতিক্রিয়ার মধ্যে অবস্থা বজায় রাখার জন্য state প্যারামিটার ব্যবহার করে।
login_hint	ঐচ্ছিক আপনার অ্যাপ্লিকেশন যদি জানে কোন ব্যবহারকারী প্রমাণীকরণের চেষ্টা করছে, তাহলে এটি এই প্যারামিটারটি ব্যবহার করে Google প্রমাণীকরণ সার্ভারে একটি ইঙ্গিত দিতে পারে। সার্ভার সাইন-ইন ফর্মে ইমেল ক্ষেত্রটি প্রিফিলিং করে বা উপযুক্ত মাল্টি-লগইন সেশন নির্বাচন করে লগইন প্রবাহকে সহজ করার জন্য ইঙ্গিতটি ব্যবহার করে। প্যারামিটার মানটিকে একটি ইমেল ঠিকানা বা sub -শনাক্তকারীতে সেট করুন, যা ব্যবহারকারীর Google আইডির সমতুল্য।

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

নমুনা অনুমোদন URL

নীচের ট্যাবগুলি বিভিন্ন পুনঃনির্দেশ URI বিকল্পগুলির জন্য নমুনা অনুমোদন URLগুলি দেখায়৷

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

কাস্টম ইউআরআই স্কিম

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 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=email%20profile&
 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

ধাপ 3: Google ব্যবহারকারীকে সম্মতির জন্য অনুরোধ করে

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

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

ত্রুটি

Google-এর OAuth 2.0 অনুমোদনের এন্ডপয়েন্টের অনুরোধগুলি প্রত্যাশিত প্রমাণীকরণ এবং অনুমোদনের প্রবাহের পরিবর্তে ব্যবহারকারী-মুখী ত্রুটি বার্তাগুলি প্রদর্শন করতে পারে৷ সাধারণ ত্রুটি কোড এবং প্রস্তাবিত রেজোলিউশন নীচে তালিকাভুক্ত করা হয়.

admin_policy_enforced

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

disallowed_useragent

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

অ্যান্ড্রয়েড

android.webkit.WebView এ অনুমোদনের অনুরোধগুলি খোলার সময় Android বিকাশকারীরা এই ত্রুটির বার্তাটির সম্মুখীন হতে পারে৷ বিকাশকারীদের পরিবর্তে Android লাইব্রেরিগুলি ব্যবহার করা উচিত যেমন Android এর জন্য Google সাইন-ইন বা Android এর জন্য OpenID ফাউন্ডেশনের AppAuth ৷

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

iOS

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

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

org_internal

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

invalid_grant

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

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

redirect_uri_mismatch

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

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

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

invalid_request

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

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

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

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

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

ধাপ 5: রিফ্রেশ এবং অ্যাক্সেস টোকেনগুলির জন্য এক্সচেঞ্জ অনুমোদন কোড

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

ক্ষেত্র
client_id	ক্লায়েন্ট আইডি থেকে প্রাপ্ত API ConsoleCredentials page.
client_secret	ক্লায়েন্ট সিক্রেট থেকে প্রাপ্ত API ConsoleCredentials page.
code	অনুমোদন কোড প্রাথমিক অনুরোধ থেকে ফিরে.
code_verifier	কোড যাচাইকারী আপনি ধাপ 1 এ তৈরি করেছেন।
grant_type	OAuth 2.0 স্পেসিফিকেশনে যেমন সংজ্ঞায়িত করা হয়েছে , এই ক্ষেত্রের মান অবশ্যই authorization_code এ সেট করতে হবে।
redirect_uri	আপনার প্রোজেক্টের জন্য তালিকাভুক্ত রিডাইরেক্ট ইউআরআইগুলির মধ্যে একটি API ConsoleCredentials 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&
client_secret=your_client_secret&
redirect_uri=http://127.0.0.1:9004&
grant_type=authorization_code

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

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

ক্ষেত্র
access_token	একটি Google API অনুরোধ অনুমোদন করার জন্য আপনার অ্যাপ্লিকেশন যে টোকেন পাঠায়।
expires_in	সেকেন্ডে অ্যাক্সেস টোকেনের অবশিষ্ট জীবনকাল।
id_token	দ্রষ্টব্য: এই সম্পত্তিটি শুধুমাত্র তখনই ফেরত দেওয়া হয় যদি আপনার অনুরোধে একটি পরিচয়ের সুযোগ অন্তর্ভুক্ত থাকে, যেমন openid , profile বা email । মান হল একটি JSON ওয়েব টোকেন (JWT) যাতে ব্যবহারকারী সম্পর্কে ডিজিটালি স্বাক্ষরিত পরিচয় তথ্য থাকে।
refresh_token	একটি টোকেন যা আপনি একটি নতুন অ্যাক্সেস টোকেন পেতে ব্যবহার করতে পারেন। ব্যবহারকারী অ্যাক্সেস প্রত্যাহার না করা পর্যন্ত রিফ্রেশ টোকেন বৈধ। মনে রাখবেন যে রিফ্রেশ টোকেন সবসময় ইনস্টল করা অ্যাপ্লিকেশনের জন্য ফেরত দেওয়া হয়।
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/drive.metadata.readonly",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

দ্রষ্টব্য: আপনার আবেদনের প্রতিক্রিয়াতে অন্তর্ভুক্ত কোনো অচেনা ক্ষেত্র উপেক্ষা করা উচিত।

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. ( client_secret অ্যান্ড্রয়েড, আইওএস, বা ক্রোম অ্যাপ্লিকেশন হিসাবে নিবন্ধিত ক্লায়েন্টদের অনুরোধের ক্ষেত্রে প্রযোজ্য নয়৷)
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 একটি ত্রুটি কোড সহ ফেরত দেওয়া হয়।

দ্রষ্টব্য: একটি সফল প্রত্যাহার প্রতিক্রিয়া অনুসরণ করে, প্রত্যাহার সম্পূর্ণ কার্যকর হওয়ার আগে কিছু সময় লাগতে পারে৷

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

কাস্টম URI স্কিম (Android, iOS, UWP)

কাস্টম ইউআরআই স্কিম হল ডিপলিংকিংয়ের একটি ফর্ম যা আপনার অ্যাপ খুলতে একটি কাস্টম-সংজ্ঞায়িত স্কিম ব্যবহার করে।

গুরুত্বপূর্ণ: কাস্টম URI স্কিমগুলি আর নতুন Chrome অ্যাপে সমর্থিত নয় এবং অ্যাপ ছদ্মবেশের ঝুঁকির কারণে নতুন Android ক্লায়েন্টগুলিতে ডিফল্টরূপে অক্ষম করা হয়।

অ্যান্ড্রয়েডে কাস্টম ইউআরআই স্কিম ব্যবহার করার বিকল্প

Android SDK-এর জন্য Google সাইন-ইন ব্যবহার করুন যা সরাসরি আপনার অ্যাপে OAuth 2.0 প্রতিক্রিয়া প্রদান করে, একটি পুনঃনির্দেশিত URI-এর প্রয়োজনীয়তা দূর করে৷

Android SDK-এর জন্য Google সাইন-ইন-এ কীভাবে স্থানান্তর করবেন

আপনি যদি Android এ আপনার OAuth ইন্টিগ্রেশনের জন্য একটি কাস্টম স্কিম ব্যবহার করেন, তাহলে আপনাকে Android SDK-এর জন্য প্রস্তাবিত Google সাইন-ইন ব্যবহার করে সম্পূর্ণরূপে স্থানান্তরিত করতে নিম্নলিখিত ক্রিয়াগুলি সম্পূর্ণ করতে হবে:

1. Google সাইন-ইন SDK ব্যবহার করতে আপনার কোড আপডেট করুন৷
2. Google API কনসোলে কাস্টম স্কিমের জন্য সমর্থন অক্ষম করুন৷

দ্রষ্টব্য: Google API কনসোলে কাস্টম স্কিমগুলির জন্য সমর্থন অক্ষম করার আগে আপনার কোড আপডেটগুলি সম্পূর্ণ এবং স্থাপন করা উচিত (আপনার ব্যবহারকারী বেস বা পুরানো ডিভাইসগুলিতে গ্রহণের সময় হিসাবে) ব্যবহারকারীরা যখন আপনার অ্যাপ ব্যবহার করার চেষ্টা করে তখন তাদের একটি invalid_request ত্রুটি বার্তা পাওয়া এড়াতে।

Google সাইন-ইন অ্যান্ড্রয়েড SDK-এ স্থানান্তর করতে নীচের পদক্ষেপগুলি অনুসরণ করুন:

1. Google সাইন-ইন Android SDK ব্যবহার করতে আপনার কোড আপডেট করুন:
   1. আপনি Google এর OAuth 2.0 সার্ভারে কোথায় একটি অনুরোধ পাঠাচ্ছেন তা সনাক্ত করতে আপনার কোড পরীক্ষা করুন; একটি কাস্টম স্কিম ব্যবহার করলে, আপনার অনুরোধ নীচের মত দেখাবে:

        https://accounts.google.com/o/oauth2/v2/auth?
        scope=<SCOPES>&
        response_type=code&
        &state=<STATE>&
        redirect_uri=com.example.app:/oauth2redirect&
        client_id=<CLIENT_ID>
        

      com.example.app:/oauth2redirect হল উপরের উদাহরণে কাস্টম স্কিম রিডাইরেক্ট URI। কাস্টম URI স্কিমের মানের ফর্ম্যাট সম্পর্কে আরও বিশদ বিবরণের জন্য redirect_uri প্যারামিটার সংজ্ঞাটি দেখুন।
   2. Google সাইন-ইন SDK কনফিগার করার জন্য যে scope এবং client_id অনুরোধের পরামিতিগুলি আপনার প্রয়োজন তা নোট করুন৷
      দ্রষ্টব্য: আপনি যদি তৃতীয় পক্ষের লাইব্রেরি ব্যবহার করেন, তাহলে এই তথ্যগুলি খুঁজে পেতে লাইব্রেরির কনফিগারেশন ফাইলটি পর্যালোচনা করুন৷
   3. SDK সেট আপ করতে আপনার Android অ্যাপে Google সাইন-ইন করা শুরু করুন। আপনি আপনার ব্যাকএন্ড সার্ভারের OAuth 2.0 ক্লায়েন্ট আইডি পাওয়ার ধাপটি এড়িয়ে যেতে পারেন কারণ আপনি আগের ধাপ থেকে পুনরুদ্ধার করা client_id পুনরায় ব্যবহার করবেন।
   4. সক্রিয় সার্ভার-সাইড API অ্যাক্সেস নির্দেশাবলী অনুসরণ করুন. এটি নিম্নলিখিত পদক্ষেপগুলি অন্তর্ভুক্ত করে:
      1. আপনি যে স্কোপের জন্য অনুমতির অনুরোধ করছেন তার জন্য একটি প্রমাণীকরণ কোড পুনরুদ্ধার করতে getServerAuthCode পদ্ধতি ব্যবহার করুন।
      2. একটি অ্যাক্সেস এবং রিফ্রেশ টোকেনের জন্য এটি বিনিময় করতে আপনার অ্যাপের ব্যাকএন্ডে প্রমাণীকরণ কোড পাঠান।
      3. ব্যবহারকারীর পক্ষে Google API-এ কল করতে পুনরুদ্ধার করা অ্যাক্সেস টোকেন ব্যবহার করুন।
      দ্রষ্টব্য: আপনার অ্যাপ্লিকেশনের অফলাইন অ্যাক্সেসের প্রয়োজন না হলে, ক্লায়েন্ট-সাইড API অ্যাক্সেসের অনুরোধ করার পরিবর্তে এই নির্দেশাবলী অনুসরণ করুন।
2. Google API কনসোলে কাস্টম স্কিমের জন্য সমর্থন অক্ষম করুন:
   1. আপনার OAuth 2.0 শংসাপত্রের তালিকায় যান এবং আপনার Android ক্লায়েন্ট নির্বাচন করুন৷
   2. উন্নত সেটিংস বিভাগে নেভিগেট করুন, কাস্টম ইউআরআই স্কিম সক্ষম করুন চেকবক্সটি আনচেক করুন এবং কাস্টম ইউআরআই স্কিম সমর্থন নিষ্ক্রিয় করতে সংরক্ষণ করুন ক্লিক করুন।

কাস্টম ইউআরআই স্কিম সক্ষম করুন

যদি প্রস্তাবিত বিকল্পটি আপনার জন্য কাজ না করে, আপনি নীচের নির্দেশাবলী অনুসরণ করে আপনার Android ক্লায়েন্টের জন্য কাস্টম URI স্কিমগুলি সক্ষম করতে পারেন:

1. আপনার OAuth 2.0 শংসাপত্রের তালিকায় যান এবং আপনার Android ক্লায়েন্ট নির্বাচন করুন৷
2. উন্নত সেটিংস বিভাগে নেভিগেট করুন, কাস্টম ইউআরআই স্কিম সক্ষম করুন চেকবক্সটি চেক করুন এবং কাস্টম ইউআরআই স্কিম সমর্থন সক্ষম করতে সংরক্ষণ ক্লিক করুন।

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

ক্রোম আইডেন্টিটি API ব্যবহার করুন যা সরাসরি আপনার অ্যাপে OAuth 2.0 প্রতিক্রিয়া প্রদান করে, একটি পুনঃনির্দেশিত URI-এর প্রয়োজনীয়তা দূর করে৷

লুপব্যাক আইপি ঠিকানা (macOS, Linux, Windows ডেস্কটপ)

গুরুত্বপূর্ণ: লুপব্যাক আইপি অ্যাড্রেস রিডাইরেক্ট বিকল্পটি Android , Chrome অ্যাপ এবং iOS OAuth ক্লায়েন্টের প্রকারের জন্য বন্ধ করা হয়েছে। কিভাবে একটি সমর্থিত বিকল্পে স্থানান্তর করতে হয় তার নির্দেশাবলীর জন্য লুপব্যাক আইপি ঠিকানা মাইগ্রেশন গাইড পর্যালোচনা করুন।

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

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

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

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

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

গুরুত্বপূর্ণ: ম্যানুয়াল কপি/পেস্ট বিকল্প, যাকে আউট অফ ব্যান্ড (OOB) পুনঃনির্দেশ পদ্ধতি হিসাবেও উল্লেখ করা হয়, এটি আর সমর্থিত নয় ৷ কিভাবে একটি নিরাপদ বিকল্পে মাইগ্রেট করতে হয় তার নির্দেশাবলীর জন্য OOB মাইগ্রেশন গাইড পর্যালোচনা করুন।

আপনার অ্যাপস রক্ষা করুন

অ্যাপের মালিকানা যাচাই করুন (Android, Chrome)

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

অ্যান্ড্রয়েড

দ্রষ্টব্য: Android অ্যাপ মালিকানা যাচাইকরণ শুধুমাত্র Google Play অ্যাপের জন্য উপলব্ধ।

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

• আপনি যে অ্যান্ড্রয়েড OAuth ক্লায়েন্টের জন্য যাচাইকরণ সম্পূর্ণ করছেন সেই একই প্যাকেজের নাম এবং SHA-1 সাইনিং সার্টিফিকেট ফিঙ্গারপ্রিন্ট সহ আপনার Google Play Console-এ একটি নিবন্ধিত অ্যাপ্লিকেশন থাকতে হবে।
• Google Play Console-এ অ্যাপটির জন্য আপনার অ্যাডমিনের অনুমতি থাকতে হবে। Google Play Console-এ অ্যাক্সেস ম্যানেজমেন্ট সম্পর্কে আরও জানুন ।

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

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

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

• নিশ্চিত করুন যে আপনি যে অ্যাপটি যাচাই করছেন সেটি Google Play Console-এ একটি নিবন্ধিত অ্যাপ।
• Google Play Console-এ অ্যাপটির জন্য আপনার কাছে অ্যাডমিনের অনুমতি আছে তা নিশ্চিত করুন।

ক্রোম

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

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

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

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

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

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

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

অ্যাপ্লিকেশন চেক (কেবল আইওএস)

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

আপনার আইওএস ক্লায়েন্টের জন্য অ্যাপ্লিকেশন চেক সক্ষম করুন

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

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

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

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

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

আপনার আইওএস অ্যাপ্লিকেশনটির জন্য অ্যাপ্লিকেশন চেক সক্ষম করার সময় আপনি অ্যাপ্লিকেশন চেক বৈশিষ্ট্য সম্পর্কিত ত্রুটিগুলি দেখতে পাবেন। এই ত্রুটিগুলি ঠিক করতে, নিম্নলিখিতগুলি চেষ্টা করুন:

• আপনার নির্দিষ্ট করা বান্ডিল আইডি এবং টিম আইডি বৈধ কিনা তা যাচাই করুন।
• আপনি বান্ডিল আইডির জন্য ওয়াইল্ডকার্ড ব্যবহার করছেন না তা যাচাই করুন।

আপনার আইওএস ক্লায়েন্টের জন্য অ্যাপ্লিকেশন প্রয়োগ করুন

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

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

অ্যাপ্লিকেশন চেক কীভাবে প্রয়োগ করা আপনার ব্যবহারকারীদের প্রভাবিত করবে তা বুঝতে এই মেট্রিকগুলি পর্যালোচনা করুন।

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

দ্রষ্টব্য : আপনি প্রয়োগকারী সক্ষম করার পরে, পরিবর্তনগুলি কার্যকর হতে 15 মিনিট সময় নিতে পারে।

আপনার আইওএস ক্লায়েন্টের জন্য ননফোর্স অ্যাপ চেক করুন

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

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

দ্রষ্টব্য : অ্যাপ্লিকেশন চেক চেক করার পরে, পরিবর্তনগুলি কার্যকর হতে 15 মিনিট সময় নিতে পারে।

আপনার আইওএস ক্লায়েন্টের জন্য অ্যাপ্লিকেশন চেক অক্ষম করুন

আপনার অ্যাপ্লিকেশনটির জন্য অ্যাপ্লিকেশন চেক অক্ষম করা সমস্ত অ্যাপ্লিকেশন চেক মনিটরিং এবং প্রয়োগকরণ বন্ধ করবে। পরিবর্তে অপরিশোধিত অ্যাপ্লিকেশন চেক বিবেচনা করুন যাতে আপনি আপনার ক্লায়েন্টের জন্য মেট্রিকগুলি পর্যবেক্ষণ চালিয়ে যেতে পারেন।

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

দ্রষ্টব্য : অ্যাপ্লিকেশন চেক অক্ষম করার পরে, পরিবর্তনগুলি কার্যকর হতে 15 মিনিট সময় নিতে পারে।

আরও পড়া

নেটিভ অ্যাপ্লিকেশনগুলির জন্য আইইটিএফ সেরা বর্তমান অনুশীলন OAuth 2.0 এখানে নথিভুক্ত সেরা অনুশীলনগুলির অনেকগুলি প্রতিষ্ঠা করে।

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

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

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

• 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 এ নতুন হন তবে আমরা আপনাকে সুপারিশ করি যে আপনি শুরু করার আগে ওআউথ 2.0 ওভারভিউ পড়ুন। ওভারভিউটি গুগল সমর্থন করে এমন OAuth 2.0 প্রবাহের সংক্ষিপ্তসার জানায়, যা আপনাকে আপনার অ্যাপ্লিকেশনটির জন্য সঠিক প্রবাহ নির্বাচন করেছে তা নিশ্চিত করতে আপনাকে সহায়তা করতে পারে।

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

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

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

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

বিকল্প

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

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

গ্রন্থাগার এবং নমুনা

আমরা এই নথিতে বর্ণিত OAuth 2.0 প্রবাহ বাস্তবায়নে সহায়তা করার জন্য নিম্নলিখিত গ্রন্থাগার এবং নমুনাগুলির প্রস্তাব দিই:

• অ্যান্ড্রয়েড লাইব্রেরির জন্য অ্যাপাথ
• আইওএস লাইব্রেরির জন্য অ্যাপাথ
• অ্যাপ্লিকেশনগুলির জন্য oauth: উইন্ডোজ নমুনা

পূর্বশর্ত

আপনার প্রকল্পের জন্য 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. আপনি সক্ষম করতে চান এপিআই নির্বাচন করুন, তারপরে সক্ষম বোতামটি ক্লিক করুন।
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. শংসাপত্রগুলি তৈরি করুন> ওআউথ ক্লায়েন্ট আইডি ক্লিক করুন।
3. নিম্নলিখিত বিভাগগুলি গুগলের অনুমোদনের সার্ভার সমর্থন করে এমন ক্লায়েন্টের ধরণগুলি বর্ণনা করে। আপনার আবেদনের জন্য প্রস্তাবিত ক্লায়েন্টের ধরণটি চয়ন করুন, আপনার ওআউথ ক্লায়েন্টের নাম দিন এবং অন্য ক্ষেত্রগুলি যথাযথ হিসাবে ফর্মটিতে সেট করুন।

অ্যান্ড্রয়েড

1. অ্যান্ড্রয়েড অ্যাপ্লিকেশন প্রকারটি নির্বাচন করুন।
2. OAuth ক্লায়েন্টের জন্য একটি নাম লিখুন। এই নামটি আপনার প্রকল্পের প্রদর্শিত হয় Credentials page ক্লায়েন্ট সনাক্ত করতে।
3. আপনার অ্যান্ড্রয়েড অ্যাপ্লিকেশনটির প্যাকেজ নাম লিখুন। এই মানটি আপনার অ্যাপ্লিকেশন ম্যানিফেস্ট ফাইলে <manifest> উপাদানটির package বৈশিষ্ট্যে সংজ্ঞায়িত করা হয়েছে।
4. অ্যাপ্লিকেশন বিতরণের SHA-1 স্বাক্ষরকারী শংসাপত্রের ফিঙ্গারপ্রিন্ট প্রবেশ করান।
   • যদি আপনার অ্যাপ্লিকেশনটি গুগল প্লে দ্বারা অ্যাপ্লিকেশন স্বাক্ষর ব্যবহার করে তবে প্লে কনসোলের অ্যাপ্লিকেশন স্বাক্ষরকারী পৃষ্ঠা থেকে SHA-1 ফিঙ্গারপ্রিন্টটি অনুলিপি করুন।
   • আপনি যদি নিজের কীস্টোর এবং স্বাক্ষরকারী কীগুলি পরিচালনা করেন তবে মানব-পঠনযোগ্য বিন্যাসে শংসাপত্রের তথ্য মুদ্রণ করতে জাভার সাথে অন্তর্ভুক্ত কীটুল ইউটিলিটি ব্যবহার করুন। কীটুল আউটপুটটির Certificate fingerprints বিভাগে SHA1 মানটি অনুলিপি করুন। আরও তথ্যের জন্য অ্যান্ড্রয়েড ডকুমেন্টেশনের জন্য গুগল এপিআইগুলিতে আপনার ক্লায়েন্টকে প্রমাণীকরণ করা দেখুন।
5. (Al চ্ছিক) আপনার অ্যান্ড্রয়েড অ্যাপ্লিকেশনটির মালিকানা যাচাই করুন ।
6. তৈরি করুন ক্লিক করুন।

iOS

1. আইওএস অ্যাপ্লিকেশন প্রকারটি নির্বাচন করুন।
2. OAuth ক্লায়েন্টের জন্য একটি নাম লিখুন। এই নামটি আপনার প্রকল্পের প্রদর্শিত হয় Credentials page ক্লায়েন্ট সনাক্ত করতে।
3. আপনার অ্যাপ্লিকেশনটির জন্য বান্ডিল শনাক্তকারী প্রবেশ করান। বান্ডিল আইডি হ'ল আপনার অ্যাপের তথ্য সম্পত্তি তালিকা রিসোর্স ফাইল ( info.plist ) এর সিএফবিল্ডলাইডেন্টিফায়ার কীটির মান। মানটি সর্বাধিক সাধারণ ফলক বা এক্সকোড প্রকল্প সম্পাদকের সাইনিং এবং সক্ষমতা ফলকে প্রদর্শিত হয়। বান্ডিল আইডি অ্যাপলের অ্যাপ স্টোর কানেক্ট সাইটে অ্যাপের জন্য অ্যাপ্লিকেশন তথ্য পৃষ্ঠার সাধারণ তথ্য বিভাগেও প্রদর্শিত হয়।

   নিশ্চিত করুন যে আপনি আপনার অ্যাপ্লিকেশনটির জন্য সঠিক বান্ডিল আইডি ব্যবহার করছেন, কারণ আপনি যদি অ্যাপ চেক বৈশিষ্ট্যটি ব্যবহার করেন তবে আপনি এটি পরিবর্তন করতে সক্ষম হবেন না।

4. (ঐচ্ছিক)

   অ্যাপলের অ্যাপ স্টোরে যদি অ্যাপ্লিকেশনটি প্রকাশিত হয় তবে আপনার অ্যাপের অ্যাপ স্টোর আইডি লিখুন। স্টোর আইডি হ'ল প্রতিটি অ্যাপল অ্যাপ স্টোর ইউআরএলে অন্তর্ভুক্ত একটি সংখ্যাসূচক স্ট্রিং।

   1. আপনার আইওএস বা আইপ্যাডোস ডিভাইসে অ্যাপল অ্যাপ স্টোর অ্যাপটি খুলুন।
   2. আপনার অ্যাপ্লিকেশন অনুসন্ধান করুন।
   3. শেয়ার বোতামটি নির্বাচন করুন (স্কোয়ার এবং অ্যারো আপ প্রতীক)।
   4. অনুলিপি লিঙ্ক নির্বাচন করুন।
   5. একটি পাঠ্য সম্পাদকে লিঙ্কটি আটকান। অ্যাপ স্টোর আইডিটি ইউআরএল এর চূড়ান্ত অংশ।

      উদাহরণ: https://apps.apple.com/app/google/id 284815942

5. (ঐচ্ছিক)

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

   দ্রষ্টব্য: আপনি যদি আপনার ক্লায়েন্টের জন্য অ্যাপ্লিকেশন চেক সক্ষম করে থাকেন তবে টিম আইডি ক্ষেত্রের প্রয়োজন।
6. (ঐচ্ছিক)

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

7. তৈরি করুন ক্লিক করুন।

UWP

1. ইউনিভার্সাল উইন্ডোজ প্ল্যাটফর্ম অ্যাপ্লিকেশন প্রকারটি নির্বাচন করুন।
2. OAuth ক্লায়েন্টের জন্য একটি নাম লিখুন। এই নামটি আপনার প্রকল্পের প্রদর্শিত হয় Credentials page ক্লায়েন্ট সনাক্ত করতে।
3. আপনার অ্যাপ্লিকেশনটির 12-চরিত্রের মাইক্রোসফ্ট স্টোর আইডি লিখুন। আপনি অ্যাপ ম্যানেজমেন্ট বিভাগে অ্যাপ্লিকেশন পরিচয় পৃষ্ঠায় মাইক্রোসফ্ট পার্টনার সেন্টারে এই মানটি খুঁজে পেতে পারেন।
4. তৈরি করুন ক্লিক করুন।

ইউডাব্লুপি অ্যাপ্লিকেশনগুলির জন্য, কাস্টম ইউআরআই স্কিম 39 টি অক্ষরের চেয়ে বেশি হতে পারে না।

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

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

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

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

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

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

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

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

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

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

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

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

কোড যাচাইকারীটির মানটি অনুমান করার জন্য এটি অযৌক্তিক করে তুলতে পর্যাপ্ত এনট্রপি থাকা উচিত।

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

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

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

পদক্ষেপ 2: গুগলের OAuth 2.0 সার্ভারে একটি অনুরোধ প্রেরণ করুন

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

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

পরামিতি
client_id	প্রয়োজন আপনার আবেদনের জন্য ক্লায়েন্ট আইডি। আপনি এই মানটি খুঁজে পেতে পারেন API ConsoleCredentials page.
redirect_uri	প্রয়োজন গুগলের অনুমোদনের সার্ভার কীভাবে আপনার অ্যাপ্লিকেশনটিতে একটি প্রতিক্রিয়া প্রেরণ করে তা নির্ধারণ করে। ইনস্টল করা অ্যাপ্লিকেশনগুলির জন্য বেশ কয়েকটি পুনঃনির্দেশ বিকল্প উপলব্ধ রয়েছে এবং আপনি একটি নির্দিষ্ট পুনঃনির্দেশ পদ্ধতিটি মাথায় রেখে আপনার অনুমোদনের শংসাপত্রগুলি সেট আপ করবেন। আপনি আপনার ক্লায়েন্টের কনফিগার করা OAuth 2.0 ক্লায়েন্টের জন্য অনুমোদিত একটি পুনর্নির্দেশ ইউআরআইগুলির সাথে মানটি অবশ্যই মেলে অবশ্যই API ConsoleCredentials page. যদি এই মানটি কোনও অনুমোদিত ইউআরআইয়ের সাথে মেলে না, আপনি একটি redirect_uri_mismatch ত্রুটি পাবেন। নীচের টেবিলটি প্রতিটি পদ্ধতির জন্য উপযুক্ত redirect_uri প্যারামিটার মান দেখায়: redirect_uri মান কাস্টম ইউআরআই স্কিম com.example.app : redirect_uri_path বা com.googleusercontent.apps.123 : redirect_uri_path com.example.app হ'ল আপনার নিয়ন্ত্রণাধীন একটি ডোমেনের বিপরীত ডিএনএস স্বরলিপি। কাস্টম স্কিমটিতে বৈধ হওয়ার জন্য একটি পিরিয়ড থাকতে হবে। com.googleusercontent.apps.123 ক্লায়েন্ট আইডির বিপরীত ডিএনএস স্বরলিপি। redirect_uri_path একটি al চ্ছিক পাথ উপাদান, যেমন /oauth2redirect । নোট করুন যে পথটি একটি একক স্ল্যাশ দিয়ে শুরু করা উচিত, যা নিয়মিত এইচটিটিপি ইউআরএল থেকে পৃথক। দ্রষ্টব্য : কাস্টম ইউআরআই স্কিমগুলি আর ক্রোম অ্যাপ্লিকেশনগুলিতে সমর্থিত নয় এবং অ্যান্ড্রয়েডে ডিফল্টরূপে অক্ষম। অ্যান্ড্রয়েড এবং ক্রোম অ্যাপ্লিকেশনগুলির জন্য কাস্টম স্কিম বিকল্প সম্পর্কে আরও জানুন । লুপব্যাক আইপি ঠিকানা http://127.0.0.1: port বা http://[::1]: port প্রাসঙ্গিক লুপব্যাক আইপি ঠিকানার জন্য আপনার প্ল্যাটফর্মটি জিজ্ঞাসা করুন এবং এলোমেলো উপলভ্য বন্দরে একটি এইচটিটিপি শ্রোতা শুরু করুন। আসল পোর্ট নম্বর সহ বিকল্প port আপনার অ্যাপ্লিকেশনটি শুনবে। নোট করুন যে মোবাইল অ্যাপ্লিকেশনগুলিতে লুপব্যাক আইপি ঠিকানা পুনঃনির্দেশ বিকল্পের জন্য সমর্থনটি হ্রাস করা হয়েছে ।
response_type	প্রয়োজন গুগল ওএউথ 2.0 এন্ডপয়েন্টটি কোনও অনুমোদনের কোডটি ফেরত দেয় কিনা তা নির্ধারণ করে। ইনস্টলড অ্যাপ্লিকেশনগুলির জন্য code প্যারামিটার মান সেট করুন।
scope	প্রয়োজন স্কোপগুলির একটি স্পেস-ডিসেলিমিটেড তালিকা যা আপনার অ্যাপ্লিকেশনটি ব্যবহারকারীর পক্ষে অ্যাক্সেস করতে পারে এমন সংস্থানগুলি সনাক্ত করে। এই মানগুলি সম্মতি স্ক্রিনটি অবহিত করে যা গুগল ব্যবহারকারীকে প্রদর্শন করে। স্কোপগুলি আপনার অ্যাপ্লিকেশনটিকে কেবলমাত্র যে সংস্থানগুলি প্রয়োজনীয় সংস্থানগুলিতে অ্যাক্সেসের জন্য অনুরোধ করতে সক্ষম করে এবং ব্যবহারকারীদের আপনার অ্যাপ্লিকেশনটিতে যে পরিমাণ অ্যাক্সেস দেয় তা নিয়ন্ত্রণ করতে সক্ষম করে। সুতরাং, অনুরোধ করা স্কোপের সংখ্যা এবং ব্যবহারকারীর সম্মতি পাওয়ার সম্ভাবনার মধ্যে একটি বিপরীত সম্পর্ক রয়েছে।
code_challenge	প্রস্তাবিত অনুমোদনের কোড এক্সচেঞ্জের সময় সার্ভার-সাইড চ্যালেঞ্জ হিসাবে ব্যবহৃত হবে এমন একটি এনকোডেড code_verifier নির্দিষ্ট করে। আরও তথ্যের জন্য উপরে কোড চ্যালেঞ্জ বিভাগ তৈরি করুন দেখুন।
code_challenge_method	প্রস্তাবিত অনুমোদনের কোড এক্সচেঞ্জের সময় ব্যবহৃত হবে এমন একটি code_verifier এনকোড করতে কোন পদ্ধতিটি ব্যবহৃত হয়েছিল তা নির্দিষ্ট করে। এই প্যারামিটারটি অবশ্যই উপরে বর্ণিত code_challenge প্যারামিটারের সাথে ব্যবহার করা উচিত। code_challenge_method এর মানটি plain ডিফল্ট করে যদি অনুরোধটিতে উপস্থিত না থাকে যাতে কোনও code_challenge অন্তর্ভুক্ত থাকে। এই প্যারামিটারের জন্য একমাত্র সমর্থিত মানগুলি S256 বা plain ।
state	প্রস্তাবিত আপনার অ্যাপ্লিকেশনটি আপনার অনুমোদনের অনুরোধ এবং অনুমোদনের সার্ভারের প্রতিক্রিয়ার মধ্যে অবস্থা বজায় রাখতে যে কোনও স্ট্রিং মান ব্যবহার করে তা নির্দিষ্ট করে। ব্যবহারকারী আপনার অ্যাপ্লিকেশনটির অ্যাক্সেসের অনুরোধের সাথে সম্মতি জানায় বা অস্বীকার করার পরে আপনি redirect_uri ইউআরএল খণ্ড সনাক্তকারী ( # ) এর name=value জোড় হিসাবে আপনি যে মানটি প্রেরণ করেন তার সঠিক মানটি সার্ভারটি ফেরত দেয়। আপনি এই প্যারামিটারটি বেশ কয়েকটি উদ্দেশ্যে ব্যবহার করতে পারেন, যেমন ব্যবহারকারীকে আপনার অ্যাপ্লিকেশনটিতে সঠিক সংস্থানগুলিতে পরিচালিত করা, ননসেস প্রেরণ এবং ক্রস-সাইট অনুরোধের জালিয়াতি প্রশমিত করা। যেহেতু আপনার redirect_uri অনুমান করা যায়, তাই একটি state মান ব্যবহার করা আপনার আশ্বাস বাড়িয়ে তুলতে পারে যে আগত সংযোগটি প্রমাণীকরণের অনুরোধের ফলাফল। আপনি যদি কোনও এলোমেলো স্ট্রিং তৈরি করেন বা কোনও কুকির হ্যাশ বা অন্য কোনও মানকে এনকোড করেন যা ক্লায়েন্টের রাষ্ট্রকে ক্যাপচার করে, আপনি ক্রস-সাইটের মতো আক্রমণগুলির বিরুদ্ধে সুরক্ষা সরবরাহ করে একই ব্রাউজারে অনুরোধ এবং প্রতিক্রিয়াটির উত্সটি অতিরিক্তভাবে নিশ্চিত করার প্রতিক্রিয়াটিকে বৈধতা দিতে পারেন জালিয়াতি অনুরোধ । কীভাবে একটি state টোকেন তৈরি এবং নিশ্চিত করা যায় তার উদাহরণের জন্য ওপেনআইডি সংযোগ ডকুমেন্টেশন দেখুন। গুরুত্বপূর্ণ: ওএউথ ক্লায়েন্টকে অবশ্যই OAUTH2 স্পেসিফিকেশনে ডাকা হিসাবে সিএসআরএফ প্রতিরোধ করতে হবে। এটি অর্জনের একটি উপায় হ'ল আপনার অনুমোদনের অনুরোধ এবং অনুমোদনের সার্ভারের প্রতিক্রিয়ার মধ্যে রাজ্য বজায় রাখতে state প্যারামিটার ব্যবহার করা।
login_hint	ঐচ্ছিক যদি আপনার অ্যাপ্লিকেশনটি জানে যে কোন ব্যবহারকারী প্রমাণীকরণের চেষ্টা করছে, এটি গুগল প্রমাণীকরণ সার্ভারে একটি ইঙ্গিত সরবরাহ করতে এই প্যারামিটারটি ব্যবহার করতে পারে। সার্ভারটি সাইন-ইন ফর্মটিতে ইমেল ক্ষেত্রটি উপস্থাপন করে বা উপযুক্ত মাল্টি-লগইন সেশনটি নির্বাচন করে লগইন প্রবাহকে সহজ করার জন্য ইঙ্গিতটি ব্যবহার করে। কোনও ইমেল ঠিকানা বা sub আইডেন্টিফায়ারে প্যারামিটার মান সেট করুন, যা ব্যবহারকারীর গুগল আইডির সমতুল্য।

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

নমুনা অনুমোদনের urls

নীচের ট্যাবগুলি বিভিন্ন পুনর্নির্দেশের ইউআরআই বিকল্পগুলির জন্য নমুনা অনুমোদনের ইউআরএল দেখায়।

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

কাস্টম ইউআরআই স্কিম

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 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=email%20profile&
 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

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

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

আপনার অ্যাপ্লিকেশনটিকে এই পর্যায়ে কিছু করার দরকার নেই কারণ এটি কোনও অ্যাক্সেস মঞ্জুর হয়েছে কিনা তা নির্দেশ করে গুগলের ওএউথ ২.০ সার্ভারের প্রতিক্রিয়ার জন্য অপেক্ষা করে। এই প্রতিক্রিয়াটি নিম্নলিখিত পদক্ষেপে ব্যাখ্যা করা হয়েছে।

ত্রুটি

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

admin_policy_enforced

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

disallowed_useragent

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

অ্যান্ড্রয়েড

অ্যান্ড্রয়েড বিকাশকারীরাandroid.webkit.WebView এ অনুমোদনের অনুরোধগুলি খোলার সময় এই ত্রুটি বার্তার মুখোমুখি হতে পারে। বিকাশকারীদের পরিবর্তে Android লাইব্রেরিগুলি ব্যবহার করা উচিত যেমন Android এর জন্য Google সাইন-ইন বা Android এর জন্য OpenID ফাউন্ডেশনের AppAuth ৷

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

iOS

আইওএস এবং ম্যাকোস বিকাশকারীরাWKWebView অনুমোদনের অনুরোধগুলি খোলার সময় এই ত্রুটির মুখোমুখি হতে পারে। বিকাশকারীদের পরিবর্তে iOS লাইব্রেরিগুলি ব্যবহার করা উচিত যেমন iOS এর জন্য Google সাইন-ইন বা iOS এর জন্য OpenID ফাউন্ডেশনের AppAuth ৷

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

org_internal

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

invalid_grant

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

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

redirect_uri_mismatch

অনুমোদনের অনুরোধে পাস করা redirect_uri ওএথ ক্লায়েন্ট আইডির জন্য অনুমোদিত পুনঃনির্দেশ ইউআরআইয়ের সাথে মেলে না। পর্যালোচনা অনুমোদিত পুনর্নির্দেশের ইউআরআইগুলি পর্যালোচনা করুন Google API Console Credentials page.

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

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

invalid_request

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

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

পদক্ষেপ 4: OAuth 2.0 সার্ভারের প্রতিক্রিয়া পরিচালনা করুন

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

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

ধাপ 5: রিফ্রেশ এবং অ্যাক্সেস টোকেনগুলির জন্য এক্সচেঞ্জ অনুমোদন কোড

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

ক্ষেত্র
client_id	ক্লায়েন্ট আইডি থেকে প্রাপ্ত API ConsoleCredentials page.
client_secret	ক্লায়েন্ট সিক্রেট থেকে প্রাপ্ত API ConsoleCredentials page.
code	প্রাথমিক অনুরোধ থেকে অনুমোদনের কোডটি ফিরে আসে।
code_verifier	আপনি ধাপ 1 এ তৈরি করা কোড যাচাইকারী।
grant_type	OAuth 2.0 স্পেসিফিকেশন হিসাবে সংজ্ঞায়িত হিসাবে , এই ক্ষেত্রের মান অবশ্যই authorization_code সেট করা উচিত।
redirect_uri	আপনার প্রকল্পের জন্য তালিকাভুক্ত পুনর্নির্দেশের একটি ইউআরআই API ConsoleCredentials 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&
client_secret=your_client_secret&
redirect_uri=http://127.0.0.1:9004&
grant_type=authorization_code

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

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

ক্ষেত্র
access_token	আপনার অ্যাপ্লিকেশনটি গুগল এপিআই অনুরোধ অনুমোদনের জন্য যে টোকেন প্রেরণ করে।
expires_in	সেকেন্ডে অ্যাক্সেস টোকেনের অবশিষ্ট জীবনকাল।
id_token	দ্রষ্টব্য: এই সম্পত্তিটি কেবল তখনই ফিরে আসে যদি আপনার অনুরোধে openid , profile বা email হিসাবে কোনও পরিচয়ের সুযোগ অন্তর্ভুক্ত থাকে। মানটি একটি জেএসএন ওয়েব টোকেন (জেডাব্লুটি) যা ব্যবহারকারী সম্পর্কে ডিজিটালি স্বাক্ষরিত পরিচয় সম্পর্কিত তথ্য ধারণ করে।
refresh_token	একটি টোকেন যা আপনি একটি নতুন অ্যাক্সেস টোকেন পেতে ব্যবহার করতে পারেন। ব্যবহারকারী অ্যাক্সেস প্রত্যাহার না করা পর্যন্ত রিফ্রেশ টোকেন বৈধ। নোট করুন যে রিফ্রেশ টোকেনগুলি সর্বদা ইনস্টলড অ্যাপ্লিকেশনগুলির জন্য ফিরে আসে।
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/drive.metadata.readonly",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

দ্রষ্টব্য: আপনার অ্যাপ্লিকেশনটিতে প্রতিক্রিয়াতে অন্তর্ভুক্ত কোনও অচেনা ক্ষেত্রগুলি উপেক্ষা করা উচিত।

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

আপনার অ্যাপ্লিকেশন অ্যাক্সেস টোকেন পাওয়ার পরে, আপনি যদি এপিআই দ্বারা প্রয়োজনীয় অ্যাক্সেসের স্কোপ (গুলি) মঞ্জুর করা হয় তবে আপনি প্রদত্ত ব্যবহারকারী অ্যাকাউন্টের পক্ষে গুগল এপিআইতে কল করতে টোকেনটি ব্যবহার করতে পারেন। এটি করার জন্য, 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. ( client_secret অ্যান্ড্রয়েড, আইওএস, বা ক্রোম অ্যাপ্লিকেশন হিসাবে নিবন্ধিত ক্লায়েন্টদের অনুরোধগুলির জন্য প্রযোজ্য নয়))
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 প্রতিক্রিয়া সরবরাহ করে, একটি পুনর্নির্দেশের ইউআরআইয়ের প্রয়োজনীয়তা দূর করে।

অ্যান্ড্রয়েড এসডিকে-র জন্য গুগল সাইন-ইন কীভাবে স্থানান্তরিত করবেন

আপনি যদি অ্যান্ড্রয়েডে আপনার OAuth সংহতকরণের জন্য একটি কাস্টম স্কিম ব্যবহার করেন তবে অ্যান্ড্রয়েড এসডিকে-র জন্য প্রস্তাবিত গুগল সাইন-ইন ব্যবহার করে সম্পূর্ণরূপে স্থানান্তর করতে আপনাকে নিম্নলিখিত ক্রিয়াগুলি সম্পূর্ণ করতে হবে:

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

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

গুগল সাইন ইন অ্যান্ড্রয়েড এসডিকে স্থানান্তর করতে নীচের পদক্ষেপগুলি অনুসরণ করুন:

1. গুগল সাইন-ইন অ্যান্ড্রয়েড এসডিকে ব্যবহার করতে আপনার কোড আপডেট করুন:
   1. আপনি কোথায় গুগলের OAuth 2.0 সার্ভারে একটি অনুরোধ প্রেরণ করছেন তা সনাক্ত করতে আপনার কোডটি পরীক্ষা করুন; যদি কোনও কাস্টম স্কিম ব্যবহার করা হয় তবে আপনার অনুরোধটি নীচের মতো দেখাবে:

        https://accounts.google.com/o/oauth2/v2/auth?
        scope=<SCOPES>&
        response_type=code&
        &state=<STATE>&
        redirect_uri=com.example.app:/oauth2redirect&
        client_id=<CLIENT_ID>
        

      com.example.app:/oauth2redirect হ'ল কাস্টম স্কিমটি উপরের উদাহরণে ইউআরআই পুনর্নির্দেশ। কাস্টম ইউআরআই স্কিম মানের ফর্ম্যাট সম্পর্কে আরও তথ্যের জন্য redirect_uri প্যারামিটার সংজ্ঞাটি দেখুন।
   2. scope এবং client_id অনুরোধ পরামিতিগুলির নোট করুন যা আপনাকে গুগল সাইন-ইন এসডিকে কনফিগার করতে হবে।
      দ্রষ্টব্য: আপনি যদি কোনও তৃতীয় পক্ষের গ্রন্থাগার ব্যবহার করছেন তবে এই তথ্যগুলি খুঁজে পেতে লাইব্রেরির কনফিগারেশন ফাইলটি পর্যালোচনা করুন।
   3. এসডিকে সেট আপ করতে আপনার অ্যান্ড্রয়েড অ্যাপ্লিকেশন নির্দেশাবলীতে গুগল সাইন-ইন সংহতকরণ শুরু করুন। আপনি পূর্ববর্তী পদক্ষেপ থেকে প্রাপ্ত client_id পুনরায় ব্যবহার করবেন বলে আপনি আপনার ব্যাকএন্ড সার্ভারের ওএউথ 2.0 ক্লায়েন্ট আইডি পদক্ষেপটি এড়িয়ে যেতে পারেন।
   4. সক্ষম সার্ভার-সাইড এপিআই অ্যাক্সেস নির্দেশাবলী অনুসরণ করুন। এর মধ্যে নিম্নলিখিত পদক্ষেপগুলি অন্তর্ভুক্ত রয়েছে:
      1. আপনি যে স্কোপগুলির জন্য অনুমতি চেয়েছেন তার জন্য কোনও এথ কোড পুনরুদ্ধার করতে getServerAuthCode পদ্ধতিটি ব্যবহার করুন।
      2. অ্যাক্সেস এবং রিফ্রেশ টোকেনের জন্য এটি বিনিময় করতে আপনার অ্যাপের ব্যাকএন্ডে এথ কোডটি প্রেরণ করুন।
      3. Use the retrieved access token to make calls to Google APIs on behalf of the user.
      Note: If your application does not require offline access, follow these instructions instead to request client-side API access.
2. Disable support for custom scheme in the Google API Console:
   1. Go to your OAuth 2.0 credentials list and select your Android client.
   2. Navigate to the Advanced Settings section, uncheck the Enable Custom URI Scheme checkbox, and click Save to disable custom URI scheme support.

Enable custom URI scheme

If the recommended alternative does not work for you, you can enable custom URI schemes for your Android client by following the below instructions:

1. Go to your OAuth 2.0 credentials list and select your Android client.
2. Navigate to the Advanced Settings section, check the Enable Custom URI Scheme checkbox, and click Save to enable custom URI scheme support.

Alternative to using custom URI schemes on Chrome apps

Use the Chrome Identity API which delivers the OAuth 2.0 response directly to your app, eliminating the need for a redirect URI.

Loopback IP address (macOS, Linux, Windows desktop)

Important: The loopback IP address redirect option is DEPRECATED for the Android , Chrome app , and iOS OAuth client types. Review the loopback IP address migration guide for instructions on how to migrate to a supported alternative.

To receive the authorization code using this URL, your application must be listening on the local web server. That is possible on many, but not all, platforms. However, if your platform supports it, this is the recommended mechanism for obtaining the authorization code.

When your app receives the authorization response, for best usability it should respond by displaying an HTML page that instructs the user to close the browser and return to your app.

প্রস্তাবিত ব্যবহার	macOS, Linux, and Windows desktop (but not Universal Windows Platform) apps
ফর্ম মান	Set the application type to Desktop app .

Note: See the redirect_uri parameter definition for more information about the loopback IP address. It is also possible to use localhost in place of the loopback IP, but this configuration may cause issues with client firewalls. Most, but not all, firewalls allow loopback communication.

Manual copy/paste (Deprecated)

Important: The manual copy/paste option, also referred to as an out of band (OOB) redirect method, is no longer supported . Review the OOB migration guide for instructions on how to migrate to a secure alternative.

Protect your apps

Verify app ownership (Android, Chrome)

You can verify ownership of your application to reduce the risk of app impersonation.

অ্যান্ড্রয়েড

Note: Android app ownership verification is only available for Google Play apps.

To complete the verification process, you can use your Google Play Developer Account if you have one and your app is registered on the Google Play Console . The following requirements must be met for a successful verification:

• You must have a registered application in the Google Play Console with the same package name and SHA-1 signing certificate fingerprint as the Android OAuth client you are completing the verification for.
• You must have Admin permission for the app in the Google Play Console. Learn more about access management in the Google Play Console.

In the Verify App Ownership section of the Android client, click the Verify Ownership button to complete the verification process.

If the verification is successful, a notification will be displayed to confirm the success of the verification process. Otherwise, an error prompt will be shown.

To fix a failed verification, try the following:

• Make sure the app you are verifying is a registered app in the Google Play Console.
• Make sure you have Admin permission for the app in the Google Play Console.

ক্রোম

To complete the verification process, you would use your Chrome Web Store Developer account. The following requirements must be met for a successful verification:

• You must have a registered item in the Chrome Web Store Developer Dashboard with the same item ID as the Chrome Extension OAuth client you are completing the verification for.
• You must be a publisher for the Chrome Web Store item. Learn more about access management in the Chrome Web Store Developer Dashboard.

In the Verify App Ownership section of the Chrome Extension client, click the Verify Ownership button to complete the verification process.

Note: Wait a few minutes before completing the verification process after granting access to your account.

If the verification is successful, a notification will be displayed to confirm the success of the verification process. Otherwise, an error prompt will be shown.

To fix a failed verification, try the following:

• Make sure there is a registered item in the Chrome Web Store Developer Dashboard with the same item ID as the Chrome Extension OAuth client you are completing the verification for.
• Make sure you are a publisher for the app, that is, you must either be the individual publisher of the app or a member of the group publisher of the app. Learn more about access management in the Chrome Web Store Developer Dashboard.
• If you just updated your group publisher list, verify that the group publisher membership list is synced in the Chrome Web Store Developer Dashboard. Learn more about syncing your publisher membership list.

App Check (iOS only)

The App Check feature helps safeguard your iOS applications from unauthorized usage by using Apple's App Attest service to verify that requests made to Google OAuth 2.0 endpoints originate from your authentic applications. This helps to reduce the risk of app impersonation.

Enable App Check for your iOS Client

The following requirements must be met to successfully enable App Check for your iOS client:

• You must specify a team ID for your iOS client.
• You must not use a wildcard in your bundle ID since it can resolve to more than one app. This means that the bundle ID must not include the asterisk (*) symbol.

Warning: When App Check is enabled, you won't be able to edit your OAuth client bundle ID without creating a new client. Before creating your iOS client or enabling App Check, verify that you are using the correct bundle ID. Updating your bundle ID for an existing project can result in a broken experience for users of your apps if you are using the bundle ID as a redirect URI.

To enable App Check, turn on the Protect your OAuth client from abuse with Firebase App Check toggle button in the edit view of your iOS client.

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.

আরও পড়া

The IETF Best Current Practice OAuth 2.0 for Native Apps establishes many of the best practices documented here.

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

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.

,

Note: If you are new to OAuth 2.0, we recommend that you read the OAuth 2.0 overview before getting started. The overview summarizes OAuth 2.0 flows that Google supports, which can help you to ensure that you've selected the right flow for your application.

This document explains how applications installed on devices like phones, tablets, and computers use Google's OAuth 2.0 endpoints to authorize access to Google APIs.

OAuth 2.0 allows users to share specific data with an application while keeping their usernames, passwords, and other information private. For example, an application can use OAuth 2.0 to obtain permission from users to store files in their Google Drives.

Installed apps are distributed to individual devices, and it is assumed that these apps cannot keep secrets. They can access Google APIs while the user is present at the app or when the app is running in the background.

This authorization flow is similar to the one used for web server applications . The main difference is that installed apps must open the system browser and supply a local redirect URI to handle responses from Google's authorization server.

বিকল্প

For mobile apps, you may prefer to use Google Sign-in for Android or iOS . The Google Sign-in client libraries handle authentication and user authorization, and they may be simpler to implement than the lower-level protocol described here.

For apps running on devices that do not support a system browser or that have limited input capabilities, such as TVs, game consoles, cameras, or printers, see OAuth 2.0 for TVs & Devices or Sign-In on TVs and Limited Input Devices .

Libraries and samples

We recommend the following libraries and samples to help you implement the OAuth 2.0 flow described in this document:

• AppAuth for Android library
• AppAuth for iOS library
• OAuth for Apps: Windows Samples

পূর্বশর্ত

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

Any application that calls Google APIs needs to enable those APIs in the API Console.

To enable an API for your project:

1. Open the API Library মধ্যে Google API Console.
2. If prompted, select a project, or create a new one.
3. দ API Library lists all available APIs, grouped by product family and popularity. If the API you want to enable isn't visible in the list, use search to find it, or click View All in the product family it belongs to.
4. Select the API you want to enable, then click the Enable button.
5. If prompted, enable billing.
6. If prompted, read and accept the API's Terms of Service.

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

Any application that uses OAuth 2.0 to access Google APIs must have authorization credentials that identify the application to Google's OAuth 2.0 server. The following steps explain how to create credentials for your project. Your applications can then use the credentials to access APIs that you have enabled for that project.

1. Go to the Credentials page.
2. Click Create credentials > OAuth client ID .
3. The following sections describe the client types that Google's authorization server supports. Choose the client type that is recommended for your application, name your OAuth client, and set the other fields in the form as appropriate.

অ্যান্ড্রয়েড

1. Select the Android application type.
2. Enter a name for the OAuth client. This name is displayed on your project's Credentials page to identify the client.
3. Enter the package name of your Android app. This value is defined in the package attribute of the <manifest> element in your app manifest file.
4. Enter the SHA-1 signing certificate fingerprint of the app distribution.
   • If your app uses app signing by Google Play , copy the SHA-1 fingerprint from the app signing page of the Play Console.
   • If you manage your own keystore and signing keys, use the keytool utility included with Java to print certificate information in a human-readable format. Copy the SHA1 value in the Certificate fingerprints section of the keytool output. See Authenticating Your Client in the Google APIs for Android documentation for more information.
5. (Optional) Verify ownership of your Android application.
6. তৈরি করুন ক্লিক করুন।

iOS

1. Select the iOS application type.
2. Enter a name for the OAuth client. This name is displayed on your project's Credentials page to identify the client.
3. Enter the bundle identifier for your app. The bundle ID is the value of the CFBundleIdentifier key in your app's information property list resource file ( info.plist ). The value is most commonly displayed in the General pane or the Signing & Capabilities pane of the Xcode project editor. The bundle ID is also displayed in the General Information section of the App Information page for the app on Apple's App Store Connect site .

   Confirm that you are using the correct bundle ID for your app, as you won't be able to change it if you are using the App Check feature.

4. (ঐচ্ছিক)

   Enter your app's App Store ID if the app is published in Apple's App Store. The Store ID is a numeric string included in every Apple App Store URL.

   1. Open the Apple App Store app on your iOS or iPadOS device.
   2. Search for your app.
   3. Select the Share button (square and arrow up symbol).
   4. অনুলিপি লিঙ্ক নির্বাচন করুন।
   5. একটি পাঠ্য সম্পাদকে লিঙ্কটি আটকান। The App Store ID is the final part of the URL.

      Example: https://apps.apple.com/app/google/id 284815942

5. (ঐচ্ছিক)

   Enter your Team ID. See Locate your Team ID in the Apple Developer Account documentation for more information.

   Note: The Team ID field is required if you are enabling App Check for your client.
6. (ঐচ্ছিক)

   Enable App Check for your iOS app. When you enable App Check, Apple's App Attest service is used to verify that OAuth 2.0 requests originating from your OAuth client are genuine and come from your app. This helps to reduce the risk of app impersonation. Learn more about enabling App Check for your iOS app .

7. তৈরি করুন ক্লিক করুন।

UWP

1. Select the Universal Windows Platform application type.
2. Enter a name for the OAuth client. This name is displayed on your project's Credentials page to identify the client.
3. Enter your app's 12-character Microsoft Store ID. You can find this value in Microsoft Partner Center on the App identity page in the App management section.
4. তৈরি করুন ক্লিক করুন।

For UWP apps, the custom URI scheme cannot be longer than 39 characters.

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

Scopes enable your application to only request access to the resources that it needs while also enabling users to control the amount of access that they grant to your application. Thus, there may be an inverse relationship between the number of scopes requested and the likelihood of obtaining user consent.

Before you start implementing OAuth 2.0 authorization, we recommend that you identify the scopes that your app will need permission to access.

Note: Incremental authorization is not supported for installed apps or devices.

The OAuth 2.0 API Scopes document contains a full list of scopes that you might use to access Google APIs.

If your public application uses scopes that permit access to certain user data, it must complete a verification process. If you see unverified app on the screen when testing your application, you must submit a verification request to remove it. Find out more about unverified apps and get answers to frequently asked questions about app verification in the Help Center.

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

The following steps show how your application interacts with Google's OAuth 2.0 server to obtain a user's consent to perform an API request on the user's behalf. Your application must have that consent before it can execute a Google API request that requires user authorization.

Step 1: Generate a code verifier and challenge

Google supports the Proof Key for Code Exchange (PKCE) protocol to make the installed app flow more secure. A unique code verifier is created for every authorization request, and its transformed value, called "code_challenge", is sent to the authorization server to obtain the authorization code.

Create the code verifier

A code_verifier is a high-entropy cryptographic random string using the unreserved characters [AZ] / [az] / [0-9] / "-" / "." / "_" / "~", with a minimum length of 43 characters and a maximum length of 128 characters.

The code verifier should have enough entropy to make it impractical to guess the value.

Create the code challenge

Two methods of creating the code challenge are supported.

Code Challenge Generation Methods
S256 (recommended)	The code challenge is the Base64URL (with no padding) encoded SHA256 hash of the code verifier. code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
সমতল	The code challenge is the same value as the code verifier generated above. code_challenge = code_verifier

Step 2: Send a request to Google's OAuth 2.0 server

To obtain user authorization, send a request to Google's authorization server at https://accounts.google.com/o/oauth2/v2/auth . This endpoint handles active session lookup, authenticates the user, and obtains user consent. The endpoint is only accessible over SSL, and it refuses HTTP (non-SSL) connections.

The authorization server supports the following query string parameters for installed applications:

পরামিতি
client_id	প্রয়োজন The client ID for your application. You can find this value in the API ConsoleCredentials page.
redirect_uri	প্রয়োজন Determines how Google's authorization server sends a response to your app. There are several redirect options available to installed apps, and you will have set up your authorization credentials with a particular redirect method in mind. The value must exactly match one of the authorized redirect URIs for the OAuth 2.0 client, which you configured in your client's API ConsoleCredentials page. If this value doesn't match an authorized URI, you will get a redirect_uri_mismatch error. The table below shows the appropriate redirect_uri parameter value for each method: redirect_uri values Custom URI scheme com.example.app : redirect_uri_path বা com.googleusercontent.apps.123 : redirect_uri_path com.example.app is the reverse DNS notation of a domain under your control. The custom scheme must contain a period to be valid. com.googleusercontent.apps.123 is the reverse DNS notation of the client ID. redirect_uri_path is an optional path component, such as /oauth2redirect . Note that the path should begin with a single slash, which is different from regular HTTP URLs. Note : Custom URI schemes are no longer supported on Chrome apps and are disabled by default on Android. Learn more about custom scheme alternatives for Android and Chrome apps. Loopback IP address http://127.0.0.1: port or http://[::1]: port Query your platform for the relevant loopback IP address and start an HTTP listener on a random available port. Substitute port with the actual port number your app listens on. Note that support for the loopback IP address redirect option on mobile apps is DEPRECATED .
response_type	প্রয়োজন Determines whether the Google OAuth 2.0 endpoint returns an authorization code. Set the parameter value to code for installed applications.
scope	প্রয়োজন A space-delimited list of scopes that identify the resources that your application could access on the user's behalf. These values inform the consent screen that Google displays to the user. Scopes enable your application to only request access to the resources that it needs while also enabling users to control the amount of access that they grant to your application. Thus, there is an inverse relationship between the number of scopes requested and the likelihood of obtaining user consent.
code_challenge	প্রস্তাবিত Specifies an encoded code_verifier that will be used as a server-side challenge during authorization code exchange. See create code challenge section above for more information.
code_challenge_method	প্রস্তাবিত Specifies what method was used to encode a code_verifier that will be used during authorization code exchange. This parameter must be used with the code_challenge parameter described above. The value of the code_challenge_method defaults to plain if not present in the request that includes a code_challenge . The only supported values for this parameter are S256 or plain .
state	প্রস্তাবিত Specifies any string value that your application uses to maintain state between your authorization request and the authorization server's response. The server returns the exact value that you send as a name=value pair in the URL fragment identifier ( # ) of the redirect_uri after the user consents to or denies your application's access request. You can use this parameter for several purposes, such as directing the user to the correct resource in your application, sending nonces, and mitigating cross-site request forgery. Since your redirect_uri can be guessed, using a state value can increase your assurance that an incoming connection is the result of an authentication request. If you generate a random string or encode the hash of a cookie or another value that captures the client's state, you can validate the response to additionally ensure that the request and response originated in the same browser, providing protection against attacks such as cross-site request forgery . See the OpenID Connect documentation for an example of how to create and confirm a state token. Important: The OAuth client must prevent CSRF as called out in the OAuth2 Specification . One way to achieve this is by using the state parameter to maintain state between your authorization request and the authorization server's response.
login_hint	ঐচ্ছিক If your application knows which user is trying to authenticate, it can use this parameter to provide a hint to the Google Authentication Server. The server uses the hint to simplify the login flow either by prefilling the email field in the sign-in form or by selecting the appropriate multi-login session. Set the parameter value to an email address or sub identifier, which is equivalent to the user's Google ID.

Note: incremental authorization with installed apps is not supported due to the fact that the client cannot keep the client_secret confidential.

Sample authorization URLs

The tabs below show sample authorization URLs for the different redirect URI options.

The URLs are identical except for the value of the redirect_uri parameter. The URLs also contain the required response_type and client_id parameters as well as the optional state parameter. Each URL contains line breaks and spaces for readability.

Custom URI scheme

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 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

Loopback IP address

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 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

Step 3: Google prompts user for consent

In this step, the user decides whether to grant your application the requested access. At this stage, Google displays a consent window that shows the name of your application and the Google API services that it is requesting permission to access with the user's authorization credentials and a summary of the scopes of access to be granted. The user can then consent to grant access to one or more scopes requested by your application or refuse the request.

Your application doesn't need to do anything at this stage as it waits for the response from Google's OAuth 2.0 server indicating whether any access was granted. That response is explained in the following step.

ত্রুটি

Requests to Google's OAuth 2.0 authorization endpoint may display user-facing error messages instead of the expected authentication and authorization flows. Common error codes and suggested resolutions are listed below.

admin_policy_enforced

The Google Account is unable to authorize one or more scopes requested due to the policies of their Google Workspace administrator. See the Google Workspace Admin help article Control which third-party & internal apps access Google Workspace data for more information about how an administrator may restrict access to all scopes or sensitive and restricted scopes until access is explicitly granted to your OAuth client ID.

disallowed_useragent

The authorization endpoint is displayed inside an embedded user-agent disallowed by Google's OAuth 2.0 Policies .

অ্যান্ড্রয়েড

Android developers may encounter this error message when opening authorization requests inandroid.webkit.WebView . বিকাশকারীদের পরিবর্তে Android লাইব্রেরিগুলি ব্যবহার করা উচিত যেমন Android এর জন্য Google সাইন-ইন বা Android এর জন্য OpenID ফাউন্ডেশনের AppAuth ৷

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

iOS

iOS and macOS developers may encounter this error when opening authorization requests inWKWebView . বিকাশকারীদের পরিবর্তে iOS লাইব্রেরিগুলি ব্যবহার করা উচিত যেমন iOS এর জন্য Google সাইন-ইন বা iOS এর জন্য OpenID ফাউন্ডেশনের AppAuth ৷

Web developers may encounter this error when an iOS or macOS app opens a general web link in an embedded user-agent and a user navigates to Google's OAuth 2.0 authorization endpoint from your site. Developers should allow general links to open in the default link handler of the operating system, which includes both Universal Links handlers or the default browser app. TheSFSafariViewController library is also a supported option.

org_internal

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

invalid_grant

If you are using a code verifier and challenge , the code_callenge parameter is invalid or missing. Ensure that the code_challenge parameter is set correctly.

When refreshing an access token , the token may have expired or has beeninvalidated. Authenticate the user again and ask for user consent to obtain new tokens. If you are continuing to see this error, ensure that your application has been configured correctly and that you are using the correct tokens and parameters in your request. Otherwise, the user account may have been deleted or disabled.

redirect_uri_mismatch

The redirect_uri passed in the authorization request does not match an authorized redirect URI for the OAuth client ID. Review authorized redirect URIs in the Google API Console Credentials page.

The passed redirect_uri may be invalid for the client type.

The redirect_uri parameter may refer to the OAuth out-of-band (OOB) flow that has been deprecated and is no longer supported. আপনার ইন্টিগ্রেশন আপডেট করতে মাইগ্রেশন গাইড পড়ুন।

invalid_request

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

• The request was not properly formatted
• অনুরোধে প্রয়োজনীয় পরামিতি অনুপস্থিত ছিল
• The request uses an authorization method that Google doesn't support. Verify your OAuth integration uses a recommended integration method
• A custom scheme is used for the redirect uri : If you see the error message Custom URI scheme is not supported on Chrome apps or Custom URI scheme is not enabled for your Android client , it means you are using a custom URI scheme which isn't supported on Chrome apps and is disabled by default on Android. Learn more about custom URI scheme alternatives

Step 4: Handle the OAuth 2.0 server response

The manner in which your application receives the authorization response depends on the redirect URI scheme that it uses. Regardless of the scheme, the response will either contain an authorization code ( code ) or an error ( error ). For example, error=access_denied indicates that the user declined the request.

If the user grants access to your application, you can exchange the authorization code for an access token and a refresh token as described in the next step.

ধাপ 5: রিফ্রেশ এবং অ্যাক্সেস টোকেনগুলির জন্য এক্সচেঞ্জ অনুমোদন কোড

To exchange an authorization code for an access token, call the https://oauth2.googleapis.com/token endpoint and set the following parameters:

ক্ষেত্র
client_id	The client ID obtained from the API ConsoleCredentials page.
client_secret	The client secret obtained from the API ConsoleCredentials page.
code	The authorization code returned from the initial request.
code_verifier	The code verifier you created in Step 1 .
grant_type	As defined in the OAuth 2.0 specification , this field's value must be set to authorization_code .
redirect_uri	One of the redirect URIs listed for your project in the API ConsoleCredentials page for the given client_id .

The following snippet shows a sample request:

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&
client_secret=your_client_secret&
redirect_uri=http://127.0.0.1:9004&
grant_type=authorization_code

Google responds to this request by returning a JSON object that contains a short-lived access token and a refresh token.

The response contains the following fields:

ক্ষেত্র
access_token	The token that your application sends to authorize a Google API request.
expires_in	The remaining lifetime of the access token in seconds.
id_token	Note: This property is only returned if your request included an identity scope, such as openid , profile , or email . The value is a JSON Web Token (JWT) that contains digitally signed identity information about the user.
refresh_token	A token that you can use to obtain a new access token. ব্যবহারকারী অ্যাক্সেস প্রত্যাহার না করা পর্যন্ত রিফ্রেশ টোকেন বৈধ। Note that refresh tokens are always returned for installed applications.
scope	The scopes of access granted by the access_token expressed as a list of space-delimited, case-sensitive strings.
token_type	The type of token returned. At this time, this field's value is always set to Bearer .

Important: Your application should store both tokens in a secure, long-lived location that is accessible between different invocations of your application. The refresh token enables your application to obtain a new access token if the one that you have expires. As such, if your application loses the refresh token, the user will need to repeat the OAuth 2.0 consent flow so that your application can obtain a new refresh token.

The following snippet shows a sample response:

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

Note: Your application should ignore any unrecognized fields included in the response.

Calling Google APIs

After your application obtains an access token, you can use the token to make calls to a Google API on behalf of a given user account if the scope(s) of access required by the API have been granted. To do this, include the access token in a request to the API by including either an access_token query parameter or an Authorization HTTP header Bearer value. When possible, the HTTP header is preferable, because query strings tend to be visible in server logs. In most cases you can use a client library to set up your calls to Google APIs (for example, when calling the Drive Files API ).

You can try out all the Google APIs and view their scopes at the OAuth 2.0 Playground .

HTTP GET examples

A call to the drive.files endpoint (the Drive Files API) using the Authorization: Bearer HTTP header might look like the following. Note that you need to specify your own access token:

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

Here is a call to the same API for the authenticated user using the access_token query string parameter:

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

curl examples

You can test these commands with the curl command-line application. Here's an example that uses the HTTP header option (preferred):

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

Or, alternatively, the query string parameter option:

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

Refreshing an access token

Access tokens periodically expire and become invalid credentials for a related API request. You can refresh an access token without prompting the user for permission (including when the user is not present) if you requested offline access to the scopes associated with the token.

To refresh an access token, your application sends an HTTPS POST request to Google's authorization server ( https://oauth2.googleapis.com/token ) that includes the following parameters:

ক্ষেত্র
client_id	The client ID obtained from the API Console.
client_secret	The client secret obtained from the API Console. (The client_secret is not applicable to requests from clients registered as Android, iOS, or Chrome applications.)
grant_type	As defined in the OAuth 2.0 specification , this field's value must be set to refresh_token .
refresh_token	The refresh token returned from the authorization code exchange.

The following snippet shows a sample request:

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

As long as the user has not revoked the access granted to the application, the token server returns a JSON object that contains a new access token. The following snippet shows a sample response:

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

Note that there are limits on the number of refresh tokens that will be issued; one limit per client/user combination, and another per user across all clients. You should save refresh tokens in long-term storage and continue to use them as long as they remain valid. If your application requests too many refresh tokens, it may run into these limits, in which case older refresh tokens will stop working.

একটি টোকেন প্রত্যাহার করা হচ্ছে

In some cases a user may wish to revoke access given to an application. A user can revoke access by visiting Account Settings . See the Remove site or app access section of the Third-party sites & apps with access to your account support document for more information.

It is also possible for an application to programmatically revoke the access given to it. Programmatic revocation is important in instances where a user unsubscribes, removes an application, or the API resources required by an app have significantly changed. In other words, part of the removal process can include an API request to ensure the permissions previously granted to the application are removed.

To programmatically revoke a token, your application makes a request to https://oauth2.googleapis.com/revoke and includes the token as a parameter:

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

The token can be an access token or a refresh token. If the token is an access token and it has a corresponding refresh token, the refresh token will also be revoked.

If the revocation is successfully processed, then the HTTP status code of the response is 200 . For error conditions, an HTTP status code 400 is returned along with an error code.

Note: Following a successful revocation response, it might take some time before the revocation has full effect.

App redirect methods

Custom URI scheme (Android, iOS, UWP)

Custom URI schemes are a form of deeplinking that use a custom-defined scheme to open your app.

Important: Custom URI schemes are no longer supported on new Chrome apps and are disabled by default on new Android clients due to the risk of app impersonation.

Alternative to using custom URI schemes on Android

Use the Google Sign-In for Android SDK which delivers the OAuth 2.0 response directly to your app, eliminating the need for a redirect URI.

How to migrate to the Google Sign-In for Android SDK

If you use a custom scheme for your OAuth integration on Android, you would need to complete the following actions to fully migrate to using the recommended Google Sign-In for Android SDK:

1. Update your code to use the Google Sign-In SDK.
2. Disable support for custom scheme in the Google API Console.

Note: You should complete and deploy your code updates (accounting for adoption time across your user base or older devices) before disabling support for custom schemes in the Google API Console to avoid users getting an invalid_request error message when they try to use your app.

Follow the below steps to migrate to the Google Sign-In Android SDK:

1. Update your code to use the Google Sign-In Android SDK:
   1. Examine your code to identify where you are sending a request to Google's OAuth 2.0 server ; if using a custom scheme, your request would look like the below:

        https://accounts.google.com/o/oauth2/v2/auth?
        scope=<SCOPES>&
        response_type=code&
        &state=<STATE>&
        redirect_uri=com.example.app:/oauth2redirect&
        client_id=<CLIENT_ID>
        

      com.example.app:/oauth2redirect is the custom scheme redirect URI in the above example. See the redirect_uri parameter definition for more details about the format of the custom URI scheme value.
   2. Make note of the scope and client_id request parameters which you would need to configure the Google Sign-In SDK.
      Note: If you are using a third-party library, review the library's configuration file to find these information.
   3. Follow the Start Integrating Google Sign-In into Your Android App instructions to set up the SDK. You can skip the Get your backend server's OAuth 2.0 client ID step as you would re-use the client_id you retrieved from the previous step.
   4. Follow the Enabling Server-Side API access instructions. This includes the following steps:
      1. Use the getServerAuthCode method to retrieve an auth code for the scopes you are requesting permission for.
      2. Send the auth code to your app's backend to exchange it for an access & refresh token.
      3. Use the retrieved access token to make calls to Google APIs on behalf of the user.
      Note: If your application does not require offline access, follow these instructions instead to request client-side API access.
2. Disable support for custom scheme in the Google API Console:
   1. Go to your OAuth 2.0 credentials list and select your Android client.
   2. Navigate to the Advanced Settings section, uncheck the Enable Custom URI Scheme checkbox, and click Save to disable custom URI scheme support.

Enable custom URI scheme

If the recommended alternative does not work for you, you can enable custom URI schemes for your Android client by following the below instructions:

1. Go to your OAuth 2.0 credentials list and select your Android client.
2. Navigate to the Advanced Settings section, check the Enable Custom URI Scheme checkbox, and click Save to enable custom URI scheme support.

Alternative to using custom URI schemes on Chrome apps

Use the Chrome Identity API which delivers the OAuth 2.0 response directly to your app, eliminating the need for a redirect URI.

Loopback IP address (macOS, Linux, Windows desktop)

Important: The loopback IP address redirect option is DEPRECATED for the Android , Chrome app , and iOS OAuth client types. Review the loopback IP address migration guide for instructions on how to migrate to a supported alternative.

To receive the authorization code using this URL, your application must be listening on the local web server. That is possible on many, but not all, platforms. However, if your platform supports it, this is the recommended mechanism for obtaining the authorization code.

When your app receives the authorization response, for best usability it should respond by displaying an HTML page that instructs the user to close the browser and return to your app.

প্রস্তাবিত ব্যবহার	macOS, Linux, and Windows desktop (but not Universal Windows Platform) apps
ফর্ম মান	Set the application type to Desktop app .

Note: See the redirect_uri parameter definition for more information about the loopback IP address. It is also possible to use localhost in place of the loopback IP, but this configuration may cause issues with client firewalls. Most, but not all, firewalls allow loopback communication.

Manual copy/paste (Deprecated)

Important: The manual copy/paste option, also referred to as an out of band (OOB) redirect method, is no longer supported . Review the OOB migration guide for instructions on how to migrate to a secure alternative.

Protect your apps

Verify app ownership (Android, Chrome)

You can verify ownership of your application to reduce the risk of app impersonation.

অ্যান্ড্রয়েড

Note: Android app ownership verification is only available for Google Play apps.

To complete the verification process, you can use your Google Play Developer Account if you have one and your app is registered on the Google Play Console . The following requirements must be met for a successful verification:

• You must have a registered application in the Google Play Console with the same package name and SHA-1 signing certificate fingerprint as the Android OAuth client you are completing the verification for.
• You must have Admin permission for the app in the Google Play Console. Learn more about access management in the Google Play Console.

In the Verify App Ownership section of the Android client, click the Verify Ownership button to complete the verification process.

If the verification is successful, a notification will be displayed to confirm the success of the verification process. Otherwise, an error prompt will be shown.

To fix a failed verification, try the following:

• Make sure the app you are verifying is a registered app in the Google Play Console.
• Make sure you have Admin permission for the app in the Google Play Console.

ক্রোম

To complete the verification process, you would use your Chrome Web Store Developer account. The following requirements must be met for a successful verification:

• You must have a registered item in the Chrome Web Store Developer Dashboard with the same item ID as the Chrome Extension OAuth client you are completing the verification for.
• You must be a publisher for the Chrome Web Store item. Learn more about access management in the Chrome Web Store Developer Dashboard.

In the Verify App Ownership section of the Chrome Extension client, click the Verify Ownership button to complete the verification process.

Note: Wait a few minutes before completing the verification process after granting access to your account.

If the verification is successful, a notification will be displayed to confirm the success of the verification process. Otherwise, an error prompt will be shown.

To fix a failed verification, try the following:

• Make sure there is a registered item in the Chrome Web Store Developer Dashboard with the same item ID as the Chrome Extension OAuth client you are completing the verification for.
• Make sure you are a publisher for the app, that is, you must either be the individual publisher of the app or a member of the group publisher of the app. Learn more about access management in the Chrome Web Store Developer Dashboard.
• If you just updated your group publisher list, verify that the group publisher membership list is synced in the Chrome Web Store Developer Dashboard. Learn more about syncing your publisher membership list.

App Check (iOS only)

The App Check feature helps safeguard your iOS applications from unauthorized usage by using Apple's App Attest service to verify that requests made to Google OAuth 2.0 endpoints originate from your authentic applications. This helps to reduce the risk of app impersonation.

Enable App Check for your iOS Client

The following requirements must be met to successfully enable App Check for your iOS client:

• You must specify a team ID for your iOS client.
• You must not use a wildcard in your bundle ID since it can resolve to more than one app. This means that the bundle ID must not include the asterisk (*) symbol.

Warning: When App Check is enabled, you won't be able to edit your OAuth client bundle ID without creating a new client. Before creating your iOS client or enabling App Check, verify that you are using the correct bundle ID. Updating your bundle ID for an existing project can result in a broken experience for users of your apps if you are using the bundle ID as a redirect URI.

To enable App Check, turn on the Protect your OAuth client from abuse with Firebase App Check toggle button in the edit view of your iOS client.

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.

আরও পড়া

The IETF Best Current Practice OAuth 2.0 for Native Apps establishes many of the best practices documented here.

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

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.