اتصال OpenID

نقطة نهاية OpenID Connect من Google معتمَدة من OpenID.

يمكن استخدام واجهات برمجة تطبيقات 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

تحتاج إلى بيانات اعتماد OAuth 2.0، بما في ذلك معرِّف العميل وسر العميل، لمصادقة المستخدمين والوصول إلى واجهات برمجة تطبيقات Google.

لعرض معرّف العميل وسر العميل لبيانات اعتماد OAuth 2.0 معيّنة، انقر على النص التالي: اختيار بيانات الاعتماد. في النافذة التي تظهر، اختَر مشروعك وبيانات الاعتماد التي تريدها، ثم انقر على عرض.

أو يمكنك الاطّلاع على معرّف العميل وسر العميل من صفحة "العملاء" في Cloud Console:

  1. انتقِل إلى صفحة "العملاء".
  2. انقر على اسم العميل أو رمز التعديل (). يظهر معرّف العميل وسر العميل في أعلى الصفحة.

ضبط معرّف الموارد المنتظم (URI) الخاص بإعادة التوجيه

يحدّد معرّف الموارد المنتظم (URI) لإعادة التوجيه الذي تضبطه في Cloud Console المكان الذي ترسل إليه Google الردود على طلبات المصادقة.

لإنشاء عناوين URI لإعادة التوجيه أو عرضها أو تعديلها لبيانات اعتماد OAuth 2.0 معيّنة، اتّبِع الخطوات التالية:

  1. انتقِل إلى صفحة "العملاء".
  2. انقر على العميل.
  3. عرض معرّفات الموارد المنتظمة (URI) لإعادة التوجيه أو تعديلها

إذا لم يكن هناك عميل مدرج في صفحة "العملاء"، يعني ذلك أنّ مشروعك لا يتضمّن بيانات اعتماد OAuth. لإنشاء عميل، انقر على إنشاء عميل.

تخصيص شاشة طلب موافقة المستخدم

بالنسبة إلى المستخدمين، تتضمّن تجربة مصادقة OAuth 2.0 شاشة طلب موافقة تصف المعلومات التي يشاركها المستخدم والأحكام السارية. على سبيل المثال، عندما يسجّل المستخدم الدخول، قد يُطلب منه منح تطبيقك إذن الوصول إلى عنوان بريده الإلكتروني ومعلومات حسابه الأساسية. يمكنك طلب الوصول إلى هذه المعلومات باستخدام المَعلمة scope التي يضمّنها تطبيقك في طلب المصادقة. يمكنك أيضًا استخدام النطاقات لطلب الوصول إلى Google APIs الأخرى.

تعرض شاشة موافقة المستخدم أيضًا معلومات العلامة التجارية، مثل اسم المنتج وشعاره وعنوان URL للصفحة الرئيسية. يمكنك التحكّم في معلومات الهوية البصرية للعلامة التجارية في Cloud Console.

لتفعيل شاشة طلب الموافقة في مشروعك، اتّبِع الخطوات التالية:

  1. افتح صفحة "الهوية البصرية للعلامة التجارية" في Google Cloud Console.
  2. اختَر مشروعًا أو أنشِئ مشروعًا جديدًا إذا طُلب منك ذلك.
  3. املأ النموذج وانقر على حفظ.

يعرض مربّع إفادة الموافقة التالي ما يظهر للمستخدم عندما يتضمّن الطلب مزيجًا من نطاقات OAuth 2.0 وGoogle Drive. (تم إنشاء مربّع الحوار العام هذا باستخدام Google OAuth 2.0 Playground، لذا لا يتضمّن معلومات الهوية البصرية للعلامة التجارية التي سيتم ضبطها في Cloud Console).

مثال على صفحة موافقة
الشكل 1. لقطة شاشة لصفحة الموافقة

الوصول إلى الخدمة

توفّر Google وجهات خارجية مكتبات يمكنك استخدامها لإدارة العديد من تفاصيل تنفيذ مصادقة المستخدمين والوصول إلى Google APIs. وتشمل الأمثلة Google Identity Services ومكتبات برامج Google المتاحة لمجموعة متنوعة من المنصات.

إذا اخترت عدم استخدام مكتبة، اتّبِع التعليمات الواردة في بقية هذا المستند، والذي يصف تدفقات طلبات HTTP التي تستند إليها المكتبات المتاحة.

مصادقة المستخدم

تتضمن مصادقة المستخدم الحصول على رمز مميز للمعرّف والتحقق من صحته. رموز التعريف المميّزة هي ميزة عادية في OpenID Connect مصمَّمة للاستخدام في مشاركة تأكيدات الهوية على الإنترنت.

تُعرف الطرق الأكثر شيوعًا لمصادقة المستخدم والحصول على رمز مميّز للرقم التعريفي باسم مسار "الخادم" والمسار "الضمني". يسمح تدفق الخادم لخادم الخلفية للتطبيق بالتحقق من هوية الشخص باستخدام متصفح أو جهاز محمول. يتم استخدام التدفق الضمني عندما يحتاج تطبيق من جهة العميل (عادةً ما يكون تطبيق JavaScript يعمل في المتصفح) إلى الوصول إلى واجهات برمجة التطبيقات مباشرةً بدلاً من استخدام خادم الخلفية.

يوضّح هذا المستند كيفية تنفيذ عملية الخادم لمصادقة المستخدم. يُعدّ التدفّق الضمني أكثر تعقيدًا بسبب المخاطر الأمنية في معالجة الرموز المميّزة واستخدامها من جهة العميل. إذا كنت بحاجة إلى تنفيذ تدفّق ضمني، ننصحك بشدة باستخدام خدمات الهوية في Google.

مسار الخادم

تأكَّد من إعداد تطبيقك في Cloud Console لتفعيل استخدام هذه البروتوكولات ومصادقة المستخدمين. عندما يحاول مستخدم تسجيل الدخول باستخدام حساب Google، عليك:

  1. إنشاء رمز مميّز للحالة لمكافحة التزوير
  2. إرسال طلب مصادقة إلى Google
  3. تأكيد الرمز المميّز لحالة مكافحة التزوير
  4. استبدال code برمز الدخول ورمز التعريف
  5. الحصول على معلومات المستخدم من الرمز المميّز للمعرّف
  6. مصادقة المستخدم

1. إنشاء رمز مميّز للحالة لمنع التزوير

يجب حماية أمان المستخدمين من خلال منع هجمات تزوير الطلبات. الخطوة الأولى هي إنشاء رمز مميز فريد للجلسة يحفظ الحالة بين تطبيقك وعميل المستخدم. بعد ذلك، يمكنك مطابقة الرمز المميز الفريد للجلسة مع استجابة المصادقة التي تعرضها خدمة تسجيل الدخول إلى Google OAuth للتحقّق من أنّ المستخدم هو من يرسل الطلب وليس مهاجمًا ضارًا. وغالبًا ما يُشار إلى هذه الرموز المميّزة باسم رموز تزوير طلبات من موقع إلكتروني مختلف (CSRF).

من الخيارات الجيدة لرمز الحالة استخدام سلسلة من 30 حرفًا تقريبًا يتم إنشاؤها باستخدام أداة إنشاء أرقام عشوائية عالية الجودة. والطريقة الأخرى هي تجزئة يتم إنشاؤها من خلال توقيع بعض متغيّرات حالة الجلسة باستخدام مفتاح يتم الاحتفاظ به سرًا في الواجهة الخلفية.

يوضّح الرمز التالي كيفية إنشاء رموز مميّزة فريدة للجلسات.

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

2. إرسال طلب مصادقة إلى Google

الخطوة التالية هي إنشاء طلب HTTPS GET باستخدام مَعلمات معرّف الموارد المنتظم (URI) المناسبة. يُرجى ملاحظة استخدام HTTPS بدلاً من HTTP في جميع خطوات هذه العملية، إذ يتم رفض اتصالات HTTP. يجب استرداد معرّف الموارد المنتظم (URI) الأساسي من مستند الاستكشاف باستخدام قيمة البيانات الوصفية authorization_endpoint. تفترض المناقشة التالية أنّ عنوان URI الأساسي هو https://accounts.google.com/o/oauth2/v2/auth.

بالنسبة إلى الطلب الأساسي، حدِّد المَعلمات التالية:

  • client_id، والذي تحصل عليه من صفحة "العملاء" في Cloud Console.
  • ‫response_type، والذي يجب أن يكون code في طلب مسار رمز التفويض الأساسي. (يمكنك الاطّلاع على مزيد من المعلومات على response_type.)
  • scope، والتي يجب أن تكون openid email في الطلب الأساسي. (يمكنك الاطّلاع على مزيد من المعلومات على scope.)
  • يجب أن يكون redirect_uri هو نقطة نهاية HTTP على الخادم الذي سيتلقّى الردّ من Google. يجب أن تتطابق القيمة تمامًا مع أحد معرّفات الموارد المنتظمة (URI) المصرّح بها لإعادة التوجيه لعميل OAuth 2.0، والتي تم ضبطها في صفحة "بيانات الاعتماد" ضمن Cloud Console. إذا لم تتطابق هذه القيمة مع معرّف موارد منتظم (URI) معتمَد، سيتعذّر تنفيذ الطلب وسيظهر الخطأ redirect_uri_mismatch.
  • يجب أن يتضمّن state قيمة الرمز المميز الفريد للجلسة والمخصّص لمكافحة التزوير، بالإضافة إلى أي معلومات أخرى مطلوبة لاسترداد السياق عندما يعود المستخدم إلى تطبيقك، مثل عنوان URL للبدء. (مزيد من المعلومات على الرابط 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

يجب أن يمنح المستخدمون موافقتهم إذا طلب تطبيقك أي معلومات جديدة عنهم، أو إذا طلب تطبيقك الوصول إلى الحساب الذي لم يسبق لهم الموافقة عليه.

3- تأكيد الرمز المميّز للحالة المضاد للتزوير

يتم إرسال الردّ إلى 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 يتطابق مع الرمز المميّز للجلسة الذي أنشأته في الخطوة 1. تساعد عملية التحقّق هذه في التأكّد من أنّ المستخدم هو من يرسل الطلب، وليس نصًا برمجيًا ضارًا.

يوضّح الرمز التالي كيفية تأكيد الرموز المميّزة للجلسات التي أنشأتها في الخطوة 1:

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

4. استبدال 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 Console، كما هو موضّح في ضبط معرّف موارد منتظم (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 في طلب المصادقة. لمعرفة التفاصيل، يُرجى الاطّلاع على الرموز المميزة لإعادة التحميل.

5- الحصول على معلومات المستخدم من الرمز المميّز للمعرّف

رمز التعريف هو JWT، أي عنصر JSON موقَّع بطريقة مشفّرة ومرمَّز بتنسيق Base64. عادةً، من المهم التحقّق من صحة رمز مميّز للرقم التعريفي قبل استخدامه، ولكن بما أنّك تتواصل مباشرةً مع Google عبر قناة HTTPS بدون وسيط وتستخدم سر العميل للمصادقة على هويتك لدى Google، يمكنك التأكّد من أنّ الرمز المميّز الذي تتلقّاه صادر من Google وصالح. إذا كان الخادم يمرّر الرمز المميّز للرقم التعريفي إلى مكوّنات أخرى في تطبيقك، من المهم جدًا أن تتحقّق المكوّنات الأخرى من صلاحية الرمز المميّز قبل استخدامه.

بما أنّ معظم مكتبات واجهات برمجة التطبيقات تجمع بين عملية التحقّق من الصحة وفك ترميز القيم المرمّزة باستخدام base64url وتحليل JSON، من المحتمل أن ينتهي بك الأمر إلى التحقّق من صحة الرمز المميّز على أي حال عند الوصول إلى المطالبات في الرمز المميّز للمعرّف.

حمولة رمز مميّز للتعريف

رمز التعريف المميّز هو عنصر JSON يحتوي على مجموعة من أزواج الاسم/القيمة. إليك مثال على ذلك، تم تنسيقه لتسهيل قراءته:

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

قد تحتوي رموز Google المميّزة للتعريف على الحقول التالية (المعروفة باسم المطالبات):

المطالبة تم الإدخال الوصف
aud دائمًا الجمهور الذي يستهدفه رمز التعريف هذا ويجب أن يكون أحد معرّفات عملاء OAuth 2.0 لتطبيقك.
exp دائمًا وقت انتهاء الصلاحية الذي يجب عدم قبول الرمز المميّز للمعرّف بعده يتم تمثيلها في وقت حقبة يونكس (ثوانٍ صحيحة).
iat دائمًا وقت إصدار الرمز المميّز للهوية يتم تمثيلها بوقت حقبة يونكس (عدد صحيح بالثواني).
iss دائمًا معرّف جهة إصدار الردّ يجب دائمًا https://accounts.google.com أو accounts.google.com لرموز تعريف Google المميّزة.
sub دائمًا معرّف للمستخدم، فريد من نوعه بين جميع حسابات Google ولا تتم إعادة استخدامه مطلقًا. يمكن أن يتضمّن حساب Google عدة عناوين بريد إلكتروني في أوقات مختلفة، ولكن لا يتم تغيير قيمة sub أبدًا. استخدِم sub ضمن تطبيقك كمفتاح المعرّف الفريد للمستخدم. الحد الأقصى للطول هو 255 حرفًا من أحرف ASCII الحسّاسة لحالة الأحرف.
amr مصفوفة JSON من السلاسل التي تحدّد طرق المصادقة المستخدَمة لتسجيل الدخول إلى حساب Google. في حال توفّرها، تتضمّن قيمة واحدة أو أكثر من قيم [IANA.AMR] المحتمَلة التالية:
  • تم استخدام مفتاح جهاز في hwk
  • mfa تم إكمال المصادقة المتعدّدة العوامل
  • تم استخدام كلمة مرور في "pwd"
  • تم استخدام رسالة SMS واحدة (sms) لإثبات الهوية
  • swk تم استخدام مفتاح برنامج، مثل مفتاح مرور
  • تم استخدام مكالمة هاتفية لإثبات الهوية في tel
لا يظهر إلا عند تضمين المطالبة amr في طلب المصادقة وتفعيلها في الإعدادات.
auth_time يشير هذا الحقل إلى وقت مصادقة المستخدم، وهو رقم JSON يمثّل عدد الثواني التي انقضت منذ بداية حقبة يونكس (1 يناير 1970، الساعة 00:00:00 بالتوقيت العالمي المنسق). يتم توفيرها عند تضمين مطالبة auth_time في طلب المصادقة وتفعيلها في الإعدادات.
at_hash تجزئة رمز الدخول يوفّر التحقّق من أنّ رمز الدخول مرتبط برمز التعريف. إذا تم إصدار رمز التعريف المميّز بقيمة access_token في مسار الخادم، يتم دائمًا تضمين هذا الادعاء. يمكن استخدام هذا الادعاء كآلية بديلة للحماية من هجمات تزوير طلبات من موقع إلكتروني مختلف، ولكن إذا اتّبعت الخطوة 1 والخطوة 3، لن يكون من الضروري التحقّق من رمز الدخول.
azp ‫client_id لمقدّم العرض المفوَّض لا تكون هذه المطالبة مطلوبة إلا عندما لا تكون الجهة التي تطلب رمز التعريف هي نفسها جمهور رمز التعريف. وقد يكون هذا هو الحال في Google للتطبيقات المختلطة حيث يكون لتطبيق الويب وتطبيق Android client_id مختلف لبروتوكول OAuth 2.0، ولكنهما يتشاركان مشروع Google APIs نفسه.
email عنوان البريد الإلكتروني للمستخدِم. يتم توفيرها فقط إذا قمت بتضمين نطاق email في طلبك. قد لا تكون قيمة هذا الادّعاء فريدة لهذا الحساب وقد تتغيّر بمرور الوقت، لذا يجب عدم استخدام هذه القيمة كمعرّف أساسي للربط بسجلّ المستخدم. لا يمكنك أيضًا الاعتماد على نطاق المطالبة email لتحديد مستخدمي مؤسسات Google Workspace أو Cloud، بل عليك استخدام المطالبة hd بدلاً من ذلك.
email_verified تكون القيمة "صحيح" إذا تم تأكيد عنوان البريد الإلكتروني للمستخدم، وإلا تكون "خطأ".
family_name اسم عائلة المستخدم أو أسماء عائلته قد يتم توفيرها عند توفّر مطالبة name.
given_name الأسماء الأولى للمستخدم قد يتم توفيرها عند توفّر مطالبة name.
hd النطاق المرتبط بمؤسسة Google Workspace أو Cloud الخاصة بالمستخدم يتم توفيرها فقط إذا كان المستخدم ينتمي إلى مؤسسة على Google Cloud. يجب التحقّق من هذا الادّعاء عند حصر الوصول إلى مورد بأعضاء نطاقات معيّنة فقط. يشير عدم توفّر هذا الادعاء إلى أنّ الحساب لا ينتمي إلى نطاق مستضاف على Google.
locale الإعدادات المحلية للمستخدم، ويتم تمثيلها بعلامة لغة BCP 47. Might be provided when a name claim is present.
name الاسم الكامل للمستخدم، في نموذج قابل للعرض. يمكن تقديمها في الحالات التالية:
  • تضمّن نطاق الطلب السلسلة "الملف الشخصي"
  • يتم عرض الرمز المميّز للمعرّف من إعادة تحميل الرمز المميّز

عند توفّر مطالبات name، يمكنك استخدامها لتعديل سجلّات المستخدمين في تطبيقك. يُرجى العِلم أنّه لا يمكن ضمان توفّر هذا الادّعاء مطلقًا.

nonce قيمة nonce التي يوفّرها تطبيقك في طلب المصادقة يجب الحماية من هجمات إعادة التشغيل من خلال تقديم هذه القيمة مرة واحدة فقط.
picture عنوان URL لصورة الملف الشخصي للمستخدم يمكن تقديمها في الحالات التالية:
  • تضمّن نطاق الطلب السلسلة "الملف الشخصي"
  • يتم عرض الرمز المميّز للمعرّف من إعادة تحميل الرمز المميّز

عند توفّر مطالبات picture، يمكنك استخدامها لتعديل سجلّات المستخدمين في تطبيقك. يُرجى العِلم أنّه لا يمكن ضمان توفّر هذا الادّعاء مطلقًا.

profile عنوان URL لصفحة الملف الشخصي للمستخدم يمكن تقديمها في الحالات التالية:
  • تضمّن نطاق الطلب السلسلة "الملف الشخصي"
  • يتم عرض الرمز المميّز للمعرّف من إعادة تحميل الرمز المميّز

عند توفّر مطالبات profile، يمكنك استخدامها لتعديل سجلّات المستخدمين في تطبيقك. يُرجى العِلم أنّه لا يمكن ضمان توفّر هذا الادّعاء مطلقًا.

6. مصادقة المستخدم

بعد الحصول على معلومات المستخدم من الرمز المميّز للتعريف، عليك الاستعلام عن قاعدة بيانات المستخدمين في تطبيقك. إذا كان المستخدم موجودًا في قاعدة بياناتك، عليك بدء جلسة تطبيق لهذا المستخدم إذا كانت جميع متطلبات تسجيل الدخول مستوفاة من خلال الردّ من واجهة برمجة التطبيقات في Google.

إذا لم يكن المستخدم متوفّرًا في قاعدة بيانات المستخدمين، عليك إعادة توجيهه إلى مسار الاشتراك الخاص بالمستخدمين الجدد. قد تتمكّن من تسجيل المستخدم تلقائيًا استنادًا إلى المعلومات التي تتلقّاها من Google، أو على الأقل قد تتمكّن من ملء العديد من الحقول المطلوبة في نموذج التسجيل مسبقًا. بالإضافة إلى المعلومات الواردة في الرمز المميّز للتعريف، يمكنك الحصول على معلومات إضافية حول ملف المستخدم الشخصي من خلال نقاط نهاية ملف المستخدم الشخصي.

مواضيع متقدّمة

توضّح الأقسام التالية Google OAuth 2.0 API بمزيد من التفصيل. هذه المعلومات موجّهة للمطوّرين الذين لديهم متطلبات متقدّمة في ما يتعلّق بالمصادقة والتفويض.

الوصول إلى Google APIs الأخرى

من مزايا استخدام OAuth 2.0 للمصادقة أنّه يمكن لتطبيقك الحصول على إذن لاستخدام Google APIs أخرى نيابةً عن المستخدم (مثل YouTube أو Google Drive أو "تقويم Google" أو "جهات اتصال Google") في الوقت نفسه الذي تتم فيه مصادقة المستخدم. لإجراء ذلك، عليك تضمين النطاقات الأخرى التي تحتاج إليها في طلب المصادقة الذي ترسله إلى Google. على سبيل المثال، لإضافة الفئة العمرية للمستخدم إلى طلب المصادقة، يجب تمرير مَعلمة نطاق بقيمة openid email https://www.googleapis.com/auth/profile.agerange.read. يتم توجيه المستخدم بشكل مناسب على شاشة طلب الموافقة. سيسمح رمز الدخول الذي تتلقّاه من Google لتطبيقك بالوصول إلى جميع واجهات برمجة التطبيقات ذات الصلة بنطاقات الوصول التي طلبتها وتم منحها لك.

الرموز المميّزة لإعادة التحميل

في طلبك للوصول إلى واجهة برمجة التطبيقات، يمكنك طلب عرض رمز مميز لإعادة التحميل أثناء تبادل code. يوفّر الرمز المميّز لإعادة التحميل لتطبيقك إمكانية الوصول المستمر إلى Google APIs عندما لا يكون المستخدم متصلاً بتطبيقك. لطلب رمز مميّز لإعادة التحميل، أضِف المَعلمة access_type واضبطها على offline في طلب المصادقة.

الاعتبارات:

  • احرص على تخزين الرمز المميز لإعادة التحميل بشكل آمن ودائم، لأنّه لا يمكنك الحصول عليه إلا في المرة الأولى التي تنفّذ فيها عملية تبادل الرموز.
  • هناك حدود لعدد الرموز المميزة لإعادة التحميل التي يتم إصدارها: حد واحد لكل مجموعة من العميل/المستخدم، وحد آخر لكل مستخدم في جميع العملاء. إذا طلب تطبيقك عددًا كبيرًا جدًا من الرموز المميزة لإعادة التحميل، قد يواجه هذه الحدود، وفي هذه الحالة تتوقف الرموز المميزة لإعادة التحميل القديمة عن العمل.

لمزيد من المعلومات، يُرجى الاطّلاع على إعادة تحميل رمز الدخول (التشغيل بلا إنترنت).

يمكنك أن تطلب من المستخدم إعادة تفويض تطبيقك من خلال ضبط المَعلمة prompt على consent في طلب المصادقة. عند تضمين prompt=consent، يتم عرض شاشة طلب الموافقة في كل مرة يطلب فيها تطبيقك تفويضًا لنطاقات الوصول، حتى إذا تم منح جميع النطاقات سابقًا لمشروعك على Google APIs. لهذا السبب، لا تُدرِج السمة prompt=consent إلا عند الضرورة.

لمزيد من المعلومات عن المَعلمة prompt، يُرجى الاطّلاع على prompt في جدول مَعلمات معرّف الموارد المنتظم (URI) للمصادقة.

مَعلمات معرّف الموارد المنتظم (URI) للمصادقة

يقدّم الجدول التالي أوصافًا أكثر اكتمالاً للمَعلمات التي تقبلها واجهة برمجة التطبيقات لمصادقة OAuth 2.0 من Google.

المَعلمة مطلوب الوصف
client_id (مطلوب) سلسلة معرِّف العميل التي تحصل عليها من صفحة "العملاء" في Cloud Console، كما هو موضّح في مقالة الحصول على بيانات اعتماد OAuth 2.0.
nonce (مطلوب) قيمة عشوائية ينشئها تطبيقك تتيح الحماية من إعادة التشغيل.
response_type (مطلوب) إذا كانت القيمة code، يتم إطلاق مسار رمز تفويض أساسي، يتطلّب إرسال طلب POST إلى نقطة نهاية الرمز المميّز للحصول على الرموز المميّزة. إذا كانت القيمة token id_token أو id_token token، يتم إطلاق تدفّق ضمني، يتطلّب استخدام JavaScript في معرّف الموارد المنتظم (URI) لإعادة التوجيه من أجل استرداد الرموز المميّزة من معرّف #fragment لمعرّف الموارد المنتظم (URI).
redirect_uri (مطلوب) يحدّد هذا الحقل مكان إرسال الردّ. يجب أن تتطابق قيمة هذه المَعلمة تمامًا مع إحدى قيم إعادة التوجيه المصرَّح بها التي حدّدتها في صفحة "العملاء" ضمن Cloud Console (بما في ذلك مخطّط 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 (اختياري) تُستخدم مَعلمة المطالبات لتحديد حقل اختياري واحد أو أكثر لتضمينه في نقطة نهاية معلومات المستخدم أو أنواع استجابة الرمز المميّز لتعريف طلب المصادقة. القيمة هي عنصر 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 أو ضمن عناوين الطلبات. إذا كنت تخزّن رموز التعريف المميّزة على خادمك، عليك أيضًا تخزينها بأمان.

من الأمور التي تجعل رموز التعريف مفيدة هي إمكانية تمريرها بين مكوّنات مختلفة من تطبيقك. يمكن لهذه المكوّنات استخدام رمز التعريف كآلية مصادقة خفيفة لمصادقة التطبيق والمستخدم. ولكن قبل أن تتمكّن من استخدام المعلومات في رمز التعريف المميّز أو الاعتماد عليها كتأكيد على أنّ المستخدم قد أجرى المصادقة، عليك التحقّق من صحتها.

يتطلّب التحقّق من صحة رمز مميّز للتعريف عدة خطوات:

  1. تأكَّد من أنّ جهة الإصدار قد وقّعت على رمز التعريف بشكل صحيح. يتم توقيع الرموز المميّزة الصادرة عن Google باستخدام إحدى الشهادات المتوفّرة في معرّف الموارد المنتظم (URI) المحدّد في قيمة البيانات الوصفية jwks_uri في مستند الاستكشاف.
  2. تأكَّد من أنّ قيمة مطالبة iss في رمز التعريف تساوي https://accounts.google.com أو accounts.google.com.
  3. تأكَّد من أنّ قيمة المطالبة aud في رمز التعريف تتطابق مع معرّف العميل الخاص بتطبيقك.
  4. تحقَّق من عدم انتهاء وقت انتهاء الصلاحية (المطالبة exp) لرمز التعريف المميّز.
  5. إذا حدّدت قيمة مَعلمة hd في الطلب، تأكَّد من أنّ رمز التعريف المميّز يتضمّن مطالبة hd تتطابق مع نطاق مقبول مرتبط بمؤسسة على Google Cloud.

تتضمّن الخطوات من 2 إلى 5 مقارنات بين السلاسل والتواريخ فقط، وهي بسيطة للغاية، لذا لن نوضّحها بالتفصيل هنا.

الخطوة الأولى أكثر تعقيدًا، وتتضمّن التحقّق من التوقيع المشفّر. لأغراض تصحيح الأخطاء، يمكنك استخدام نقطة نهاية tokeninfo من Google للمقارنة بالمعالجة المحلية التي يتم تنفيذها على خادمك أو جهازك. لنفترض أنّ قيمة رمز التعريف المميّز هي XYZ123. بعد ذلك، عليك إلغاء الإشارة إلى معرّف الموارد المنتظم (URI) https://oauth2.googleapis.com/tokeninfo?id_token=XYZ123. إذا كان توقيع الرمز المميّز صالحًا، ستكون الاستجابة هي حمولة JWT في شكل عنصر JSON الذي تم فك ترميزه.

تُعدّ نقطة النهاية tokeninfo مفيدة لتصحيح الأخطاء، ولكن لأغراض الإنتاج، يمكنك استرداد مفاتيح Google العامة من نقطة نهاية المفاتيح وإجراء عملية التحقّق محليًا. يجب استرداد معرّف الموارد المنتظم (URI) للمفاتيح من مستند الاستكشاف باستخدام قيمة البيانات الوصفية jwks_uri. قد يتم تقييد الطلبات المرسَلة إلى نقطة نهاية تصحيح الأخطاء أو قد تخضع لأخطاء متقطّعة.

بما أنّ Google لا تغيّر مفاتيحها العامة إلا نادرًا، يمكنك تخزينها مؤقتًا باستخدام توجيهات ذاكرة التخزين المؤقت لاستجابة HTTP، وفي الغالبية العظمى من الحالات، يمكنك إجراء عملية التحقّق المحلية بكفاءة أكبر من استخدام نقطة النهاية tokeninfo. تتطلب عملية التحقّق هذه استرداد الشهادات وتحليلها، وإجراء طلبات التشفير المناسبة للتحقّق من التوقيع. لحسن الحظ، تتوفّر مكتبات تم تصحيح أخطائها بشكل جيد في مجموعة متنوعة من اللغات لإنجاز ذلك (راجِع jwt.io).

الحصول على معلومات ملف المستخدم الشخصي

للحصول على معلومات إضافية عن الملف الشخصي للمستخدم، يمكنك استخدام رمز الدخول (الذي يتلقّاه تطبيقك أثناء عملية المصادقة) ومعيار اتصال OpenID:

  1. للالتزام بمعيار OpenID، يجب تضمين قيم نطاق openid profile في طلب المصادقة.

    إذا أردت تضمين عنوان البريد الإلكتروني للمستخدم، يمكنك تحديد قيمة نطاق إضافية تبلغ email. لتحديد كل من profile وemail، يمكنك تضمين المَعلمة التالية في عنوان URI لطلب المصادقة:

    scope=openid%20profile%20email
    
  2. أضِف رمز الدخول إلى عنوان التفويض وأرسِل طلب HTTPS GET إلى نقطة نهاية معلومات المستخدم التي يجب استردادها من مستند الاستكشاف باستخدام قيمة البيانات الوصفية userinfo_endpoint. تتضمّن استجابة userinfo معلومات عن المستخدم، كما هو موضّح في OpenID Connect Standard Claims وقيمة البيانات الوصفية claims_supported لمستند الاستكشاف. يمكن للمستخدمين أو مؤسساتهم اختيار تقديم حقول معيّنة أو حجبها، لذا قد لا تحصل على معلومات لكل حقل في نطاقات الوصول المصرَّح بها.

مستند الاستكشاف

يتطلّب بروتوكول OpenID Connect استخدام نقاط نهاية متعددة لمصادقة المستخدمين، ولطلب الموارد، بما في ذلك الرموز المميّزة ومعلومات المستخدمين والمفاتيح العامة.

لتبسيط عمليات التنفيذ وزيادة المرونة، يسمح OpenID Connect باستخدام "مستند الاستكشاف"، وهو مستند JSON موجود في موقع معروف يحتوي على أزواج من القيم الرئيسية التي توفّر تفاصيل حول إعدادات موفّر OpenID Connect، بما في ذلك معرّفات الموارد المنتظمة (URI) لنقاط النهاية الخاصة بالتفويض والرمز المميّز والإبطال ومعلومات المستخدم والمفاتيح العامة. يمكن استرداد مستند الاستكشاف لخدمة OpenID Connect من Google من:

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

لاستخدام خدمات OpenID Connect من Google، عليك ترميز معرّف الموارد المنتظم (URI) لمستند الاستكشاف (https://accounts.google.com/.well-known/openid-configuration) في تطبيقك. يجلب تطبيقك المستند ويطبّق قواعد التخزين المؤقت في الاستجابة، ثم يستردّ معرّفات الموارد المنتظمة (URI) لنقاط النهاية منه حسب الحاجة. على سبيل المثال، لمصادقة مستخدم، يسترد الرمز قيمة البيانات الوصفية 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).