نظرة عامة
تضيف ميزة الربط السلس لتسجيل الدخول بحساب Google OAuth ميزة "تسجيل الدخول بحساب Google" بالإضافة إلى ربط OAuth. ويوفّر ذلك تجربة ربط سلسة لمستخدمي Google، ويساعد أيضًا على إنشاء الحساب، ما يسمح للمستخدم بإنشاء حساب جديد على خدمتك باستخدام حسابه على Google.
لإجراء ربط الحساب باستخدام OAuth وتسجيل الدخول بحساب Google، يُرجى اتّباع الخطوات العامة التالية:
- أولاً، اطلب من المستخدم منح الموافقة للوصول إلى ملفه الشخصي على Google.
- استخدِم المعلومات الواردة في ملفه الشخصي للتحقق من وجود حساب المستخدم.
- بالنسبة إلى المستخدمين الحاليين، اربط الحسابات.
- إذا لم تتمكّن من العثور على تطابق لمستخدم Google في نظام المصادقة، تحقّق من الرمز المميّز للمعرّف الذي تلقّيته من Google. يمكنك بعد ذلك إنشاء مستخدم استنادًا إلى معلومات الملف الشخصي الموجودة في الرمز المميز للمعرّف.
![يوضح هذا الرقم خطوات المستخدم لربط حسابه على Google باستخدام مسار الربط السلس. تعرض لقطة الشاشة الأولى كيف يمكن للمستخدم اختيار تطبيقك للربط. تتيح لقطة الشاشة الثانية للمستخدم تأكيد ما إذا كان لديه حساب حالي في خدمتك. تتيح لقطة الشاشة الثالثة للمستخدم اختيار حساب Google الذي يريد الربط به. تعرض لقطة الشاشة الرابعة تأكيدًا لربط حساب Google بتطبيقك. تعرض لقطة الشاشة الخامسة حساب مستخدم تم ربطه بنجاح في تطبيق Google.](https://developers-dot-devsite-v2-prod.appspot.com/static/identity/account-linking/images/streamlined-linking-flow.png?authuser=6&hl=ar)
الشكل 1. ربط الحسابات على هاتف المستخدم من خلال الربط السلس
متطلبات الربط السلس
- نفِّذ تدفق ربط OAuth الأساسي. يجب أن تتوافق خدمتك مع نقاط نهاية التفويض والتبادل المميز المتوافقة مع OAuth 2.0.
- يجب أن تتوافق نقطة نهاية تبادل الرموز المميّزة مع عمليات تأكيد JSON Web Token (JWT) وتنفيذ عناصر
check
وcreate
وget
.
تنفيذ خادم OAuth
يجب أن تتوافق نقطة نهاية تبادل الرموز المميّزة مع أهداف check
وcreate
وget
. يوضّح ما يلي الخطوات المكتملة من خلال مسار ربط الحساب، ويشير إلى الحالات التي يتم فيها استدعاء الأغراض المختلفة:
- هل يمتلك المستخدم حسابًا في نظام المصادقة؟ (يحدد المستخدم عن طريق اختيار "نعم" أو "لا")
- نعم : هل يستخدم المستخدم البريد الإلكتروني المرتبط بحسابه على Google لتسجيل الدخول إلى المنصة؟ (يحدد المستخدم عن طريق اختيار "نعم" أو "لا")
- نعم : هل يمتلك المستخدم حسابًا مطابقًا في نظام المصادقة؟ (تم طلب
check intent
للتأكيد)- نعم: يتم طلب
get intent
ويتم ربط الحساب في حال نجاح عمليات الإرجاع. - لا : هل تريد إنشاء حساب جديد؟ (يحدد المستخدم عن طريق اختيار "نعم" أو "لا")
- نعم: يتم طلب
create intent
ويتم ربط الحساب إذا تم إنشاء طلب إعادة السلع بنجاح. - لا : يتم تشغيل تدفق OAuth على الويب ويتم توجيه المستخدم إلى المتصفح التابع له، ويتم منح المستخدم خيار الربط بعنوان بريد إلكتروني مختلف.
- نعم: يتم طلب
- نعم: يتم طلب
- لا : يتم تشغيل تدفق OAuth على الويب، ويتم توجيه المستخدم إلى المتصفح التابع له، ويُمنح المستخدم خيار الربط بعنوان بريد إلكتروني مختلف.
- نعم : هل يمتلك المستخدم حسابًا مطابقًا في نظام المصادقة؟ (تم طلب
- لا : هل يمتلك المستخدم حسابًا مطابقًا في نظام المصادقة؟ (تم طلب
check intent
للتأكيد)- نعم : يتم طلب
get intent
ويتم ربط الحساب في حال نجاح عمليات الإرجاع. - لا:
create intent
يتم ربطها ويتم ربط الحساب في حال إنشاء عمليات إرجاع نية الشراء بنجاح.
- نعم : يتم طلب
- نعم : هل يستخدم المستخدم البريد الإلكتروني المرتبط بحسابه على Google لتسجيل الدخول إلى المنصة؟ (يحدد المستخدم عن طريق اختيار "نعم" أو "لا")
البحث عن حساب مستخدم حالي (التحقّق من القصد)
بعد أن يوافق المستخدم على الوصول إلى ملفه الشخصي على Google، ترسل Google طلبًا يحتوي على تأكيد موقّع لهوية مستخدم Google. يحتوي التأكيد على معلومات تتضمن رقم تعريف حساب المستخدم واسمه وعنوان بريده الإلكتروني على Google. نقطة نهاية تبادل الرموز المميزة التي تم إعدادها لمشروعك تتولى هذا الطلب.
إذا كان حساب Google المقابل موجودًا في نظام المصادقة الذي تستخدمه، ستستجيب نقطة نهاية تبادل الرموز المميّزة باستخدام account_found=true
. وإذا لم يتطابق حساب Google مع مستخدم حالي، ستعرض نقطة نهاية تبادل الرموز المميّزة خطأ HTTP 404 لم يتم العثور على الصفحة في account_found=false
.
يكون الطلب على النحو التالي:
POST /token HTTP/1.1 Host: oauth2.example.com Content-Type: application/x-www-form-urlencoded grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&intent=check&assertion=JWT&scope=SCOPES&client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET
يجب أن تكون نقطة نهاية تبادل الرمز المميز قادرة على التعامل مع المعلمات التالية:
معلّمات نقاط نهاية الرمز المميز | |
---|---|
intent |
بالنسبة إلى هذه الطلبات، تكون قيمة هذه المعلمة check . |
grant_type |
نوع الرمز المميّز الذي يتم تبادله بالنسبة إلى هذه الطلبات، تحتوي هذه المعلَمة على القيمة urn:ietf:params:oauth:grant-type:jwt-bearer . |
assertion |
رمز JSON المميّز للويب (JWT) الذي يقدّم تأكيدًا موقّعًا هوية المستخدم على Google. يحتوي JWT على معلومات تتضمن رقم تعريف حساب المستخدم على Google واسمه وعنوان بريده الإلكتروني. |
client_id |
معرِّف العميل الذي تم تخصيصه إلى Google. |
client_secret |
سر العميل الذي حددته لـ Google. |
للردّ على طلبات intent في check
، يجب أن تنفّذ نقطة نهاية تبادل الرموز المميزة الخطوات التالية:
- التحقّق من صحة تأكيد JWT وفك ترميزه
- تحقق مما إذا كان حساب Google موجودًا في نظام المصادقة.
Validate and decode the JWT assertion
You can validate and decode the JWT assertion by using a JWT-decoding library for your language. Use Google's public keys, available in JWK or PEM formats, to verify the token's signature.
When decoded, the JWT assertion looks like the following example:
{ "sub": "1234567890", // The unique ID of the user's Google Account "iss": "https://accounts.google.com", // The assertion's issuer "aud": "123-abc.apps.googleusercontent.com", // Your server's client ID "iat": 233366400, // Unix timestamp of the assertion's creation time "exp": 233370000, // Unix timestamp of the assertion's expiration time "name": "Jan Jansen", "given_name": "Jan", "family_name": "Jansen", "email": "jan@gmail.com", // If present, the user's email address "email_verified": true, // true, if Google has verified the email address "hd": "example.com", // If present, the host domain of the user's GSuite email address // If present, a URL to user's profile picture "picture": "https://lh3.googleusercontent.com/a-/AOh14GjlTnZKHAeb94A-FmEbwZv7uJD986VOF1mJGb2YYQ", "locale": "en_US" // User's locale, from browser or phone settings }
In addition to verifying the token's signature, verify that the assertion's
issuer (iss
field) is https://accounts.google.com
, that the audience
(aud
field) is your assigned client ID, and that the token has not expired
(exp
field).
Using the email
, email_verified
and hd
fields you can determine if
Google hosts and is authoritative for an email address. In cases where Google is
authoritative the user is currently known to be the legitimate account owner
and you may skip password or other challenges methods. Otherwise, these methods
can be used to verify the account prior to linking.
Cases where Google is authoritative:
email
has a@gmail.com
suffix, this is a Gmail account.email_verified
is true andhd
is set, this is a G Suite account.
Users may register for Google Accounts without using Gmail or G Suite. When
email
does not contain a @gmail.com
suffix and hd
is absent Google is not
authoritative and password or other challenge methods are recommended to verify
the user. email_verified
can also be true as Google initially verified the
user when the Google account was created, however ownership of the third party
email account may have since changed.
تحقق مما إذا كان حساب Google موجودًا في نظام المصادقة.
تحقّق مما إذا كان أيٌّ من الشروط التالية صحيحًا:
- يمكنك العثور على رقم تعريف حساب Google في حقل
sub
التأكيد، في قاعدة بيانات المستخدم. - يتطابق عنوان البريد الإلكتروني في التأكيد مع مستخدم في قاعدة بيانات المستخدم.
إذا كان أي من الشرطين صحيحًا، قد يكون المستخدم قد اشترك من قبل. في هذه الحالة، يمكنك عرض رد كما يلي:
HTTP/1.1 200 Success Content-Type: application/json;charset=UTF-8 { "account_found":"true", }
إذا لم يتطابق رقم تعريف حساب Google أو عنوان البريد الإلكتروني المحدّد في التقييم مع مستخدم في قاعدة البيانات، لم يشترك المستخدم بعد. في هذه الحالة، تحتاج نقطة نهاية تبادل الرموز المميزة إلى الرد مع تضمين خطأ HTTP 404 الذي يحدد "account_found": "false"
، كما هو موضح في المثال التالي:
HTTP/1.1 404 Not found Content-Type: application/json;charset=UTF-8 { "account_found":"false", }
Handle automatic linking (get intent)
After the user gives consent to access their Google profile, Google sends a request that contains a signed assertion of the Google user's identity. The assertion contains information that includes the user's Google Account ID, name, and email address. The token exchange endpoint configured for your project handles that request.
If the corresponding Google Account is already present in your authentication
system, your token exchange endpoint returns a token for the user. If the
Google Account doesn't match an existing user, your token exchange endpoint
returns a linking_error
error and optional login_hint
.
The request has the following form:
POST /token HTTP/1.1 Host: oauth2.example.com Content-Type: application/x-www-form-urlencoded grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&intent=get&assertion=JWT&scope=SCOPES&client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET
Your token exchange endpoint must be able to handle the following parameters:
Token endpoint parameters | |
---|---|
intent |
For these requests, the value of this parameter is get . |
grant_type |
The type of token being exchanged. For these requests, this
parameter has the value urn:ietf:params:oauth:grant-type:jwt-bearer . |
assertion |
A JSON Web Token (JWT) that provides a signed assertion of the Google user's identity. The JWT contains information that includes the user's Google Account ID, name, and email address. |
scope |
Optional: Any scopes that you've configured Google to request from users. |
client_id |
The client ID you assigned to Google. |
client_secret |
The client secret you assigned to Google. |
To respond to the get
intent requests, your token exchange endpoint must perform the following steps:
- Validate and decode the JWT assertion.
- Check if the Google account is already present in your authentication system.
Validate and decode the JWT assertion
You can validate and decode the JWT assertion by using a JWT-decoding library for your language. Use Google's public keys, available in JWK or PEM formats, to verify the token's signature.
When decoded, the JWT assertion looks like the following example:
{ "sub": "1234567890", // The unique ID of the user's Google Account "iss": "https://accounts.google.com", // The assertion's issuer "aud": "123-abc.apps.googleusercontent.com", // Your server's client ID "iat": 233366400, // Unix timestamp of the assertion's creation time "exp": 233370000, // Unix timestamp of the assertion's expiration time "name": "Jan Jansen", "given_name": "Jan", "family_name": "Jansen", "email": "jan@gmail.com", // If present, the user's email address "email_verified": true, // true, if Google has verified the email address "hd": "example.com", // If present, the host domain of the user's GSuite email address // If present, a URL to user's profile picture "picture": "https://lh3.googleusercontent.com/a-/AOh14GjlTnZKHAeb94A-FmEbwZv7uJD986VOF1mJGb2YYQ", "locale": "en_US" // User's locale, from browser or phone settings }
In addition to verifying the token's signature, verify that the assertion's
issuer (iss
field) is https://accounts.google.com
, that the audience
(aud
field) is your assigned client ID, and that the token has not expired
(exp
field).
Using the email
, email_verified
and hd
fields you can determine if
Google hosts and is authoritative for an email address. In cases where Google is
authoritative the user is currently known to be the legitimate account owner
and you may skip password or other challenges methods. Otherwise, these methods
can be used to verify the account prior to linking.
Cases where Google is authoritative:
email
has a@gmail.com
suffix, this is a Gmail account.email_verified
is true andhd
is set, this is a G Suite account.
Users may register for Google Accounts without using Gmail or G Suite. When
email
does not contain a @gmail.com
suffix and hd
is absent Google is not
authoritative and password or other challenge methods are recommended to verify
the user. email_verified
can also be true as Google initially verified the
user when the Google account was created, however ownership of the third party
email account may have since changed.
Check if the Google account is already present in your authentication system
Check whether either of the following conditions are true:
- The Google Account ID, found in the assertion's
sub
field, is in your user database. - The email address in the assertion matches a user in your user database.
If an account is found for the user, issue an access token and return the values in a JSON object in the body of your HTTPS response, like in the following example:
{ "token_type": "Bearer", "access_token": "ACCESS_TOKEN", "expires_in": SECONDS_TO_EXPIRATION }
In some cases, account linking based on ID token might fail for the user. If it
does so for any reason, your token exchange endpoint needs to reply with a HTTP
401 error that specifies error=linking_error
, as the following example shows:
HTTP/1.1 401 Unauthorized Content-Type: application/json;charset=UTF-8 { "error":"linking_error", "login_hint":"foo@bar.com" }
When Google receives a 401 error response with linking_error
, Google sends
the user to your authorization endpoint with login_hint
as a parameter. The
user completes account linking using the OAuth linking flow in their browser.
التعامل مع إنشاء الحساب من خلال تسجيل الدخول إلى Google (إنشاء هدف)
عندما يحتاج المستخدم إلى إنشاء حساب على خدمتك، تقدم Google طلبًا إلى نقطة نهاية تبادل الرموز المميزة التي تحدد intent=create
.
يكون الطلب على النحو التالي:
POST /token HTTP/1.1 Host: oauth2.example.com Content-Type: application/x-www-form-urlencoded response_type=token&grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&scope=SCOPES&intent=create&assertion=JWT&client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET
يجب أن معالجة نقطة نهاية تبادل الرموز المميزة المعلمات التالية:
معلّمات نقاط نهاية الرمز المميز | |
---|---|
intent |
بالنسبة إلى هذه الطلبات، قيمة هذه المعلمة هي create . |
grant_type |
نوع الرمز المميّز الذي يتم تبادله بالنسبة إلى هذه الطلبات، تحتوي هذه المعلَمة على القيمة urn:ietf:params:oauth:grant-type:jwt-bearer . |
assertion |
رمز JSON المميّز للويب (JWT) الذي يقدّم تأكيدًا موقّعًا هوية المستخدم على Google. يحتوي JWT على معلومات تتضمن رقم تعريف حساب المستخدم على Google واسمه وعنوان بريده الإلكتروني. |
client_id |
معرِّف العميل الذي تم تخصيصه إلى Google. |
client_secret |
سر العميل الذي حددته لـ Google. |
يحتوي JWT ضمن المعلمة assertion
على رقم تعريف حساب Google للمستخدم، واسمه، وعنوان بريده الإلكتروني، والذي يمكنك استخدامه لإنشاء حساب جديد على خدمتك.
للردّ على طلبات intent في create
، يجب أن تنفّذ نقطة نهاية تبادل الرموز المميزة الخطوات التالية:
- التحقّق من صحة تأكيد JWT وفك ترميزه
- تحقّق من صحة معلومات المستخدم وأنشئ حسابًا جديدًا.
Validate and decode the JWT assertion
You can validate and decode the JWT assertion by using a JWT-decoding library for your language. Use Google's public keys, available in JWK or PEM formats, to verify the token's signature.
When decoded, the JWT assertion looks like the following example:
{ "sub": "1234567890", // The unique ID of the user's Google Account "iss": "https://accounts.google.com", // The assertion's issuer "aud": "123-abc.apps.googleusercontent.com", // Your server's client ID "iat": 233366400, // Unix timestamp of the assertion's creation time "exp": 233370000, // Unix timestamp of the assertion's expiration time "name": "Jan Jansen", "given_name": "Jan", "family_name": "Jansen", "email": "jan@gmail.com", // If present, the user's email address "email_verified": true, // true, if Google has verified the email address "hd": "example.com", // If present, the host domain of the user's GSuite email address // If present, a URL to user's profile picture "picture": "https://lh3.googleusercontent.com/a-/AOh14GjlTnZKHAeb94A-FmEbwZv7uJD986VOF1mJGb2YYQ", "locale": "en_US" // User's locale, from browser or phone settings }
In addition to verifying the token's signature, verify that the assertion's
issuer (iss
field) is https://accounts.google.com
, that the audience
(aud
field) is your assigned client ID, and that the token has not expired
(exp
field).
Using the email
, email_verified
and hd
fields you can determine if
Google hosts and is authoritative for an email address. In cases where Google is
authoritative the user is currently known to be the legitimate account owner
and you may skip password or other challenges methods. Otherwise, these methods
can be used to verify the account prior to linking.
Cases where Google is authoritative:
email
has a@gmail.com
suffix, this is a Gmail account.email_verified
is true andhd
is set, this is a G Suite account.
Users may register for Google Accounts without using Gmail or G Suite. When
email
does not contain a @gmail.com
suffix and hd
is absent Google is not
authoritative and password or other challenge methods are recommended to verify
the user. email_verified
can also be true as Google initially verified the
user when the Google account was created, however ownership of the third party
email account may have since changed.
التحقُّق من صحة معلومات المستخدم وإنشاء حساب جديد
تحقّق مما إذا كان أيٌّ من الشروط التالية صحيحًا:
- يمكنك العثور على رقم تعريف حساب Google في حقل
sub
التأكيد، في قاعدة بيانات المستخدم. - يتطابق عنوان البريد الإلكتروني في التأكيد مع مستخدم في قاعدة بيانات المستخدم.
إذا كان أي من الشرطين صحيحًا، اطلب من المستخدم ربط حسابه الحالي على Google. ولإجراء ذلك، يجب الردّ على الطلب الذي يتضمّن الخطأ HTTP 401 الذي يحدّد error=linking_error
ويمنح المستخدم عنوان البريد الإلكتروني على أنه login_hint
. في ما يلي نموذج ردّ:
HTTP/1.1 401 Unauthorized Content-Type: application/json;charset=UTF-8 { "error":"linking_error", "login_hint":"foo@bar.com" }
عندما تتلقّى Google استجابة خطأ 401 مع linking_error
، ترسل Google المستخدم إلى نقطة نهاية التفويض مع معلمة login_hint
. يُكمل المستخدم ربط الحساب باستخدام تدفق ربط OAuth في المتصفح.
إذا لم يكن أيٌّ من الشرطين صحيحًا، أنشِئ حساب مستخدم جديدًا باستخدام المعلومات الواردة في JWT. لا يتم عادةً إعداد كلمة مرور للحسابات الجديدة. من المستحسن إضافة تسجيل الدخول بحساب Google إلى الأنظمة الأساسية الأخرى لتمكين المستخدمين من تسجيل الدخول باستخدام حساب Google عبر مساحات عرض تطبيقك. يمكنك بدلاً من ذلك إرسال رسالة إلكترونية إلى المستخدم تتضمن رابطًا يبدأ بتدفق استرداد كلمة المرور للسماح للمستخدم بضبط كلمة مرور لتسجيل الدخول على أنظمة أساسية أخرى.
عند اكتمال الإنشاء، يمكنك إصدار رمز الدخول وعرض القيم في كائن JSON في نص استجابة HTTPS، كما في المثال التالي:
{ "token_type": "Bearer", "access_token": "ACCESS_TOKEN", "expires_in": SECONDS_TO_EXPIRATION }
الحصول على معرِّف عميل Google API
سيُطلب منك تقديم معرّف عميل Google API أثناء عملية تسجيل ربط الحساب.
للحصول على معرِّف عميل واجهة برمجة التطبيقات باستخدام المشروع الذي أنشأته أثناء إكمال خطوات ربط OAuth. ولإجراء ذلك، أكمِل الخطوات التالية:
- افتح صفحة بيانات الاعتماد في وحدة تحكّم Google API.
أنشئ مشروع Google APIs أو اختَره.
إذا لم يكن مشروعك يحتوي على معرِّف عميل لنوع تطبيق الويب، انقر على إنشاء بيانات اعتماد >؛ معرِّف عميل بروتوكول OAuth لإنشاء معرِّف. وتأكّد من تضمين نطاق موقعك الإلكتروني في المربّع مصادر JavaScript المعتمَدة. عند إجراء اختبارات أو تطوير محلي، عليك إضافة كل من
http://localhost
وhttp://localhost:<port_number>
إلى حقل مصادر JavaScript المعتمَدة.
التحقّق من صحة عملية التنفيذ
يمكنك التحقق من صحة التطبيق الخاص بك باستخدام ملعب أوث 2.0 الأداة.
في الأداة ، قم بالخطوات التالية:
- انقر فوق تكوين لفتح نافذة تكوين أوث 2.0.
- في مجال تدفق أوث، اختر من جانب العميل.
- في مجال أوث النهايات، حدد مخصص.
- حدد نقطة نهاية OAuth 2.0 ومعرف العميل الذي عينته لـ Google في الحقول المقابلة.
- في القسم الخطوة 1، لا تحدد أي نطاقات جوجل. بدلاً من ذلك ، اترك هذا الحقل فارغًا أو اكتب نطاقًا صالحًا لخادمك (أو سلسلة عشوائية إذا كنت لا تستخدم نطاقات OAuth). عند الانتهاء من ذلك، انقر فوق تخويل واجهات برمجة التطبيقات.
- في الأقسام الخطوة 2 و الخطوة 3، انتقل من خلال تدفق أوث 2.0 والتحقق من أن كل خطوة تعمل على النحو المنشود.
يمكنك التحقق من صحة التطبيق الخاص بك باستخدام حساب Google ربط تجريبي الأداة.
في الأداة ، قم بالخطوات التالية:
- انقر على تسجيل الدخول باستخدام زر جوجل.
- اختر الحساب الذي ترغب في ربطه.
- أدخل معرف الخدمة.
- اختياريًا ، أدخل نطاقًا واحدًا أو أكثر ستطلب الوصول إليه.
- انقر فوق ابدأ تجريبي.
- عند المطالبة ، أكد أنه يمكنك الموافقة ورفض طلب الربط.
- تأكد من إعادة توجيهك إلى النظام الأساسي الخاص بك.