প্রতিটি Cloud-to-cloud ইন্টিগ্রেশনে ব্যবহারকারীদের প্রমাণীকরণের জন্য একটি প্রক্রিয়া অন্তর্ভুক্ত থাকতে হবে।
প্রমাণীকরণ আপনাকে আপনার ব্যবহারকারীদের Google অ্যাকাউন্টগুলিকে আপনার প্রমাণীকরণ সিস্টেমের ব্যবহারকারী অ্যাকাউন্টগুলির সাথে লিঙ্ক করার অনুমতি দেয়। এটি আপনাকে আপনার ব্যবহারকারীদের সনাক্ত করতে দেয় যখন আপনার পূরণ একটি স্মার্ট হোম ইন্টেন্ট পায়। Google স্মার্ট হোম শুধুমাত্র একটি অনুমোদন কোড প্রবাহ সহ OAuth সমর্থন করে।
এই পৃষ্ঠাটি বর্ণনা করে কিভাবে আপনার OAuth 2.0 সার্ভার সেট আপ করবেন যাতে এটি আপনার Cloud-to-cloud ইন্টিগ্রেশনের সাথে কাজ করে।
OAuth-এর সাথে Google অ্যাকাউন্ট লিঙ্ক করা
In the authorization code flow, you need two endpoints:
The authorization endpoint, which presents the sign-in UI to your users that aren't already signed in. The authorization endpoint also creates a short-lived authorization code to record users' consent to the requested access.
The token exchange endpoint, which is responsible for two types of exchanges:
- Exchanges an authorization code for a long-lived refresh token and a short-lived access token. This exchange happens when the user goes through the account linking flow.
- Exchanges a long-lived refresh token for a short-lived access token. This exchange happens when Google needs a new access token because the one it had expired.
Design guidelines
This section describes the design requirements and recommendations for the user screen that you host for OAuth linking flows. After it's called by Google's app, your platform displays a sign in to Google page and account linking consent screen to the user. The user is directed back to Google's app after giving their consent to link accounts.
Requirements
- You must communicate that the user’s account will be linked to Google, not a specific Google product like Google Home or Google Assistant.
- You must have a Google authorization statement such as "By signing in, you are authorizing Google to control your devices." See the Google Device Control Authorization section of the Google Home Developer Policies.
- You must open the Web OAuth linking page and ensure users have a clear method for signing in to their Google Account, such as fields for their username and password. Don't use the Google Sign-In (GSI) method that enables users to link without being taken to the Web OAuth Linking page. It is a violation of Google policy.
- You must include at least one of the following items in the OAuth linking
page to indicate the integration to which the user is linking:
- Company logo
- Company name
- Integration name
- App icon
Recommendations
We recommend that you do the following:
Display Google's Privacy Policy. Include a link to Google’s Privacy Policy on the consent screen.
Data to be shared. Use clear and concise language to tell the user what data of theirs Google requires and why.
Clear call-to-action. State a clear call-to-action on your consent screen, such as “Agree and link.” This is because users need to understand what data they're required to share with Google to link their accounts.
Ability to cancel. Provide a way for users to go back or cancel, if they choose not to link.
Clear sign-in process. Ensure that users have a clear method for signing in to their Google Account, such as fields for their username and password or Sign in with Google.
Ability to unlink. Offer a mechanism for users to unlink, such as a URL to their account settings on your platform. Alternatively, you can include a link to Google Account where users can manage their linked account.
Ability to change user account. Suggest a method for users to switch their account(s). This is especially beneficial if users tend to have multiple accounts.
- If a user must close the consent screen to switch accounts, send a recoverable error to Google so the user can sign in to the desired account with OAuth linking.
Include your logo. Display your company logo on the consent screen. Use your style guidelines to place your logo. If you wish to also display Google's logo, see Logos and trademarks.
অনুমোদন কোড প্রবাহ
অনুমোদন কোড প্রবাহের একটি OAuth 2.0 সার্ভার বাস্তবায়নে দুটি এন্ডপয়েন্ট থাকে, যা আপনার পরিষেবা HTTPS দ্বারা উপলব্ধ করে। প্রথম এন্ডপয়েন্ট হল অনুমোদন এন্ডপয়েন্ট, যা ডেটা অ্যাক্সেসের জন্য ব্যবহারকারীদের কাছ থেকে সম্মতি খোঁজার বা পাওয়ার জন্য দায়ী। অনুমোদন এন্ডপয়েন্টটি আপনার ব্যবহারকারীদের জন্য একটি সাইন-ইন UI উপস্থাপন করে যারা ইতিমধ্যে সাইন ইন করেননি এবং অনুরোধ করা অ্যাক্সেসের জন্য সম্মতি রেকর্ড করে। দ্বিতীয় এন্ডপয়েন্ট হল টোকেন এক্সচেঞ্জ এন্ডপয়েন্ট, যা এনক্রিপ্ট করা স্ট্রিং, যা টোকেন নামে পরিচিত, পেতে ব্যবহৃত হয় যা একজন ব্যবহারকারীকে আপনার পরিষেবা অ্যাক্সেস করার অনুমতি দেয়।
যখন কোনও Google অ্যাপ্লিকেশনকে আপনার পরিষেবার কোনও API-তে কল করার প্রয়োজন হয়, তখন Google এই এন্ডপয়েন্টগুলি একসাথে ব্যবহার করে আপনার ব্যবহারকারীদের কাছ থেকে তাদের পক্ষ থেকে এই API-গুলিতে কল করার অনুমতি নেয়।
Google দ্বারা শুরু করা একটি OAuth 2.0 অনুমোদন কোড ফ্লো সেশনে নিম্নলিখিত ফ্লো থাকে:
- গুগল ব্যবহারকারীর ব্রাউজারে আপনার অনুমোদনের শেষ বিন্দুটি খোলে। যদি কোনও অ্যাকশনের জন্য কেবল ভয়েস ডিভাইসে ফ্লো শুরু হয়, তাহলে গুগল এক্সিকিউশনটি একটি ফোনে স্থানান্তর করে।
- ব্যবহারকারী যদি ইতিমধ্যেই সাইন ইন না করে থাকেন, তাহলে তিনি সাইন ইন করেন এবং যদি ইতিমধ্যেই অনুমতি না দিয়ে থাকেন, তাহলে Google-কে আপনার API ব্যবহার করে তাদের ডেটা অ্যাক্সেস করার অনুমতি দেন।
- আপনার পরিষেবা একটি অনুমোদন কোড তৈরি করে এবং এটি Google-এ ফেরত পাঠায়। এটি করার জন্য, অনুরোধের সাথে সংযুক্ত অনুমোদন কোড সহ ব্যবহারকারীর ব্রাউজারটিকে Google-এ ফিরিয়ে আনুন।
- গুগল আপনার টোকেন এক্সচেঞ্জ এন্ডপয়েন্টে অনুমোদন কোড পাঠায়, যা কোডের সত্যতা যাচাই করে এবং একটি অ্যাক্সেস টোকেন এবং একটি রিফ্রেশ টোকেন ফেরত দেয়। অ্যাক্সেস টোকেন হল একটি স্বল্পস্থায়ী টোকেন যা আপনার পরিষেবা API অ্যাক্সেস করার জন্য শংসাপত্র হিসাবে গ্রহণ করে। রিফ্রেশ টোকেন হল একটি দীর্ঘস্থায়ী টোকেন যা গুগল সংরক্ষণ করতে পারে এবং মেয়াদ শেষ হয়ে গেলে নতুন অ্যাক্সেস টোকেন অর্জন করতে ব্যবহার করতে পারে।
- ব্যবহারকারী অ্যাকাউন্ট লিঙ্কিং ফ্লো সম্পন্ন করার পর, 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
আপনার অনুমোদনের শেষ বিন্দু সাইন-ইন অনুরোধগুলি পরিচালনা করার জন্য, নিম্নলিখিত পদক্ষেপগুলি অনুসরণ করুন:
-
client_idআপনার Google-কে দেওয়া ক্লায়েন্ট আইডির সাথে মেলে কিনা এবংredirect_uriআপনার পরিষেবার জন্য Google দ্বারা প্রদত্ত রিডাইরেক্ট URL-এর সাথে মেলে কিনা তা যাচাই করুন। অযাচিত বা ভুল কনফিগার করা ক্লায়েন্ট অ্যাপগুলিতে অ্যাক্সেস দেওয়া রোধ করার জন্য এই পরীক্ষাগুলি গুরুত্বপূর্ণ। আপনি যদি একাধিক OAuth 2.0 ফ্লো সমর্থন করেন, তাহলে নিশ্চিত করুন যেresponse_typeহলcode। - ব্যবহারকারী আপনার পরিষেবায় সাইন ইন করেছেন কিনা তা পরীক্ষা করুন। যদি ব্যবহারকারী সাইন ইন না করে থাকেন, তাহলে আপনার পরিষেবার সাইন-ইন বা সাইন-আপ প্রক্রিয়াটি সম্পূর্ণ করুন।
- আপনার API অ্যাক্সেস করার জন্য Google-এর জন্য একটি অনুমোদন কোড তৈরি করুন। অনুমোদন কোডটি যেকোনো স্ট্রিং মান হতে পারে, তবে এটি ব্যবহারকারী, টোকেনটি যে ক্লায়েন্টের জন্য এবং কোডের মেয়াদ শেষ হওয়ার সময়কে অনন্যভাবে উপস্থাপন করবে এবং এটি অনুমানযোগ্য হওয়া উচিত নয়। আপনি সাধারণত অনুমোদন কোডগুলি জারি করেন যা প্রায় 10 মিনিট পরে মেয়াদ শেষ হয়ে যায়।
-
redirect_uriপ্যারামিটার দ্বারা নির্দিষ্ট করা URL-এ নিম্নলিখিত ফর্ম আছে কিনা তা নিশ্চিত করুন:https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
- ব্যবহারকারীর ব্রাউজারটিকে
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 ইন্টিগ্রেশনটি সেই অনুযায়ী কনফিগার করতে হবে:
প্রকল্পের তালিকা থেকে, আপনি যে প্রকল্পের সাথে কাজ করতে চান তার পাশে "খুলুন" এ ক্লিক করুন।
ক্লাউড-টু-ক্লাউড এর অধীনে, ডেভেলপ নির্বাচন করুন।
আপনার ইন্টিগ্রেশনের পরবর্তী "খুলুন" এ ক্লিক করুন।
"অনুমতি" (ঐচ্ছিক) বিভাগে স্ক্রোল করুন এবং "Have Google transmit Client ID and secret via HTTP basic auth header" চেকবক্সটি নির্বাচন করুন।
আপনার পরিবর্তনগুলি সংরক্ষণ করতে সংরক্ষণ করুন ক্লিক করুন।
অ্যাক্সেস টোকেনের জন্য অনুমোদন কোড বিনিময় করুন এবং টোকেন রিফ্রেশ করুন
ব্যবহারকারী সাইন ইন করার পর এবং আপনার অনুমোদনের শেষ বিন্দু 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 অনুরোধগুলিতে সাড়া দেয়:
- যাচাই করুন যে
client_idঅনুরোধের উৎসটিকে একটি অনুমোদিত উৎস হিসেবে চিহ্নিত করে এবংclient_secretপ্রত্যাশিত মানের সাথে মেলে। - যাচাই করুন যে অনুমোদন কোডটি বৈধ এবং মেয়াদোত্তীর্ণ নয়, এবং অনুরোধে উল্লেখিত ক্লায়েন্ট আইডি অনুমোদন কোডের সাথে সম্পর্কিত ক্লায়েন্ট আইডির সাথে মেলে।
- নিশ্চিত করুন যে
redirect_uriপ্যারামিটার দ্বারা নির্দিষ্ট করা URLটি প্রাথমিক অনুমোদনের অনুরোধে ব্যবহৃত মানের সাথে অভিন্ন। - যদি আপনি উপরের সমস্ত মানদণ্ড যাচাই করতে না পারেন,
{"error": "invalid_grant"}এর মূল অংশ হিসেবে HTTP 400 Bad Request ত্রুটিটি ফেরত পাঠান। - অন্যথায়, অনুমোদন কোড থেকে ব্যবহারকারী আইডি ব্যবহার করে একটি রিফ্রেশ টোকেন এবং একটি অ্যাক্সেস টোকেন তৈরি করুন। এই টোকেনগুলি যেকোনো স্ট্রিং মান হতে পারে, তবে এগুলি অবশ্যই ব্যবহারকারী এবং ক্লায়েন্টকে স্বতন্ত্রভাবে উপস্থাপন করবে যার জন্য টোকেনটি তৈরি করা হয়েছে এবং এগুলি অনুমানযোগ্য হওয়া উচিত নয়। অ্যাক্সেস টোকেনের জন্য, টোকেনের মেয়াদও রেকর্ড করুন, যা সাধারণত আপনি টোকেন ইস্যু করার এক ঘন্টা পরে হয়। রিফ্রেশ টোকেনগুলির মেয়াদ শেষ হয় না।
- 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 অনুরোধের প্রতিক্রিয়া জানায়:
-
client_idঅনুরোধের উৎসটিকে Google হিসেবে শনাক্ত করে এবংclient_secretপ্রত্যাশিত মানের সাথে মেলে কিনা তা যাচাই করুন। - যাচাই করুন যে রিফ্রেশ টোকেনটি বৈধ, এবং অনুরোধে উল্লেখিত ক্লায়েন্ট আইডি রিফ্রেশ টোকেনের সাথে সম্পর্কিত ক্লায়েন্ট আইডির সাথে মেলে।
- যদি আপনি উপরের সমস্ত মানদণ্ড যাচাই করতে না পারেন,
{"error": "invalid_grant"}এর মূল অংশ হিসেবে HTTP 400 Bad Request ত্রুটিটি ফেরত পাঠান। - অন্যথায়, রিফ্রেশ টোকেন থেকে ব্যবহারকারী আইডি ব্যবহার করে একটি অ্যাক্সেস টোকেন তৈরি করুন। এই টোকেনগুলি যেকোনো স্ট্রিং মান হতে পারে, তবে এগুলিকে অবশ্যই ব্যবহারকারী এবং ক্লায়েন্টকে স্বতন্ত্রভাবে উপস্থাপন করতে হবে যার জন্য টোকেনটি তৈরি করা হয়েছে এবং এগুলি অনুমানযোগ্য হওয়া উচিত নয়। অ্যাক্সেস টোকেনের জন্য, টোকেনের মেয়াদ শেষ হওয়ার সময়টিও রেকর্ড করুন, সাধারণত টোকেন ইস্যু করার এক ঘন্টা পরে।
- HTTPS রেসপন্সের বডিতে নিম্নলিখিত JSON অবজেক্টটি রিটার্ন করুন:
{ "token_type": "Bearer", "access_token": " ACCESS_TOKEN ", "expires_in": SECONDS_TO_EXPIRATION }
ব্যবহারকারীর তথ্যের অনুরোধগুলি পরিচালনা করুন
ইউজারইনফো এন্ডপয়েন্ট হল একটি OAuth 2.0 সুরক্ষিত রিসোর্স যা লিঙ্ক করা ব্যবহারকারীর বিষয়ে দাবি ফেরত দেয়। ইউজার ইনফো এন্ডপয়েন্ট বাস্তবায়ন এবং হোস্ট করা ঐচ্ছিক, নিম্নলিখিত ব্যবহারের ক্ষেত্রে ছাড়া:
- Google One ট্যাপের মাধ্যমে লিঙ্ক করা অ্যাকাউন্টে সাইন-ইন করুন ।
- AndroidTV-তে ঘর্ষণহীন সাবস্ক্রিপশন ।
আপনার টোকেন এন্ডপয়েন্ট থেকে অ্যাক্সেস টোকেন সফলভাবে পুনরুদ্ধার করার পরে, Google লিঙ্ক করা ব্যবহারকারীর সম্পর্কে প্রাথমিক প্রোফাইল তথ্য পুনরুদ্ধার করার জন্য আপনার ব্যবহারকারীর তথ্য এন্ডপয়েন্টে একটি অনুরোধ পাঠায়।
| userinfo এন্ডপয়েন্ট রিকোয়েস্ট হেডার | |
|---|---|
Authorization header | টাইপ বিয়ারারের অ্যাক্সেস টোকেন। |
উদাহরণস্বরূপ, যদি আপনার ব্যবহারকারীর তথ্যের এন্ডপয়েন্ট https://myservice.example.com/userinfo এ উপলব্ধ থাকে, তাহলে একটি অনুরোধ নিম্নলিখিতটির মতো দেখতে পারে:
GET /userinfo HTTP/1.1 Host: myservice.example.com Authorization: Bearer ACCESS_TOKEN
অনুরোধগুলি পরিচালনা করার জন্য আপনার ব্যবহারকারীর তথ্যের শেষ পয়েন্টের জন্য, নিম্নলিখিত পদক্ষেপগুলি করুন:
- অনুমোদন শিরোনাম থেকে অ্যাক্সেস টোকেন বের করুন এবং অ্যাক্সেস টোকেনের সাথে যুক্ত ব্যবহারকারীর জন্য তথ্য ফেরত দিন।
- অ্যাক্সেস টোকেনটি অবৈধ হলে,
WWW-Authenticateপ্রতিক্রিয়া শিরোনাম ব্যবহার করে একটি HTTP 401 অননুমোদিত ত্রুটি ফেরত দিন। নীচে একটি ব্যবহারকারীর তথ্য ত্রুটি প্রতিক্রিয়ার একটি উদাহরণ: লিঙ্কিং প্রক্রিয়া চলাকালীন যদি একটি 401 অননুমোদিত, বা অন্য কোনো অসফল ত্রুটির প্রতিক্রিয়া ফেরত দেওয়া হয়, তবে ত্রুটিটি পুনরুদ্ধারযোগ্য হবে না, পুনরুদ্ধার করা টোকেন বাতিল করা হবে এবং ব্যবহারকারীকে আবার লিঙ্কিং প্রক্রিয়া শুরু করতে হবে।HTTP/1.1 401 Unauthorized WWW-Authenticate: error="invalid_token", error_description="The Access Token expired"
অ্যাক্সেস টোকেনটি বৈধ হলে, HTTPS প্রতিক্রিয়ার বডিতে নিম্নলিখিত JSON অবজেক্টের সাথে HTTP 200 প্রতিক্রিয়া ফেরত দিন:
যদি আপনার ব্যবহারকারীর তথ্য এন্ডপয়েন্ট একটি HTTP 200 সাফল্যের প্রতিক্রিয়া প্রদান করে, তবে পুনরুদ্ধার করা টোকেন এবং দাবিগুলি ব্যবহারকারীর Google অ্যাকাউন্টের বিরুদ্ধে নিবন্ধিত হয়।{ "sub": "USER_UUID", "email": "EMAIL_ADDRESS", "given_name": "FIRST_NAME", "family_name": "LAST_NAME", "name": "FULL_NAME", "picture": "PROFILE_PICTURE", }ব্যবহারকারীর তথ্য শেষ পয়েন্ট প্রতিক্রিয়া subএকটি অনন্য আইডি যা আপনার সিস্টেমে ব্যবহারকারীকে শনাক্ত করে। emailব্যবহারকারীর ইমেল ঠিকানা। given_nameঐচ্ছিক: ব্যবহারকারীর প্রথম নাম। family_nameঐচ্ছিক: ব্যবহারকারীর শেষ নাম। nameঐচ্ছিক: ব্যবহারকারীর পুরো নাম। pictureঐচ্ছিক: ব্যবহারকারীর প্রোফাইল ছবি।
অনুমোদন কোড প্রবাহের একটি OAuth 2.0 সার্ভার বাস্তবায়নে দুটি এন্ডপয়েন্ট থাকে, যা আপনার পরিষেবা HTTPS দ্বারা উপলব্ধ করে। প্রথম এন্ডপয়েন্ট হল অনুমোদন এন্ডপয়েন্ট, যা ডেটা অ্যাক্সেসের জন্য ব্যবহারকারীদের কাছ থেকে সম্মতি খোঁজার বা পাওয়ার জন্য দায়ী। অনুমোদন এন্ডপয়েন্টটি আপনার ব্যবহারকারীদের জন্য একটি সাইন-ইন UI উপস্থাপন করে যারা ইতিমধ্যে সাইন ইন করেননি এবং অনুরোধ করা অ্যাক্সেসের জন্য সম্মতি রেকর্ড করে। দ্বিতীয় এন্ডপয়েন্ট হল টোকেন এক্সচেঞ্জ এন্ডপয়েন্ট, যা এনক্রিপ্ট করা স্ট্রিং, যা টোকেন নামে পরিচিত, পেতে ব্যবহৃত হয় যা একজন ব্যবহারকারীকে আপনার পরিষেবা অ্যাক্সেস করার অনুমতি দেয়।
যখন কোনও Google অ্যাপ্লিকেশনকে আপনার পরিষেবার কোনও API-তে কল করার প্রয়োজন হয়, তখন Google এই এন্ডপয়েন্টগুলি একসাথে ব্যবহার করে আপনার ব্যবহারকারীদের কাছ থেকে তাদের পক্ষ থেকে এই API-গুলিতে কল করার অনুমতি নেয়।
Google দ্বারা শুরু করা একটি OAuth 2.0 অনুমোদন কোড ফ্লো সেশনে নিম্নলিখিত ফ্লো থাকে:
- গুগল ব্যবহারকারীর ব্রাউজারে আপনার অনুমোদনের শেষ বিন্দুটি খোলে। যদি কোনও অ্যাকশনের জন্য কেবল ভয়েস ডিভাইসে ফ্লো শুরু হয়, তাহলে গুগল এক্সিকিউশনটি একটি ফোনে স্থানান্তর করে।
- ব্যবহারকারী যদি ইতিমধ্যেই সাইন ইন না করে থাকেন, তাহলে তিনি সাইন ইন করেন এবং যদি ইতিমধ্যেই অনুমতি না দিয়ে থাকেন, তাহলে Google-কে আপনার API ব্যবহার করে তাদের ডেটা অ্যাক্সেস করার অনুমতি দেন।
- আপনার পরিষেবা একটি অনুমোদন কোড তৈরি করে এবং এটি Google-এ ফেরত পাঠায়। এটি করার জন্য, অনুরোধের সাথে সংযুক্ত অনুমোদন কোড সহ ব্যবহারকারীর ব্রাউজারটিকে Google-এ ফিরিয়ে আনুন।
- গুগল আপনার টোকেন এক্সচেঞ্জ এন্ডপয়েন্টে অনুমোদন কোড পাঠায়, যা কোডের সত্যতা যাচাই করে এবং একটি অ্যাক্সেস টোকেন এবং একটি রিফ্রেশ টোকেন ফেরত দেয়। অ্যাক্সেস টোকেন হল একটি স্বল্পস্থায়ী টোকেন যা আপনার পরিষেবা API অ্যাক্সেস করার জন্য শংসাপত্র হিসাবে গ্রহণ করে। রিফ্রেশ টোকেন হল একটি দীর্ঘস্থায়ী টোকেন যা গুগল সংরক্ষণ করতে পারে এবং মেয়াদ শেষ হয়ে গেলে নতুন অ্যাক্সেস টোকেন অর্জন করতে ব্যবহার করতে পারে।
- ব্যবহারকারী অ্যাকাউন্ট লিঙ্কিং ফ্লো সম্পন্ন করার পর, 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
আপনার অনুমোদনের শেষ বিন্দু সাইন-ইন অনুরোধগুলি পরিচালনা করার জন্য, নিম্নলিখিত পদক্ষেপগুলি অনুসরণ করুন:
-
client_idআপনার Google-কে দেওয়া ক্লায়েন্ট আইডির সাথে মেলে কিনা এবংredirect_uriআপনার পরিষেবার জন্য Google দ্বারা প্রদত্ত রিডাইরেক্ট URL-এর সাথে মেলে কিনা তা যাচাই করুন। অযাচিত বা ভুল কনফিগার করা ক্লায়েন্ট অ্যাপগুলিতে অ্যাক্সেস দেওয়া রোধ করার জন্য এই পরীক্ষাগুলি গুরুত্বপূর্ণ। আপনি যদি একাধিক OAuth 2.0 ফ্লো সমর্থন করেন, তাহলে নিশ্চিত করুন যেresponse_typeহলcode। - ব্যবহারকারী আপনার পরিষেবায় সাইন ইন করেছেন কিনা তা পরীক্ষা করুন। যদি ব্যবহারকারী সাইন ইন না করে থাকেন, তাহলে আপনার পরিষেবার সাইন-ইন বা সাইন-আপ প্রক্রিয়াটি সম্পূর্ণ করুন।
- আপনার API অ্যাক্সেস করার জন্য Google-এর জন্য একটি অনুমোদন কোড তৈরি করুন। অনুমোদন কোডটি যেকোনো স্ট্রিং মান হতে পারে, তবে এটি ব্যবহারকারী, টোকেনটি যে ক্লায়েন্টের জন্য এবং কোডের মেয়াদ শেষ হওয়ার সময়কে অনন্যভাবে উপস্থাপন করবে এবং এটি অনুমানযোগ্য হওয়া উচিত নয়। আপনি সাধারণত অনুমোদন কোডগুলি জারি করেন যা প্রায় 10 মিনিট পরে মেয়াদ শেষ হয়ে যায়।
-
redirect_uriপ্যারামিটার দ্বারা নির্দিষ্ট করা URL-এ নিম্নলিখিত ফর্ম আছে কিনা তা নিশ্চিত করুন:https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
- ব্যবহারকারীর ব্রাউজারটিকে
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 ইন্টিগ্রেশনটি সেই অনুযায়ী কনফিগার করতে হবে:
প্রকল্পের তালিকা থেকে, আপনি যে প্রকল্পের সাথে কাজ করতে চান তার পাশে "খুলুন" এ ক্লিক করুন।
ক্লাউড-টু-ক্লাউড এর অধীনে, ডেভেলপ নির্বাচন করুন।
আপনার ইন্টিগ্রেশনের পরবর্তী "খুলুন" এ ক্লিক করুন।
"অনুমতি" (ঐচ্ছিক) বিভাগে স্ক্রোল করুন এবং "Have Google transmit Client ID and secret via HTTP basic auth header" চেকবক্সটি নির্বাচন করুন।
আপনার পরিবর্তনগুলি সংরক্ষণ করতে সংরক্ষণ করুন ক্লিক করুন।
অ্যাক্সেস টোকেনের জন্য অনুমোদন কোড বিনিময় করুন এবং টোকেন রিফ্রেশ করুন
ব্যবহারকারী সাইন ইন করার পর এবং আপনার অনুমোদনের শেষ বিন্দু 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 অনুরোধগুলিতে সাড়া দেয়:
- যাচাই করুন যে
client_idঅনুরোধের উৎসটিকে একটি অনুমোদিত উৎস হিসেবে চিহ্নিত করে এবংclient_secretপ্রত্যাশিত মানের সাথে মেলে। - যাচাই করুন যে অনুমোদন কোডটি বৈধ এবং মেয়াদোত্তীর্ণ নয়, এবং অনুরোধে উল্লেখিত ক্লায়েন্ট আইডি অনুমোদন কোডের সাথে সম্পর্কিত ক্লায়েন্ট আইডির সাথে মেলে।
- নিশ্চিত করুন যে
redirect_uriপ্যারামিটার দ্বারা নির্দিষ্ট করা URLটি প্রাথমিক অনুমোদনের অনুরোধে ব্যবহৃত মানের সাথে অভিন্ন। - যদি আপনি উপরের সমস্ত মানদণ্ড যাচাই করতে না পারেন,
{"error": "invalid_grant"}এর মূল অংশ হিসেবে HTTP 400 Bad Request ত্রুটিটি ফেরত পাঠান। - অন্যথায়, অনুমোদন কোড থেকে ব্যবহারকারী আইডি ব্যবহার করে একটি রিফ্রেশ টোকেন এবং একটি অ্যাক্সেস টোকেন তৈরি করুন। এই টোকেনগুলি যেকোনো স্ট্রিং মান হতে পারে, তবে এগুলি অবশ্যই ব্যবহারকারী এবং ক্লায়েন্টকে স্বতন্ত্রভাবে উপস্থাপন করবে যার জন্য টোকেনটি তৈরি করা হয়েছে এবং এগুলি অনুমানযোগ্য হওয়া উচিত নয়। অ্যাক্সেস টোকেনের জন্য, টোকেনের মেয়াদও রেকর্ড করুন, যা সাধারণত আপনি টোকেন ইস্যু করার এক ঘন্টা পরে হয়। রিফ্রেশ টোকেনগুলির মেয়াদ শেষ হয় না।
- 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 অনুরোধের প্রতিক্রিয়া জানায়:
-
client_idঅনুরোধের উৎসটিকে Google হিসেবে শনাক্ত করে এবংclient_secretপ্রত্যাশিত মানের সাথে মেলে কিনা তা যাচাই করুন। - যাচাই করুন যে রিফ্রেশ টোকেনটি বৈধ, এবং অনুরোধে উল্লেখিত ক্লায়েন্ট আইডি রিফ্রেশ টোকেনের সাথে সম্পর্কিত ক্লায়েন্ট আইডির সাথে মেলে।
- যদি আপনি উপরের সমস্ত মানদণ্ড যাচাই করতে না পারেন,
{"error": "invalid_grant"}এর মূল অংশ হিসেবে HTTP 400 Bad Request ত্রুটিটি ফেরত পাঠান। - অন্যথায়, রিফ্রেশ টোকেন থেকে ব্যবহারকারী আইডি ব্যবহার করে একটি অ্যাক্সেস টোকেন তৈরি করুন। এই টোকেনগুলি যেকোনো স্ট্রিং মান হতে পারে, তবে এগুলিকে অবশ্যই ব্যবহারকারী এবং ক্লায়েন্টকে স্বতন্ত্রভাবে উপস্থাপন করতে হবে যার জন্য টোকেনটি তৈরি করা হয়েছে এবং এগুলি অনুমানযোগ্য হওয়া উচিত নয়। অ্যাক্সেস টোকেনের জন্য, টোকেনের মেয়াদ শেষ হওয়ার সময়টিও রেকর্ড করুন, সাধারণত টোকেন ইস্যু করার এক ঘন্টা পরে।
- HTTPS রেসপন্সের বডিতে নিম্নলিখিত JSON অবজেক্টটি রিটার্ন করুন:
{ "token_type": "Bearer", "access_token": " ACCESS_TOKEN ", "expires_in": SECONDS_TO_EXPIRATION }
ব্যবহারকারীর তথ্যের অনুরোধগুলি পরিচালনা করুন
ইউজারইনফো এন্ডপয়েন্ট হল একটি OAuth 2.0 সুরক্ষিত রিসোর্স যা লিঙ্ক করা ব্যবহারকারীর বিষয়ে দাবি ফেরত দেয়। ইউজার ইনফো এন্ডপয়েন্ট বাস্তবায়ন এবং হোস্ট করা ঐচ্ছিক, নিম্নলিখিত ব্যবহারের ক্ষেত্রে ছাড়া:
- Google One ট্যাপের মাধ্যমে লিঙ্ক করা অ্যাকাউন্টে সাইন-ইন করুন ।
- AndroidTV-তে ঘর্ষণহীন সাবস্ক্রিপশন ।
আপনার টোকেন এন্ডপয়েন্ট থেকে অ্যাক্সেস টোকেন সফলভাবে পুনরুদ্ধার করার পরে, Google লিঙ্ক করা ব্যবহারকারীর সম্পর্কে প্রাথমিক প্রোফাইল তথ্য পুনরুদ্ধার করার জন্য আপনার ব্যবহারকারীর তথ্য এন্ডপয়েন্টে একটি অনুরোধ পাঠায়।
| userinfo এন্ডপয়েন্ট রিকোয়েস্ট হেডার | |
|---|---|
Authorization header | টাইপ বিয়ারারের অ্যাক্সেস টোকেন। |
উদাহরণস্বরূপ, যদি আপনার ব্যবহারকারীর তথ্যের এন্ডপয়েন্ট https://myservice.example.com/userinfo এ উপলব্ধ থাকে, তাহলে একটি অনুরোধ নিম্নলিখিতটির মতো দেখতে পারে:
GET /userinfo HTTP/1.1 Host: myservice.example.com Authorization: Bearer ACCESS_TOKEN
অনুরোধগুলি পরিচালনা করার জন্য আপনার ব্যবহারকারীর তথ্যের শেষ পয়েন্টের জন্য, নিম্নলিখিত পদক্ষেপগুলি করুন:
- অনুমোদন শিরোনাম থেকে অ্যাক্সেস টোকেন বের করুন এবং অ্যাক্সেস টোকেনের সাথে যুক্ত ব্যবহারকারীর জন্য তথ্য ফেরত দিন।
- অ্যাক্সেস টোকেনটি অবৈধ হলে,
WWW-Authenticateপ্রতিক্রিয়া শিরোনাম ব্যবহার করে একটি HTTP 401 অননুমোদিত ত্রুটি ফেরত দিন। নীচে একটি ব্যবহারকারীর তথ্য ত্রুটি প্রতিক্রিয়ার একটি উদাহরণ: লিঙ্কিং প্রক্রিয়া চলাকালীন যদি একটি 401 অননুমোদিত, বা অন্য কোনো অসফল ত্রুটির প্রতিক্রিয়া ফেরত দেওয়া হয়, তবে ত্রুটিটি পুনরুদ্ধারযোগ্য হবে না, পুনরুদ্ধার করা টোকেন বাতিল করা হবে এবং ব্যবহারকারীকে আবার লিঙ্কিং প্রক্রিয়া শুরু করতে হবে।HTTP/1.1 401 Unauthorized WWW-Authenticate: error="invalid_token", error_description="The Access Token expired"
অ্যাক্সেস টোকেনটি বৈধ হলে, HTTPS প্রতিক্রিয়ার বডিতে নিম্নলিখিত JSON অবজেক্টের সাথে HTTP 200 প্রতিক্রিয়া ফেরত দিন:
যদি আপনার ব্যবহারকারীর তথ্য এন্ডপয়েন্ট একটি HTTP 200 সাফল্যের প্রতিক্রিয়া প্রদান করে, তবে পুনরুদ্ধার করা টোকেন এবং দাবিগুলি ব্যবহারকারীর Google অ্যাকাউন্টের বিরুদ্ধে নিবন্ধিত হয়।{ "sub": "USER_UUID", "email": "EMAIL_ADDRESS", "given_name": "FIRST_NAME", "family_name": "LAST_NAME", "name": "FULL_NAME", "picture": "PROFILE_PICTURE", }ব্যবহারকারীর তথ্য শেষ পয়েন্ট প্রতিক্রিয়া subএকটি অনন্য আইডি যা আপনার সিস্টেমে ব্যবহারকারীকে শনাক্ত করে। emailব্যবহারকারীর ইমেল ঠিকানা। given_nameঐচ্ছিক: ব্যবহারকারীর প্রথম নাম। family_nameঐচ্ছিক: ব্যবহারকারীর শেষ নাম। nameঐচ্ছিক: ব্যবহারকারীর পুরো নাম। pictureঐচ্ছিক: ব্যবহারকারীর প্রোফাইল ছবি।