OpenID কানেক্ট

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

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

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

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

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

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

要查看给定OAuth 2.0凭据的客户端ID和客户端密钥，请单击以下文本： 选择凭据 。在打开的窗口中，选择您的项目和所需的凭证，然后单击“ 查看” 。

或者，从API Console的“ 凭据”页面中查看您的客户端ID和客户端密钥：

  1. Go to the Credentials page.
  2. 单击您的凭证名称或铅笔（ ）图标。您的客户ID和密码位于页面顶部。

একটি রিডাইরেক্ট ইউআরআই সেট করুন

রিডাইরেক্ট ইউআরআই যা আপনি সেট করেছেন API Console Google আপনার প্রমাণীকরণ অনুরোধের প্রতিক্রিয়া কোথায় পাঠাবে তা নির্ধারণ করে।

要创建，查看或编辑给定OAuth 2.0凭据的重定向URI，请执行以下操作：

  1. Go to the Credentials page.
  2. 在页面的OAuth 2.0客户端ID部分中，点击一个凭据。
  3. 查看或编辑重定向URI。

如果“凭据”页面上没有OAuth 2.0客户端ID部分，则您的项目没有OAuth凭据。要创建一个，点击创建凭证 。

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

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

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

আপনার প্রকল্পের সম্মতি পর্দা সক্ষম করতে:

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

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

সম্মতি পৃষ্ঠার স্ক্রিন শট

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

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

আপনি যদি একটি লাইব্রেরি ব্যবহার না করা বেছে নেন, তাহলে এই নথির বাকি নির্দেশাবলী অনুসরণ করুন, যা উপলব্ধ লাইব্রেরিগুলির অন্তর্নিহিত HTTP অনুরোধের প্রবাহকে বর্ণনা করে৷

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

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

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

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

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

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

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

1. একটি জালিয়াতি বিরোধী রাষ্ট্র টোকেন তৈরি করুন৷

অনুরোধ জালিয়াতি আক্রমণ প্রতিরোধ করে আপনাকে অবশ্যই আপনার ব্যবহারকারীদের নিরাপত্তা রক্ষা করতে হবে। প্রথম ধাপ হল একটি অনন্য সেশন টোকেন তৈরি করা যা আপনার অ্যাপ এবং ব্যবহারকারীর ক্লায়েন্টের মধ্যে অবস্থা ধারণ করে। আপনি পরে এই অনন্য সেশন টোকেনটি 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
));

জাভা

এই নমুনাটি ব্যবহার করার জন্য আপনাকে অবশ্যই 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);

পাইথন

এই নমুনা ব্যবহার করার জন্য আপনাকে পাইথনের জন্য 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))

2. Google-এ একটি প্রমাণীকরণ অনুরোধ পাঠান৷

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

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

  • client_id , যা আপনি থেকে পাবেন API ConsoleCredentials page.
  • response_type , যা একটি মৌলিক অনুমোদন কোড ফ্লো অনুরোধ code হওয়া উচিত। ( response_type এ আরও পড়ুন।)
  • scope , যা একটি মৌলিক অনুরোধে openid email হওয়া উচিত। ( scope আরও পড়ুন।)
  • redirect_uri আপনার সার্ভারে HTTP এন্ডপয়েন্ট হওয়া উচিত যা Google থেকে প্রতিক্রিয়া পাবে। মানটি অবশ্যই OAuth 2.0 ক্লায়েন্টের জন্য অনুমোদিত রিডাইরেক্ট ইউআরআইগুলির একটির সাথে মিলতে হবে, যা আপনি কনফিগার করেছেন API ConsoleCredentials page. যদি এই মানটি একটি অনুমোদিত URI-এর সাথে মেলে না, তাহলে অনুরোধটি একটি redirect_uri_mismatch ত্রুটির সাথে ব্যর্থ হবে৷
  • state জালিয়াতি বিরোধী অনন্য সেশন টোকেনের মান অন্তর্ভুক্ত করা উচিত, সেইসাথে ব্যবহারকারী যখন আপনার অ্যাপ্লিকেশনে ফিরে আসে তখন প্রসঙ্গ পুনরুদ্ধারের জন্য প্রয়োজনীয় অন্য যেকোন তথ্য, যেমন, প্রারম্ভিক URL। ( state আরও পড়ুন।)
  • nonce হল আপনার অ্যাপের দ্বারা উত্পন্ন একটি র্যান্ডম মান যা উপস্থিত থাকলে রিপ্লে সুরক্ষা সক্ষম করে৷
  • login_hint ব্যবহারকারীর ইমেল ঠিকানা বা sub স্ট্রিং হতে পারে, যা ব্যবহারকারীর Google ID-এর সমতুল্য। আপনি যদি login_hint প্রদান না করেন এবং ব্যবহারকারী বর্তমানে লগ ইন করে থাকেন, তাহলে সম্মতি স্ক্রিনে আপনার অ্যাপে ব্যবহারকারীর ইমেল ঠিকানা প্রকাশ করার জন্য অনুমোদনের অনুরোধ অন্তর্ভুক্ত থাকে। ( login_hint আরও পড়ুন।)
  • একটি Google Workspace বা ক্লাউড সংস্থার সাথে যুক্ত একটি নির্দিষ্ট ডোমেনের ব্যবহারকারীদের জন্য 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

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

3. জালিয়াতি বিরোধী রাষ্ট্র টোকেন নিশ্চিত করুন

প্রতিক্রিয়াটি 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 ধাপ 1 এ আপনার তৈরি করা সেশন টোকেনের সাথে মেলে। এই রাউন্ড-ট্রিপ যাচাইকরণ নিশ্চিত করতে সাহায্য করে যে ব্যবহারকারী, একটি দূষিত স্ক্রিপ্ট নয়, অনুরোধটি করছে৷

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

পিএইচপি

এই নমুনা ব্যবহার করার জন্য আপনাকে 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 এর জন্য 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.");
}

পাইথন

এই নমুনা ব্যবহার করার জন্য আপনাকে পাইথনের জন্য 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

4. এক্সচেঞ্জ টোকেন এবং আইডি টোকেনের জন্য code বিনিময় করুন

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

ক্ষেত্র
code প্রারম্ভিক অনুরোধ থেকে ফেরত দেওয়া হয় যে অনুমোদন কোড.
client_id আপনি যে ক্লায়েন্ট আইডি থেকে পাবেন API ConsoleCredentials page, OAuth 2.0 প্রাপ্ত শংসাপত্রে বর্ণিত হিসাবে।
client_secret ক্লায়েন্ট সিক্রেট যে আপনি থেকে প্রাপ্ত API ConsoleCredentials page, OAuth 2.0 প্রাপ্ত শংসাপত্রে বর্ণিত হিসাবে।
redirect_uri প্রদত্ত client_id -তে নির্দিষ্ট করা একটি অনুমোদিত পুনঃনির্দেশ URI API ConsoleCredentials page, একটি পুনঃনির্দেশ URI সেট করুন তে বর্ণিত হিসাবে।
grant_type OAuth 2.0 স্পেসিফিকেশনে সংজ্ঞায়িত এই ক্ষেত্রটিতে authorization_code এর একটি মান থাকতে হবে।

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

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 সেট করা থাকে। বিস্তারিত জানার জন্য, রিফ্রেশ টোকেন দেখুন।

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

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

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

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

একটি আইডি টোকেন হল একটি 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 আইডি টোকেনগুলিতে নিম্নলিখিত ক্ষেত্রগুলি থাকতে পারে ( দাবি হিসাবে পরিচিত):

দাবি প্রদান করা হয়েছে বর্ণনা
aud সর্বদা এই আইডি টোকেন যে দর্শকদের উদ্দেশ্যে করা হয়েছে। এটি অবশ্যই আপনার অ্যাপ্লিকেশনের OAuth 2.0 ক্লায়েন্ট আইডিগুলির একটি হতে হবে৷
exp সর্বদা মেয়াদ শেষ হওয়ার সময় বা তার পরে আইডি টোকেন গ্রহণ করা উচিত নয়। ইউনিক্স সময় (পূর্ণসংখ্যা সেকেন্ড) প্রতিনিধিত্ব করে।
iat সর্বদা আইডি টোকেন ইস্যু করার সময়। ইউনিক্স সময় (পূর্ণসংখ্যা সেকেন্ড) প্রতিনিধিত্ব করে।
iss সর্বদা প্রতিক্রিয়া প্রদানকারীর জন্য ইস্যুকারী শনাক্তকারী। Google ID টোকেনের জন্য সর্বদা https://accounts.google.com বা accounts.google.com ।
sub সর্বদা ব্যবহারকারীর জন্য একটি শনাক্তকারী, সমস্ত Google অ্যাকাউন্টের মধ্যে অনন্য এবং কখনও পুনরায় ব্যবহার করা হয় না। একটি Google অ্যাকাউন্টের বিভিন্ন সময়ে একাধিক ইমেল ঠিকানা থাকতে পারে, কিন্তু sub মানটি কখনই পরিবর্তন হয় না। ব্যবহারকারীর জন্য অনন্য-শনাক্তকারী কী হিসাবে আপনার অ্যাপ্লিকেশনের মধ্যে sub ব্যবহার করুন। সর্বাধিক দৈর্ঘ্য 255 কেস-সংবেদনশীল ASCII অক্ষর।
at_hash টোকেন হ্যাশ অ্যাক্সেস করুন। বৈধতা প্রদান করে যে অ্যাক্সেস টোকেনটি পরিচয় টোকেনের সাথে আবদ্ধ। যদি আইডি টোকেন সার্ভারের প্রবাহে access_token মান দিয়ে জারি করা হয় তবে এই দাবিটি সর্বদা অন্তর্ভুক্ত থাকে। এই দাবিটি ক্রস-সাইট অনুরোধ জালিয়াতি আক্রমণ থেকে রক্ষা করার জন্য একটি বিকল্প প্রক্রিয়া হিসাবে ব্যবহার করা যেতে পারে, তবে আপনি যদি ধাপ 1 এবং ধাপ 3 অনুসরণ করেন তবে অ্যাক্সেস টোকেন যাচাই করার প্রয়োজন নেই।
azp অনুমোদিত উপস্থাপকের client_id । এই দাবিটি তখনই প্রয়োজন যখন আইডি টোকেনের অনুরোধকারী দলটি আইডি টোকেনের দর্শকদের মতো নয়৷ এটি হাইব্রিড অ্যাপের ক্ষেত্রে Google-এর ক্ষেত্রে হতে পারে যেখানে একটি ওয়েব অ্যাপ্লিকেশন এবং অ্যান্ড্রয়েড অ্যাপের আলাদা OAuth 2.0 client_id থাকে কিন্তু একই Google API-এর প্রকল্প শেয়ার করে।
email ব্যবহারকারীর ইমেইল ঠিকানা. আপনি যদি আপনার অনুরোধে email সুযোগ অন্তর্ভুক্ত করেন তবেই প্রদান করা হয়। এই দাবির মান এই অ্যাকাউন্টের জন্য অনন্য নাও হতে পারে এবং সময়ের সাথে সাথে পরিবর্তিত হতে পারে, তাই আপনার ব্যবহারকারীর রেকর্ডে লিঙ্ক করার জন্য এই মানটিকে প্রাথমিক শনাক্তকারী হিসাবে ব্যবহার করা উচিত নয়। এছাড়াও আপনি Google Workspace বা ক্লাউড সংস্থার ব্যবহারকারীদের শনাক্ত করার জন্য email দাবির ডোমেনের উপর নির্ভর করতে পারবেন না; পরিবর্তে hd দাবি ব্যবহার করুন।
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 দাবি উপস্থিত থাকে, আপনি আপনার অ্যাপের ব্যবহারকারীর রেকর্ড আপডেট করতে সেগুলি ব্যবহার করতে পারেন৷ মনে রাখবেন যে এই দাবিটি কখনই উপস্থিত থাকার নিশ্চয়তা দেয় না।

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

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

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

উন্নত বিষয়

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

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

প্রমাণীকরণের জন্য OAuth 2.0 ব্যবহার করার সুবিধাগুলির মধ্যে একটি হল যে আপনার অ্যাপ্লিকেশন ব্যবহারকারীর পক্ষে (যেমন YouTube, Google ড্রাইভ, ক্যালেন্ডার, বা পরিচিতি) একই সময়ে ব্যবহারকারীকে প্রমাণীকরণ করার জন্য অন্যান্য Google API ব্যবহার করার অনুমতি পেতে পারে৷ এটি করার জন্য, আপনি 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 (প্রয়োজনীয়) ক্লায়েন্ট আইডি স্ট্রিং যা আপনি থেকে পাবেন API ConsoleCredentials page, OAuth 2.0 প্রাপ্ত শংসাপত্রে বর্ণিত হিসাবে।
nonce (প্রয়োজনীয়) আপনার অ্যাপ দ্বারা উত্পন্ন একটি র্যান্ডম মান যা রিপ্লে সুরক্ষা সক্ষম করে৷
response_type (প্রয়োজনীয়) যদি মানটি code হয়, তাহলে একটি বেসিক অনুমোদন কোড প্রবাহ চালু করে, টোকেনগুলি পাওয়ার জন্য টোকেন এন্ডপয়েন্টে একটি POST প্রয়োজন৷ মানটি token id_token বা id_token token হলে, একটি অন্তর্নিহিত প্রবাহ চালু করে, URI #fragment শনাক্তকারী থেকে টোকেন পুনরুদ্ধার করার জন্য পুনঃনির্দেশ URI-এ JavaScript ব্যবহার করতে হবে।
redirect_uri (প্রয়োজনীয়) প্রতিক্রিয়া কোথায় পাঠানো হবে তা নির্ধারণ করে। এই প্যারামিটারের মানটি অবশ্যই আপনার দ্বারা সেট করা অনুমোদিত পুনঃনির্দেশ মানগুলির একটির সাথে হুবহু মিলতে হবে৷ API ConsoleCredentials page (HTTP বা HTTPS স্কিম, কেস, এবং ট্রেলিং '/' সহ, যদি থাকে)।
scope (প্রয়োজনীয়)

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

profile স্কোপের মান উপস্থিত থাকলে, আইডি টোকেন ব্যবহারকারীর ডিফল্ট profile দাবিগুলি অন্তর্ভুক্ত করতে পারে (কিন্তু নিশ্চিত নয়)।

যদি email স্কোপের মান উপস্থিত থাকে, তাহলে আইডি টোকেনে email এবং email_verified দাবি অন্তর্ভুক্ত থাকে।

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

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

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

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

মনে রাখবেন যে আপনি ইনস্টল করা অ্যাপ প্রবাহের সাথে ক্রমবর্ধমান অনুমোদন করতে পারবেন না।

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

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

  • consent

    অনুমোদন সার্ভার ক্লায়েন্টের কাছে তথ্য ফেরত দেওয়ার আগে ব্যবহারকারীকে সম্মতির জন্য অনুরোধ করে।

  • select_account

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

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

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

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

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

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

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

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

একটি আইডি টোকেনের বৈধতার জন্য কয়েকটি পদক্ষেপের প্রয়োজন:

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

ধাপ 2 থেকে 5 শুধুমাত্র স্ট্রিং এবং তারিখ তুলনা জড়িত যা বেশ সহজবোধ্য, তাই আমরা সেগুলি এখানে বিস্তারিত করব না।

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

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

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

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

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

{
  "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 কানেক্ট কোর স্পেসিফিকেশনের প্রয়োজনীয় বৈশিষ্ট্যগুলিকে সমর্থন করে৷ OpenID Connect-এর সাথে কাজ করার জন্য ডিজাইন করা যেকোন ক্লায়েন্টকে এই পরিষেবার সাথে ইন্টারঅপারেটিং করা উচিত ( OpenID Request Object বাদ দিয়ে)।