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

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

পূর্বশর্ত

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

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

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

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

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

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

  1. Go to the Credentials page.
  2. ক্রেডেনশিয়াল তৈরি করুন > OAuth ক্লায়েন্ট আইডি ক্লিক করুন।
  3. নীচের বিভাগগুলি ক্লায়েন্টের প্রকারগুলি এবং পুনঃনির্দেশ পদ্ধতিগুলি বর্ণনা করে যা 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. তৈরি করুন ক্লিক করুন।
UWP
  1. ইউনিভার্সাল উইন্ডোজ প্ল্যাটফর্ম অ্যাপ্লিকেশন টাইপ নির্বাচন করুন।
  2. OAuth ক্লায়েন্টের জন্য একটি নাম লিখুন। ক্লায়েন্ট সনাক্ত করতে এই নামটি আপনার প্রকল্পের Credentials page এ প্রদর্শিত হয়।
  3. আপনার অ্যাপের 12-অক্ষরের Microsoft স্টোর আইডি লিখুন। আপনি অ্যাপ পরিচালনা বিভাগে অ্যাপ পরিচয় পৃষ্ঠায় Microsoft অংশীদার কেন্দ্রে এই মানটি খুঁজে পেতে পারেন।
  4. তৈরি করুন ক্লিক করুন।

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

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

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

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

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

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

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

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

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-এ কল করতে পুনরুদ্ধার করা অ্যাক্সেস টোকেন ব্যবহার করুন।
  2. Google API কনসোলে কাস্টম স্কিমের জন্য সমর্থন অক্ষম করুন:
    1. আপনার OAuth 2.0 শংসাপত্রের তালিকায় যান এবং আপনার Android ক্লায়েন্ট নির্বাচন করুন৷
    2. উন্নত সেটিংস বিভাগে নেভিগেট করুন, কাস্টম ইউআরআই স্কিম সক্ষম করুন চেকবক্সটি আনচেক করুন এবং কাস্টম ইউআরআই স্কিম সমর্থন নিষ্ক্রিয় করতে সংরক্ষণ করুন ক্লিক করুন।
কাস্টম ইউআরআই স্কিম সক্ষম করা হচ্ছে
যদি প্রস্তাবিত বিকল্পটি আপনার জন্য কাজ না করে, আপনি নীচের নির্দেশাবলী অনুসরণ করে আপনার Android ক্লায়েন্টের জন্য কাস্টম URI স্কিমগুলি সক্ষম করতে পারেন:
  1. আপনার OAuth 2.0 শংসাপত্রের তালিকায় যান এবং আপনার Android ক্লায়েন্ট নির্বাচন করুন৷
  2. উন্নত সেটিংস বিভাগে নেভিগেট করুন, কাস্টম ইউআরআই স্কিম সক্ষম করুন চেকবক্সটি চেক করুন এবং কাস্টম ইউআরআই স্কিম সমর্থন সক্ষম করতে সংরক্ষণ ক্লিক করুন।
Chrome অ্যাপে কাস্টম URI স্কিম ব্যবহার করার বিকল্প

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

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

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

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

যাচাইকরণ প্রক্রিয়াটি সম্পূর্ণ করতে, আপনি আপনার 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 ওয়েব স্টোর ডেভেলপার ড্যাশবোর্ডে অ্যাক্সেস ম্যানেজমেন্ট সম্পর্কে আরও জানুন
  • আপনি যদি এইমাত্র আপনার গোষ্ঠী প্রকাশকের তালিকা আপডেট করে থাকেন, তাহলে যাচাই করুন যে গোষ্ঠী প্রকাশকের সদস্যতা তালিকাটি Chrome ওয়েব স্টোর ডেভেলপার ড্যাশবোর্ডে সিঙ্ক হয়েছে৷ আপনার প্রকাশক সদস্যতা তালিকা সিঙ্ক সম্পর্কে আরও জানুন .

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

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

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

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

ম্যানুয়াল কপি/পেস্ট

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

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

আপনি 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 থেকে আলাদা।
লুপব্যাক আইপি ঠিকানা 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 ডকুমেন্টেশন দেখুন।

login_hint ঐচ্ছিক

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

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

নমুনা অনুমোদন 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এ অনুমোদিত রিডাইরেক্ট URIগুলি পর্যালোচনা করুন।

পাস করা 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 প্রদত্ত client_id জন্য API ConsoleCredentials page এ আপনার প্রকল্পের জন্য তালিকাভুক্ত পুনঃনির্দেশিত URIগুলির মধ্যে একটি।

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

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 এ সেট করা থাকে।

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

{
  "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 একটি ত্রুটি কোড সহ ফেরত দেওয়া হয়।

আরও পড়া

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