OpenID Connect

Google-এর OpenID Connect এন্ডপয়েন্ট OpenID সার্টিফায়েড।

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

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 ক্রেডেনশিয়ালের জন্য ক্লায়েন্ট আইডি ও ক্লায়েন্ট সিক্রেট দেখতে, নিম্নলিখিত টেক্সটে ক্লিক করুন: ক্রেডেনশিয়াল বেছে নিন। যে উইন্ডো খুলবে, সেখানে আপনার প্রোজেক্ট ও ক্রেডেনশিয়াল বেছে নিন, তারপর দেখুন বিকল্পে ক্লিক করুন।

অথবা, Cloud Console-এর ক্লায়েন্ট পৃষ্ঠা থেকে আপনার ক্লায়েন্ট আইডি ও ক্লায়েন্ট সিক্রেট দেখুন:

  1. ক্লায়েন্ট পৃষ্ঠায় যান।
  2. আপনার ক্লায়েন্টের নাম বা এডিট () আইকনে ক্লিক করুন। পৃষ্ঠার সবচেয়ে উপরে আপনার ক্লায়েন্ট আইডি ও সিক্রেট আছে।

রিডাইরেক্ট URI সেট করুন

Cloud Console-এ আপনার সেট করা রিডাইরেক্ট URI নির্ধারণ করে যে Google আপনার যাচাইকরণের অনুরোধ-এর উত্তর কোথায় পাঠাবে।

প্রদত্ত OAuth 2.0 ক্রেডেনশিয়ালের জন্য রিডাইরেক্ট URI তৈরি, দেখতে বা এডিট করতে, নিম্নলিখিত ধাপগুলি অনুসরণ করুন:

  1. ক্লায়েন্ট পৃষ্ঠায় যান।
  2. ক্লায়েন্টের উপর ক্লিক করুন।
  3. রিডাইরেক্ট URI দেখুন বা এডিট করুন।

'ক্লায়েন্ট' পৃষ্ঠায় কোনও ক্লায়েন্ট তালিকাভুক্ত না থাকলে, আপনার প্রোজেক্টে কোনও OAuth ক্রেডেনশিয়াল নেই। একটি তৈরি করতে, ক্লায়েন্ট তৈরি করুন বিকল্পে ক্লিক করুন।

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

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

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

আপনার প্রোজেক্টের সম্মতি সংক্রান্ত স্ক্রিন চালু করতে:

  1. Google Cloud Console-এ ব্র্যান্ডিং পৃষ্ঠা খুলুন।
  2. প্রম্পট করা হলে, কোনও প্রোজেক্ট বেছে নিন অথবা নতুন একটি তৈরি করুন।
  3. ফর্ম পূরণ করে সেভ করুন বিকল্পে ক্লিক করুন।

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

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

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

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

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

ব্যবহারকারীকে যাচাই করা হচ্ছে

ব্যবহারকারীকে যাচাই করার মধ্যে আইডি টোকেন পাওয়া এবং সেটি যাচাই করা অন্তর্ভুক্ত। ID টোকেন হল OpenID Connect-এর একটি স্ট্যান্ডার্ড ফিচার যা ইন্টারনেটে পরিচয় সংক্রান্ত তথ্য শেয়ার করার জন্য ডিজাইন করা হয়েছে।

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

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

সার্ভার ফ্লো

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

  1. অ্যান্টি-ফর্জারি স্টেট টোকেন তৈরি করা
  2. Google-কে যাচাইকরণের অনুরোধ পাঠান
  3. অ্যান্টি-ফর্জারি স্টেট টোকেন কনফার্ম করুন
  4. অ্যাক্সেস টোকেন ও আইডি টোকেনের জন্য code এক্সচেঞ্জ করুন
  5. আইডি টোকেন থেকে ব্যবহারকারীর তথ্য পাওয়া
  6. ব্যবহারকারীকে যাচাই করা

১. একটি জালিয়াতি-বিরোধী স্টেট টোকেন তৈরি করুন

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

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

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

PHP

এই স্যাম্পেল ব্যবহার করতে আপনাকে অবশ্যই 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
));

Java

এই স্যাম্পেল ব্যবহার করতে আপনাকে অবশ্যই Java-এর জন্য 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

এই স্যাম্পেল ব্যবহার করতে আপনাকে অবশ্যই 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))

২. Google-এ যাচাইকরণের অনুরোধ পাঠান

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

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

  • client_id, যা আপনি Cloud Console-এর ক্লায়েন্ট পৃষ্ঠা থেকে পাবেন।
  • response_type, যা একটি বেসিক অথরাইজেশন কোড ফ্লো অনুরোধে code হতে হবে। response_type থেকে আরও পড়ুন।
  • scope, যা প্রাথমিক অনুরোধে openid email হওয়া উচিত। scope থেকে আরও পড়ুন।)
  • redirect_uri আপনার সার্ভারে HTTP এন্ডপয়েন্ট হওয়া উচিত যা Google থেকে উত্তর পাবে। ভ্যালুটি OAuth 2.0 ক্লায়েন্টের জন্য অনুমোদিত রিডাইরেক্ট URI-এর সাথে হুবহু মিলতে হবে, যা আপনি Cloud Console-এর ক্রেডেনশিয়াল পৃষ্ঠায় কনফিগার করেছেন। এই ভ্যালু অনুমোদিত 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//developers.google.com/oauthplayground&
 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://developers.google.com/oauthplayground?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

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

নিম্নলিখিত কোডটি আপনার তৈরি করা সেশন টোকেন কনফার্ম করার পদ্ধতি দেখায় ধাপ ১-এ:

PHP

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

// 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);
}

Java

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

// 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.");
}

Python

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

# 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 ক্লাউড কনসোলের ক্লায়েন্ট পৃষ্ঠা থেকে আপনি যে ক্লায়েন্ট আইডি পান, যেমনটি OAuth 2.0 ক্রেডেনশিয়াল পান-এ বর্ণনা করা হয়েছে।
client_secret ক্লাউড কনসোল ক্লায়েন্ট পৃষ্ঠা থেকে আপনি যে ক্লায়েন্ট সিক্রেট পান, যেমন OAuth 2.0 ক্রেডেনশিয়াল পান-এ বর্ণনা করা হয়েছে।
redirect_uri রিডাইরেক্ট URI সেট করুন-এ যেমন বর্ণনা করা হয়েছে, Cloud Console ক্লায়েন্ট পৃষ্ঠায় নির্দিষ্ট করা প্রদত্ত client_id-এর জন্য একটি অনুমোদিত রিডাইরেক্ট 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//developers.google.com/oauthplayground&
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-এ সেট করা থাকলে তবেই এই ফিল্ডটি দেখা যায়। বিস্তারিত জানতে, রিফ্রেশ টোকেন দেখুন।

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

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

যেহেতু বেশিরভাগ API লাইব্রেরি base64url-এনকোড করা ভ্যালু ডিকোড করা এবং JSON পার্স করার কাজের সাথে যাচাইকরণকে একত্রিত করে, তাই আপনি সম্ভবত 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"
}

Google ID টোকেনে নিম্নলিখিত ফিল্ড (দাবি হিসেবে পরিচিত) থাকতে পারে:

দাবি দেওয়া হয়েছে বিবরণ
aud সবসময় এই আইডি টোকেনটি যে দর্শকদের জন্য তৈরি করা হয়েছে। এটি আপনার অ্যাপ্লিকেশনের OAuth 2.0 ক্লায়েন্ট আইডিগুলির মধ্যে একটি হতে হবে।
exp সবসময় মেয়াদ শেষ হওয়ার সময় বা তার পরে আইডি টোকেন গ্রহণ করা যাবে না। Unix epoch টাইম (পূর্ণসংখ্যা সেকেন্ড) হিসেবে দেখানো হয়।
iat সবসময় আইডি টোকেন ইস্যু করার সময়। Unix epoch সময় (পূর্ণসংখ্যা সেকেন্ড) হিসেবে দেখানো হয়।
iss সবসময় উত্তরের ইস্যুকারীর জন্য ইস্যুকারী শনাক্তকারী। Google ID টোকেনের জন্য সবসময় https://accounts.google.com বা accounts.google.com ব্যবহার করুন।
sub সবসময় ব্যবহারকারীর জন্য একটি শনাক্তকারী, সমস্ত Google অ্যাকাউন্টের মধ্যে অনন্য এবং কখনও পুনরায় ব্যবহার করা হয় না। একটি Google অ্যাকাউন্টে বিভিন্ন সময়ে একাধিক ইমেল আইডি থাকতে পারে, কিন্তু sub ভ্যালু কখনও পরিবর্তন হয় না। ব্যবহারকারীর জন্য অনন্য-শনাক্তকারী কী হিসেবে আপনার অ্যাপ্লিকেশনের মধ্যে sub ব্যবহার করুন। সর্বাধিক ২৫৫টি ছোট ও বড় হাতের অক্ষরের মধ্যে পার্থক্য করা হয় ASCII অক্ষর।
amr Google অ্যাকাউন্টে সাইন-ইন করার জন্য ব্যবহৃত যাচাইকরণ পদ্ধতি শনাক্ত করে এমন স্ট্রিংয়ের JSON অ্যারে। উপস্থিত থাকলে, এগুলির মধ্যে এক বা একাধিক সম্ভাব্য [IANA.AMR] ভ্যালু অন্তর্ভুক্ত করে:
  • hwk হার্ডওয়্যার কী ব্যবহার করা হয়েছে
  • mfa বহু-স্তরীয় যাচাইকরণ সম্পূর্ণ হয়েছে
  • pwd একটি পাসওয়ার্ড ব্যবহার করা হয়েছে
  • sms যাচাইকরণের জন্য একটি এসএমএস মেসেজ ব্যবহার করা হয়েছে
  • swk পাসকী-র মতো সফ্টওয়্যার কী ব্যবহার করা হয়েছে
  • tel যাচাইকরণের জন্য ফোন কল ব্যবহার করা হয়েছে
শুধুমাত্র তখনই উপস্থিত থাকে যখন amr দাবিটি যাচাইকরণের অনুরোধে অন্তর্ভুক্ত থাকে এবং সেটিংসে চালু থাকে।
auth_time ব্যবহারকারীর পরিচয় যাচাইকরণে যে সময় লেগেছে, একটি JSON নম্বর যা Unix epoch (১ জানুয়ারি, ১৯৭০, ০০:০০:০০ UTC) থেকে কত সেকেন্ড অতিবাহিত হয়েছে তা দেখায়। auth_time দাবিটি যাচাইকরণের অনুরোধে অন্তর্ভুক্ত করা হলে এবং সেটিংসে চালু করা হলে প্রদান করা হয়।
at_hash অ্যাক্সেস টোকেন হ্যাশ। অ্যাক্সেস টোকেনটি পরিচয় টোকেনের সাথে যুক্ত কিনা তা যাচাই করে। সার্ভার ফ্লোতে access_token ভ্যালু সহ আইডি টোকেন ইস্যু করা হলে, এই দাবি সবসময় অন্তর্ভুক্ত করা হয়। ক্রস-সাইট অনুরোধ জালিয়াতি আক্রমণ থেকে রক্ষা করার জন্য এই দাবিটি একটি বিকল্প পদ্ধতি হিসাবে ব্যবহার করা যেতে পারে, তবে আপনি যদি ধাপ ১ এবং ধাপ ৩ অনুসরণ করেন তবে অ্যাক্সেস টোকেন যাচাই করার প্রয়োজন নেই।
azp অনুমোদিত উপস্থাপকের client_id। এই দাবি তখনই প্রয়োজন হয় যখন আইডি টোকেনের জন্য অনুরোধ করা পার্টি এবং আইডি টোকেনের দর্শক এক হয় না। হাইব্রিড অ্যাপের ক্ষেত্রে Google-এ এমনটা হতে পারে, যেখানে ওয়েব অ্যাপ্লিকেশন ও Android অ্যাপের আলাদা OAuth 2.0 client_id আছে, কিন্তু একই Google APIs প্রোজেক্ট শেয়ার করে।
email ব্যবহারকারীর ইমেল আইডি। আপনার অনুরোধে email স্কোপ অন্তর্ভুক্ত থাকলে তবেই এটি প্রদান করা হয়। এই দাবির ভ্যালু এই অ্যাকাউন্টের জন্য অনন্য নাও হতে পারে এবং সময়ের সাথে সাথে পরিবর্তিত হতে পারে, তাই আপনার ব্যবহারকারীর রেকর্ডের সাথে লিঙ্ক করার জন্য প্রাথমিক শনাক্তকারী হিসেবে এই ভ্যালু ব্যবহার করা উচিত নয়। এছাড়াও, Google Workspace বা Cloud সংস্থার ব্যবহারকারীদের শনাক্ত করতে আপনি email দাবির ডোমেনের উপর নির্ভর করতে পারবেন না; পরিবর্তে hd দাবি ব্যবহার করুন।
email_verified ব্যবহারকারীর ইমেল আইডি যাচাই করা হলে True; অন্যথায় False।
family_name ব্যবহারকারীর পদবি বা শেষ নাম। name দাবি থাকলে এটি প্রদান করা হতে পারে।
given_name ব্যবহারকারীর প্রদত্ত নাম বা প্রথম নাম। name দাবি থাকলে এটি প্রদান করা হতে পারে।
hd ব্যবহারকারীর Google Workspace বা Cloud সংস্থার সাথে যুক্ত ডোমেন। ব্যবহারকারী Google Cloud সংস্থার অন্তর্গত হলে তবেই এটি প্রদান করা হয়। কোনও রিসোর্সের অ্যাক্সেস নির্দিষ্ট ডোমেনের মেম্বারদের মধ্যে সীমাবদ্ধ করার সময় আপনাকে অবশ্যই এই দাবি চেক করতে হবে। এই দাবি না থাকার অর্থ হল, অ্যাকাউন্টটি Google-এর হোস্ট করা ডোমেনের নয়।
locale ব্যবহারকারীর লোকেল, যা BCP 47 ভাষা ট্যাগের মাধ্যমে দেখানো হয়। name দাবি থাকলে এটি প্রদান করা হতে পারে।
name ব্যবহারকারীর পুরো নাম, যা দেখানো যাবে। এইসব ক্ষেত্রে দেওয়া হতে পারে:
  • অনুরোধের স্কোপে "profile" স্ট্রিং অন্তর্ভুক্ত ছিল
  • টোকেন রিফ্রেশ থেকে আইডি টোকেন ফেরত দেওয়া হয়

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

nonce যাচাইকরণের অনুরোধে আপনার অ্যাপের মাধ্যমে প্রদান করা nonce-এর ভ্যালু। এই ভ্যালু শুধুমাত্র একবার দেখানোর মাধ্যমে রিপ্লে অ্যাটাক থেকে সুরক্ষিত থাকতে হবে।
picture ব্যবহারকারীর প্রোফাইল ছবির URL। এইসব ক্ষেত্রে দেওয়া হতে পারে:
  • অনুরোধের স্কোপে "profile" স্ট্রিং অন্তর্ভুক্ত ছিল
  • টোকেন রিফ্রেশ থেকে আইডি টোকেন ফেরত দেওয়া হয়

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

profile ব্যবহারকারীর প্রোফাইল পৃষ্ঠার URL। এইসব ক্ষেত্রে দেওয়া হতে পারে:
  • অনুরোধের স্কোপে "profile" স্ট্রিং অন্তর্ভুক্ত ছিল
  • টোকেন রিফ্রেশ থেকে আইডি টোকেন ফেরত দেওয়া হয়

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

৬. ব্যবহারকারীকে যাচাই করা

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

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

উন্নত বিষয়

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

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

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

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

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

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

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

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

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

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

যাচাইকরণ URI প্যারামিটার

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

প্যারামিটার প্রয়োজনীয় বিবরণ
client_id (আবশ্যক) আপনি Cloud Console ক্লায়েন্ট পৃষ্ঠা থেকে যে ক্লায়েন্ট আইডি স্ট্রিং পান, যেমন OAuth 2.0 ক্রেডেনশিয়াল পান-এ বর্ণনা করা হয়েছে।
nonce (আবশ্যক) আপনার অ্যাপের মাধ্যমে জেনারেট করা একটি র‍্যান্ডম ভ্যালু যা রিপ্লে সংক্রান্ত সুরক্ষা চালু করে।
response_type (আবশ্যক) ভ্যালু code হলে, এটি একটি বেসিক অথরাইজেশন কোডের ফ্লো চালু করে, যার জন্য টোকেন পাওয়ার জন্য টোকেন এন্ডপয়েন্টে একটি POST প্রয়োজন হয়। মান token id_token বা id_token token হলে, ইমপ্লিসিট ফ্লো চালু করে, যার জন্য URI #fragment শনাক্তকারী থেকে টোকেন ফিরিয়ে আনতে রিডাইরেক্ট URI-তে জাভাস্ক্রিপ্ট ব্যবহার করতে হয়।
redirect_uri (আবশ্যক) উত্তর কোথায় পাঠানো হবে তা নির্ধারণ করে। এই প্যারামিটারের ভ্যালু অবশ্যই Cloud Console-এর ক্লায়েন্ট পৃষ্ঠা-তে আপনার সেট করা অনুমোদিত রিডাইরেক্ট ভ্যালুর সাথে সম্পূর্ণ মিলতে হবে (HTTP বা HTTPS স্কিম, কেস এবং শেষে '/' থাকলে, সেটি সহ)।
scope (আবশ্যক)

স্কোপ প্যারামিটার অবশ্যই openid ভ্যালু দিয়ে শুরু হতে হবে এবং তারপর profile ভ্যালু, email ভ্যালু অথবা দুটিই অন্তর্ভুক্ত করতে হবে।

profile স্কোপ ভ্যালু থাকলে, ID টোকেনে ব্যবহারকারীর ডিফল্ট profile দাবি অন্তর্ভুক্ত থাকতে পারে (তবে এর কোনও গ্যারান্টি নেই)।

email স্কোপ ভ্যালু থাকলে, ID টোকেনে email ও email_verified দাবি অন্তর্ভুক্ত থাকে।

এইসব OpenID-নির্দিষ্ট স্কোপ ছাড়াও, আপনার স্কোপ আর্গুমেন্টে অন্যান্য স্কোপ ভ্যালুও অন্তর্ভুক্ত থাকতে পারে। সব স্কোপ ভ্যালু স্পেস দিয়ে আলাদা করতে হবে। যেমন, আপনি যদি ব্যবহারকারীর Google Drive-এ প্রতিটি ফাইলের অ্যাক্সেস চান, তাহলে আপনার স্কোপ প্যারামিটার 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-এর একটি মান নির্দিষ্ট করা হয়।
claims (ঐচ্ছিক) দাবি প্যারামিটার ব্যবহার করে এক বা একাধিক ঐচ্ছিক ফিল্ড নির্দিষ্ট করা হয় যা userinfo এন্ডপয়েন্ট বা যাচাইকরণ অনুরোধের ID টোকেন উত্তরের ধরনের মধ্যে অন্তর্ভুক্ত করা হয়। মানটি হল একটি JSON অবজেক্ট যাতে রেসপন্সের ধরন এবং অনুরোধ করা দাবি থাকে। Google সার্ভার নিম্নলিখিত দাবির অনুরোধ গ্রহণ করেছে:
দাবি সংক্রান্ত অনুরোধ
amr ব্যবহারকারীকে শেষবার যাচাই করার সময় যে পদ্ধতি ব্যবহার করা হয়েছিল তার জন্য অনুরোধ করুন। ID টোকেন উত্তরে amr ফিল্ড হিসেবে ফেরত পেতে, claims অনুরোধ প্যারামিটার অন্তর্ভুক্ত করুন: claims={"id_token":{"amr":{"essential":true}}} সেটিংস থেকে অবশ্যই চালু করতে হবে।
auth_time ব্যবহারকারীকে শেষবার কখন যাচাই করা হয়েছে সেই সময় জানতে চাওয়া। ID টোকেন উত্তরে auth_time ফিল্ড হিসেবে ফেরত পেতে, claims অনুরোধ প্যারামিটার অন্তর্ভুক্ত করুন: claims={"id_token":{"auth_time":{"essential":true}}} সেটিংস থেকে অবশ্যই চালু করতে হবে।
display (ঐচ্ছিক) ASCII স্ট্রিং ভ্যালু যা নির্দিষ্ট করে যে কীভাবে অথরাইজেশন সার্ভার যাচাইকরণ এবং সম্মতি সংক্রান্ত ইউজার ইন্টারফেস পৃষ্ঠাগুলি দেখায়। নিম্নলিখিত ভ্যালু নির্দিষ্ট করা আছে এবং Google সার্ভার দ্বারা গৃহীত, কিন্তু প্রোটোকল ফ্লো আচরণের উপর কোনও প্রভাব নেই: page, popup, touch এবং wap।
hd (ঐচ্ছিক)

Google Cloud সংস্থার মালিকানাধীন অ্যাকাউন্টের জন্য লগ-ইন প্রসেস স্ট্রিমলাইন করুন। Google Cloud সংস্থার ডোমেন (যেমন, mycollege.edu) অন্তর্ভুক্ত করার মাধ্যমে, আপনি ইঙ্গিত করতে পারেন যে অ্যাকাউন্ট বেছে নেওয়ার UI সেই ডোমেনের অ্যাকাউন্টের জন্য অপ্টিমাইজ করা উচিত। শুধুমাত্র একটি Google Cloud সংস্থার ডোমেনের পরিবর্তে সাধারণভাবে Google Cloud সংস্থার অ্যাকাউন্টের জন্য অপ্টিমাইজ করতে, একটি অ্যাস্টেরিস্ক (*) মান সেট করুন: hd=*।

আপনার অ্যাপ কে অ্যাক্সেস করতে পারবেন তা নিয়ন্ত্রণ করার জন্য এই UI অপ্টিমাইজেশনের উপর নির্ভর করবেন না, কারণ ক্লায়েন্ট-সাইড অনুরোধ পরিবর্তন করা যেতে পারে। ফেরত পাওয়া আইডি টোকেনে hd দাবি সংক্রান্ত ভ্যালু আছে কিনা তা যাচাই করে নিন, যা আপনার প্রত্যাশার সাথে মেলে (যেমন mycolledge.edu)। অনুরোধের প্যারামিটারের মতো, আইডি টোকেন hd দাবি Google-এর নিরাপত্তা টোকেনের মধ্যে থাকে, তাই এই ভ্যালু বিশ্বাসযোগ্য।

include_granted_scopes (ঐচ্ছিক) এই প্যারামিটারটি true ভ্যালুর সাথে প্রদান করা হলে এবং অনুমোদনের অনুরোধ মঞ্জুর করা হলে, অনুমোদনে অন্যান্য স্কোপের জন্য এই ব্যবহারকারী/অ্যাপ্লিকেশন কম্বিনেশনকে মঞ্জুর করা আগের যেকোনও অনুমোদন অন্তর্ভুক্ত থাকবে; ইনক্রিমেন্টাল অনুমোদন দেখুন।

মনে রাখবেন, ইনস্টল করা অ্যাপ ফ্লোতে আপনি ইনক্রিমেন্টাল অথরাইজেশন করতে পারবেন না।

login_hint (ঐচ্ছিক) আপনার অ্যাপ যখন জানতে পারে যে এটি কোন ব্যবহারকারীকে যাচাই করার চেষ্টা করছে, তখন এটি এই প্যারামিটারটি যাচাইকরণ সার্ভারের জন্য একটি ইঙ্গিত হিসাবে প্রদান করতে পারে। এই ইঙ্গিত পাস করলে অ্যাকাউন্ট বাছাইকারীকে দমন করে এবং সাইন-ইন ফর্মে ইমেল বক্স আগে থেকে পূরণ করে অথবা সঠিক সেশন বেছে নেয় (ব্যবহারকারী একাধিক সাইন-ইন ব্যবহার করলে), যা আপনার অ্যাপ ভুল ব্যবহারকারীর অ্যাকাউন্টে লগ-ইন করলে যে সমস্যা হয় তা এড়াতে সাহায্য করতে পারে। মানটি ইমেল আইডি বা sub স্ট্রিং হতে পারে, যা ব্যবহারকারীর Google আইডির সমতুল্য।
prompt (ঐচ্ছিক) স্পেস দিয়ে আলাদা করে লেখা স্ট্রিং ভ্যালুর তালিকা যা নির্দিষ্ট করে যে অথেন্টিকেশন সার্ভার ব্যবহারকারীকে আবার অথেন্টিকেশন ও সম্মতি দেওয়ার জন্য প্রম্পট করবে কিনা। সম্ভাব্য ভ্যালুগুলি হল:
  • none

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

  • consent

    ক্লায়েন্টকে তথ্য ফেরত দেওয়ার আগে অথরাইজেশন সার্ভার ব্যবহারকারীকে সম্মতি দেওয়ার জন্য প্রম্পট করে।

  • select_account

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

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

hl (ঐচ্ছিক) সাইন-ইন, অ্যাকাউন্ট বাছাইকারী এবং সম্মতি সংক্রান্ত স্ক্রিনের জন্য ডিসপ্লে ভাষা নির্দিষ্ট করতে BCP 47 ভাষা ট্যাগ ব্যবহার করা হয়। এই প্যারামিটার প্রদান করা না হলে, ডিফল্ট ভাষা হিসেবে ব্যবহারকারীর Google অ্যাকাউন্ট বা ব্রাউজার সেটিংসের ভাষা সেট করা হয়। যেমন, ব্রিটিশ ইংরেজিতে UI-এর জন্য অনুরোধ করতে, প্যারামিটারটি en-GB-এ সেট করুন।

আইডি টোকেন যাচাই করা

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

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

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

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

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

ID টোকেন যাচাই করার জন্য কয়েকটি ধাপ অনুসরণ করতে হয়:

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

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

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

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

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

ব্যবহারকারীর প্রোফাইল সংক্রান্ত তথ্য পাওয়া যাচ্ছে

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

  1. OpenID-কমপ্লায়েন্ট হতে হলে, আপনার যাচাইকরণের অনুরোধে openid profile স্কোপ ভ্যালু অন্তর্ভুক্ত করতে হবে।

    আপনি যদি ব্যবহারকারীর ইমেল আইডি অন্তর্ভুক্ত করতে চান, তাহলে আপনি email-এর অতিরিক্ত স্কোপ ভ্যালু নির্দিষ্ট করতে পারেন। profile এবং email, দুটিই নির্দিষ্ট করতে, আপনি নিজের যাচাইকরণ অনুরোধ URI-তে নিম্নলিখিত প্যারামিটার অন্তর্ভুক্ত করতে পারেন:

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

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

OpenID Connect প্রোটোকলের জন্য ব্যবহারকারীদের যাচাইকরণ করতে এবং টোকেন, ব্যবহারকারীর তথ্য ও সর্বজনীন কী সহ রিসোর্সের অনুরোধ করতে একাধিক এন্ডপয়েন্ট ব্যবহার করতে হয়।

প্রয়োগ করার পদ্ধতি সহজ করতে এবং আরও নমনীয়তা প্রদান করতে, OpenID Connect একটি "ডিসকভারি ডকুমেন্ট" ব্যবহার করার অনুমতি দেয়। এটি একটি JSON ডকুমেন্ট যা একটি সুপরিচিত লোকেশনে পাওয়া যায় এবং এতে কী-ভ্যালু পেয়ার থাকে। এই পেয়ারগুলি OpenID Connect প্রদানকারীর কনফিগারেশন সম্পর্কে বিস্তারিত তথ্য প্রদান করে, যার মধ্যে রয়েছে অথরাইজেশন, টোকেন, প্রত্যাহার, ব্যবহারকারীর তথ্য এবং পাবলিক-কী এন্ডপয়েন্টের URI। Google-এর OpenID Connect পরিষেবার জন্য ডিসকভারি ডকুমেন্ট এখান থেকে পাওয়া যেতে পারে:

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

Google-এর OpenID Connect পরিষেবা ব্যবহার করতে, আপনার অ্যাপ্লিকেশনে ডিসকভারি-ডকুমেন্ট URI (https://accounts.google.com/.well-known/openid-configuration) হার্ড-কোড করতে হবে। আপনার অ্যাপ্লিকেশন ডকুমেন্ট ফেচ করে, উত্তরে ক্যাশিং নিয়ম প্রয়োগ করে, তারপর প্রয়োজন অনুযায়ী এন্ডপয়েন্ট URI ফিরিয়ে আনে। যেমন, কোনও ব্যবহারকারীকে যাচাই করতে, আপনার কোড authorization_endpoint মেটাডেটা ভ্যালু (নিচের উদাহরণে https://accounts.google.com/o/oauth2/v2/auth) Google-এ পাঠানো যাচাইকরণ অনুরোধের জন্য বেস URI হিসেবে ফিরিয়ে আনবে।

এই ধরনের ডকুমেন্টের একটি উদাহরণ এখানে দেওয়া হল; ফিল্ডের নামগুলি OpenID Connect Discovery 1.0-এ উল্লেখ করা আছে (সেগুলির অর্থ জানতে সেই ডকুমেন্ট দেখুন)। এই ভ্যালুগুলি শুধুমাত্র উদাহরণ হিসেবে দেখানো হয়েছে এবং এগুলি পরিবর্তন হতে পারে, যদিও এগুলি আসল Google Discovery ডকুমেন্টের সাম্প্রতিক ভার্সন থেকে কপি করা হয়েছে:

{
  "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"
  ]
}

ডিসকভারি ডকুমেন্ট থেকে ভ্যালু ক্যাশে করার মাধ্যমে আপনি HTTP রাউন্ড-ট্রিপ এড়াতে পারবেন। স্ট্যান্ডার্ড HTTP ক্যাশিং হেডার ব্যবহার করা হয় এবং এটি মেনে চলা উচিত।

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

নিম্নলিখিত ক্লায়েন্ট লাইব্রেরিগুলি জনপ্রিয় ফ্রেমওয়ার্কের সাথে ইন্টিগ্রেট করে OAuth 2.0 প্রয়োগ করা আরও সহজ করে তোলে:

OpenID Connect সম্মতি

Google-এর OAuth 2.0 যাচাইকরণ সিস্টেম OpenID Connect Core স্পেসিফিকেশনের প্রয়োজনীয় ফিচার সাপোর্ট করে। OpenID Connect-এর সাথে কাজ করার জন্য ডিজাইন করা যেকোনও ক্লায়েন্টকে এই পরিষেবার সাথে ইন্টারঅপারেট করতে হবে (OpenID অনুরোধ অবজেক্ট ব্যতীত)।