‫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

قبل‌از اینکه برنامه‌تان بتواند از سیستم اصالت‌سنجی OAuth 2.0 در Google برای ورود به سیستم کاربر استفاده کند، باید پروژه‌ای در 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 API استفاده کنید. نمونه‌ها شامل سرویس‌های مدیریت هویت‌سنجی 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 رد می‌شوند. باید شناسه منبع یکسان پایه را از سند اکتشاف بااستفاده از مقدار فراداده 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 می‌آید و معتبر است. اگر سرورتان شناسه ژتون را به مؤلفه‌های دیگر برنامه‌تان ارسال می‌کند، بسیار مهم است که مؤلفه‌های دیگر قبل‌از استفاده از ژتون، آن را اعتبارسنجی کنند.

ازآنجایی‌که اکثر کتابخانه‌های API اعتبارسنجی را با کار رمزگشایی مقادیر کدگذاری‌شده base64url و تجزیه JSON درون آن ترکیب می‌کنند، احتمالاً درنهایت هنگام دسترسی به ادعاها در شناسه رمز، رمز را اعتبارسنجی خواهید کرد.

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

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

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

هشدار: هنگام پیاده‌سازی سیستم مدیریت حساب، نباید از فیلد email در شناسه کد به‌عنوان شناسه یکتا برای کاربر استفاده کنید. همیشه از فیلد sub استفاده کنید زیرا برای «حساب Google» منحصربه‌فرد است، حتی اگر کاربر نشانی ایمیل خود را تغییر دهد.

«ژتون‌های شناسه 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 را ازطرف کاربر (مانند YouTube،‏ Google Drive، تقویم، یا مخاطبین) هم‌زمان با اصالت‌سنجی کاربر دریافت کند. برای انجام این کار، دامنه‌های دیگری را که نیاز دارید در درخواست اصالت‌سنجی که به Google ارسال می‌کنید بگنجانید. برای مثال، برای افزودن گروه سنی کاربر به درخواست اصالت‌سنجی، پارامتر دامنه openid email https://www.googleapis.com/auth/profile.agerange.read را ارسال کنید. در صفحه رضایت، پیام‌واره مناسبی به کاربر نشان داده می‌شود. کد دسترسی که از Google دریافت می‌کنید به برنامه شما اجازه می‌دهد به همه 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 APIs یا مستندات 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 یا در سرایندهای درخواست منتقل می‌شوند. اگر کدهای شناسه را در سرورتان ذخیره می‌کنید، باید آن‌ها را به‌طور امن ذخیره کنید.

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

اعتبارسنجی شناسه 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

سیستم اصالت‌سنجی OAuth 2.0 متعلق به Google از ویژگی‌های الزامی مشخصات 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` به کد دسترسی و کد شناسه