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

OpenID কানেক্ট

গুগলের ওপেনআইডি কানেক্ট এন্ডপয়েন্টটি ওপেনআইডি সার্টিফাইড।

Google এর OAuth 2.0 API গুলি প্রমাণীকরণ এবং অনুমোদন উভয়ের জন্যই ব্যবহার করা যেতে পারে। এই ডকুমেন্টটি প্রমাণীকরণের জন্য আমাদের OAuth 2.0 বাস্তবায়নের বর্ণনা দেয়, যা OpenID Connect স্পেসিফিকেশনের সাথে সঙ্গতিপূর্ণ এবং OpenID সার্টিফাইড । Using OAuth 2.0 to Access Google API গুলিতে পাওয়া ডকুমেন্টেশনগুলি এই পরিষেবার ক্ষেত্রেও প্রযোজ্য। আপনি যদি এই প্রোটোকলটি ইন্টারেক্টিভভাবে অন্বেষণ করতে চান, তাহলে আমরা Google OAuth 2.0 Playground ব্যবহার করার পরামর্শ দিচ্ছি। Stack Overflow সম্পর্কে সাহায্য পেতে, আপনার প্রশ্নগুলিকে 'google-oauth' দিয়ে ট্যাগ করুন।

দ্রষ্টব্য: আপনার ওয়েবসাইটের জন্য "Google-এর সাথে সাইন-ইন করুন" বোতামটি প্রদান করতে, OpenID Connect প্রোটোকলে নির্মিত আমাদের সাইন-ইন ক্লায়েন্ট লাইব্রেরি, Google Identity Services ব্যবহার করুন। এই লাইব্রেরিটি OpenID Connect ফর্ম্যাট করা ID টোকেন সরবরাহ করে। Google-এর সাথে সাইন ইন ফ্লো বাস্তবায়নের জন্য Android অ্যাপগুলির Credential Manager API ব্যবহার করা উচিত।

OAuth 2.0 সেট আপ করা হচ্ছে

আপনার অ্যাপ্লিকেশনটি ব্যবহারকারী লগইনের জন্য Google এর OAuth 2.0 প্রমাণীকরণ সিস্টেম ব্যবহার করার আগে, আপনাকে অবশ্যই একটি প্রকল্প সেট আপ করতে হবে Google Cloud Console OAuth 2.0 শংসাপত্র পেতে, একটি পুনর্নির্দেশ URI সেট করুন এবং (ঐচ্ছিকভাবে) ব্যবহারকারী-সম্মতি স্ক্রিনে আপনার ব্যবহারকারীরা যে ব্র্যান্ডিং তথ্য দেখেন তা কাস্টমাইজ করুন। আপনি এটিও ব্যবহার করতে পারেন Cloud Console একটি পরিষেবা অ্যাকাউন্ট তৈরি করতে, বিলিং সক্ষম করতে, ফিল্টারিং সেট আপ করতে এবং অন্যান্য কাজ করতে। আরও বিস্তারিত জানার জন্য, দেখুন Google Cloud Console সাহায্য ।

OAuth 2.0 শংসাপত্রগুলি পান

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

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

অথবা, আপনার ক্লায়েন্ট আইডি এবং ক্লায়েন্ট গোপনীয়তা দেখুনClients page ভিতরেCloud Console:

Go to the Clients page.
আপনার ক্লায়েন্টের নাম অথবা সম্পাদনা ( ) আইকনে ক্লিক করুন। আপনার ক্লায়েন্ট আইডি এবং গোপনীয়তা পৃষ্ঠার শীর্ষে রয়েছে।

একটি পুনর্নির্দেশ URI সেট করুন

আপনার সেট করা পুনঃনির্দেশ URI Cloud Console আপনার প্রমাণীকরণ অনুরোধের উত্তর Google কোথায় পাঠাবে তা নির্ধারণ করে।

প্রদত্ত OAuth 2.0 শংসাপত্রের জন্য পুনর্নির্দেশ URI তৈরি করতে, দেখতে বা সম্পাদনা করতে, নিম্নলিখিতগুলি করুন:

Go to the Clients page.
ক্লায়েন্টে ক্লিক করুন।
পুনঃনির্দেশ URI গুলি দেখুন বা সম্পাদনা করুন।

যদি ক্লায়েন্ট পৃষ্ঠায় কোনও তালিকাভুক্ত ক্লায়েন্ট না থাকে, তাহলে আপনার প্রকল্পের কোনও OAuth শংসাপত্র নেই। একটি তৈরি করতে, Create client এ ক্লিক করুন।

ব্যবহারকারীর সম্মতি স্ক্রিন কাস্টমাইজ করুন

আপনার ব্যবহারকারীদের জন্য, OAuth 2.0 প্রমাণীকরণ অভিজ্ঞতায় একটি সম্মতি স্ক্রিন অন্তর্ভুক্ত থাকে যা ব্যবহারকারীর প্রকাশ করা তথ্য এবং প্রযোজ্য শর্তাবলী বর্ণনা করে। উদাহরণস্বরূপ, যখন ব্যবহারকারী লগ ইন করেন, তখন তাদের আপনার অ্যাপকে তাদের ইমেল ঠিকানা এবং মৌলিক অ্যাকাউন্ট তথ্য অ্যাক্সেস দিতে বলা হতে পারে। আপনি scope প্যারামিটার ব্যবহার করে এই তথ্য অ্যাক্সেসের অনুরোধ করেন, যা আপনার অ্যাপ তার প্রমাণীকরণ অনুরোধে অন্তর্ভুক্ত করে। আপনি অন্যান্য Google API-তে অ্যাক্সেসের অনুরোধ করতে স্কোপ ব্যবহার করতে পারেন।

ব্যবহারকারীর সম্মতি স্ক্রিনে আপনার পণ্যের নাম, লোগো এবং একটি হোমপেজ URL এর মতো ব্র্যান্ডিং তথ্যও উপস্থাপন করা হয়। আপনি ব্র্যান্ডিং তথ্য নিয়ন্ত্রণ করেন Cloud Console.

আপনার প্রোজেক্টের সম্মতি স্ক্রিন সক্ষম করতে:

খুলুন Branding page মধ্যে Google Cloud Console.
If prompted, select a project, or create a new one.
ফর্মটি পূরণ করুন এবং সংরক্ষণ করুন এ ক্লিক করুন।

নিম্নলিখিত সম্মতি ডায়ালগটি দেখায় যে অনুরোধে OAuth 2.0 এবং Google ড্রাইভ স্কোপের সংমিশ্রণ উপস্থিত থাকলে একজন ব্যবহারকারী কী দেখতে পাবেন। (এই জেনেরিক ডায়ালগটি Google OAuth 2.0 Playground ব্যবহার করে তৈরি করা হয়েছিল, তাই এতে ব্র্যান্ডিং তথ্য অন্তর্ভুক্ত নেই যা সেট করা হবে Cloud Console.)

সম্মতি পৃষ্ঠার উদাহরণ — **চিত্র ১.** সম্মতি পৃষ্ঠার স্ক্রিনশট

পরিষেবাটি অ্যাক্সেস করা

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

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

যদি আপনি কোনও লাইব্রেরি ব্যবহার না করার সিদ্ধান্ত নেন, তাহলে এই নথির বাকি অংশে দেওয়া নির্দেশাবলী অনুসরণ করুন, যা উপলব্ধ লাইব্রেরির অন্তর্নিহিত HTTP অনুরোধ প্রবাহের বর্ণনা দেয়।

ব্যবহারকারীর প্রমাণীকরণ

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

ব্যবহারকারীর প্রমাণীকরণ এবং আইডি টোকেন পাওয়ার জন্য সর্বাধিক ব্যবহৃত পদ্ধতিগুলিকে "সার্ভার" ফ্লো এবং "ইমপ্লিসিট" ফ্লো বলা হয়। সার্ভার ফ্লো একটি অ্যাপ্লিকেশনের ব্যাকএন্ড সার্ভারকে ব্রাউজার বা মোবাইল ডিভাইস ব্যবহারকারী ব্যক্তির পরিচয় যাচাই করার অনুমতি দেয়। যখন একটি ক্লায়েন্ট-সাইড অ্যাপ্লিকেশন (সাধারণত ব্রাউজারে চলমান একটি জাভাস্ক্রিপ্ট অ্যাপ) তার ব্যাকএন্ড সার্ভার ব্যবহার না করে সরাসরি API অ্যাক্সেস করার প্রয়োজন হয় তখন ইমপ্লিসিট ফ্লো ব্যবহার করা হয়।

এই ডকুমেন্টে ব্যবহারকারীর প্রমাণীকরণের জন্য সার্ভার ফ্লো কীভাবে সম্পাদন করতে হয় তা বর্ণনা করা হয়েছে। ক্লায়েন্ট সাইডে টোকেন পরিচালনা এবং ব্যবহারে নিরাপত্তা ঝুঁকির কারণে অন্তর্নিহিত প্রবাহ উল্লেখযোগ্যভাবে জটিল। যদি আপনার একটি অন্তর্নিহিত প্রবাহ বাস্তবায়নের প্রয়োজন হয়, তাহলে আমরা Google Identity Services ব্যবহার করার পরামর্শ দিচ্ছি।

সার্ভার প্রবাহ

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

একটি অ্যান্টি-ফোরজি স্টেট টোকেন তৈরি করুন
Google-এ একটি প্রমাণীকরণ অনুরোধ পাঠান
অ্যান্টি-ফোরজি স্টেট টোকেন নিশ্চিত করুন
অ্যাক্সেস টোকেন এবং আইডি টোকেনের জন্য code বিনিময় করুন
আইডি টোকেন থেকে ব্যবহারকারীর তথ্য সংগ্রহ করুন
ব্যবহারকারীকে প্রমাণীকরণ করুন

১. একটি অ্যান্টি-ফোরজি স্টেট টোকেন তৈরি করুন

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

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

নিম্নলিখিত কোডটি অনন্য সেশন টোকেন তৈরি করার পদ্ধতি প্রদর্শন করে।

পিএইচপি

এই নমুনাটি ব্যবহার করার জন্য আপনাকে PHP-এর জন্য Google APIs ক্লায়েন্ট লাইব্রেরি ডাউনলোড করতে হবে।

// Create a state token to prevent request forgery.
// Store it in the session for later validation.
$state = bin2hex(random_bytes(128/8));
$app['session']->set('state', $state);
// Set the client ID, token state, and application name in the HTML while
// serving it.
return $app['twig']->render('index.html', array(
    'CLIENT_ID' => CLIENT_ID,
    'STATE' => $state,
    'APPLICATION_NAME' => APPLICATION_NAME
));

জাভা

এই নমুনাটি ব্যবহার করার জন্য আপনাকে জাভার জন্য Google APIs ক্লায়েন্ট লাইব্রেরি ডাউনলোড করতে হবে।

// Create a state token to prevent request forgery.
// Store it in the session for later validation.
String state = new BigInteger(130, new SecureRandom()).toString(32);
request.session().attribute("state", state);
// Read index.html into memory, and set the client ID,
// token state, and application name in the HTML before serving it.
return new Scanner(new File("index.html"), "UTF-8")
    .useDelimiter("\\A").next()
    .replaceAll("[{]{2}\\s*CLIENT_ID\\s*[}]{2}", CLIENT_ID)
    .replaceAll("[{]{2}\\s*STATE\\s*[}]{2}", state)
    .replaceAll("[{]{2}\\s*APPLICATION_NAME\\s*[}]{2}",
    APPLICATION_NAME);

পাইথন

এই নমুনাটি ব্যবহার করার জন্য আপনাকে Python-এর জন্য Google APIs ক্লায়েন্ট লাইব্রেরি ডাউনলোড করতে হবে।

# Create a state token to prevent request forgery.
# Store it in the session for later validation.
state = hashlib.sha256(os.urandom(1024)).hexdigest()
session['state'] = state
# Set the client ID, token state, and application name in the HTML while
# serving it.
response = make_response(
    render_template('index.html',
                    CLIENT_ID=CLIENT_ID,
                    STATE=state,
                    APPLICATION_NAME=APPLICATION_NAME))

২. গুগলে একটি প্রমাণীকরণ অনুরোধ পাঠান

পরবর্তী ধাপ হল উপযুক্ত URI প্যারামিটার সহ একটি HTTPS GET অনুরোধ তৈরি করা। এই প্রক্রিয়ার সমস্ত ধাপে HTTP এর পরিবর্তে HTTPS ব্যবহার লক্ষ্য করুন; HTTP সংযোগগুলি প্রত্যাখ্যান করা হয়েছে। আপনার authorization_endpoint মেটাডেটা মান ব্যবহার করে Discovery ডকুমেন্ট থেকে বেস URI পুনরুদ্ধার করা উচিত। নিম্নলিখিত আলোচনায় ধরে নেওয়া হয়েছে যে বেস URI হল https://accounts.google.com/o/oauth2/v2/auth ।

একটি মৌলিক অনুরোধের জন্য, নিম্নলিখিত পরামিতিগুলি নির্দিষ্ট করুন:

client_id , যা আপনি থেকে পাবেন Cloud ConsoleClients page.
response_type , যা একটি মৌলিক অনুমোদন কোড প্রবাহ অনুরোধে code হওয়া উচিত। ( response_type এ আরও পড়ুন।)
scope , যা একটি মৌলিক অনুরোধে openid email হওয়া উচিত। ( scope এ আরও পড়ুন।)
redirect_uri আপনার সার্ভারের HTTP এন্ডপয়েন্ট হওয়া উচিত যা Google থেকে প্রতিক্রিয়া পাবে। মানটি OAuth 2.0 ক্লায়েন্টের জন্য অনুমোদিত রিডাইরেক্ট URI গুলির মধ্যে একটির সাথে হুবহু মিলতে হবে, যা আপনি Cloud ConsoleCredentials page. যদি এই মানটি একটি অনুমোদিত URI-এর সাথে না মেলে, তাহলে অনুরোধটি একটি redirect_uri_mismatch ত্রুটির সাথে ব্যর্থ হবে।
state অ্যান্টি-ফোরজি ইউনিক সেশন টোকেনের মান অন্তর্ভুক্ত করা উচিত, সেইসাথে ব্যবহারকারী যখন আপনার অ্যাপ্লিকেশনে ফিরে আসবে তখন প্রসঙ্গ পুনরুদ্ধার করার জন্য প্রয়োজনীয় অন্যান্য তথ্য, যেমন, শুরুর URL। ( state এ আরও পড়ুন।)
nonce হলো আপনার অ্যাপ দ্বারা তৈরি একটি এলোমেলো মান যা উপস্থিত থাকলে রিপ্লে সুরক্ষা সক্ষম করে।
login_hint ব্যবহারকারীর ইমেল ঠিকানা অথবা sub স্ট্রিং হতে পারে, যা ব্যবহারকারীর Google আইডির সমতুল্য। যদি আপনি login_hint প্রদান না করেন এবং ব্যবহারকারী লগ ইন করে থাকেন, তাহলে সম্মতি স্ক্রিনে আপনার অ্যাপে ব্যবহারকারীর ইমেল ঠিকানা প্রকাশ করার জন্য অনুমোদনের অনুরোধ থাকবে। ( login_hint এ আরও পড়ুন।)
Google Workspace বা Cloud সংস্থার সাথে যুক্ত একটি নির্দিষ্ট ডোমেনের ব্যবহারকারীদের জন্য OpenID Connect প্রবাহ অপ্টিমাইজ করতে hd প্যারামিটার ব্যবহার করুন ( hd এ আরও পড়ুন)।

এখানে একটি সম্পূর্ণ OpenID Connect প্রমাণীকরণ URI এর একটি উদাহরণ দেওয়া হল, যেখানে পঠনযোগ্যতার জন্য লাইন ব্রেক এবং স্পেস থাকবে:

https://accounts.google.com/o/oauth2/v2/auth?
 response_type=code&
 client_id=424911365001.apps.googleusercontent.com&
 scope=openid%20email&
 redirect_uri=https%3A//oauth2.example.com/code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2-login-demo.example.com%2FmyHome&
 login_hint=jsmith@example.com&
 nonce=0394852-3190485-2490358&
 hd=example.com

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

৩. জালিয়াতি-বিরোধী অবস্থা টোকেন নিশ্চিত করুন

আপনার অনুরোধে উল্লেখ করা redirect_uri তে প্রতিক্রিয়া পাঠানো হবে। সমস্ত প্রতিক্রিয়া কোয়েরি স্ট্রিং-এ ফেরত পাঠানো হবে:

https://oauth2.example.com/code?state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foa2cb.example.com%2FmyHome&code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&scope=openid%20email%20https://www.googleapis.com/auth/userinfo.email

সার্ভারে, আপনাকে নিশ্চিত করতে হবে যে Google থেকে প্রাপ্ত state ধাপ ১- এ তৈরি করা সেশন টোকেনের সাথে মিলে যাচ্ছে। এই রাউন্ড-ট্রিপ যাচাইকরণটি যাচাই করতে সাহায্য করে যে ব্যবহারকারী, কোনও ক্ষতিকারক স্ক্রিপ্ট নয়, অনুরোধটি করছে।

নিম্নলিখিত কোডটি ধাপ ১ এ আপনার তৈরি করা সেশন টোকেনগুলি নিশ্চিত করে:

পিএইচপি

// Ensure that there is no request forgery going on, and that the user
// sending us this connect request is the user that was supposed to.
if ($request->get('state') != ($app['session']->get('state'))) {
  return new Response('Invalid state parameter', 401);
}

জাভা

// Ensure that there is no request forgery going on, and that the user
// sending us this connect request is the user that was supposed to.
if (!request.queryParams("state").equals(
    request.session().attribute("state"))) {
  response.status(401);
  return GSON.toJson("Invalid state parameter.");
}

পাইথন

# Ensure that the request is not a forgery and that the user sending
# this connect request is the expected user.
if request.args.get('state', '') != session['state']:
  response = make_response(json.dumps('Invalid state parameter.'), 401)
  response.headers['Content-Type'] = 'application/json'
  return response

৪. অ্যাক্সেস টোকেন এবং আইডি টোকেনের জন্য `code` বিনিময় করুন

প্রতিক্রিয়াটিতে একটি code প্যারামিটার, একটি এককালীন অনুমোদন কোড রয়েছে যা আপনার সার্ভার একটি অ্যাক্সেস টোকেন এবং আইডি টোকেনের জন্য বিনিময় করতে পারে। আপনার সার্ভার একটি HTTPS POST অনুরোধ পাঠিয়ে এই বিনিময়টি করে। POST অনুরোধটি টোকেন এন্ডপয়েন্টে পাঠানো হয়, যা আপনাকে token_endpoint মেটাডেটা মান ব্যবহার করে ডিসকভারি ডকুমেন্ট থেকে পুনরুদ্ধার করতে হবে। নিম্নলিখিত আলোচনায় ধরে নেওয়া হয়েছে যে এন্ডপয়েন্টটি https://oauth2.googleapis.com/token । অনুরোধটিতে POST বডিতে নিম্নলিখিত প্যারামিটারগুলি অন্তর্ভুক্ত করতে হবে:

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

আসল অনুরোধটি নিম্নলিখিত উদাহরণের মতো দেখতে হতে পারে:

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=https%3A//oauth2.example.com/code&
grant_type=authorization_code

এই অনুরোধের একটি সফল প্রতিক্রিয়ায় একটি JSON অ্যারেতে নিম্নলিখিত ক্ষেত্রগুলি থাকে:

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

৫. আইডি টোকেন থেকে ব্যবহারকারীর তথ্য সংগ্রহ করুন

একটি ID টোকেন হল একটি JWT (JSON ওয়েব টোকেন), অর্থাৎ, একটি ক্রিপ্টোগ্রাফিকভাবে স্বাক্ষরিত Base64-এনকোডেড JSON অবজেক্ট। সাধারণত, একটি ID টোকেন ব্যবহার করার আগে এটি যাচাই করা অত্যন্ত গুরুত্বপূর্ণ, কিন্তু যেহেতু আপনি একটি মধ্যস্থতাকারী-মুক্ত HTTPS চ্যানেলের মাধ্যমে Google এর সাথে সরাসরি যোগাযোগ করছেন এবং Google এর কাছে নিজেকে প্রমাণীকরণ করার জন্য আপনার ক্লায়েন্ট সিক্রেট ব্যবহার করছেন, তাই আপনি নিশ্চিত থাকতে পারেন যে আপনি যে টোকেনটি পেয়েছেন তা আসলে Google থেকে এসেছে এবং বৈধ। যদি আপনার সার্ভার আপনার অ্যাপের অন্যান্য উপাদানগুলিতে ID টোকেনটি প্রেরণ করে, তাহলে এটি ব্যবহার করার আগে অন্যান্য উপাদানগুলির দ্বারা টোকেনটি যাচাই করা অত্যন্ত গুরুত্বপূর্ণ।

যেহেতু বেশিরভাগ API লাইব্রেরি যাচাইকরণকে base64url-এনকোডেড মানগুলি ডিকোড করার এবং এর মধ্যে JSON পার্স করার কাজের সাথে একত্রিত করে, তাই ID টোকেনের দাবিগুলি অ্যাক্সেস করার সাথে সাথে আপনি সম্ভবত টোকেনটি যাচাই করে ফেলবেন।

একটি আইডি টোকেনের পেলোড

একটি ID টোকেন হল একটি JSON অবজেক্ট যাতে নাম/মান জোড়ার একটি সেট থাকে। এখানে একটি উদাহরণ দেওয়া হল, পঠনযোগ্যতার জন্য ফর্ম্যাট করা:

{
  "iss": "https://accounts.google.com",
  "azp": "1234987819200.apps.googleusercontent.com",
  "aud": "1234987819200.apps.googleusercontent.com",
  "sub": "10769150350006150715113082367",
  "at_hash": "HK6E_P6Dh8Y93mRNtsDB1Q",
  "hd": "example.com",
  "email": "jsmith@example.com",
  "email_verified": "true",
  "iat": 1353601026,
  "exp": 1353604926,
  "nonce": "0394852-3190485-2490358"
}

সতর্কতা: আপনার অ্যাকাউন্ট ম্যানেজমেন্ট সিস্টেম বাস্তবায়নের সময়, আপনার আইডি টোকেনের email ক্ষেত্রটি ব্যবহারকারীর জন্য একটি অনন্য শনাক্তকারী হিসাবে ব্যবহার করা উচিত নয় । সর্বদা sub ক্ষেত্রটি ব্যবহার করুন কারণ এটি একটি Google অ্যাকাউন্টের জন্য অনন্য, এমনকি যদি ব্যবহারকারী তাদের ইমেল ঠিকানা পরিবর্তন করে।

গুগল আইডি টোকেনগুলিতে নিম্নলিখিত ক্ষেত্রগুলি থাকতে পারে ( দাবি নামে পরিচিত):

দাবি	প্রদান করা হয়েছে	বিবরণ
`aud`	সর্বদা	এই আইডি টোকেনটি যে দর্শকদের জন্য তৈরি করা হয়েছে। এটি অবশ্যই আপনার অ্যাপ্লিকেশনের OAuth 2.0 ক্লায়েন্ট আইডিগুলির মধ্যে একটি হতে হবে।
`exp`	সর্বদা	মেয়াদ শেষ হওয়ার সময় যে তারিখে বা তার পরে আইডি টোকেন গ্রহণ করা উচিত নয়। ইউনিক্স যুগের সময় (পূর্ণসংখ্যা সেকেন্ড) দ্বারা প্রতিনিধিত্ব করা হয়।
`iat`	সর্বদা	আইডি টোকেন ইস্যু করার সময়। ইউনিক্স যুগের সময় (পূর্ণসংখ্যা সেকেন্ড) দ্বারা প্রতিনিধিত্ব করা হয়েছে।
`iss`	সর্বদা	প্রতিক্রিয়া প্রদানকারীর জন্য ইস্যুকারী শনাক্তকারী। Google আইডি টোকেনের জন্য সর্বদা `https://accounts.google.com` অথবা `accounts.google.com` ব্যবহার করুন।
`sub`	সর্বদা	ব্যবহারকারীর জন্য একটি শনাক্তকারী, সমস্ত Google অ্যাকাউন্টের মধ্যে অনন্য এবং কখনও পুনঃব্যবহৃত হয় না। একটি Google অ্যাকাউন্টে বিভিন্ন সময়ে একাধিক ইমেল ঠিকানা থাকতে পারে, কিন্তু `sub` মান কখনও পরিবর্তন করা হয় না। ব্যবহারকারীর জন্য অনন্য-শনাক্তকারী কী হিসাবে আপনার অ্যাপ্লিকেশনের মধ্যে `sub` ব্যবহার করুন। সর্বাধিক দৈর্ঘ্য 255 কেস-সংবেদনশীল ASCII অক্ষর।
`at_hash`		অ্যাক্সেস টোকেন হ্যাশ। অ্যাক্সেস টোকেনটি পরিচয় টোকেনের সাথে সংযুক্ত কিনা তা যাচাই করে। যদি আইডি টোকেনটি সার্ভার ফ্লোতে `access_token` মান সহ জারি করা হয়, তবে এই দাবিটি সর্বদা অন্তর্ভুক্ত থাকে। ক্রস-সাইট অনুরোধ জালিয়াতি আক্রমণ থেকে রক্ষা করার জন্য এই দাবিটি একটি বিকল্প ব্যবস্থা হিসাবে ব্যবহার করা যেতে পারে, তবে আপনি যদি ধাপ 1 এবং ধাপ 3 অনুসরণ করেন তবে অ্যাক্সেস টোকেন যাচাই করার প্রয়োজন নেই।
`azp`		অনুমোদিত উপস্থাপকের `client_id` । এই দাবিটি কেবল তখনই প্রয়োজন যখন ID টোকেনের অনুরোধকারী পক্ষ এবং ID টোকেনের দর্শক একই রকম না হয়। এটি Google-এর ক্ষেত্রে হাইব্রিড অ্যাপের ক্ষেত্রে প্রযোজ্য হতে পারে যেখানে একটি ওয়েব অ্যাপ্লিকেশন এবং Android অ্যাপের OAuth 2.0 `client_id` আলাদা কিন্তু একই Google API প্রকল্প শেয়ার করে।
`email`		ব্যবহারকারীর ইমেল ঠিকানা। আপনার অনুরোধে `email` স্কোপ অন্তর্ভুক্ত করলেই কেবল এটি প্রদান করা হবে। এই দাবির মান এই অ্যাকাউন্টের জন্য অনন্য নাও হতে পারে এবং সময়ের সাথে সাথে পরিবর্তিত হতে পারে, তাই আপনার ব্যবহারকারীর রেকর্ডের সাথে লিঙ্ক করার জন্য এই মানটিকে প্রাথমিক শনাক্তকারী হিসাবে ব্যবহার করা উচিত নয়। Google Workspace বা ক্লাউড সংস্থার ব্যবহারকারীদের সনাক্ত করার জন্য আপনি `email` দাবির ডোমেনের উপরও নির্ভর করতে পারবেন না; পরিবর্তে `hd` দাবি ব্যবহার করুন। সতর্কতা: ব্যবহারকারীর জন্য অনন্য শনাক্তকারী হিসেবে `email` ক্ষেত্রটি ব্যবহার করবেন না। সর্বদা `sub` ক্ষেত্রটি ব্যবহার করুন।
`email_verified`		ব্যবহারকারীর ইমেল ঠিকানা যাচাই করা হলে সত্য; অন্যথায় মিথ্যা।
`family_name`		ব্যবহারকারীর উপাধি (গুলি) বা পদবি (গুলি)। `name` দাবি উপস্থিত থাকলে প্রদান করা যেতে পারে।
`given_name`		ব্যবহারকারীর প্রদত্ত নাম(গুলি) অথবা প্রথম নাম(গুলি)। `name` দাবি উপস্থিত থাকলে প্রদান করা হতে পারে।
`hd`		ব্যবহারকারীর Google Workspace বা ক্লাউড সংস্থার সাথে সম্পর্কিত ডোমেন। শুধুমাত্র যদি ব্যবহারকারী কোনও Google ক্লাউড সংস্থার অন্তর্ভুক্ত হন তবেই প্রদান করা হবে। কোনও রিসোর্সে অ্যাক্সেস সীমাবদ্ধ করার সময় আপনাকে অবশ্যই এই দাবিটি পরীক্ষা করতে হবে, শুধুমাত্র নির্দিষ্ট ডোমেনের সদস্যদের জন্য। এই দাবির অনুপস্থিতি ইঙ্গিত দেয় যে অ্যাকাউন্টটি Google হোস্ট করা কোনও ডোমেনের অন্তর্গত নয়।
`locale`		ব্যবহারকারীর লোকেল, যা একটি BCP 47 ভাষা ট্যাগ দ্বারা প্রতিনিধিত্ব করা হয়। `name` দাবি উপস্থিত থাকলে এটি প্রদান করা হতে পারে।
`name`		ব্যবহারকারীর পুরো নাম, একটি প্রদর্শনযোগ্য আকারে। প্রদান করা হতে পারে যখন: অনুরোধের সুযোগে "প্রোফাইল" স্ট্রিংটি অন্তর্ভুক্ত ছিল টোকেন রিফ্রেশ থেকে আইডি টোকেনটি ফেরত পাঠানো হয় যখন `name` দাবি উপস্থিত থাকে, তখন আপনি আপনার অ্যাপের ব্যবহারকারীর রেকর্ড আপডেট করার জন্য সেগুলি ব্যবহার করতে পারেন। মনে রাখবেন যে এই দাবিটি উপস্থিত থাকার নিশ্চয়তা কখনও দেওয়া হয় না।
`nonce`		প্রমাণীকরণ অনুরোধে আপনার অ্যাপ দ্বারা সরবরাহ করা `nonce` মান। এই মানটি শুধুমাত্র একবার উপস্থাপন করে আপনার রিপ্লে আক্রমণ থেকে রক্ষা করা উচিত।
`picture`		ব্যবহারকারীর প্রোফাইল ছবির URL। নিম্নলিখিত ক্ষেত্রে প্রদান করা হতে পারে: অনুরোধের সুযোগে "প্রোফাইল" স্ট্রিংটি অন্তর্ভুক্ত ছিল টোকেন রিফ্রেশ থেকে আইডি টোকেনটি ফেরত পাঠানো হয় যখন `picture` দাবি উপস্থিত থাকে, তখন আপনি আপনার অ্যাপের ব্যবহারকারীর রেকর্ড আপডেট করার জন্য সেগুলি ব্যবহার করতে পারেন। মনে রাখবেন যে এই দাবিটি উপস্থিত থাকার নিশ্চয়তা কখনও দেওয়া হয় না।
`profile`		ব্যবহারকারীর প্রোফাইল পৃষ্ঠার URL। নিম্নলিখিত ক্ষেত্রে প্রদান করা হতে পারে: অনুরোধের সুযোগে "প্রোফাইল" স্ট্রিংটি অন্তর্ভুক্ত ছিল টোকেন রিফ্রেশ থেকে আইডি টোকেনটি ফেরত পাঠানো হয় যখন `profile` দাবি উপস্থিত থাকে, তখন আপনি আপনার অ্যাপের ব্যবহারকারীর রেকর্ড আপডেট করতে সেগুলি ব্যবহার করতে পারেন। মনে রাখবেন যে এই দাবিটি উপস্থিত থাকার নিশ্চয়তা কখনও দেওয়া হয় না।

৬. ব্যবহারকারীকে প্রমাণীকরণ করুন

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

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

উন্নত বিষয়

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

অন্যান্য Google API-তে অ্যাক্সেস

OAuth 2.0 প্রমাণীকরণের জন্য ব্যবহারের একটি সুবিধা হল, আপনার অ্যাপ্লিকেশনটি ব্যবহারকারীর পক্ষ থেকে অন্যান্য Google API (যেমন YouTube, Google Drive, Calendar, অথবা Contacts) ব্যবহারের অনুমতি পেতে পারে, একই সাথে আপনি ব্যবহারকারীকে প্রমাণীকরণ করেন। এটি করার জন্য, Google-এ পাঠানো প্রমাণীকরণ অনুরোধে আপনার প্রয়োজনীয় অন্যান্য স্কোপগুলি অন্তর্ভুক্ত করুন। উদাহরণস্বরূপ, আপনার প্রমাণীকরণ অনুরোধে ব্যবহারকারীর বয়স গোষ্ঠী যোগ করতে, openid email https://www.googleapis.com/auth/profile.agerange.read এর একটি স্কোপ প্যারামিটার পাস করুন। ব্যবহারকারীকে সম্মতি স্ক্রিনে যথাযথভাবে অনুরোধ করা হবে। Google থেকে আপনি যে অ্যাক্সেস টোকেনটি পাবেন তা আপনার অ্যাপ্লিকেশনটিকে আপনার অনুরোধ করা এবং মঞ্জুর করা অ্যাক্সেসের স্কোপগুলির সাথে সম্পর্কিত সমস্ত API অ্যাক্সেস করতে দেবে।

টোকেন রিফ্রেশ করুন

আপনার API অ্যাক্সেসের অনুরোধে, code এক্সচেঞ্জের সময় আপনি একটি রিফ্রেশ টোকেন ফেরত দেওয়ার জন্য অনুরোধ করতে পারেন। একটি রিফ্রেশ টোকেন আপনার অ্যাপ্লিকেশনে ব্যবহারকারী উপস্থিত না থাকাকালীন আপনার অ্যাপ্লিকেশনটিকে Google API গুলিতে অবিচ্ছিন্ন অ্যাক্সেস প্রদান করে। একটি রিফ্রেশ টোকেন অনুরোধ করতে, আপনার প্রমাণীকরণ অনুরোধে access_type প্যারামিটারটি offline সেট করুন।

বিবেচ্য বিষয়:

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

আরও তথ্যের জন্য, অ্যাক্সেস টোকেন রিফ্রেশ করা (অফলাইন অ্যাক্সেস) দেখুন।

আপনার প্রমাণীকরণ অনুরোধে consent জন্য prompt প্যারামিটার সেট করে আপনি ব্যবহারকারীকে আপনার অ্যাপটি পুনরায় অনুমোদনের জন্য অনুরোধ করতে পারেন। যখন prompt=consent অন্তর্ভুক্ত করা হয়, তখন আপনার অ্যাপটি অ্যাক্সেসের স্কোপগুলির অনুমোদনের অনুরোধ করার সময় প্রতিবার সম্মতি স্ক্রিনটি প্রদর্শিত হয়, এমনকি যদি সমস্ত স্কোপ আপনার Google API প্রকল্পে পূর্বে মঞ্জুর করা হয়েছিল। এই কারণে, শুধুমাত্র প্রয়োজন হলেই prompt=consent অন্তর্ভুক্ত করুন।

prompt প্যারামিটার সম্পর্কে আরও জানতে, প্রমাণীকরণ URI প্যারামিটার টেবিলে prompt দেখুন।

প্রমাণীকরণ URI প্যারামিটার

নিম্নলিখিত টেবিলটি Google এর OAuth 2.0 প্রমাণীকরণ API দ্বারা গৃহীত প্যারামিটারগুলির আরও সম্পূর্ণ বিবরণ দেয়।

প্যারামিটার	প্রয়োজনীয়	বিবরণ
`client_id`	(প্রয়োজনীয়)	ক্লায়েন্ট আইডি স্ট্রিং যা আপনি থেকে পাবেন Cloud ConsoleClients page, যেমনটি OAuth 2.0 শংসাপত্রগুলি পান এ বর্ণিত হয়েছে।
`nonce`	(প্রয়োজনীয়)	আপনার অ্যাপ দ্বারা তৈরি একটি এলোমেলো মান যা রিপ্লে সুরক্ষা সক্ষম করে।
`response_type`	(প্রয়োজনীয়)	যদি মানটি `code` হয়, তাহলে একটি বেসিক অথোরাইজেশন কোড ফ্লো চালু হয়, যার ফলে টোকেনগুলি পেতে টোকেন এন্ডপয়েন্টে একটি `POST` প্রয়োজন হয়। যদি মানটি `token id_token` বা `id_token token` হয়, তাহলে একটি ইমপ্লিসিট ফ্লো চালু হয়, যার ফলে URI `#fragment` শনাক্তকারী থেকে টোকেনগুলি পুনরুদ্ধার করতে পুনঃনির্দেশ URI-তে জাভাস্ক্রিপ্ট ব্যবহার করা প্রয়োজন।
`redirect_uri`	(প্রয়োজনীয়)	প্রতিক্রিয়াটি কোথায় পাঠানো হবে তা নির্ধারণ করে। এই প্যারামিটারের মানটি অবশ্যই আপনার দ্বারা সেট করা অনুমোদিত পুনঃনির্দেশ মানগুলির একটির সাথে হুবহু মিলতে হবে Cloud ConsoleClients page (HTTP অথবা HTTPS স্কিম, কেস, এবং ট্রেইলিং '/', যদি থাকে, সহ)।
`scope`	(প্রয়োজনীয়)	স্কোপ প্যারামিটারটি অবশ্যই `openid` মান দিয়ে শুরু হতে হবে এবং তারপরে `profile` মান, `email` মান, অথবা উভয়ই অন্তর্ভুক্ত করতে হবে। যদি `profile` স্কোপ মান উপস্থিত থাকে, তাহলে আইডি টোকেনটি ব্যবহারকারীর ডিফল্ট `profile` দাবিগুলি অন্তর্ভুক্ত করতে পারে (কিন্তু নিশ্চিত নয়)। যদি `email` স্কোপ মান উপস্থিত থাকে, তাহলে আইডি টোকেনে `email` এবং `email_verified` দাবি অন্তর্ভুক্ত থাকে। এই OpenID-নির্দিষ্ট স্কোপগুলি ছাড়াও, আপনার স্কোপ আর্গুমেন্টে অন্যান্য স্কোপ মানও অন্তর্ভুক্ত থাকতে পারে। সমস্ত স্কোপ মান অবশ্যই স্থান-বিচ্ছিন্ন করতে হবে। উদাহরণস্বরূপ, যদি আপনি কোনও ব্যবহারকারীর Google ড্রাইভে প্রতি-ফাইল অ্যাক্সেস চান, তাহলে আপনার স্কোপ প্যারামিটারটি `openid profile email https://www.googleapis.com/auth/drive.file` হতে পারে। উপলব্ধ স্কোপ সম্পর্কে তথ্যের জন্য, Google API-এর জন্য OAuth 2.0 স্কোপ অথবা আপনি যে Google API ব্যবহার করতে চান তার ডকুমেন্টেশন দেখুন।
`state`	(ঐচ্ছিক, কিন্তু দৃঢ়ভাবে সুপারিশ করা হয়েছে)	একটি অস্বচ্ছ স্ট্রিং যা প্রোটোকলে রাউন্ড-ট্রিপ করা হয়; অর্থাৎ, এটি বেসিক ফ্লোতে একটি URI প্যারামিটার হিসাবে এবং ইমপ্লিসিট ফ্লোতে URI `#fragment` আইডেন্টিফায়ার হিসাবে ফেরত পাঠানো হয়। অনুরোধ এবং প্রতিক্রিয়াগুলির মধ্যে সম্পর্ক স্থাপনের জন্য এই `state` কার্যকর হতে পারে। যেহেতু আপনার `redirect_uri` অনুমান করা যেতে পারে, তাই একটি `state` মান ব্যবহার করলে আপনার নিশ্চিততা বৃদ্ধি পাবে যে একটি ইনকামিং সংযোগ আপনার অ্যাপ দ্বারা শুরু করা একটি প্রমাণীকরণ অনুরোধের ফলাফল। যদি আপনি একটি র্যান্ডম স্ট্রিং তৈরি করেন বা এই `state` ভেরিয়েবলে কিছু ক্লায়েন্ট স্টেটের (যেমন, একটি কুকি) হ্যাশ এনকোড করেন, তাহলে আপনি প্রতিক্রিয়াটি যাচাই করতে পারেন যাতে অনুরোধ এবং প্রতিক্রিয়া একই ব্রাউজারে উৎপন্ন হয়েছে তা যাচাই করা যায়। এটি ক্রস-সাইট অনুরোধ জালিয়াতির মতো আক্রমণের বিরুদ্ধে সুরক্ষা প্রদান করে।
`access_type`	(ঐচ্ছিক)	অনুমোদিত মানগুলি `offline` এবং `online` । প্রভাবটি অফলাইন অ্যাক্সেসে নথিভুক্ত করা হয়েছে; যদি একটি অ্যাক্সেস টোকেন অনুরোধ করা হয়, তবে ক্লায়েন্ট একটি রিফ্রেশ টোকেন পাবে না যদি না `offline` মান নির্দিষ্ট করা থাকে।
`display`	(ঐচ্ছিক)	একটি ASCII স্ট্রিং মান যা অনুমোদন সার্ভার কীভাবে প্রমাণীকরণ এবং সম্মতি ব্যবহারকারী ইন্টারফেস পৃষ্ঠাগুলি প্রদর্শন করে তা নির্দিষ্ট করে। নিম্নলিখিত মানগুলি নির্দিষ্ট করা হয় এবং Google সার্ভার দ্বারা গৃহীত হয়, কিন্তু প্রোটোকল প্রবাহ আচরণের উপর কোনও প্রভাব ফেলে না: `page` , `popup` , `touch` এবং `wap` ।
`hd`	(ঐচ্ছিক)	গুগল ক্লাউড প্রতিষ্ঠানের মালিকানাধীন অ্যাকাউন্টগুলির জন্য লগইন প্রক্রিয়াটি সহজ করুন। গুগল ক্লাউড প্রতিষ্ঠান ডোমেন (উদাহরণস্বরূপ, `mycollege.edu` ) অন্তর্ভুক্ত করে, আপনি নির্দেশ করতে পারেন যে অ্যাকাউন্ট নির্বাচন UI সেই ডোমেনের অ্যাকাউন্টগুলির জন্য অপ্টিমাইজ করা উচিত। সাধারণত গুগল ক্লাউড প্রতিষ্ঠান অ্যাকাউন্টগুলির জন্য অপ্টিমাইজ করতে শুধুমাত্র একটি গুগল ক্লাউড প্রতিষ্ঠান ডোমেনের পরিবর্তে, একটি তারকাচিহ্ন ( `` ) এর মান সেট করুন : `hd=` । আপনার অ্যাপটি কে অ্যাক্সেস করতে পারবে তা নিয়ন্ত্রণ করার জন্য এই UI অপ্টিমাইজেশনের উপর নির্ভর করবেন না, কারণ ক্লায়েন্ট-সাইড অনুরোধগুলি পরিবর্তন করা যেতে পারে। নিশ্চিত করুন যে ফেরত দেওয়া ID টোকেনের একটি `hd` দাবির মান রয়েছে যা আপনার প্রত্যাশার সাথে মেলে (যেমন `mycolledge.edu` )। অনুরোধ প্যারামিটারের বিপরীতে, ID টোকেন `hd` দাবিটি Google থেকে একটি নিরাপত্তা টোকেনের মধ্যে থাকে, তাই মানটি বিশ্বাসযোগ্য হতে পারে।
`include_granted_scopes`	(ঐচ্ছিক)	যদি এই প্যারামিটারে `true` মান দেওয়া থাকে এবং অনুমোদনের অনুরোধ মঞ্জুর করা হয়, তাহলে অনুমোদনের মধ্যে অন্যান্য স্কোপের জন্য এই ব্যবহারকারী/অ্যাপ্লিকেশন সংমিশ্রণে প্রদত্ত পূর্ববর্তী যেকোনো অনুমোদন অন্তর্ভুক্ত থাকবে; বর্ধিত অনুমোদন দেখুন। মনে রাখবেন যে আপনি ইনস্টল করা অ্যাপ ফ্লো দিয়ে ক্রমবর্ধমান অনুমোদন করতে পারবেন না।
`login_hint`	(ঐচ্ছিক)	যখন আপনার অ্যাপ জানে যে কোন ব্যবহারকারীকে প্রমাণীকরণ করার চেষ্টা করছে, তখন এটি প্রমাণীকরণ সার্ভারকে এই প্যারামিটারটি ইঙ্গিত হিসেবে প্রদান করতে পারে। এই ইঙ্গিতটি পাস করলে অ্যাকাউন্ট চয়নকারী দমন করা হয় এবং সাইন-ইন ফর্মের ইমেল বাক্সটি আগে থেকে পূরণ করা হয়, অথবা সঠিক সেশনটি নির্বাচন করা হয় (যদি ব্যবহারকারী একাধিক সাইন-ইন ব্যবহার করেন), যা আপনার অ্যাপ ভুল ব্যবহারকারী অ্যাকাউন্টে লগ ইন করলে যে সমস্যাগুলি ঘটে তা এড়াতে সাহায্য করতে পারে। মানটি একটি ইমেল ঠিকানা বা `sub` স্ট্রিং হতে পারে, যা ব্যবহারকারীর Google ID এর সমতুল্য।
`prompt`	(ঐচ্ছিক)	স্ট্রিং মানের একটি স্পেস-ডিলিমিটেড তালিকা যা নির্দিষ্ট করে যে অনুমোদন সার্ভার ব্যবহারকারীকে পুনরায় প্রমাণীকরণ এবং সম্মতির জন্য অনুরোধ করে কিনা। সম্ভাব্য মানগুলি হল: `none` অনুমোদন সার্ভার কোনও প্রমাণীকরণ বা ব্যবহারকারীর সম্মতি স্ক্রিন প্রদর্শন করে না; যদি ব্যবহারকারী ইতিমধ্যেই প্রমাণীকরণ না করে থাকেন এবং অনুরোধ করা স্কোপের জন্য আগে থেকে সম্মতি কনফিগার না করে থাকেন তবে এটি একটি ত্রুটি ফেরত দেবে। বিদ্যমান প্রমাণীকরণ এবং/অথবা সম্মতি পরীক্ষা করার জন্য আপনি `none` ব্যবহার করতে পারেন। `consent` ক্লায়েন্টকে তথ্য ফেরত দেওয়ার আগে অনুমোদন সার্ভার ব্যবহারকারীকে সম্মতির জন্য অনুরোধ করে। `select_account` অনুমোদন সার্ভার ব্যবহারকারীকে একটি ব্যবহারকারী অ্যাকাউন্ট নির্বাচন করতে অনুরোধ করে। এটি অনুমোদন সার্ভারে একাধিক অ্যাকাউন্ট থাকা ব্যবহারকারীকে একাধিক অ্যাকাউন্টের মধ্যে থেকে নির্বাচন করতে দেয় যার জন্য তাদের বর্তমান সেশন থাকতে পারে। যদি কোনও মান নির্দিষ্ট না করা থাকে এবং ব্যবহারকারী পূর্বে অ্যাক্সেস অনুমোদিত না করে থাকেন, তাহলে ব্যবহারকারীকে একটি সম্মতি স্ক্রিন দেখানো হবে।
`hl`	(ঐচ্ছিক)	সাইন-ইন, অ্যাকাউন্ট চয়নকারী এবং সম্মতি স্ক্রিনের জন্য প্রদর্শন ভাষা নির্দিষ্ট করতে ব্যবহৃত একটি BCP 47 ভাষার ট্যাগ। যদি এই প্যারামিটারটি প্রদান না করা হয়, তাহলে ভাষাটি ব্যবহারকারীর Google অ্যাকাউন্ট বা ব্রাউজার সেটিংসে ডিফল্টভাবে সেট করা হয়। উদাহরণস্বরূপ, ব্রিটিশ ইংরেজিতে UI অনুরোধ করতে, প্যারামিটারটি `en-GB` এ সেট করুন।

একটি আইডি টোকেন যাচাই করা হচ্ছে

আপনার সার্ভারের সমস্ত আইডি টোকেন যাচাই করতে হবে যদি না আপনি জানেন যে সেগুলি সরাসরি গুগল থেকে এসেছে। উদাহরণস্বরূপ, আপনার সার্ভারকে আপনার ক্লায়েন্ট অ্যাপ থেকে প্রাপ্ত যেকোনো আইডি টোকেনকে খাঁটি কিনা তা যাচাই করতে হবে।

নিম্নলিখিত সাধারণ পরিস্থিতিগুলি যেখানে আপনি আপনার সার্ভারে আইডি টোকেন পাঠাতে পারেন:

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

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

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

একটি আইডি টোকেনের যাচাইকরণের জন্য বেশ কয়েকটি ধাপ প্রয়োজন:

যাচাই করুন যে আইডি টোকেনটি ইস্যুকারীর দ্বারা সঠিকভাবে স্বাক্ষরিত। Google-এর দ্বারা জারি করা টোকেনগুলি Discovery ডকুমেন্টের jwks_uri মেটাডেটা মানের মধ্যে নির্দিষ্ট URI-তে পাওয়া সার্টিফিকেটগুলির একটি ব্যবহার করে স্বাক্ষরিত হয়।
যাচাই করুন যে আইডি টোকেনে iss দাবির মান https://accounts.google.com বা accounts.google.com এর সমান।
যাচাই করুন যে আইডি টোকেনে থাকা aud দাবির মান আপনার অ্যাপের ক্লায়েন্ট আইডির সমান।
যাচাই করুন যে আইডি টোকেনের মেয়াদ শেষ হওয়ার সময় ( exp দাবি) অতিক্রান্ত হয়নি।
যদি আপনি অনুরোধে একটি hd প্যারামিটার মান নির্দিষ্ট করে থাকেন, তাহলে যাচাই করুন যে আইডি টোকেনটিতে একটি hd দাবি আছে যা একটি Google ক্লাউড সংস্থার সাথে সম্পর্কিত একটি গৃহীত ডোমেনের সাথে মেলে।

ধাপ ২ থেকে ৫-এ কেবল স্ট্রিং এবং তারিখের তুলনা করা হবে যা বেশ সহজবোধ্য, তাই আমরা এখানে সেগুলি বিস্তারিতভাবে বর্ণনা করব না।

প্রথম ধাপটি আরও জটিল, এবং এতে ক্রিপ্টোগ্রাফিক স্বাক্ষর পরীক্ষা করা জড়িত। ডিবাগিংয়ের উদ্দেশ্যে, আপনি আপনার সার্ভার বা ডিভাইসে বাস্তবায়িত স্থানীয় প্রক্রিয়াকরণের সাথে তুলনা করার জন্য Google এর tokeninfo এন্ডপয়েন্ট ব্যবহার করতে পারেন। ধরুন আপনার ID টোকেনের মান XYZ123 । তাহলে আপনি URI https://oauth2.googleapis.com/tokeninfo?id_token= XYZ123 কে ডিরেফারেন্স করবেন। যদি টোকেন স্বাক্ষরটি বৈধ হয়, তাহলে প্রতিক্রিয়াটি হবে JWT পেলোড যা তার ডিকোড করা JSON অবজেক্ট আকারে থাকবে।

tokeninfo এন্ডপয়েন্টটি ডিবাগিংয়ের জন্য কার্যকর তবে উৎপাদনের উদ্দেশ্যে, কী এন্ডপয়েন্ট থেকে গুগলের পাবলিক কীগুলি পুনরুদ্ধার করুন এবং স্থানীয়ভাবে যাচাইকরণ সম্পাদন করুন। আপনার jwks_uri মেটাডেটা মান ব্যবহার করে ডিসকভারি ডকুমেন্ট থেকে কী URI পুনরুদ্ধার করা উচিত। ডিবাগিং এন্ডপয়েন্টে অনুরোধগুলি থ্রোটল করা হতে পারে বা অন্যথায় মাঝে মাঝে ত্রুটির বিষয় হতে পারে।

যেহেতু গুগল তার পাবলিক কীগুলি খুব কমই পরিবর্তন করে, তাই আপনি HTTP প্রতিক্রিয়ার ক্যাশে নির্দেশিকা ব্যবহার করে সেগুলি ক্যাশে করতে পারেন এবং বেশিরভাগ ক্ষেত্রে, tokeninfo এন্ডপয়েন্ট ব্যবহারের চেয়ে স্থানীয় বৈধতা অনেক বেশি দক্ষতার সাথে সম্পাদন করতে পারেন। এই বৈধতার জন্য সার্টিফিকেটগুলি পুনরুদ্ধার এবং পার্সিং করা এবং স্বাক্ষর পরীক্ষা করার জন্য উপযুক্ত ক্রিপ্টোগ্রাফিক কল করা প্রয়োজন। সৌভাগ্যবশত, এটি সম্পন্ন করার জন্য বিভিন্ন ভাষায় ভালভাবে ডিবাগ করা লাইব্রেরি উপলব্ধ রয়েছে ( jwt.io দেখুন)।

ব্যবহারকারীর প্রোফাইল তথ্য প্রাপ্ত করা

ব্যবহারকারী সম্পর্কে অতিরিক্ত প্রোফাইল তথ্য পেতে, আপনি অ্যাক্সেস টোকেন (যা আপনার অ্যাপ্লিকেশন প্রমাণীকরণ প্রবাহের সময় গ্রহণ করে) এবং OpenID Connect স্ট্যান্ডার্ড ব্যবহার করতে পারেন:

OpenID-সম্মত হতে হলে, আপনার প্রমাণীকরণ অনুরোধে openid profile স্কোপ মানগুলি অন্তর্ভুক্ত করতে হবে।
যদি আপনি ব্যবহারকারীর ইমেল ঠিকানা অন্তর্ভুক্ত করতে চান, তাহলে আপনি email এর একটি অতিরিক্ত স্কোপ মান নির্দিষ্ট করতে পারেন। profile এবং email উভয়ই নির্দিষ্ট করতে, আপনি আপনার প্রমাণীকরণ অনুরোধ URI-তে নিম্নলিখিত প্যারামিটারটি অন্তর্ভুক্ত করতে পারেন:
```
scope=openid%20profile%20email
```
আপনার অ্যাক্সেস টোকেনটি অনুমোদনের শিরোনামে যুক্ত করুন এবং userinfo এন্ডপয়েন্টে একটি HTTPS GET অনুরোধ করুন, যা আপনাকে userinfo_endpoint মেটাডেটা মান ব্যবহার করে Discovery ডকুমেন্ট থেকে পুনরুদ্ধার করতে হবে। userinfo প্রতিক্রিয়াতে ব্যবহারকারী সম্পর্কে তথ্য অন্তর্ভুক্ত থাকে, যেমনটি OpenID Connect Standard Claims এবং Discovery ডকুমেন্টের claims_supported মেটাডেটা মান হিসাবে বর্ণিত হয়েছে। ব্যবহারকারী বা তাদের সংস্থাগুলি নির্দিষ্ট ক্ষেত্র সরবরাহ করতে বা আটকে রাখতে বেছে নিতে পারে, তাই আপনি আপনার অনুমোদিত অ্যাক্সেসের সুযোগের জন্য প্রতিটি ক্ষেত্রের জন্য তথ্য নাও পেতে পারেন।

ডিসকভারি ডকুমেন্ট

The OpenID Connect protocol requires the use of multiple endpoints for authenticating users, and for requesting resources including tokens, user information, and public keys.

To simplify implementations and increase flexibility, OpenID Connect allows the use of a "Discovery document," a JSON document found at a well-known location containing key-value pairs which provide details about the OpenID Connect provider's configuration, including the URIs of the authorization, token, revocation, userinfo, and public-keys endpoints. The Discovery document for Google's OpenID Connect service may be retrieved from:

https://accounts.google.com/.well-known/openid-configuration

To use Google's OpenID Connect services, you should hard-code the Discovery-document URI ( https://accounts.google.com/.well-known/openid-configuration ) into your application. Your application fetches the document, applies caching rules in the response, then retrieves endpoint URIs from it as needed. For example, to authenticate a user, your code would retrieve the authorization_endpoint metadata value ( https://accounts.google.com/o/oauth2/v2/auth in the example below) as the base URI for authentication requests that are sent to Google.

Here is an example of such a document; the field names are those specified in OpenID Connect Discovery 1.0 (refer to that document for their meanings). The values are purely illustrative and might change, although they are copied from a recent version of the actual Google Discovery document:

{
  "issuer": "https://accounts.google.com",
  "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
  "device_authorization_endpoint": "https://oauth2.googleapis.com/device/code",
  "token_endpoint": "https://oauth2.googleapis.com/token",
  "userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
  "revocation_endpoint": "https://oauth2.googleapis.com/revoke",
  "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
  "response_types_supported": [
    "code",
    "token",
    "id_token",
    "code token",
    "code id_token",
    "token id_token",
    "code token id_token",
    "none"
  ],
  "subject_types_supported": [
    "public"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ],
  "scopes_supported": [
    "openid",
    "email",
    "profile"
  ],
  "token_endpoint_auth_methods_supported": [
    "client_secret_post",
    "client_secret_basic"
  ],
  "claims_supported": [
    "aud",
    "email",
    "email_verified",
    "exp",
    "family_name",
    "given_name",
    "iat",
    "iss",
    "locale",
    "name",
    "picture",
    "sub"
  ],
  "code_challenge_methods_supported": [
    "plain",
    "S256"
  ]
}

You may be able to avoid an HTTP round-trip by caching the values from the Discovery document. Standard HTTP caching headers are used and should be respected.

ক্লায়েন্ট লাইব্রেরি

The following client libraries make implementing OAuth 2.0 simpler by integrating with popular frameworks:

OpenID Connect compliance

Google's OAuth 2.0 authentication system supports the required features of the OpenID Connect Core specification. Any client which is designed to work with OpenID Connect should interoperate with this service (with the exception of the OpenID Request Object ).

OAuth 2.0 সেট আপ করা হচ্ছে

OAuth 2.0 শংসাপত্রগুলি পান

একটি পুনর্নির্দেশ URI সেট করুন

ব্যবহারকারীর সম্মতি স্ক্রিন কাস্টমাইজ করুন

পরিষেবাটি অ্যাক্সেস করা

ব্যবহারকারীর প্রমাণীকরণ

সার্ভার প্রবাহ

১. একটি অ্যান্টি-ফোরজি স্টেট টোকেন তৈরি করুন

পিএইচপি

জাভা

পাইথন

২. গুগলে একটি প্রমাণীকরণ অনুরোধ পাঠান

৩. জালিয়াতি-বিরোধী অবস্থা টোকেন নিশ্চিত করুন

পিএইচপি

জাভা

পাইথন

৪. অ্যাক্সেস টোকেন এবং আইডি টোকেনের জন্য code বিনিময় করুন

৫. আইডি টোকেন থেকে ব্যবহারকারীর তথ্য সংগ্রহ করুন

একটি আইডি টোকেনের পেলোড

৬. ব্যবহারকারীকে প্রমাণীকরণ করুন

উন্নত বিষয়

অন্যান্য Google API-তে অ্যাক্সেস

টোকেন রিফ্রেশ করুন

পুনরায় সম্মতি চাওয়া

প্রমাণীকরণ URI প্যারামিটার

একটি আইডি টোকেন যাচাই করা হচ্ছে

ব্যবহারকারীর প্রোফাইল তথ্য প্রাপ্ত করা

ডিসকভারি ডকুমেন্ট

ক্লায়েন্ট লাইব্রেরি

OpenID Connect compliance

৪. অ্যাক্সেস টোকেন এবং আইডি টোকেনের জন্য `code` বিনিময় করুন