একটি OAuth 2.0 সার্ভার প্রয়োগ করুন

প্রতিটি Cloud-to-cloud ইন্টিগ্রেশনে ব্যবহারকারীদের প্রমাণীকরণের জন্য একটি প্রক্রিয়া অন্তর্ভুক্ত থাকতে হবে।

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

এই পৃষ্ঠাটি বর্ণনা করে কিভাবে আপনার OAuth 2.0 সার্ভার সেট আপ করবেন যাতে এটি আপনার Cloud-to-cloud ইন্টিগ্রেশনের সাথে কাজ করে।

OAuth-এর সাথে Google অ্যাকাউন্ট লিঙ্ক করা

অনুমোদন কোড প্রবাহে, আপনার দুটি শেষ পয়েন্ট প্রয়োজন:

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

  • টোকেন এক্সচেঞ্জ এন্ডপয়েন্ট, যা দুই ধরনের এক্সচেঞ্জের জন্য দায়ী:

    1. একটি দীর্ঘস্থায়ী রিফ্রেশ টোকেন এবং একটি স্বল্পকালীন অ্যাক্সেস টোকেনের জন্য একটি অনুমোদন কোড বিনিময় করে৷ এই বিনিময়টি ঘটে যখন ব্যবহারকারী অ্যাকাউন্ট লিঙ্কিং প্রবাহের মধ্য দিয়ে যায়।
    2. একটি স্বল্পকালীন অ্যাক্সেস টোকেনের জন্য দীর্ঘস্থায়ী রিফ্রেশ টোকেন বিনিময় করে। এই বিনিময়টি ঘটে যখন Google এর একটি নতুন অ্যাক্সেস টোকেনের প্রয়োজন হয় কারণ এটির মেয়াদ শেষ হয়ে গেছে৷

ডিজাইন নির্দেশিকা

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

এই চিত্রটি একজন ব্যবহারকারীকে তাদের Google অ্যাকাউন্ট লিঙ্ক করার পদক্ষেপগুলি দেখায়৷ আপনার প্রমাণীকরণ সিস্টেমে। প্রথম স্ক্রিনশট দেখায় আপনার প্ল্যাটফর্ম থেকে ব্যবহারকারীর সূচনা লিঙ্কিং। দ্বিতীয় চিত্র দেখায় ব্যবহারকারী Google-এ সাইন-ইন করে, যখন তৃতীয়টি ব্যবহারকারীর সম্মতি দেখায় এবং আপনার অ্যাপের সাথে তাদের Google অ্যাকাউন্ট লিঙ্ক করার জন্য নিশ্চিতকরণ। দ চূড়ান্ত স্ক্রিনশট একটি সফলভাবে লিঙ্ক করা ব্যবহারকারী অ্যাকাউন্ট দেখায় গুগল অ্যাপ।
চিত্র 1. অ্যাকাউন্ট লিঙ্ককারী ব্যবহারকারী গুগলে সাইন ইন করুন এবং সম্মতি স্ক্রীন।

প্রয়োজনীয়তা

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

সুপারিশ

আমরা আপনাকে নিম্নলিখিতগুলি করার পরামর্শ দিই:

  1. Google এর গোপনীয়তা নীতি প্রদর্শন করুন। সম্মতি স্ক্রিনে Google-এর গোপনীয়তা নীতির একটি লিঙ্ক অন্তর্ভুক্ত করুন।

  2. ডেটা শেয়ার করতে হবে। ব্যবহারকারীকে তাদের Google-এর কোন ডেটা প্রয়োজন এবং কেন তা জানাতে স্পষ্ট এবং সংক্ষিপ্ত ভাষা ব্যবহার করুন।

  3. কল-টু-অ্যাকশন পরিষ্কার করুন। আপনার সম্মতি স্ক্রিনে একটি স্পষ্ট কল-টু-অ্যাকশন বলুন, যেমন "সম্মতি এবং লিঙ্ক"। এর কারণ হল ব্যবহারকারীদের বুঝতে হবে তাদের অ্যাকাউন্ট লিঙ্ক করার জন্য Google-এর সাথে কী ডেটা শেয়ার করতে হবে।

  4. বাতিল করার ক্ষমতা। ব্যবহারকারীরা যদি লিঙ্ক না করতে চান তাহলে ফিরে যেতে বা বাতিল করার জন্য একটি উপায় প্রদান করুন৷

  5. সাইন-ইন প্রক্রিয়া পরিষ্কার করুন। নিশ্চিত করুন যে ব্যবহারকারীদের তাদের Google অ্যাকাউন্টে সাইন ইন করার জন্য একটি পরিষ্কার পদ্ধতি রয়েছে, যেমন তাদের ব্যবহারকারীর নাম এবং পাসওয়ার্ডের জন্য ক্ষেত্র বা Google দিয়ে সাইন ইন করুন ।

  6. লিঙ্কমুক্ত করার ক্ষমতা। ব্যবহারকারীদের আনলিঙ্ক করার জন্য একটি পদ্ধতি অফার করুন, যেমন আপনার প্ল্যাটফর্মে তাদের অ্যাকাউন্ট সেটিংসের URL। বিকল্পভাবে, আপনি Google অ্যাকাউন্টে একটি লিঙ্ক অন্তর্ভুক্ত করতে পারেন যেখানে ব্যবহারকারীরা তাদের লিঙ্ক করা অ্যাকাউন্ট পরিচালনা করতে পারে।

  7. ব্যবহারকারীর অ্যাকাউন্ট পরিবর্তন করার ক্ষমতা। ব্যবহারকারীদের তাদের অ্যাকাউন্ট(গুলি) পরিবর্তন করার জন্য একটি পদ্ধতির পরামর্শ দিন। এটি বিশেষত উপকারী যদি ব্যবহারকারীদের একাধিক অ্যাকাউন্ট থাকে।

    • যদি কোনো ব্যবহারকারীকে অ্যাকাউন্ট পাল্টানোর জন্য সম্মতি স্ক্রীন বন্ধ করতে হয়, তাহলে Google-এ একটি পুনরুদ্ধারযোগ্য ত্রুটি পাঠান যাতে ব্যবহারকারী OAuth লিঙ্কের মাধ্যমে পছন্দসই অ্যাকাউন্টে সাইন ইন করতে পারেন।

  8. আপনার লোগো অন্তর্ভুক্ত করুন. সম্মতি স্ক্রিনে আপনার কোম্পানির লোগো প্রদর্শন করুন। আপনার লোগো স্থাপন করতে আপনার শৈলী নির্দেশিকা ব্যবহার করুন. আপনি যদি Google এর লোগোও প্রদর্শন করতে চান তবে লোগো এবং ট্রেডমার্ক দেখুন।

অনুমোদন কোড প্রবাহ

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

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

Google দ্বারা শুরু করা একটি OAuth 2.0 অনুমোদন কোড ফ্লো সেশনে নিম্নলিখিত ফ্লো থাকে:

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

অনুমোদনের অনুরোধগুলি পরিচালনা করুন

যখন আপনাকে OAuth 2.0 অনুমোদন কোড ফ্লো ব্যবহার করে অ্যাকাউন্ট লিঙ্কিং করতে হবে, তখন Google ব্যবহারকারীকে আপনার অনুমোদনের শেষ বিন্দুতে একটি অনুরোধ পাঠায় যার মধ্যে নিম্নলিখিত প্যারামিটারগুলি অন্তর্ভুক্ত থাকে:

অনুমোদনের শেষ বিন্দুর প্যারামিটার
client_id আপনার Google-কে অ্যাসাইন করা ক্লায়েন্ট আইডি।
redirect_uri এই অনুরোধের উত্তর আপনি যে URL-এ পাঠাবেন।
state একটি হিসাবরক্ষণ মান যা পুনঃনির্দেশ URI-তে অপরিবর্তিতভাবে Google-এ ফেরত পাঠানো হয়।
scope ঐচ্ছিক: Google যে ডেটার জন্য অনুমোদনের অনুরোধ করছে তা নির্দিষ্ট করে এমন স্কোপ স্ট্রিংগুলির একটি স্থান-বিভাজিত সেট।
response_type প্রতিক্রিয়াতে যে ধরণের মানের রিটার্ন করতে হবে। OAuth 2.0 অনুমোদন কোড প্রবাহের জন্য, প্রতিক্রিয়ার ধরণ সর্বদা code হয়।

উদাহরণস্বরূপ, যদি আপনার অনুমোদনের শেষ বিন্দু https://myservice.example.com/auth এ উপলব্ধ থাকে, তাহলে একটি অনুরোধ নিম্নলিখিতগুলির মতো দেখতে পারে:

GET https://myservice.example.com/auth?client_id=GOOGLE_CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE_STRING&scope=REQUESTED_SCOPES&response_type=code

আপনার অনুমোদনের শেষ বিন্দু সাইন-ইন অনুরোধগুলি পরিচালনা করার জন্য, নিম্নলিখিত পদক্ষেপগুলি অনুসরণ করুন:

  1. client_id আপনার Google-কে দেওয়া ক্লায়েন্ট আইডির সাথে মেলে কিনা এবং redirect_uri আপনার পরিষেবার জন্য Google দ্বারা প্রদত্ত রিডাইরেক্ট URL-এর সাথে মেলে কিনা তা যাচাই করুন। অযাচিত বা ভুল কনফিগার করা ক্লায়েন্ট অ্যাপগুলিতে অ্যাক্সেস দেওয়া রোধ করার জন্য এই পরীক্ষাগুলি গুরুত্বপূর্ণ। আপনি যদি একাধিক OAuth 2.0 ফ্লো সমর্থন করেন, তাহলে নিশ্চিত করুন যে response_type হল code ।
  2. ব্যবহারকারী আপনার পরিষেবায় সাইন ইন করেছেন কিনা তা পরীক্ষা করুন। যদি ব্যবহারকারী সাইন ইন না করে থাকেন, তাহলে আপনার পরিষেবার সাইন-ইন বা সাইন-আপ প্রক্রিয়াটি সম্পূর্ণ করুন।
  3. আপনার API অ্যাক্সেস করার জন্য Google-এর জন্য একটি অনুমোদন কোড তৈরি করুন। অনুমোদন কোডটি যেকোনো স্ট্রিং মান হতে পারে, তবে এটি ব্যবহারকারী, টোকেনটি যে ক্লায়েন্টের জন্য এবং কোডের মেয়াদ শেষ হওয়ার সময়কে অনন্যভাবে উপস্থাপন করবে এবং এটি অনুমানযোগ্য হওয়া উচিত নয়। আপনি সাধারণত অনুমোদন কোডগুলি জারি করেন যা প্রায় 10 মিনিট পরে মেয়াদ শেষ হয়ে যায়।
  4. redirect_uri প্যারামিটার দ্বারা নির্দিষ্ট করা URL-এ নিম্নলিখিত ফর্ম আছে কিনা তা নিশ্চিত করুন: 
      https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID
  https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
  5. ব্যবহারকারীর ব্রাউজারটিকে redirect_uri প্যারামিটার দ্বারা নির্দিষ্ট URL-এ পুনঃনির্দেশিত করুন। code এবং state প্যারামিটার যুক্ত করে পুনঃনির্দেশিত করার সময় আপনার তৈরি করা অনুমোদন কোড এবং মূল, অপরিবর্তিত অবস্থা মান অন্তর্ভুক্ত করুন। ফলাফল URL-এর একটি উদাহরণ নিচে দেওয়া হল: 
    https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID?code=AUTHORIZATION_CODE&state=STATE_STRING

টোকেন বিনিময় অনুরোধগুলি পরিচালনা করুন

আপনার পরিষেবার টোকেন এক্সচেঞ্জ এন্ডপয়েন্ট দুই ধরণের টোকেন এক্সচেঞ্জের জন্য দায়ী:

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

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

টোকেন এক্সচেঞ্জ এন্ডপয়েন্ট প্যারামিটার
client_id একটি স্ট্রিং যা অনুরোধের উৎসকে Google হিসেবে শনাক্ত করে। এই স্ট্রিংটি আপনার সিস্টেমে Google-এর অনন্য শনাক্তকারী হিসেবে নিবন্ধিত হতে হবে।
client_secret আপনার পরিষেবার জন্য Google-এ নিবন্ধিত একটি গোপন স্ট্রিং।
grant_type যে ধরণের টোকেন বিনিময় করা হচ্ছে। এটি হয় authorization_code অথবা refresh_token ।
code যখন grant_type=authorization_code , তখন এই প্যারামিটারটি হল সেই কোড যা Google আপনার সাইন-ইন অথবা টোকেন এক্সচেঞ্জ এন্ডপয়েন্ট থেকে পেয়েছে।
redirect_uri যখন grant_type=authorization_code , তখন এই প্যারামিটারটি হল প্রাথমিক অনুমোদনের অনুরোধে ব্যবহৃত URL।
refresh_token যখন grant_type=refresh_token , তখন এই প্যারামিটারটি হল আপনার টোকেন এক্সচেঞ্জ এন্ডপয়েন্ট থেকে Google প্রাপ্ত রিফ্রেশ টোকেন।

Google কীভাবে আপনার সার্ভারে শংসাপত্র পাঠায় তা কনফিগার করুন

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

ডিফল্টরূপে, Google অনুরোধের বডিতে শংসাপত্রগুলি পাঠায়। যদি আপনার অনুমোদন সার্ভার ক্লায়েন্ট শংসাপত্রগুলিকে অনুরোধের শিরোনামে থাকা প্রয়োজন, তাহলে আপনাকে অবশ্যই আপনার Cloud-to-cloud ইন্টিগ্রেশনটি সেই অনুযায়ী কনফিগার করতে হবে:

ডেভেলপার কনসোলে যান

  1. প্রকল্পের তালিকা থেকে, আপনি যে প্রকল্পের সাথে কাজ করতে চান তার পাশে "খুলুন" এ ক্লিক করুন।

  2. ক্লাউড-টু-ক্লাউড এর অধীনে, ডেভেলপ নির্বাচন করুন।

  3. আপনার ইন্টিগ্রেশনের পরবর্তী "খুলুন" এ ক্লিক করুন।

  4. "অনুমতি" (ঐচ্ছিক) বিভাগে স্ক্রোল করুন এবং "Have Google transmit Client ID and secret via HTTP basic auth header" চেকবক্সটি নির্বাচন করুন।

  5. আপনার পরিবর্তনগুলি সংরক্ষণ করতে সংরক্ষণ করুন ক্লিক করুন।

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

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

এই অনুরোধগুলির জন্য, grant_type এর মান হল authorization_code , এবং code মান হল Google কে পূর্বে দেওয়া অনুমোদন কোডের মান। একটি অ্যাক্সেস টোকেন এবং একটি রিফ্রেশ টোকেনের জন্য একটি অনুমোদন কোড বিনিময়ের অনুরোধের একটি উদাহরণ নিচে দেওয়া হল:

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

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URI

একটি অ্যাক্সেস টোকেন এবং একটি রিফ্রেশ টোকেনের জন্য অনুমোদন কোড বিনিময় করতে, আপনার টোকেন এক্সচেঞ্জ এন্ডপয়েন্ট নিম্নলিখিত পদক্ষেপগুলি সম্পাদন করে POST অনুরোধগুলিতে সাড়া দেয়:

  1. যাচাই করুন যে client_id অনুরোধের উৎসটিকে একটি অনুমোদিত উৎস হিসেবে চিহ্নিত করে এবং client_secret প্রত্যাশিত মানের সাথে মেলে।
  2. যাচাই করুন যে অনুমোদন কোডটি বৈধ এবং মেয়াদোত্তীর্ণ নয়, এবং অনুরোধে উল্লেখিত ক্লায়েন্ট আইডি অনুমোদন কোডের সাথে সম্পর্কিত ক্লায়েন্ট আইডির সাথে মেলে।
  3. নিশ্চিত করুন যে redirect_uri প্যারামিটার দ্বারা নির্দিষ্ট করা URLটি প্রাথমিক অনুমোদনের অনুরোধে ব্যবহৃত মানের সাথে অভিন্ন।
  4. যদি আপনি উপরের সমস্ত মানদণ্ড যাচাই করতে না পারেন, {"error": "invalid_grant"} এর মূল অংশ হিসেবে HTTP 400 Bad Request ত্রুটিটি ফেরত পাঠান।
  5. অন্যথায়, অনুমোদন কোড থেকে ব্যবহারকারী আইডি ব্যবহার করে একটি রিফ্রেশ টোকেন এবং একটি অ্যাক্সেস টোকেন তৈরি করুন। এই টোকেনগুলি যেকোনো স্ট্রিং মান হতে পারে, তবে এগুলি অবশ্যই ব্যবহারকারী এবং ক্লায়েন্টকে স্বতন্ত্রভাবে উপস্থাপন করবে যার জন্য টোকেনটি তৈরি করা হয়েছে এবং এগুলি অনুমানযোগ্য হওয়া উচিত নয়। অ্যাক্সেস টোকেনের জন্য, টোকেনের মেয়াদও রেকর্ড করুন, যা সাধারণত আপনি টোকেন ইস্যু করার এক ঘন্টা পরে হয়। রিফ্রেশ টোকেনগুলির মেয়াদ শেষ হয় না।
  6. HTTPS রেসপন্সের বডিতে নিম্নলিখিত JSON অবজেক্টটি রিটার্ন করুন: 
    {
"token_type": "Bearer",
"access_token": "ACCESS_TOKEN",
"refresh_token": "REFRESH_TOKEN",
"expires_in": SECONDS_TO_EXPIRATION
}

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

অ্যাক্সেস টোকেনের জন্য রিফ্রেশ টোকেন বিনিময় করুন

যখন একটি অ্যাক্সেস টোকেনের মেয়াদ শেষ হয়ে যায়, তখন Google আপনার টোকেন এক্সচেঞ্জ এন্ডপয়েন্টে একটি রিফ্রেশ টোকেন বিনিময় করে একটি নতুন অ্যাক্সেস টোকেন পাঠানোর জন্য একটি অনুরোধ পাঠায়।

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

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

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=refresh_token&refresh_token=REFRESH_TOKEN

একটি রিফ্রেশ টোকেনকে একটি অ্যাক্সেস টোকেনের সাথে বিনিময় করতে, আপনার টোকেন এক্সচেঞ্জ এন্ডপয়েন্ট নিম্নলিখিত পদক্ষেপগুলি সম্পাদন করে POST অনুরোধের প্রতিক্রিয়া জানায়:

  1. client_id অনুরোধের উৎসটিকে Google হিসেবে শনাক্ত করে এবং client_secret প্রত্যাশিত মানের সাথে মেলে কিনা তা যাচাই করুন।
  2. যাচাই করুন যে রিফ্রেশ টোকেনটি বৈধ, এবং অনুরোধে উল্লেখিত ক্লায়েন্ট আইডি রিফ্রেশ টোকেনের সাথে সম্পর্কিত ক্লায়েন্ট আইডির সাথে মেলে।
  3. যদি আপনি উপরের সমস্ত মানদণ্ড যাচাই করতে না পারেন, {"error": "invalid_grant"} এর মূল অংশ হিসেবে HTTP 400 Bad Request ত্রুটিটি ফেরত পাঠান।
  4. অন্যথায়, রিফ্রেশ টোকেন থেকে ব্যবহারকারী আইডি ব্যবহার করে একটি অ্যাক্সেস টোকেন তৈরি করুন। এই টোকেনগুলি যেকোনো স্ট্রিং মান হতে পারে, তবে এগুলিকে অবশ্যই ব্যবহারকারী এবং ক্লায়েন্টকে স্বতন্ত্রভাবে উপস্থাপন করতে হবে যার জন্য টোকেনটি তৈরি করা হয়েছে এবং এগুলি অনুমানযোগ্য হওয়া উচিত নয়। অ্যাক্সেস টোকেনের জন্য, টোকেনের মেয়াদ শেষ হওয়ার সময়টিও রেকর্ড করুন, সাধারণত টোকেন ইস্যু করার এক ঘন্টা পরে।
  5. HTTPS রেসপন্সের বডিতে নিম্নলিখিত JSON অবজেক্টটি রিটার্ন করুন:
    {
"token_type": "Bearer",
"access_token": " ACCESS_TOKEN ",
"expires_in": SECONDS_TO_EXPIRATION
}

Handle userinfo requests

The userinfo endpoint is an OAuth 2.0 protected resource that return claims about the linked user. Implementing and hosting the userinfo endpoint is optional, except for the following use cases:

After the access token has been successfully retrieved from your token endpoint, Google sends a request to your userinfo endpoint to retrieve basic profile information about the linked user.

userinfo endpoint request headers
Authorization header The access token of type Bearer.

For example, if your userinfo endpoint is available at https://myservice.example.com/userinfo, a request might look like the following:

GET /userinfo HTTP/1.1
Host: myservice.example.com
Authorization: Bearer ACCESS_TOKEN

For your userinfo endpoint to handle requests, do the following steps:

  1. Extract access token from the Authorization header and return information for the user associated with the access token.
  2. If the access token is invalid, return an HTTP 401 Unauthorized error with using the WWW-Authenticate Response Header. Below is an example of a userinfo error response: 
    HTTP/1.1 401 Unauthorized
WWW-Authenticate: error="invalid_token",
error_description="The Access Token expired"
    If a 401 Unauthorized, or any other unsuccessful error response is returned during the linking process, the error will be non-recoverable, the retrieved token will be discarded and the user will have to initiate the linking process again.

  3. If the access token is valid, return and HTTP 200 response with the following JSON object in the body of the HTTPS response: 

    {
"sub": "USER_UUID",
"email": "EMAIL_ADDRESS",
"given_name": "FIRST_NAME",
"family_name": "LAST_NAME",
"name": "FULL_NAME",
"picture": "PROFILE_PICTURE",
}
     If your userinfo endpoint returns an HTTP 200 success response, the retrieved token and claims are registered against the user's Google account.

    userinfo endpoint response
    sub A unique ID that identifies the user in your system.
    email Email address of the user.
    given_name Optional: First name of the user.
    family_name Optional: Last name of the user.
    name Optional: Full name of the user.
    picture Optional: Profile picture of the user.
,

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

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

Google দ্বারা শুরু করা একটি OAuth 2.0 অনুমোদন কোড ফ্লো সেশনে নিম্নলিখিত ফ্লো থাকে:

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

অনুমোদনের অনুরোধগুলি পরিচালনা করুন

যখন আপনাকে OAuth 2.0 অনুমোদন কোড ফ্লো ব্যবহার করে অ্যাকাউন্ট লিঙ্কিং করতে হবে, তখন Google ব্যবহারকারীকে আপনার অনুমোদনের শেষ বিন্দুতে একটি অনুরোধ পাঠায় যার মধ্যে নিম্নলিখিত প্যারামিটারগুলি অন্তর্ভুক্ত থাকে:

অনুমোদনের শেষ বিন্দুর প্যারামিটার
client_id আপনার Google-কে অ্যাসাইন করা ক্লায়েন্ট আইডি।
redirect_uri এই অনুরোধের উত্তর আপনি যে URL-এ পাঠাবেন।
state একটি হিসাবরক্ষণ মান যা পুনঃনির্দেশ URI-তে অপরিবর্তিতভাবে Google-এ ফেরত পাঠানো হয়।
scope ঐচ্ছিক: Google যে ডেটার জন্য অনুমোদনের অনুরোধ করছে তা নির্দিষ্ট করে এমন স্কোপ স্ট্রিংগুলির একটি স্থান-বিভাজিত সেট।
response_type প্রতিক্রিয়াতে যে ধরণের মানের রিটার্ন করতে হবে। OAuth 2.0 অনুমোদন কোড প্রবাহের জন্য, প্রতিক্রিয়ার ধরণ সর্বদা code হয়।

উদাহরণস্বরূপ, যদি আপনার অনুমোদনের শেষ বিন্দু https://myservice.example.com/auth এ উপলব্ধ থাকে, তাহলে একটি অনুরোধ নিম্নলিখিতগুলির মতো দেখতে পারে:

GET https://myservice.example.com/auth?client_id=GOOGLE_CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE_STRING&scope=REQUESTED_SCOPES&response_type=code

আপনার অনুমোদনের শেষ বিন্দু সাইন-ইন অনুরোধগুলি পরিচালনা করার জন্য, নিম্নলিখিত পদক্ষেপগুলি অনুসরণ করুন:

  1. client_id আপনার Google-কে দেওয়া ক্লায়েন্ট আইডির সাথে মেলে কিনা এবং redirect_uri আপনার পরিষেবার জন্য Google দ্বারা প্রদত্ত রিডাইরেক্ট URL-এর সাথে মেলে কিনা তা যাচাই করুন। অযাচিত বা ভুল কনফিগার করা ক্লায়েন্ট অ্যাপগুলিতে অ্যাক্সেস দেওয়া রোধ করার জন্য এই পরীক্ষাগুলি গুরুত্বপূর্ণ। আপনি যদি একাধিক OAuth 2.0 ফ্লো সমর্থন করেন, তাহলে নিশ্চিত করুন যে response_type হল code ।
  2. ব্যবহারকারী আপনার পরিষেবায় সাইন ইন করেছেন কিনা তা পরীক্ষা করুন। যদি ব্যবহারকারী সাইন ইন না করে থাকেন, তাহলে আপনার পরিষেবার সাইন-ইন বা সাইন-আপ প্রক্রিয়াটি সম্পূর্ণ করুন।
  3. আপনার API অ্যাক্সেস করার জন্য Google-এর জন্য একটি অনুমোদন কোড তৈরি করুন। অনুমোদন কোডটি যেকোনো স্ট্রিং মান হতে পারে, তবে এটি ব্যবহারকারী, টোকেনটি যে ক্লায়েন্টের জন্য এবং কোডের মেয়াদ শেষ হওয়ার সময়কে অনন্যভাবে উপস্থাপন করবে এবং এটি অনুমানযোগ্য হওয়া উচিত নয়। আপনি সাধারণত অনুমোদন কোডগুলি জারি করেন যা প্রায় 10 মিনিট পরে মেয়াদ শেষ হয়ে যায়।
  4. redirect_uri প্যারামিটার দ্বারা নির্দিষ্ট করা URL-এ নিম্নলিখিত ফর্ম আছে কিনা তা নিশ্চিত করুন: 
      https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID
  https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
  5. ব্যবহারকারীর ব্রাউজারটিকে redirect_uri প্যারামিটার দ্বারা নির্দিষ্ট URL-এ পুনঃনির্দেশিত করুন। code এবং state প্যারামিটার যুক্ত করে পুনঃনির্দেশিত করার সময় আপনার তৈরি করা অনুমোদন কোড এবং মূল, অপরিবর্তিত অবস্থা মান অন্তর্ভুক্ত করুন। ফলাফল URL-এর একটি উদাহরণ নিচে দেওয়া হল: 
    https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID?code=AUTHORIZATION_CODE&state=STATE_STRING

টোকেন বিনিময় অনুরোধগুলি পরিচালনা করুন

আপনার পরিষেবার টোকেন এক্সচেঞ্জ এন্ডপয়েন্ট দুই ধরণের টোকেন এক্সচেঞ্জের জন্য দায়ী:

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

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

টোকেন এক্সচেঞ্জ এন্ডপয়েন্ট প্যারামিটার
client_id একটি স্ট্রিং যা অনুরোধের উৎসকে Google হিসেবে শনাক্ত করে। এই স্ট্রিংটি আপনার সিস্টেমে Google-এর অনন্য শনাক্তকারী হিসেবে নিবন্ধিত হতে হবে।
client_secret আপনার পরিষেবার জন্য Google-এ নিবন্ধিত একটি গোপন স্ট্রিং।
grant_type যে ধরণের টোকেন বিনিময় করা হচ্ছে। এটি হয় authorization_code অথবা refresh_token ।
code যখন grant_type=authorization_code , তখন এই প্যারামিটারটি হল সেই কোড যা Google আপনার সাইন-ইন অথবা টোকেন এক্সচেঞ্জ এন্ডপয়েন্ট থেকে পেয়েছে।
redirect_uri যখন grant_type=authorization_code , তখন এই প্যারামিটারটি হল প্রাথমিক অনুমোদনের অনুরোধে ব্যবহৃত URL।
refresh_token যখন grant_type=refresh_token , তখন এই প্যারামিটারটি হল আপনার টোকেন এক্সচেঞ্জ এন্ডপয়েন্ট থেকে Google প্রাপ্ত রিফ্রেশ টোকেন।

Google কীভাবে আপনার সার্ভারে শংসাপত্র পাঠায় তা কনফিগার করুন

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

ডিফল্টরূপে, Google অনুরোধের বডিতে শংসাপত্রগুলি পাঠায়। যদি আপনার অনুমোদন সার্ভার ক্লায়েন্ট শংসাপত্রগুলিকে অনুরোধের শিরোনামে থাকা প্রয়োজন, তাহলে আপনাকে অবশ্যই আপনার Cloud-to-cloud ইন্টিগ্রেশনটি সেই অনুযায়ী কনফিগার করতে হবে:

ডেভেলপার কনসোলে যান

  1. প্রকল্পের তালিকা থেকে, আপনি যে প্রকল্পের সাথে কাজ করতে চান তার পাশে "খুলুন" এ ক্লিক করুন।

  2. ক্লাউড-টু-ক্লাউড এর অধীনে, ডেভেলপ নির্বাচন করুন।

  3. আপনার ইন্টিগ্রেশনের পরবর্তী "খুলুন" এ ক্লিক করুন।

  4. "অনুমতি" (ঐচ্ছিক) বিভাগে স্ক্রোল করুন এবং "Have Google transmit Client ID and secret via HTTP basic auth header" চেকবক্সটি নির্বাচন করুন।

  5. আপনার পরিবর্তনগুলি সংরক্ষণ করতে সংরক্ষণ করুন ক্লিক করুন।

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

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

এই অনুরোধগুলির জন্য, grant_type এর মান হল authorization_code , এবং code মান হল Google কে পূর্বে দেওয়া অনুমোদন কোডের মান। একটি অ্যাক্সেস টোকেন এবং একটি রিফ্রেশ টোকেনের জন্য একটি অনুমোদন কোড বিনিময়ের অনুরোধের একটি উদাহরণ নিচে দেওয়া হল:

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

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URI

একটি অ্যাক্সেস টোকেন এবং একটি রিফ্রেশ টোকেনের জন্য অনুমোদন কোড বিনিময় করতে, আপনার টোকেন এক্সচেঞ্জ এন্ডপয়েন্ট নিম্নলিখিত পদক্ষেপগুলি সম্পাদন করে POST অনুরোধগুলিতে সাড়া দেয়:

  1. যাচাই করুন যে client_id অনুরোধের উৎসটিকে একটি অনুমোদিত উৎস হিসেবে চিহ্নিত করে এবং client_secret প্রত্যাশিত মানের সাথে মেলে।
  2. যাচাই করুন যে অনুমোদন কোডটি বৈধ এবং মেয়াদোত্তীর্ণ নয়, এবং অনুরোধে উল্লেখিত ক্লায়েন্ট আইডি অনুমোদন কোডের সাথে সম্পর্কিত ক্লায়েন্ট আইডির সাথে মেলে।
  3. নিশ্চিত করুন যে redirect_uri প্যারামিটার দ্বারা নির্দিষ্ট করা URLটি প্রাথমিক অনুমোদনের অনুরোধে ব্যবহৃত মানের সাথে অভিন্ন।
  4. যদি আপনি উপরের সমস্ত মানদণ্ড যাচাই করতে না পারেন, {"error": "invalid_grant"} এর মূল অংশ হিসেবে HTTP 400 Bad Request ত্রুটিটি ফেরত পাঠান।
  5. অন্যথায়, অনুমোদন কোড থেকে ব্যবহারকারী আইডি ব্যবহার করে একটি রিফ্রেশ টোকেন এবং একটি অ্যাক্সেস টোকেন তৈরি করুন। এই টোকেনগুলি যেকোনো স্ট্রিং মান হতে পারে, তবে এগুলি অবশ্যই ব্যবহারকারী এবং ক্লায়েন্টকে স্বতন্ত্রভাবে উপস্থাপন করবে যার জন্য টোকেনটি তৈরি করা হয়েছে এবং এগুলি অনুমানযোগ্য হওয়া উচিত নয়। অ্যাক্সেস টোকেনের জন্য, টোকেনের মেয়াদও রেকর্ড করুন, যা সাধারণত আপনি টোকেন ইস্যু করার এক ঘন্টা পরে হয়। রিফ্রেশ টোকেনগুলির মেয়াদ শেষ হয় না।
  6. HTTPS রেসপন্সের বডিতে নিম্নলিখিত JSON অবজেক্টটি রিটার্ন করুন: 
    {
"token_type": "Bearer",
"access_token": "ACCESS_TOKEN",
"refresh_token": "REFRESH_TOKEN",
"expires_in": SECONDS_TO_EXPIRATION
}

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

অ্যাক্সেস টোকেনের জন্য রিফ্রেশ টোকেন বিনিময় করুন

যখন একটি অ্যাক্সেস টোকেনের মেয়াদ শেষ হয়ে যায়, তখন Google আপনার টোকেন এক্সচেঞ্জ এন্ডপয়েন্টে একটি রিফ্রেশ টোকেন বিনিময় করে একটি নতুন অ্যাক্সেস টোকেন পাঠানোর জন্য একটি অনুরোধ পাঠায়।

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

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

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=refresh_token&refresh_token=REFRESH_TOKEN

একটি রিফ্রেশ টোকেনকে একটি অ্যাক্সেস টোকেনের সাথে বিনিময় করতে, আপনার টোকেন এক্সচেঞ্জ এন্ডপয়েন্ট নিম্নলিখিত পদক্ষেপগুলি সম্পাদন করে POST অনুরোধের প্রতিক্রিয়া জানায়:

  1. client_id অনুরোধের উৎসটিকে Google হিসেবে শনাক্ত করে এবং client_secret প্রত্যাশিত মানের সাথে মেলে কিনা তা যাচাই করুন।
  2. যাচাই করুন যে রিফ্রেশ টোকেনটি বৈধ, এবং অনুরোধে উল্লেখিত ক্লায়েন্ট আইডি রিফ্রেশ টোকেনের সাথে সম্পর্কিত ক্লায়েন্ট আইডির সাথে মেলে।
  3. যদি আপনি উপরের সমস্ত মানদণ্ড যাচাই করতে না পারেন, {"error": "invalid_grant"} এর মূল অংশ হিসেবে HTTP 400 Bad Request ত্রুটিটি ফেরত পাঠান।
  4. অন্যথায়, রিফ্রেশ টোকেন থেকে ব্যবহারকারী আইডি ব্যবহার করে একটি অ্যাক্সেস টোকেন তৈরি করুন। এই টোকেনগুলি যেকোনো স্ট্রিং মান হতে পারে, তবে এগুলিকে অবশ্যই ব্যবহারকারী এবং ক্লায়েন্টকে স্বতন্ত্রভাবে উপস্থাপন করতে হবে যার জন্য টোকেনটি তৈরি করা হয়েছে এবং এগুলি অনুমানযোগ্য হওয়া উচিত নয়। অ্যাক্সেস টোকেনের জন্য, টোকেনের মেয়াদ শেষ হওয়ার সময়টিও রেকর্ড করুন, সাধারণত টোকেন ইস্যু করার এক ঘন্টা পরে।
  5. HTTPS রেসপন্সের বডিতে নিম্নলিখিত JSON অবজেক্টটি রিটার্ন করুন:
    {
"token_type": "Bearer",
"access_token": " ACCESS_TOKEN ",
"expires_in": SECONDS_TO_EXPIRATION
}

Handle userinfo requests

The userinfo endpoint is an OAuth 2.0 protected resource that return claims about the linked user. Implementing and hosting the userinfo endpoint is optional, except for the following use cases:

After the access token has been successfully retrieved from your token endpoint, Google sends a request to your userinfo endpoint to retrieve basic profile information about the linked user.

userinfo endpoint request headers
Authorization header The access token of type Bearer.

For example, if your userinfo endpoint is available at https://myservice.example.com/userinfo, a request might look like the following:

GET /userinfo HTTP/1.1
Host: myservice.example.com
Authorization: Bearer ACCESS_TOKEN

For your userinfo endpoint to handle requests, do the following steps:

  1. Extract access token from the Authorization header and return information for the user associated with the access token.
  2. If the access token is invalid, return an HTTP 401 Unauthorized error with using the WWW-Authenticate Response Header. Below is an example of a userinfo error response: 
    HTTP/1.1 401 Unauthorized
WWW-Authenticate: error="invalid_token",
error_description="The Access Token expired"
    If a 401 Unauthorized, or any other unsuccessful error response is returned during the linking process, the error will be non-recoverable, the retrieved token will be discarded and the user will have to initiate the linking process again.

  3. If the access token is valid, return and HTTP 200 response with the following JSON object in the body of the HTTPS response: 

    {
"sub": "USER_UUID",
"email": "EMAIL_ADDRESS",
"given_name": "FIRST_NAME",
"family_name": "LAST_NAME",
"name": "FULL_NAME",
"picture": "PROFILE_PICTURE",
}
     If your userinfo endpoint returns an HTTP 200 success response, the retrieved token and claims are registered against the user's Google account.

    userinfo endpoint response
    sub A unique ID that identifies the user in your system.
    email Email address of the user.
    given_name Optional: First name of the user.
    family_name Optional: Last name of the user.
    name Optional: Full name of the user.
    picture Optional: Profile picture of the user.
পূর্ববর্তী
বিকাশকারী চেকলিস্ট
পরবর্তী
একটি ক্লাউড-টু-ক্লাউড প্রকল্প তৈরি করুন