‫Google برای ترجمه محتوا به زبان ترجیحی شما از فناوری هوشواره استفاده می‌کند. ترجمه‌های هوشواره‌ای ممکن است اشتباه داشته باشند.

OpenID Connect

از میاناهای برنامه‌سازی کاربردی OAuth 2.0 در Google می‌توان هم برای اصالت‌سنجی و هم برای صدور مجوز استفاده کرد. این سند پیاده‌سازی OAuth 2.0 ما را برای اصالت‌سنجی شرح می‌دهد که با مشخصات OpenID Connect مطابقت دارد و دارای گواهینامه OpenID است. مستندات موجود در استفاده از OAuth 2.0 برای دسترسی به Google APIs بر این سرویس نیز اعمال می‌شود. اگر می‌خواهید این پروتکل را به‌صورت تعاملی کاوش کنید، 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 مشاهده کنید:

به صفحه کارخواهان بروید.
روی نام مشتری یا نماد ویرایش () کلیک کنید. شناسه و رمز کارخواه شما در بالای صفحه قرار دارد.

تنظیم URI هدایت

URI هدایت که در Cloud Console تنظیم می‌کنید تعیین می‌کند Google پاسخ‌های مربوط به درخواست‌های اصالت‌سنجی شما را به کجا ارسال کند.

برای ایجاد، مشاهده، یا ویرایش URIهای هدایت برای اعتبارنامه OAuth 2.0، کارهای زیر را انجام دهید:

به صفحه کارخواهان بروید.
روی کارخواه کلیک کنید.
شناسه‌های منبع یکسان هدایت را مشاهده یا ویرایش کنید.

اگر کارخواهی در صفحه «کارخواهان» فهرست نشده باشد، پروژه شما اعتبارنامه OAuth ندارد. برای ایجاد کردن آن، روی ایجاد کردن کارخواه کلیک کنید.

سفارشی‌سازی صفحه رضایت کاربر

برای کاربران شما، تجربه اصالت‌سنجی OAuth 2.0 شامل صفحه رضایت است که اطلاعاتی را که کاربر منتشر می‌کند و شرایطی را که اعمال می‌شود شرح می‌دهد. برای مثال، وقتی کاربر به سیستم وارد می‌شود، ممکن است از او خواسته شود به برنامه‌تان اجازه دهد به نشانی ایمیل و اطلاعات پایه حسابش دسترسی داشته باشد. بااستفاده از پارامتر scope که برنامه‌تان در درخواست اصالت‌سنجی خود لحاظ می‌کند، دسترسی به این اطلاعات را درخواست می‌کنید. همچنین می‌توانید از دامنه‌ها برای درخواست دسترسی به دیگر Google APIها استفاده کنید.

صفحه رضایت کاربر همچنین اطلاعات نمانام‌سازی مانند نام محصول، نشان‌واره، و نشانی وب صفحه اصلی را ارائه می‌دهد. شما اطلاعات نمانام‌سازی را در «کنسول Cloud» کنترل می‌کنید.

برای فعال کردن صفحه رضایت پروژه:

صفحه نمانام‌سازی را در «کنسول Google Cloud» باز کنید.
درصورت درخواست، پروژه‌ای را انتخاب کنید یا پروژه جدیدی ایجاد کنید.
فرم را تکمیل کنید و روی ذخیره کلیک کنید.

کادر گفتگوی رضایت زیر نشان می‌دهد که کاربر چه چیزی را می‌بیند وقتی که ترکیبی از OAuth 2.0 و دامنه‌های Google Drive در درخواست وجود دارد. (این کادر گفتگوی عمومی بااستفاده از Google OAuth 2.0 Playground تولید شده است، بنابراین شامل اطلاعات نمانامی که در Cloud Console تنظیم می‌شود نیست.)

نمونه‌ای از صفحه رضایت — **شکل ۱.** نماگرفت صفحه رضایت

دسترسی به سرویس

Google و اشخاص ثالث کتابخانه‌هایی ارائه می‌دهند که می‌توانید از آن‌ها برای رسیدگی به بسیاری از جزئیات پیاده‌سازی اصالت‌سنجی کاربران و دسترسی به میاناهای برنامه‌سازی کاربردی Google استفاده کنید. نمونه‌هایی از این ابزارها عبارتند از سرویس‌های مدیریت هویت‌سنجی Google و کتابخانه‌های کارخواه Google که برای پلاتفرم‌های مختلفی دردسترس هستند.

اگر انتخاب می‌کنید که از کتابخانه استفاده نکنید، دستورالعمل‌های باقی‌مانده این سند را دنبال کنید که جریان‌های درخواست HTTP را که زیربنای کتابخانه‌های دردسترس هستند شرح می‌دهد.

درحال اصالت‌سنجی کاربر

اصالت‌سنجی کاربر شامل دریافت یک کد شناسه و اعتبارسنجی آن است. نشان‌های شناسه یکی از ویژگی‌های استانداردشده OpenID Connect است که برای استفاده در هم‌رسانی ادعاهای هویتی در اینترنت طراحی شده است.

رایج‌ترین رویکردها برای اصالت‌سنجی کاربر و دریافت شناسه ژتون، جریان «سرور» و جریان «ضمنی» نامیده می‌شوند. جریان سرور به سرور زیرینه برنامه اجازه می‌دهد هویت فردی را که از مرورگر یا دستگاه همراه استفاده می‌کند درستی‌سنجی کند. جریان ضمنی زمانی استفاده می‌شود که یک برنامه سمت کارخواه (معمولاً یک برنامه جاوا اسکریپت که در مرورگر اجرا می‌شود) نیاز دارد مستقیماً به میاناهای برنامه‌سازی کاربردی دسترسی داشته باشد، به‌جای اینکه از سرور زیرینه خود استفاده کند.

این سند نحوه اجرای جریان سرور برای اصالت‌سنجی کاربر را شرح می‌دهد. جریان ضمنی به‌دلیل خطرات امنیتی در مدیریت و استفاده از نشان‌ها در سمت کارخواه، به‌طور قابل‌توجهی پیچیده‌تر است. اگر لازم است جریان ضمنی را پیاده‌سازی کنید، اکیداً توصیه می‌کنیم از سرویس‌های مدیریت هویت‌سنجی Google استفاده کنید.

جریان سرور

مطمئن شوید برنامه‌تان را در Cloud Console راه‌اندازی کرده‌اید تا بتواند از این پروتکل‌ها استفاده کند و کاربران شما را اصالت‌سنجی کند. وقتی کاربری می‌خواهد با Google به سیستم وارد شود، باید:

ایجاد کردن توکن حالت ضدجعل
ارسال درخواست اصالت‌سنجی به Google
تأیید کردن کد حالت ضدجعل
تبدیل code به کد دسترسی و کد شناسه
دریافت اطلاعات کاربر از شناسه رمزه
اصالت‌سنجی کاربر

۱. ایجاد کردن یک توکن حالت ضدجعل

باید با جلوگیری از حملات جعل درخواست، از امنیت کاربران خود محافظت کنید. اولین قدم ایجاد یک کد جلسه منحصربه‌فرد است که وضعیت را بین برنامه شما و کارخواه کاربر نگه می‌دارد. بعداً این کد جلسه منحصربه‌فرد را با پاسخ اصالت‌سنجی برگردانده‌شده توسط سرویس «ورود به سیستم Google OAuth» مطابقت می‌دهید تا تأیید کنید که کاربر درخواست را ارسال می‌کند و نه یک مهاجم مخرب. به این توکن‌ها اغلب توکن‌های جعل درخواست بین‌سایتی (CSRF) گفته می‌شود.

یک انتخاب خوب برای توکن حالت، رشته‌ای از حدود ۳۰ نویسه است که بااستفاده از تولیدکننده عدد تصادفی با کیفیت بالا ساخته شده است. دیگری درهم‌سازی است که با امضای برخی‌از متغیرهای وضعیت جلسه شما با کلیدی که در باطن شما مخفی نگه داشته می‌شود تولید می‌شود.

کد زیر نحوه تولید کردن کد جلسه یکتا را نشان می‌دهد.

PHP

برای استفاده از این نمونه، باید کتابخانه کارخواه Google APIs برای PHP را بارگیری کنید.

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

جاوا

برای استفاده از این نمونه، باید کتابخانه کارخواه Google APIs برای Java را بارگیری کنید.

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

Python

برای استفاده از این نمونه، باید کتابخانه کارخواه Google APIs برای Python را بارگیری کنید.

# 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

مرحله بعدی تشکیل درخواست HTTPS GET با پارامترهای URI مناسب است. توجه داشته باشید که در تمام مراحل این فرایند از HTTPS به‌جای HTTP استفاده می‌شود؛ اتصالات HTTP رد می‌شوند. باید URI پایه را از سند اکتشاف بااستفاده از مقدار فراداده authorization_endpoint بازیابی کنید. بحث زیر فرض می‌کند که شناسه منبع یکسان پایه 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 دریافت می‌کند. این مقدار باید دقیقاً با یکی از URIهای هدایت مجاز برای کارخواه OAuth 2.0 که در صفحه «اطلاعات کاربری Cloud Console» پیکربندی کرده‌اید مطابقت داشته باشد. اگر این مقدار با URI مجاز مطابقت نداشته باشد، درخواست با خطای redirect_uri_mismatch ناموفق خواهد بود.
state باید شامل مقدار کد جلسه منحصربه‌فرد ضدجعل، و همچنین هر اطلاعات دیگری باشد که برای بازیابی بافت هنگام بازگشت کاربر به برنامه‌تان لازم است، مثلاً نشانی وب شروع. (اطلاعات بیشتر در state.)
nonce مقداری تصادفی است که توسط برنامه‌تان تولید می‌شود و درصورت وجود، محافظت دربرابر بازپخش را فعال می‌کند.
login_hint می‌تواند نشانی ایمیل کاربر یا رشته sub باشد که معادل شناسه Google کاربر است. اگر login_hint ارائه نکنید و کاربر به سیستم وارد شده باشد، صفحه رضایت شامل درخواستی برای تأیید انتشار نشانی ایمیل کاربر در برنامه شما است. (در login_hint بیشتر بخوانید.)
از پارامتر hd برای بهینه‌سازی جریان OpenID Connect برای کاربران دامنه خاصی که با سازمان Google Workspace یا Cloud مرتبط است استفاده کنید (در hd بیشتر بخوانید).

در اینجا مثالی از URI اصالت‌سنجی کامل OpenID Connect آورده شده است که برای خوانایی بیشتر، شکست خط و فاصله دارد:

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 دریافتی از Google با کد جلسه ایجادشده در مرحله ۱ مطابقت دارد. این درستی‌سنجی رفت‌وبرگشت کمک می‌کند تأیید شود که کاربر درخواست را ارسال می‌کند، نه یک اسکریپت مخرب.

کد زیر تأیید کردن کد جلسه را که در مرحله ۱ ایجاد کردید نشان می‌دهد:

PHP

برای استفاده از این نمونه، باید کتابخانه کارخواه Google APIs برای PHP را بارگیری کنید.

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

جاوا

برای استفاده از این نمونه، باید کتابخانه کارخواه Google APIs برای Java را بارگیری کنید.

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

برای استفاده از این نمونه، باید کتابخانه کارخواه Google APIs برای Python را بارگیری کنید.

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

۴. تبدیل `code` به کد دسترسی و کد شناسه

پاسخ شامل پارامتر code است، کد مجوز یک‌باره‌ای که سرور شما می‌تواند با کد دسترسی و کد شناسه معاوضه کند. سرور شما این تبادل را با ارسال درخواست HTTPS POST انجام می‌دهد. درخواست POST به نقطه پایانی کد ارسال می‌شود که باید آن را بااستفاده از مقدار فراداده token_endpoint از سند اکتشاف بازیابی کنید. بحث زیر فرض می‌کند که نقطه پایانی https://oauth2.googleapis.com/token است. درخواست باید شامل پارامترهای زیر در بدنه POST باشد:

فیلدها
`code`	کد مجوزی که از درخواست اولیه برگردانده می‌شود.
`client_id`	شناسه کارخواهی که از صفحه «کارخواه‌ها» در Cloud Console دریافت می‌کنید، همان‌طور که در دریافت اطلاعات کاربری OAuth 2.0 شرح داده شده است.
`client_secret`	رمز کارخواهی که از صفحه کارخواه‌ها در Cloud Console دریافت می‌کنید، همان‌طور که در دریافت اعتبارنامه OAuth 2.0 شرح داده شده است.
`redirect_uri`	یک URI هدایت مجاز برای `client_id` داده‌شده که در صفحه «کارخواه‌ها» در کنسول Cloud مشخص شده است، همان‌طور که در تنظیم 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) است، یعنی یک شیء JSON کدبندی‌شده با Base64 که به‌صورت رمزنگاری‌شده امضا شده است. معمولاً بسیار مهم است که قبل‌از استفاده از یک شناسه کاربری، آن را اعتبارسنجی کنید، اما ازآنجایی‌که شما مستقیماً با Google ازطریق یک کانال HTTPS بدون واسطه ارتباط برقرار می‌کنید و از رمز کارخواه خود برای اصالت‌سنجی خود در Google استفاده می‌کنید، می‌توانید مطمئن باشید که شناسه کاربری دریافتی واقعاً از Google ارسال شده و معتبر است. اگر سرورتان کد شناسه را به مؤلفه‌های دیگر برنامه‌تان ارسال می‌کند، بسیار مهم است که مؤلفه‌های دیگر قبل‌از استفاده از کد، آن را اعتبارسنجی کنند.

ازآنجایی‌که اکثر کتابخانه‌های میانای برنامه‌سازی کاربردی اعتبارسنجی را با کار رمزگشایی مقادیر کدگذاری‌شده با 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» ممکن است حاوی فیلدهای زیر (معروف به ادعاها) باشد:

ادعای مالکیت	ارائه‌شده	شرح
`aud`	همیشه	مخاطبی که این شناسه برای آن درنظر گرفته شده است. باید یکی از شناسه‌های کارخواه OAuth 2.0 برنامه‌تان باشد.
`exp`	همیشه	زمان انقضا که در آن یا پس‌از آن، شناسه ژتون نباید پذیرفته شود. نمایش‌داده‌شده در زمان تاریخ یونیکس (ثانیه‌های عدد صحیح).
`iat`	همیشه	زمانی که کد شناسه صادر شده است. به‌صورت زمان مبدأ یونیکس (ثانیه عدد صحیح) نشان داده می‌شود.
`iss`	همیشه	«شناسه صادرکننده» برای «صادرکننده» پاسخ. همیشه `https://accounts.google.com` یا `accounts.google.com` برای نشان‌های شناسه Google.
`sub`	همیشه	شناسه‌ای برای کاربر که در بین همه «حساب‌های Google» یکتا است و هرگز دوباره استفاده نمی‌شود. یک «حساب Google» می‌تواند در زمان‌های مختلف چندین نشانی ایمیل داشته باشد، اما مقدار `sub` هرگز تغییر نمی‌کند. از `sub` در برنامه‌تان به‌عنوان کلید شناسه یکتا برای کاربر استفاده کنید. حداکثر طول ۲۵۵ نویسه ASCII حساس به حروف بزرگ و کوچک.
`amr`		آرایه JSON از رشته‌هایی که روش‌های اصالت‌سنجی مورداستفاده برای ورود به سیستم «حساب Google» را شناسایی می‌کند. درصورت وجود، شامل یک یا چند مورد از این مقادیر احتمالی [IANA.AMR] است: `hwk` از کلید سخت‌افزاری استفاده شد `mfa` اصالت‌سنجی چندعاملی تکمیل شد `pwd` از گذرواژه استفاده شد `sms` از پیامک برای درستی‌سنجی استفاده شد `swk` از کلید نرم‌افزاری مثل «گذرکلید» استفاده شد `tel` از تماس تلفنی برای درستی‌سنجی استفاده شد فقط زمانی وجود دارد که ادعای `amr` در درخواست اصالت‌سنجی گنجانده شده باشد و در تنظیمات فعال شده باشد.
`auth_time`		زمانی که اصالت‌سنجی کاربر انجام شد، یک عدد JSON که نشان‌دهنده تعداد ثانیه‌هایی است که از مبدأ Unix (‏۱ ژانویه ۱۹۷۰، ساعت ۰۰:۰۰:۰۰ به‌وقت ساعت هماهنگ جهانی) گذشته است. وقتی ادعای `auth_time` در درخواست اصالت‌سنجی گنجانده شده باشد و در تنظیمات فعال شده باشد، ارائه می‌شود.
`at_hash`		درهم‌سازی کد دسترسی. تأیید می‌کند که کد دسترسی به کد هویت گره خورده است. اگر کد شناسه با مقدار `access_token` در جریان سرور صادر شود، این ادعا همیشه گنجانده می‌شود. این ادعا می‌تواند به‌عنوان سازوکار جایگزینی برای محافظت دربرابر حملات جعل درخواست بین‌سایتی استفاده شود، اما اگر مرحله ۱ و مرحله ۳ را دنبال کنید، نیازی به درستی‌سنجی کد دسترسی نیست.
`azp`		`client_id` ارائه‌دهنده مجاز. این ادعا فقط زمانی لازم است که طرف درخواست‌کننده کد شناسه با مخاطب کد شناسه یکسان نباشد. این ممکن است در Google برای برنامه‌های ترکیبی که در آن‌ها برنامه وب و برنامه Android دارای `client_id` OAuth 2.0 متفاوتی هستند اما پروژه Google APIs یکسانی دارند اتفاق بیفتد.
`email`		نشانی ایمیل کاربر. فقط درصورتی ارائه می‌شود که دامنه `email` را در درخواستتان لحاظ کرده باشید. مقدار این ادعا ممکن است برای این حساب منحصربه‌فرد نباشد و ممکن است درطول زمان تغییر کند، بنابراین نباید از این مقدار به‌عنوان شناسه اصلی برای پیوند دادن به سابقه کاربرتان استفاده کنید. همچنین نمی‌توانید برای شناسایی کاربران Google Workspace یا سازمان‌های Cloud به ادعای دامنه `email` تکیه کنید؛ به‌جای آن از ادعای `hd` استفاده کنید. هشدار: از فیلد `email` به‌عنوان شناسه یکتا برای کاربر استفاده نکنید. همیشه از فیلد `sub` استفاده کنید.
`email_verified`		اگر نشانی ایمیل کاربر درستی‌سنجی شده باشد، «درست» است؛ درغیراین‌صورت «نادرست» است.
`family_name`		نام خانوادگی کاربر. ممکن است وقتی ادعای `name` وجود دارد ارائه شود.
`given_name`		نام (نام‌های) کوچک کاربر. ممکن است وقتی ادعای `name` وجود دارد ارائه شود.
`hd`		دامنه مرتبط با Google Workspace یا سازمان Cloud کاربر. فقط درصورتی ارائه می‌شود که کاربر به سازمان Google Cloud تعلق داشته باشد. هنگام محدود کردن دسترسی به یک منبع فقط برای اعضای دامنه‌های خاص، باید این ادعا را بررسی کنید. نبودن این ادعا نشان می‌دهد که حساب به دامنه میزبانی‌شده Google تعلق ندارد.
`locale`		منطقه زبانی کاربر که با برچسب زبان BCP 47 نشان داده می‌شود. ممکن است وقتی ادعای `name` وجود دارد، ارائه شود.
`name`		نام کامل کاربر، در فرم قابل‌نمایش. ممکن است در شرایط زیر ارائه شود: دامنه درخواست شامل رشته «نمایه» بود کد شناسه از تازه‌سازی کد برگردانده می‌شود وقتی ادعاهای `name` وجود داشته باشد، می‌توانید از آن‌ها برای به‌روزرسانی سوابق کاربر برنامه‌تان استفاده کنید. توجه داشته باشید که وجود این ادعا هرگز تضمین نمی‌شود.
`nonce`		مقدار `nonce` که برنامه‌تان در درخواست اصالت‌سنجی ارائه کرده است. باید با ارائه این مقدار فقط برای یک‌بار، از حملات بازپخش محافظت کنید.
`picture`		نشانی وب عکس نمایه کاربر. ممکن است در شرایط زیر ارائه شود: دامنه درخواست شامل رشته «نمایه» بود کد شناسه از تازه‌سازی کد برگردانده می‌شود وقتی ادعاهای `picture` وجود داشته باشد، می‌توانید از آن‌ها برای به‌روزرسانی سوابق کاربر برنامه‌تان استفاده کنید. توجه داشته باشید که وجود این ادعا هرگز تضمین نمی‌شود.
`profile`		نشانی وب صفحه نمایه کاربر. ممکن است در شرایط زیر ارائه شود: دامنه درخواست شامل رشته «نمایه» بود کد شناسه از تازه‌سازی کد برگردانده می‌شود وقتی ادعاهای `profile` وجود داشته باشد، می‌توانید از آن‌ها برای به‌روزرسانی سوابق کاربر برنامه‌تان استفاده کنید. توجه داشته باشید که وجود این ادعا هرگز تضمین نمی‌شود.

‫۶. اصالت‌سنجی کاربر

پس‌از دریافت اطلاعات کاربر از شناسه، باید پایگاه داده کاربر برنامه‌تان را پُرسمان کنید. اگر کاربر ازقبل در پایگاه داده شما وجود دارد، باید جلسه برنامه را برای آن کاربر شروع کنید، البته اگر همه الزامات ورود به سیستم توسط پاسخ Google API برآورده شده باشد.

اگر کاربر در پایگاه داده کاربر شما وجود ندارد، باید کاربر را به جریان ثبت‌نام کاربر جدیدتان هدایت کنید. ممکن است بتوانید کاربر را براساس اطلاعاتی که از Google دریافت می‌کنید به‌طور خودکار ثبت‌نام کنید، یا حداقل بتوانید بسیاری از فیلدهای موردنیاز در فرم ثبت‌نام را ازقبل تکمیل کنید. علاوه‌بر اطلاعات موجود در شناسه ژتون، می‌توانید اطلاعات تکمیلی نمایه کاربر را در نقاط پایانی نمایه کاربر ما دریافت کنید.

موضوعات پیشرفته

بخش‌های زیر Google OAuth 2.0 API را با جزئیات بیشتری شرح می‌دهند. این اطلاعات برای توسعه‌دهندگانی درنظر گرفته شده است که الزامات پیشرفته‌ای درزمینه اصالت‌سنجی و صدور مجوز دارند.

دسترسی به دیگر میاناهای برنامه‌سازی کاربردی Google

یکی از مزایای استفاده از OAuth 2.0 برای اصالت‌سنجی این است که برنامه شما می‌تواند هم‌زمان با اصالت‌سنجی کاربر، اجازه استفاده از دیگر Google APIها را ازطرف کاربر دریافت کند (مانند YouTube،‏ Google Drive، «تقویم»، یا «مخاطبین»). برای انجام این کار، دامنه‌های دیگری را که نیاز دارید در درخواست اصالت‌سنجی که به Google ارسال می‌کنید بگنجانید. برای مثال، برای افزودن گروه سنی کاربر به درخواست اصالت‌سنجی، پارامتر دامنه openid email https://www.googleapis.com/auth/profile.agerange.read را ارسال کنید. کاربر به‌طور مناسب در صفحه کسب رضایت درخواست می‌شود. کد دسترسی که از Google دریافت می‌کنید به برنامه شما اجازه می‌دهد به همه APIهای مربوط به دامنه‌های دسترسی که درخواست کرده‌اید و به شما اعطا شده است دسترسی داشته باشد.

ژتون‌های بازآوری

در درخواستتان برای دسترسی به API می‌توانید درخواست کنید که ژتون بازآوری درطول تبادل code برگردانده شود. ژتون بازآوری به برنامه شما امکان می‌دهد درحالی‌که کاربر در برنامه شما حضور ندارد، به‌طور مداوم به میاناهای برنامه‌سازی کاربردی Google دسترسی داشته باشد. برای درخواست ژتون بازآوری، پارامتر access_type را در درخواست اصالت‌سنجی روی offline تنظیم کنید.

ملاحظات:

حتماً ژتون بازآوری را به‌طور ایمن و دائمی ذخیره کنید، زیرا فقط اولین باری که جریان تبادل کد را انجام می‌دهید می‌توانید ژتون بازآوری دریافت کنید.
محدودیت‌هایی برای تعداد ژتون‌های بازآوری صادرشده وجود دارد: یک محدودیت برای هر ترکیب مشتری/کاربر، و محدودیت دیگر برای هر کاربر در همه مشتری‌ها. اگر برنامه شما تعداد زیادی ژتون بازآوری درخواست کند، ممکن است با این محدودیت‌ها مواجه شود که در این صورت ژتون‌های بازآوری قدیمی‌تر دیگر کار نمی‌کنند.

برای اطلاعات بیشتر، بازآوری کد دسترسی (دسترسی آفلاین) را ببینید.

با تنظیم پارامتر prompt روی consent در درخواست اصالت‌سنجی، می‌توانید از کاربر بخواهید دوباره به برنامه‌تان اجازه دهد. وقتی prompt=consent اضافه شود، هر بار که برنامه‌تان درخواست مجوز برای دامنه‌های دسترسی می‌کند، صفحه رضایت نمایش داده می‌شود، حتی اگر قبلاً همه دامنه‌ها به پروژه Google APIs شما اعطا شده باشد. به همین دلیل، prompt=consent را فقط درصورت لزوم اضافه کنید.

برای اطلاعات بیشتر درباره پارامتر prompt، به prompt در جدول پارامترهای URI اصالت‌سنجی مراجعه کنید.

پارامترهای URI اصالت‌سنجی

جدول زیر شرح کامل‌تری از پارامترهای پذیرفته‌شده توسط میانای برنامه‌سازی کاربردی اصالت‌سنجی Google OAuth 2.0 ارائه می‌دهد.

پارامتر الزامی شرح

client_id (الزامی) رشته شناسه کارخواه که از صفحه کارخواه‌ها در Cloud Console دریافت می‌کنید، همان‌طور که در دریافت اطلاعات کاربری OAuth 2.0 شرح داده شده است.

nonce (الزامی) مقدار تصادفی تولیدشده توسط برنامه‌تان که محافظت دربرابر بازپخش را فعال می‌کند.

response_type (الزامی) اگر مقدار code باشد، جریان کد مجوز پایه را راه‌اندازی می‌کند، که برای دریافت کردن کدها به POST به نقطه پایان کد نیاز دارد. اگر مقدار token id_token یا id_token token باشد، جریان ضمنی را راه‌اندازی می‌کند، که برای بازیابی کردن کدها از شناسه URI #fragment، استفاده از جاوا اسکریپت در URI هدایتگر را الزامی می‌کند.

redirect_uri (الزامی) تعیین می‌کند پاسخ به کجا ارسال شود. مقدار این پارامتر باید دقیقاً با یکی از مقادیر بازهدایت مجاز که در «کنسول Cloud» در صفحه مشتریان تنظیم کرده‌اید مطابقت داشته باشد (ازجمله طرح HTTP یا HTTPS، حروف بزرگ و کوچک، و «/» پایانی، درصورت وجود).

scope

(الزامی)

پارامتر دامنه باید با مقدار openid شروع شود و سپس شامل مقدار profile، مقدار email، یا هر دو باشد.

اگر مقدار دامنه profile وجود داشته باشد، ممکن است (اما تضمین نمی‌شود) که کد شناسه شامل ادعاهای پیش‌فرض profile کاربر باشد.

اگر مقدار دامنه email وجود داشته باشد، شناسه رمز شامل ادعاهای email و email_verified می‌شود.

علاوه‌بر این دامنه‌های خاص OpenID، آرگومان دامنه شما می‌تواند شامل مقادیر دامنه دیگری نیز باشد. همه مقادیر دامنه باید با فاصله از هم جدا شوند. برای مثال، اگر بخواهید به Google Drive کاربر دسترسی فایل‌به‌فایل داشته باشید، پارامتر گستره شما ممکن است openid profile email https://www.googleapis.com/auth/drive.file باشد.

برای کسب اطلاعات درباره گستره‌های دردسترس، گستره‌های OAuth 2.0 برای Google API یا مستندات Google API موردنظرتان برای استفاده را ببینید.

state

(اختیاری، اما اکیداً توصیه می‌شود)

رشته‌ای مبهم که در پروتکل رفت‌وبرگشت می‌شود؛ یعنی به‌عنوان پارامتر URI در جریان «پایه» و در شناسه URI #fragment در جریان «ضمنی» برگردانده می‌شود.

state می‌تواند برای همبسته کردن درخواست‌ها و پاسخ‌ها مفید باشد. چون redirect_uri شما قابل‌حدس زدن است، استفاده از مقدار state می‌تواند اطمینان شما را از اینکه اتصال ورودی نتیجه درخواست اصالت‌سنجی آغازشده توسط برنامه‌تان است افزایش دهد. اگر رشته‌ای تصادفی تولید کنید یا درهم‌سازی برخی‌از وضعیت‌های کارخواه (مثلاً کوکی) را در این متغیر state کدبندی کنید، می‌توانید پاسخ را اعتبارسنجی کنید تا تأیید شود که درخواست و پاسخ از یک مرورگر منشأ گرفته‌اند. این کار از شما دربرابر حملاتی مثل جعل درخواست بین‌سایتی محافظت می‌کند.

access_type (اختیاری) مقادیر مجاز offline و online هستند. این تأثیر در دسترسی آفلاین مستند شده است؛ اگر کد دسترسی درخواست شود، سرویس‌گیرنده کد بازآوری دریافت نمی‌کند، مگراینکه مقدار offline مشخص شده باشد.

claims

(اختیاری)

از پارامتر ادعاها برای مشخص کردن یک یا چند فیلد اختیاری برای گنجاندن در نقطه پایانی userinfo یا انواع پاسخ‌های شناسه توکن درخواست اصالت‌سنجی استفاده می‌شود. این مقدار یک شیء JSON است که حاوی نوع پاسخ و ادعاهای درخواست‌شده است. درخواست‌های ادعای زیر توسط سرورهای Google پذیرفته می‌شوند:

درخواست‌های ادعا
`amr`	درخواست روشی که آخرین‌بار برای اصالت‌سنجی کاربر استفاده شده است. برای برگرداندن `amr` به‌عنوان فیلدی در پاسخ شناسه توکن، پارامتر درخواست `claims` را اضافه کنید: `claims={"id_token":{"amr":{"essential":true}}}` باید در تنظیمات فعال شود.
`auth_time`	درخواست زمان آخرین اصالت‌سنجی کاربر. برای برگرداندن `auth_time` به‌عنوان فیلدی در پاسخ شناسه توکن، پارامتر درخواست `claims` را اضافه کنید: `claims={"id_token":{"auth_time":{"essential":true}}}` باید در تنظیمات فعال شود.

display (اختیاری) مقدار رشته ASCII برای مشخص کردن نحوه نمایش صفحه‌های میانای کاربر اصالت‌سنجی و رضایت توسط سرور مجوز. مقادیر زیر مشخص شده‌اند و سرورهای Google آن‌ها را پذیرفته‌اند، اما تأثیری بر رفتار جریان پروتکل ندارند: page،‏ popup،‏ touch، و wap.

hd

(اختیاری)

فرایند ورود به سیستم را برای حساب‌های متعلق به سازمان Google Cloud ساده کنید. با گنجاندن دامنه سازمان Google Cloud (برای مثال، mycollege.edu)، می‌توانید نشان دهید که واسط کاربری انتخاب حساب باید برای حساب‌های آن دامنه بهینه‌سازی شود. برای بهینه‌سازی حساب‌های سازمان Google Cloud به‌طور کلی به‌جای فقط یک دامنه سازمان Google Cloud، مقدار ستاره (*) را تنظیم کنید: hd=*.

برای کنترل اینکه چه کسی می‌تواند به برنامه‌تان دسترسی داشته باشد، به این بهینه‌سازی واسط کاربر اتکا نکنید، زیرا درخواست‌های سمت کارخواه را می‌توان اصلاح کرد. حتماً اعتبارسنجی کنید که شناسه برگردانده‌شده دارای مقدار ادعای hd باشد که با آنچه انتظار دارید مطابقت داشته باشد (مثلاً mycolledge.edu). برخلاف پارامتر درخواست، ادعای hd شناسه در یک توکن امنیتی از Google قرار دارد، بنابراین می‌توان به این مقدار اعتماد کرد.

include_granted_scopes

(اختیاری)

اگر این پارامتر با مقدار true ارائه شود و درخواست مجوز اعطا شود، مجوز شامل هرگونه مجوز قبلی اعطاشده به این ترکیب کاربر/برنامه برای دامنه‌های دیگر خواهد بود؛ به مجوز افزایشی مراجعه کنید.

توجه داشته باشید که نمی‌توانید با جریان «برنامه نصب‌شده» مجوز افزایشی انجام دهید.

login_hint (اختیاری) وقتی برنامه‌تان بداند کدام کاربر را می‌خواهد اصالت‌سنجی کند، می‌تواند این پارامتر را به‌عنوان راهنمایی به سرور اصالت‌سنجی ارائه دهد. ارسال این راهنمایی، انتخاب‌گر حساب را پنهان می‌کند و یا کادر ایمیل را در فرم ورود به سیستم ازقبل تکمیل می‌کند یا جلسه مناسب را انتخاب می‌کند (اگر کاربر از ورود به سیستم چندگانه استفاده می‌کند)، که می‌تواند به شما کمک کند از مشکلاتی که درصورت ورود برنامه به سیستم حساب کاربری اشتباه رخ می‌دهد جلوگیری کنید. این مقدار می‌تواند نشانی ایمیل یا رشته sub باشد که معادل شناسه Google کاربر است.

prompt

(اختیاری)

فهرستی از مقادیر رشته‌ای با جداساز فاصله که مشخص می‌کند آیا سرور صدور مجوز از کاربر درخواست اصالت‌سنجی مجدد و رضایت می‌کند یا نه. مقادیر ممکن عبارت‌اند از:

none
سرور مجوزدهی هیچ صفحه اصالت‌سنجی یا کسب رضایت کاربر را نمایش نمی‌دهد؛ اگر کاربر ازقبل اصالت‌سنجی نشده باشد و رضایت را برای دامنه‌های درخواستی ازقبل پیکربندی نکرده باشد، سرور خطا برمی‌گرداند. می‌توانید از none برای بررسی اصالت‌سنجی و/یا رضایت موجود استفاده کنید.
consent
سرور صدور مجوز قبل‌از برگرداندن اطلاعات به کارخواه، از کاربر درخواست رضایت می‌کند.
select_account
سرور صدور مجوز از کاربر می‌خواهد حساب کاربری انتخاب کند. این کار به کاربری که چند حساب در سرور مجوزدهی دارد اجازه می‌دهد از بین چند حسابی که ممکن است درحال‌حاضر جلسه فعال داشته باشند انتخاب کند.

اگر مقداری مشخص نشده باشد و کاربر قبلاً دسترسی را مجاز نکرده باشد، صفحه رضایت به کاربر نشان داده می‌شود.

hl (اختیاری) برچسب زبان BCP 47 که برای مشخص کردن زبان نمایش برای صفحه‌های ورود به سیستم، انتخاب‌کننده حساب، و رضایت استفاده می‌شود. اگر این پارامتر ارائه نشود، زبان به‌طور پیش‌فرض روی تنظیمات مرورگر یا «حساب Google» کاربر تنظیم می‌شود. برای مثال، برای درخواست واسط کاربر به زبان انگلیسی بریتانیایی، پارامتر را روی en-GB تنظیم کنید.

اعتبارسنجی کردن شناسه نمادافزار

باید همه داده‌واحدهای شناسه را در سرورتان اعتبارسنجی کنید، مگراینکه بدانید مستقیماً از Google آمده‌اند. برای مثال، سرور شما باید اصالت هرگونه کد شناسه دریافتی از برنامه‌های کارخواه را درستی‌سنجی کند.

موارد زیر موقعیت‌های رایجی هستند که ممکن است توکن‌های شناسه را به سرور خود ارسال کنید:

ارسال کردن توکن‌های شناسه با درخواست‌هایی که باید اصالت‌سنجی شوند. نشان‌های شناسه به شما می‌گویند کدام کاربر خاص درخواست را ارائه کرده است و آن نشان شناسه برای کدام کارخواه اعطا شده است.

نشان‌های شناسه حساس هستند و اگر رهگیری شوند ممکن است مورد سوءاستفاده قرار گیرند. باید مطمئن شوید که این توکن‌ها با انتقال فقط ازطریق HTTPS و فقط بااستفاده از داده‌های POST یا در سرایندهای درخواست، به‌طور ایمن مدیریت می‌شوند. اگر توکن‌های شناسه را در سرورتان ذخیره می‌کنید، باید آن‌ها را به‌طور ایمن ذخیره کنید.

One thing that makes ID tokens useful is that fact that you can pass them around different components of your app. These components can use an ID token as a lightweight authentication mechanism authenticating the app and the user. اما قبل‌از اینکه بتوانید از اطلاعات موجود در شناسه ژتون استفاده کنید یا به‌عنوان ادعایی بر اینکه کاربر اصالت‌سنجی شده است به آن تکیه کنید، باید آن را اعتبارسنجی کنید.

اعتبارسنجی شناسه ID به چند مرحله نیاز دارد:

تأیید کنید که شناسه ژتون به‌درستی توسط صادرکننده امضا شده باشد. نشان‌های صادرشده توسط Google بااستفاده از یکی از گواهی‌های موجود در URI مشخص‌شده در مقدار فراداده jwks_uri سند اکتشاف امضا می‌شوند.
تأیید کنید که مقدار ادعای iss در شناسه رمز برابر با https://accounts.google.com یا accounts.google.com باشد.
تأیید کنید که مقدار ادعای aud در شناسه ID با شناسه مشتری برنامه‌تان برابر باشد.
بررسی کنید که زمان انقضای (ادعای exp) کد شناسه نگذشته باشد.
اگر مقدار پارامتر hd را در درخواست مشخص کرده‌اید، بررسی کنید که شناسه ادعای hd داشته باشد که با دامنه پذیرفته‌شده مرتبط با سازمان Google Cloud مطابقت داشته باشد.

مراحل ۲ تا ۵ فقط شامل مقایسه رشته و تاریخ است که بسیار ساده است، بنابراین در اینجا به جزئیات آن‌ها نمی‌پردازیم.

مرحله اول پیچیده‌تر است و شامل بررسی امضای رمزنگاری می‌شود. برای اهداف اشکال‌زدایی، می‌توانید از نقطه پایانی tokeninfo Google برای مقایسه با پردازش محلی اجراشده در سرور یا دستگاهتان استفاده کنید. فرض کنید مقدار شناسه ژتون شما XYZ123 است. سپس شناسه منبع یکسان را ارجاع‌زدایی می‌کنید https://oauth2.googleapis.com/tokeninfo?id_token=XYZ123. اگر امضای داده‌واحد معتبر باشد، پاسخ، پایه‌بار JWT در قالب شیء JSON رمزگشایی‌شده آن خواهد بود.

نقطه پایانی tokeninfo برای اشکال‌زدایی مفید است اما برای اهداف تولید، کلیدهای عمومی Google را از نقطه پایانی کلیدها بازیابی کنید و اعتبارسنجی را به‌صورت محلی انجام دهید. باید شناسه منبع یکسان کلیدها را از سند اکتشاف بااستفاده از مقدار فراداده jwks_uri بازیابی کنید. درخواست‌های ارسال‌شده به نقطه پایانی اشکال‌زدایی ممکن است محدود شوند یا به‌نحوی دیگر با خطاهای متناوب مواجه شوند.

ازآنجایی‌که Google کلیدهای عمومی خود را به‌ندرت تغییر می‌دهد، می‌توانید آن‌ها را بااستفاده از دستورالعمل‌های حافظه پنهان پاسخ HTTP در حافظه پنهان ذخیره کنید و در اکثر موارد، اعتبارسنجی محلی را بسیار کارآمدتر از استفاده از نقطه پایانی tokeninfo انجام دهید. این اعتبارسنجی مستلزم بازیابی و تجزیه گواهی‌ها و برقراری تماس‌های رمزنگاری مناسب برای بررسی امضا است. خوشبختانه، کتابخانه‌های اشکال‌زدایی‌شده خوبی به زبان‌های مختلف برای انجام این کار دردسترس است (به jwt.io مراجعه کنید).

درحال دریافت اطلاعات نمایه کاربر

برای دریافت اطلاعات نمایه بیشتر درباره کاربر، می‌توانید از کد دسترسی (که برنامه‌تان درطول جریان اصالت‌سنجی دریافت می‌کند) و استاندارد OpenID Connect استفاده کنید:

برای سازگار بودن با OpenID، باید مقادیر گستره openid profile را در درخواست اصالت‌سنجی خود بگنجانید.

اگر می‌خواهید نشانی ایمیل کاربر اضافه شود، می‌توانید مقدار دامنه اضافی email را مشخص کنید. برای مشخص کردن هر دو profile و email، می‌توانید پارامتر زیر را در URI درخواست اصالت‌سنجی خود اضافه کنید:
```
scope=openid%20profile%20email
```
کد دسترسی‌تان را به سرصفحه مجوز اضافه کنید و درخواست HTTPS GET به نقطه پایانی userinfo ارسال کنید، که باید آن را از سند اکتشاف بااستفاده از مقدار فراداده userinfo_endpoint بازیابی کنید. پاسخ userinfo شامل اطلاعاتی درباره کاربر است، همان‌طور که در OpenID Connect Standard Claims و مقدار فراداده claims_supported سند Discovery شرح داده شده است. کاربران یا سازمان‌های آن‌ها ممکن است تصمیم بگیرند برخی فیلدها را ارائه دهند یا ندهند، بنابراین ممکن است برای همه فیلدهای مربوط به گستره‌های دسترسی مجازتان اطلاعات دریافت نکنید.

سند «اکتشاف»

پروتکل OpenID Connect برای اصالت‌سنجی کاربران و درخواست منابع ازجمله توکن‌ها، اطلاعات کاربر، و کلیدهای عمومی، استفاده از چندین نقطه پایانی را الزامی می‌کند.

برای ساده‌سازی پیاده‌سازی‌ها و افزایش انعطاف‌پذیری، OpenID Connect امکان استفاده از «سند اکتشاف» را فراهم می‌کند، سند JSON که در مکانی شناخته‌شده حاوی جفت‌های کلید-مقدار یافت می‌شود که جزئیاتی درباره پیکربندی ارائه‌دهنده OpenID Connect ارائه می‌دهد، ازجمله URIهای نقطه‌های پایانی مجوز، کد، لغو، اطلاعات کاربر، و کلیدهای عمومی. سند Discovery برای سرویس OpenID Connect متعلق به Google را می‌توان از اینجا بازیابی کرد:

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

برای استفاده از سرویس‌های OpenID Connect متعلق به Google، باید شناسه منبع یکسان سند اکتشاف (https://accounts.google.com/.well-known/openid-configuration) را در برنامه‌تان کدگذاری ثابت کنید. برنامه شما سند را واکشی می‌کند، قوانین ذخیره‌سازی موقت را در پاسخ اعمال می‌کند، سپس شناسه‌های منبع یکسان نقطه پایانی را درصورت نیاز از آن بازیابی می‌کند. برای مثال، برای اصالت‌سنجی کاربر، کد شما مقدار فراداده authorization_endpoint (https://accounts.google.com/o/oauth2/v2/auth در مثال زیر) را به‌عنوان URI پایه برای درخواست‌های اصالت‌سنجی که به Google ارسال می‌شود بازیابی می‌کند.

در اینجا نمونه‌ای از چنین سندی آورده شده است؛ نام فیلدها همان‌هایی است که در 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).

OpenID Connect با مجموعه‌ها، منظم بمانید ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.

راه‌اندازی OAuth 2.0

دریافت اعتبارنامه‌های OAuth 2.0

تنظیم URI هدایت

سفارشی‌سازی صفحه رضایت کاربر

دسترسی به سرویس

درحال اصالت‌سنجی کاربر

جریان سرور

۱. ایجاد کردن یک توکن حالت ضدجعل

PHP

جاوا

Python

۲. ارسال درخواست اصالت‌سنجی به Google

۳. تأیید کردن کد حالت ضدجعل

PHP

جاوا

Python

۴. تبدیل code به کد دسترسی و کد شناسه

۵. دریافت اطلاعات کاربر از کد شناسه

بار داده شناسه نشانه

‫۶. اصالت‌سنجی کاربر

موضوعات پیشرفته

دسترسی به دیگر میاناهای برنامه‌سازی کاربردی Google

ژتون‌های بازآوری

درخواست مجدد برای کسب رضایت

پارامترهای URI اصالت‌سنجی

اعتبارسنجی کردن شناسه نمادافزار

درحال دریافت اطلاعات نمایه کاربر

سند «اکتشاف»

کتابخانه‌های مشتری

مطابقت با OpenID Connect

OpenID Connect

۴. تبدیل `code` به کد دسترسی و کد شناسه