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

iOS এবং ডেস্কটপ অ্যাপের জন্য OAuth 2.0

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

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

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

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

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

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

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

পূর্বশর্ত

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

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

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

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

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

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

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

আইওএস

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

ইউডব্লিউপি

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

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

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

ms-app://YOUR_APP_PACKAGE_SID

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

পরামিতি

client_id

প্রয়োজনীয়

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

redirect_uri

প্রয়োজনীয়

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

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

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

redirect_uri মান

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

com.example.app : redirect_uri_path

অথবা

com.googleusercontent.apps.123 : redirect_uri_path

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

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

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

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

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

response_type

প্রয়োজনীয়

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

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

scope

প্রয়োজনীয়

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

code_challenge

প্রস্তাবিত

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

code_challenge_method

প্রস্তাবিত

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

state

প্রস্তাবিত

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

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

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

login_hint

ঐচ্ছিক

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

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

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

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

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

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

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

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

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

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

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

ত্রুটি

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

`admin_policy_enforced`

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

`disallowed_useragent`

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

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

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

`org_internal`

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

`deleted_client`

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

`invalid_grant`

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

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

`redirect_uri_mismatch`

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

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

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

`invalid_request`

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

HTTP GET উদাহরণ

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

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://oauth2.googleapis.com/token ) একটি HTTPS POST অনুরোধ পাঠায় যাতে নিম্নলিখিত প্যারামিটারগুলি অন্তর্ভুক্ত থাকে:

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

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

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

client_id=your_client_id&
refresh_token=refresh_token&
grant_type=refresh_token

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

আপনার iOS ক্লায়েন্টের জন্য অ্যাপ চেক প্রয়োগ করুন

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

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

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

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

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

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

আপনার অ্যাপের জন্য আনইনফোর্সিং অ্যাপ চেক এনফোর্সমেন্ট বন্ধ করে দেবে এবং আপনার ক্লায়েন্ট থেকে Google OAuth 2.0 এন্ডপয়েন্টে সমস্ত অনুরোধ অনুমোদন করবে, যার মধ্যে যাচাই না করা অনুরোধও অন্তর্ভুক্ত থাকবে।

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

দ্রষ্টব্য : অ্যাপ চেক আনইনফোর্স করার পরে, পরিবর্তনগুলি কার্যকর হতে ১৫ মিনিট পর্যন্ত সময় লাগতে পারে।

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

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

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

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

সময়-ভিত্তিক অ্যাক্সেস

সময়-ভিত্তিক অ্যাক্সেস ব্যবহারকারীকে কোনও কাজ সম্পন্ন করার জন্য সীমিত সময়ের জন্য আপনার অ্যাপকে তাদের ডেটাতে অ্যাক্সেস দেওয়ার অনুমতি দেয়। সম্মতি প্রবাহের সময় নির্বাচিত Google পণ্যগুলিতে সময়-ভিত্তিক অ্যাক্সেস পাওয়া যায়, যা ব্যবহারকারীদের সীমিত সময়ের জন্য অ্যাক্সেস দেওয়ার বিকল্প দেয়। একটি উদাহরণ হল ডেটা পোর্টেবিলিটি API যা এককালীন ডেটা স্থানান্তর সক্ষম করে।

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

আরও পড়ুন

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

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

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

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

https://schemas.openid.net/secevent/risc/event-type/sessions-revoked
https://schemas.openid.net/secevent/oauth/event-type/token-revoked
https://schemas.openid.net/secevent/risc/event-type/account-disabled

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

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

পূর্বশর্ত

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

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

আইওএস

ইউডব্লিউপি

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

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

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

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

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

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

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

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

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

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

ত্রুটি

admin_policy_enforced

disallowed_useragent

org_internal

deleted_client

invalid_grant

redirect_uri_mismatch

invalid_request

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

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

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

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

HTTP GET উদাহরণ

curl উদাহরণ

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

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

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

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

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

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

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

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

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

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

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

আপনার iOS ক্লায়েন্টের জন্য অ্যাপ চেক প্রয়োগ করুন

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

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

সময়-ভিত্তিক অ্যাক্সেস

আরও পড়ুন

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

`admin_policy_enforced`

`disallowed_useragent`

`org_internal`

`deleted_client`

`invalid_grant`

`redirect_uri_mismatch`

`invalid_request`

`curl` উদাহরণ