OpenID কানেক্ট

Google's OAuth 2.0 APIs can be used for both authentication and authorization. This document describes our OAuth 2.0 implementation for authentication, which conforms to the OpenID Connect specification, and is OpenID Certified . The documentation found in Using OAuth 2.0 to Access Google APIs also applies to this service. If you want to explore this protocol interactively, we recommend the Google OAuth 2.0 Playground . To get help on Stack Overflow , tag your questions with 'google-oauth'.

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

Before your application can use Google's OAuth 2.0 authentication system for user login, you must set up a project in the Google Cloud Console to obtain OAuth 2.0 credentials, set a redirect URI, and (optionally) customize the branding information that your users see on the user-consent screen. You can also use the Cloud Console to create a service account, enable billing, set up filtering, and do other tasks. For more details, see the Google Cloud Console Help .

OAuth 2.0 ক্রেডেনশিয়াল সংগ্রহ করুন।

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

কোনো নির্দিষ্ট OAuth 2.0 ক্রেডেনশিয়ালের ক্লায়েন্ট আইডি এবং ক্লায়েন্ট সিক্রেট দেখতে, 'Select credential' লেখাটিতে ক্লিক করুন। যে উইন্ডোটি খুলবে, সেখানে আপনার প্রজেক্ট এবং কাঙ্ক্ষিত ক্রেডেনশিয়ালটি বেছে নিন, তারপর 'View'-তে ক্লিক করুন।

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

1. ক্লায়েন্ট পৃষ্ঠায় যান।
2. আপনার ক্লায়েন্টের নামে অথবা সম্পাদনা ( create ) আইকনে ক্লিক করুন। আপনার ক্লায়েন্ট আইডি এবং সিক্রেট পেজের উপরে রয়েছে।

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

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

প্রদত্ত কোনো OAuth 2.0 ক্রেডেনশিয়ালের জন্য রিডাইরেক্ট ইউআরআই তৈরি, দেখা বা সম্পাদনা করতে, নিম্নলিখিতগুলি করুন:

1. ক্লায়েন্ট পৃষ্ঠায় যান।
2. ক্লায়েন্টে ক্লিক করুন।
3. রিডাইরেক্ট ইউআরআইগুলো দেখুন বা সম্পাদনা করুন।

যদি ক্লায়েন্টস পেজে কোনো ক্লায়েন্ট তালিকাভুক্ত না থাকে, তাহলে আপনার প্রোজেক্টে কোনো OAuth ক্রেডেনশিয়াল নেই। একটি তৈরি করতে, ক্রিয়েট ক্লায়েন্ট-এ ক্লিক করুন।

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

For your users, the OAuth 2.0 authentication experience includes a consent screen that describes the information that the user is releasing and the terms that apply. For example, when the user logs in, they might be asked to give your app access to their email address and basic account information. You request access to this information using the scope parameter, which your app includes in its authentication request . You can also use scopes to request access to other Google APIs.

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

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

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

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

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

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

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

ব্যবহারকারীকে প্রমাণীকরণ করা হচ্ছে

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

The most commonly used approaches for authenticating a user and obtaining an ID token are called the "server" flow and the "implicit" flow. The server flow allows the backend server of an application to verify the identity of the person using a browser or mobile device. The implicit flow is used when a client-side application (typically a JavaScript app running in the browser) needs to access APIs directly instead of using its backend server.

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

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

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

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

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

You must protect the security of your users by preventing request forgery attacks. The first step is creating a unique session token that holds state between your app and the user's client. You later match this unique session token with the authentication response returned by the Google OAuth Login service to verify that the user is making the request and not a malicious attacker. These tokens are often referred to as cross-site request forgery ( CSRF ) tokens.

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

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

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

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

# 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))

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

The next step is forming an HTTPS GET request with the appropriate URI parameters. Note the use of HTTPS rather than HTTP in all the steps of this process; HTTP connections are refused. You should retrieve the base URI from the Discovery document using the authorization_endpoint metadata value. The following discussion assumes the base URI is https://accounts.google.com/o/oauth2/v2/auth .

একটি সাধারণ অনুরোধের জন্য, নিম্নলিখিত প্যারামিটারগুলো উল্লেখ করুন:

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

The response includes a code parameter, a one-time authorization code that your server can exchange for an access token and ID token. Your server makes this exchange by sending an HTTPS POST request. The POST request is sent to the token endpoint, which you should retrieve from the Discovery document using the token_endpoint metadata value. The following discussion assumes the endpoint is https://oauth2.googleapis.com/token . The request must include the following parameters in the POST body:

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

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 অ্যারেতে নিম্নলিখিত ফিল্ডগুলি থাকে:

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

An ID Token is a JWT (JSON Web Token), that is, a cryptographically signed Base64-encoded JSON object. Normally, it is critical that you validate an ID token before you use it, but since you are communicating directly with Google over an intermediary-free HTTPS channel and using your client secret to authenticate yourself to Google, you can be confident that the token you receive really comes from Google and is valid. If your server passes the ID token to other components of your app, it is extremely important that the other components validate the token before using it.

যেহেতু বেশিরভাগ এপিআই লাইব্রেরি বেস৬৪ইউআরএল-এনকোডেড ভ্যালু ডিকোড করা এবং এর ভেতরের 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"
}

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

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

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

If the user does not exist in your user database, you should redirect the user to your new-user sign-up flow. You may be able to auto-register the user based on the information you receive from Google, or at the very least you may be able to pre-populate many of the fields that you require on your registration form. In addition to the information in the ID token, you can get additional user profile information at our user profile endpoints.

উন্নত বিষয়সমূহ

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

অন্যান্য গুগল এপিআই-গুলিতে অ্যাক্সেস

One of the advantages of using OAuth 2.0 for authentication is that your application can get permission to use other Google APIs on behalf of the user (such as YouTube, Google Drive, Calendar, or Contacts) at the same time as you authenticate the user. To do this, include the other scopes that you need in the authentication request that you send to Google. For example, to add user's age group to your authentication request, pass a scope parameter of openid email https://www.googleapis.com/auth/profile.agerange.read . The user is prompted appropriately on the consent screen . The access token that you receive back from Google will let your application access all the APIs related to the scopes of access you requested and were granted.

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

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

বিবেচ্য বিষয়সমূহ:

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

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

পুনরায় সম্মতির জন্য অনুরোধ করা

You can prompt the user to re-authorize your app by setting the prompt parameter to consent in your authentication request . When prompt=consent is included, the consent screen is displayed every time your app requests authorization of scopes of access, even if all scopes were previously granted to your Google APIs project. For this reason, include prompt=consent only when necessary.

prompt প্যারামিটার সম্পর্কে আরও জানতে, অথেনটিকেশন ইউআরআই প্যারামিটার টেবিলের prompt দেখুন।

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

নিচের সারণিতে গুগলের OAuth 2.0 অথেনটিকেশন এপিআই দ্বারা গৃহীত প্যারামিটারগুলোর আরও পূর্ণাঙ্গ বিবরণ দেওয়া হয়েছে।

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

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

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

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

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

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

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

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

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

The first step is more complex, and involves cryptographic signature checking. For debugging purposes, you can use Google's tokeninfo endpoint to compare against local processing implemented on your server or device. Suppose your ID token's value is XYZ123 . Then you would dereference the URI https://oauth2.googleapis.com/tokeninfo?id_token= XYZ123 . If the token signature is valid, the response would be the JWT payload in its decoded JSON object form.

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

Since Google changes its public keys only infrequently, you can cache them using the cache directives of the HTTP response and, in the vast majority of cases, perform local validation much more efficiently than by using the tokeninfo endpoint. This validation requires retrieving and parsing certificates, and making the appropriate cryptographic calls to check the signature. Fortunately, there are well-debugged libraries available in a wide variety of languages to accomplish this (see jwt.io ).

Obtaining user profile information

To obtain additional profile information about the user, you can use the access token (which your application receives during the authentication flow ) and the OpenID Connect standard:

1. To be OpenID-compliant, you must include the openid profile scope values in your authentication request .

   If you want the user's email address to be included, you can specify an additional scope value of email . To specify both profile and email , you can include the following parameter in your authentication request URI:

   scope=openid%20profile%20email

2. Add your access token to the authorization header and make an HTTPS GET request to the userinfo endpoint, which you should retrieve from the Discovery document using the userinfo_endpoint metadata value. The userinfo response includes information about the user, as described in OpenID Connect Standard Claims and the claims_supported metadata value of the Discovery document. Users or their organizations may choose to supply or withhold certain fields, so you might not get information for every field for your authorized scopes of access.

The Discovery document

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:

• Google APIs Client Library for Java
• Google APIs Client Library for Python
• Google APIs Client Library for .NET
• Google APIs Client Library for Ruby
• Google APIs Client Library for PHP
• OAuth 2.0 Library for Google Web Toolkit
• Google Toolbox for Mac OAuth 2.0 Controllers

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 ).