پیوند حساب Google با OAuth

حساب‌ها با استفاده از جریان‌های کد ضمنی و مجوزدهی استاندارد صنعتی OAuth 2.0 به هم مرتبط می‌شوند.

احتیاط: جریان ضمنی برای جریان‌های MCP، UCP و Agent-driven پشتیبانی نمی‌شود . به‌طورکلی برای همه ادغام‌های جدید توصیه نمی‌شود. به‌جای آن از جریان کد مجوز استفاده کنید.

سرویس شما باید از نقاط پایانی احراز هویت و تبادل توکن سازگار با OAuth 2.0 پشتیبانی کند.

In the implicit flow, Google opens your authorization endpoint in the user's browser. After successful sign in, you return a long-lived access token to Google. This access token is now included in every request sent from Google.

In the authorization code flow, you need two endpoints:

• The authorization endpoint, which presents the sign-in UI to your users that aren't already signed in. The authorization endpoint also creates a short-lived authorization code to record users' consent to the requested access.

• The token exchange endpoint, which is responsible for two types of exchanges:

  1. Exchanges an authorization code for a long-lived refresh token and a short-lived access token. This exchange happens when the user goes through the account linking flow.
  2. Exchanges a long-lived refresh token for a short-lived access token. This exchange happens when Google needs a new access token because the one it had expired.

Choose an OAuth 2.0 flow

Although the implicit flow is simpler to implement, Google recommends that access tokens issued by the implicit flow never expire. This is because the user is forced to link their account again after a token expires with the implicit flow. If you need token expiration for security reasons, we strongly recommend that you use the authorization code flow instead.

Note: Use the following buttons to choose which OAuth 2.0 flow you want to implement. If needed, the content of this guide will reload to match your choice.

Implicit flow Authorization code

Design guidelines

This section describes the design requirements and recommendations for the user screen that you host for OAuth linking flows. After it's called by Google's app, your platform displays a sign in to Google page and account linking consent screen to the user. The user is directed back to Google's app after giving their consent to link accounts.

Figure 1. Account linking user sign in to Google and consent screens.

Requirements

1. You must communicate that the user’s account will be linked to Google, not a specific Google product like Google Home or Google Assistant.

Recommendations

We recommend that you do the following:

1. Display Google's Privacy Policy. Include a link to Google’s Privacy Policy on the consent screen.

2. Data to be shared. Use clear and concise language to tell the user what data of theirs Google requires and why.

3. Clear call-to-action. State a clear call-to-action on your consent screen, such as “Agree and link.” This is because users need to understand what data they're required to share with Google to link their accounts.

4. Ability to cancel. Provide a way for users to go back or cancel, if they choose not to link.

5. Clear sign-in process. Ensure that users have clear method for signing in to their Google account, such as fields for their username and password or Sign in with Google.

6. Ability to unlink. Offer a mechanism for users to unlink, such as a URL to their account settings on your platform. Alternatively, you can include a link to Google Account where users can manage their linked account.

7. Ability to change user account. Suggest a method for users to switch their account(s). This is especially beneficial if users tend to have multiple accounts.

   • If a user must close the consent screen to switch accounts, send a recoverable error to Google so the user can sign in to the desired account with OAuth linking and the implicit flow.

8. Include your logo. Display your company logo on the consent screen. Use your style guidelines to place your logo. If you wish to also display Google's logo, see Logos and trademarks.

Figure 2. Design guidelines for user sign in to Google and consent screens.

پروژه را ایجاد کنید

توجه: شما می‌توانید از یک پروژه موجود دوباره استفاده کنید و نیازی به ایجاد یک پروژه جدید برای پیوند حساب کاربری ندارید.

برای ایجاد پروژه خود با استفاده از پیوند حساب:

1. به کنسول API گوگل بروید.
2. روی ایجاد پروژه کلیک کنید.
3. یک نام وارد کنید یا پیشنهاد تولید شده را بپذیرید.
4. فیلدهای باقی مانده را تأیید یا ویرایش کنید.
5. روی ایجاد کلیک کنید.

برای مشاهده شناسه پروژه خود:

1. به کنسول API گوگل بروید.
2. پروژه خود را در جدول صفحه اصلی پیدا کنید. شناسه پروژه در ستون شناسه نمایش داده می‌شود.

صفحه رضایت OAuth خود را پیکربندی کنید

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

1. صفحه‌ی رضایت‌نامه‌ی OAuth را در کنسول Google APIs باز کنید.
2. در صورت درخواست، پروژه‌ای را که تازه ایجاد کرده‌اید انتخاب کنید.

3. در صفحه «صفحه رضایت OAuth»، فرم را پر کنید و روی دکمه «ذخیره» کلیک کنید.

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

   لوگوی برنامه: تصویری در صفحه رضایت‌نامه که به کاربران کمک می‌کند برنامه شما را بشناسند. این لوگو در صفحه رضایت‌نامه پیوند حساب و در تنظیمات حساب نمایش داده می‌شود.

   ایمیل پشتیبانی: برای اینکه کاربران بتوانند در مورد رضایت خود با شما تماس بگیرند.

   حوزه‌های دسترسی برای APIهای گوگل: حوزه‌ها به برنامه شما اجازه می‌دهند تا به داده‌های خصوصی گوگل کاربر دسترسی داشته باشد. برای مورد استفاده اتصال حساب گوگل، حوزه پیش‌فرض (ایمیل، نمایه، شناسه باز) کافی است، نیازی به اضافه کردن هیچ حوزه حساسی ندارید. به طور کلی، بهترین روش این است که حوزه‌ها را به صورت تدریجی، در زمانی که دسترسی مورد نیاز است، درخواست کنید، نه اینکه از ابتدا درخواست دهید. اطلاعات بیشتر .

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

   لینک صفحه اصلی برنامه: صفحه اصلی برنامه شما. باید روی یک دامنه مجاز میزبانی شود.

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

   لینک شرایط خدمات برنامه (اختیاری): باید روی یک دامنه مجاز میزبانی شود.

   

   شکل ۱. صفحه رضایت‌نامه اتصال حساب گوگل برای یک برنامه جعلی، Tunery

4. «وضعیت تأیید» را بررسی کنید، اگر درخواست شما نیاز به تأیید دارد، روی دکمه «ارسال برای تأیید» کلیک کنید تا درخواست شما برای تأیید ارسال شود. برای جزئیات بیشتر به الزامات تأیید OAuth مراجعه کنید.

سرور OAuth خود را پیاده‌سازی کنید

پیاده‌سازی سرور OAuth 2.0 از جریان کد مجوز شامل دو نقطه پایانی است که سرویس شما از طریق HTTPS در دسترس قرار می‌دهد. نقطه پایانی اول، نقطه پایانی مجوز است که مسئول یافتن یا اخذ رضایت از کاربران برای دسترسی به داده‌ها است. نقطه پایانی مجوز، یک رابط کاربری ورود به سیستم را به کاربرانی که قبلاً وارد سیستم نشده‌اند ارائه می‌دهد و رضایت آنها را برای دسترسی درخواستی ثبت می‌کند. نقطه پایانی دوم، نقطه پایانی تبادل توکن است که برای دریافت رشته‌های رمزگذاری شده، به نام توکن‌ها، که به کاربر اجازه دسترسی به سرویس شما را می‌دهند، استفاده می‌شود.

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

لینک کردن حساب گوگل: جریان کد مجوز OAuth

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

شکل ۱. توالی رویدادها در جریان کد مجوز OAuth 2.0 برای اتصال حساب گوگل.

نقش‌ها و مسئولیت‌ها

جدول زیر نقش‌ها و مسئولیت‌های بازیگران در جریان OAuth اتصال حساب گوگل (GAL) را تعریف می‌کند. توجه داشته باشید که در GAL، گوگل به عنوان کلاینت OAuth عمل می‌کند، در حالی که سرویس شما به عنوان ارائه‌دهنده هویت/سرویس عمل می‌کند.

بازیگر / جزء	نقش GAL	مسئولیت‌ها
برنامه/سرور گوگل	کلاینت OAuth	جریان را آغاز می‌کند، کد مجوز را دریافت می‌کند، آن را با توکن‌ها مبادله می‌کند و آنها را به طور ایمن ذخیره می‌کند تا به APIهای سرویس شما دسترسی داشته باشد.
نقطه پایانی مجوز شما	سرور احراز هویت	کاربران شما را احراز هویت می‌کند و رضایت آنها را برای اشتراک‌گذاری دسترسی به داده‌هایشان با گوگل دریافت می‌کند.
نقطه پایانی تبادل توکن شما	سرور احراز هویت	کدهای مجوز و توکن‌های به‌روزرسانی را اعتبارسنجی می‌کند و توکن‌های دسترسی را به سرور گوگل صادر می‌کند.
آدرس اینترنتی ریدایرکت گوگل	نقطه پایانی پاسخ به تماس	تغییر مسیر کاربر را از سرویس احراز هویت شما به همراه code و مقادیر state دریافت می‌کند.

یک جلسه جریان کد مجوز OAuth 2.0 که توسط گوگل آغاز شده است، جریان زیر را دارد:

1. گوگل نقطه پایانی احراز هویت شما را در مرورگر کاربر باز می‌کند. اگر جریان برای یک اقدام در دستگاهی که فقط با صدا کار می‌کند شروع شده باشد، گوگل اجرا را به تلفن منتقل می‌کند.
2. کاربر، اگر قبلاً وارد سیستم نشده باشد، وارد سیستم می‌شود و اگر قبلاً اجازه نداده باشد، به گوگل اجازه می‌دهد تا به داده‌هایش با API شما دسترسی پیدا کند.
3. سرویس شما یک کد مجوز ایجاد می‌کند و آن را به گوگل برمی‌گرداند. برای انجام این کار، مرورگر کاربر را به همراه کد مجوز پیوست شده به درخواست، به گوگل هدایت کنید.
4. گوگل کد مجوز را به نقطه پایانی تبادل توکن شما ارسال می‌کند، که صحت کد را تأیید می‌کند و یک توکن دسترسی و یک توکن به‌روزرسانی را برمی‌گرداند. توکن دسترسی یک توکن کوتاه‌مدت است که سرویس شما آن را به عنوان اعتبارنامه برای دسترسی به APIها می‌پذیرد. توکن به‌روزرسانی یک توکن بلندمدت است که گوگل می‌تواند آن را ذخیره کند و از آن برای به دست آوردن توکن‌های دسترسی جدید پس از انقضا استفاده کند.
5. پس از اینکه کاربر فرآیند اتصال حساب کاربری را تکمیل کرد، هر درخواست بعدی که از گوگل ارسال می‌شود حاوی یک توکن دسترسی است.

رسیدگی به درخواست‌های مجوز

وقتی نیاز دارید که با استفاده از جریان کد مجوز OAuth 2.0، اتصال حساب کاربری را انجام دهید، گوگل کاربر را با درخواستی که شامل پارامترهای زیر است به نقطه پایانی مجوز شما ارسال می‌کند:

پارامترهای نقطه پایانی احراز هویت
client_id	شناسه کلاینتی که به گوگل اختصاص داده‌اید.
redirect_uri	آدرس اینترنتی (URL) که پاسخ این درخواست را به آن ارسال می‌کنید.
state	یک مقدار حسابداری که بدون تغییر در URL تغییر مسیر به گوگل بازگردانده می‌شود.
scope	اختیاری: مجموعه‌ای از رشته‌های دامنه که با فاصله از هم جدا شده‌اند و داده‌هایی را که گوگل برای آنها درخواست مجوز می‌کند، مشخص می‌کنند.
response_type	نوع مقداری که در پاسخ برگردانده می‌شود. برای جریان کد احراز هویت OAuth 2.0، نوع پاسخ همیشه code است.
user_locale	تنظیمات زبان حساب گوگل در قالب RFC5646 ، که برای بومی‌سازی محتوای شما به زبان دلخواه کاربر استفاده می‌شود.

برای مثال، اگر نقطه پایانی مجوز شما در https://myservice.example.com/auth موجود باشد، یک درخواست ممکن است به شکل زیر باشد:

GET https://myservice.example.com/auth?client_id=GOOGLE_CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE_STRING&scope=REQUESTED_SCOPES&response_type=code&user_locale=LOCALE

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

1. تأیید کنید که client_id با Client ID که به گوگل اختصاص داده‌اید مطابقت دارد و redirect_uri با URL تغییر مسیر ارائه شده توسط گوگل برای سرویس شما مطابقت دارد. این بررسی‌ها برای جلوگیری از اعطای دسترسی به برنامه‌های کلاینت ناخواسته یا پیکربندی نادرست مهم هستند. اگر از چندین جریان OAuth 2.0 پشتیبانی می‌کنید، همچنین تأیید کنید که response_type code است.
2. بررسی کنید که آیا کاربر وارد سرویس شما شده است یا خیر. اگر کاربر وارد نشده است، مراحل ورود یا ثبت‌نام سرویس خود را تکمیل کنید.
3. یک کد مجوز برای دسترسی گوگل به API خود ایجاد کنید. کد مجوز می‌تواند هر مقدار رشته‌ای باشد، اما باید به طور منحصر به فرد، کاربر، کلاینتی که توکن برای آن است و زمان انقضای کد را نشان دهد و نباید قابل حدس زدن باشد. شما معمولاً کدهای مجوزی صادر می‌کنید که تقریباً پس از 10 دقیقه منقضی می‌شوند.
4. تأیید کنید که URL مشخص شده توسط پارامتر redirect_uri به شکل زیر باشد:

     https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID
     https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
     

5. مرورگر کاربر را به آدرس اینترنتی مشخص شده توسط پارامتر redirect_uri هدایت کنید. هنگام هدایت، با افزودن پارامترهای code و state ، کد مجوزی که اخیراً ایجاد کرده‌اید و مقدار وضعیت اصلی و بدون تغییر را نیز وارد کنید. در زیر نمونه‌ای از آدرس اینترنتی حاصل آمده است:

   https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID?code=AUTHORIZATION_CODE&state=STATE_STRING

رسیدگی به درخواست‌های تبادل توکن

نقطه پایانی تبادل توکن سرویس شما مسئول دو نوع تبادل توکن است:

• کدهای مجوز را برای توکن‌های دسترسی و توکن‌های به‌روزرسانی مبادله کنید
• توکن‌های به‌روزرسانی را با توکن‌های دسترسی مبادله کنید

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

پارامترهای نقطه پایانی تبادل توکن
client_id	رشته‌ای که مبدا درخواست را گوگل معرفی می‌کند. این رشته باید در سیستم شما به عنوان شناسه منحصر به فرد گوگل ثبت شود.
client_secret	یک رشته مخفی که شما برای سرویس خود در گوگل ثبت کرده‌اید.
grant_type	نوع توکنی که رد و بدل می‌شود. این توکن می‌تواند authorization_code یا refresh_token باشد.
code	وقتی grant_type=authorization_code ، این پارامتر کدی است که گوگل از نقطه پایانی ورود یا تبادل توکن شما دریافت کرده است.
redirect_uri	وقتی grant_type=authorization_code ، این پارامتر همان URL مورد استفاده در درخواست مجوز اولیه است.
refresh_token	وقتی grant_type=refresh_token ، این پارامتر توکن تازه‌سازی است که گوگل از نقطه پایانی تبادل توکن شما دریافت کرده است.

کدهای مجوز را برای توکن‌های دسترسی و توکن‌های به‌روزرسانی مبادله کنید

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

برای این درخواست‌ها، مقدار grant_type authorization_code است و مقدار code برابر با کد مجوزی است که قبلاً به گوگل اعطا کرده‌اید. در زیر مثالی از درخواست برای تعویض کد مجوز با یک access token و یک refresh token آمده است:

POST /token HTTP/1.1
Host: oauth2.example.com
Content-Type: application/x-www-form-urlencoded

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URI

برای تبادل کدهای مجوز برای یک توکن دسترسی و یک توکن به‌روزرسانی، نقطه پایانی تبادل توکن شما با اجرای مراحل زیر به درخواست‌های POST پاسخ می‌دهد:

1. تأیید کنید که client_id مبدا درخواست را به عنوان یک مبدا مجاز شناسایی می‌کند و client_secret با مقدار مورد انتظار مطابقت دارد.
2. تأیید کنید که کد مجوز معتبر و منقضی نشده است و شناسه مشتری مشخص شده در درخواست با شناسه مشتری مرتبط با کد مجوز مطابقت دارد.
3. تأیید کنید که URL مشخص شده توسط پارامتر redirect_uri با مقداری که در درخواست مجوز اولیه استفاده شده است، یکسان باشد.
4. اگر نمی‌توانید تمام معیارهای قبلی را تأیید کنید، خطای HTTP 400 Bad Request را با {"error": "invalid_grant"} به عنوان بدنه برگردانید.
5. در غیر این صورت، از شناسه کاربری از کد مجوز برای تولید یک توکن به‌روزرسانی و یک توکن دسترسی استفاده کنید. این توکن‌ها می‌توانند هر مقدار رشته‌ای باشند، اما باید به طور منحصر به فرد، کاربر و کلاینتی را که توکن برای آن است، نشان دهند و نباید قابل حدس زدن باشند. برای توکن‌های دسترسی، زمان انقضای توکن را نیز ثبت کنید، که معمولاً یک ساعت پس از صدور توکن است. توکن‌های به‌روزرسانی منقضی نمی‌شوند.
6. شیء JSON زیر را در بدنه پاسخ HTTPS برگردانید:

   {
   "token_type": "Bearer",
   "access_token": "ACCESS_TOKEN",
   "refresh_token": "REFRESH_TOKEN",
   "expires_in": SECONDS_TO_EXPIRATION
   }

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

توکن‌های به‌روزرسانی را با توکن‌های دسترسی مبادله کنید

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

برای این درخواست‌ها، مقدار grant_type refresh_token است و مقدار refresh_token برابر با مقدار توکن refresh است که قبلاً به گوگل اعطا کرده‌اید. در زیر مثالی از درخواست برای تعویض توکن refresh با توکن access آمده است:

POST /token HTTP/1.1
Host: oauth2.example.com
Content-Type: application/x-www-form-urlencoded

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=refresh_token&refresh_token=REFRESH_TOKEN

برای تبادل یک توکن به‌روزرسانی با یک توکن دسترسی، نقطه پایانی تبادل توکن شما با اجرای مراحل زیر به درخواست‌های POST پاسخ می‌دهد:

1. تأیید کنید که client_id مبدا درخواست را گوگل معرفی می‌کند و client_secret با مقدار مورد انتظار مطابقت دارد.
2. تأیید کنید که توکن به‌روزرسانی معتبر است و شناسه‌ی کلاینت مشخص‌شده در درخواست با شناسه‌ی کلاینت مرتبط با توکن به‌روزرسانی مطابقت دارد.
3. اگر نمی‌توانید تمام معیارهای قبلی را تأیید کنید، خطای HTTP 400 Bad Request را با {"error": "invalid_grant"} به عنوان بدنه برگردانید.
4. در غیر این صورت، از شناسه کاربریِ توکنِ به‌روزرسانی برای تولید یک توکن دسترسی استفاده کنید. این توکن‌ها می‌توانند هر مقدار رشته‌ای باشند، اما باید به‌طور منحصربه‌فرد، کاربر و کلاینتی را که توکن برای آن است، نشان دهند و نباید قابل حدس زدن باشند. برای توکن‌های دسترسی، زمان انقضای توکن را نیز ثبت کنید، که معمولاً یک ساعت پس از صدور توکن است.
5. شیء JSON زیر را در بدنه پاسخ HTTPS برگردانید:

   {
   "token_type": "Bearer",
   "access_token": "ACCESS_TOKEN",
   "expires_in": SECONDS_TO_EXPIRATION
   }

نکته: می‌توانید به صورت اختیاری یک refresh_token جدید را در پاسخ خود برگردانید. برای اطلاعات بیشتر در مورد اینکه چه زمانی بازگرداندن یک refresh_token جدید ترجیح داده می‌شود، به بخش «کار با توکن‌ها» مراجعه کنید.

رسیدگی به درخواست های اطلاعات کاربر

نقطه پایانی userinfo یک منبع محافظت شده OAuth 2.0 است که ادعاهای مربوط به کاربر پیوند شده را برمی‌گرداند. پیاده سازی و میزبانی نقطه پایانی اطلاعات کاربر اختیاری است، به جز موارد استفاده زیر:

• ورود به سیستم حساب پیوندی با Google One Tap.
• اشتراک بدون اصطکاک در AndroidTV.

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

سرصفحه های درخواست نقطه پایانی کاربر
Authorization header	نشانه دسترسی از نوع Bearer.

به عنوان مثال، اگر نقطه پایانی اطلاعات کاربری شما در https://myservice.example.com/userinfo در دسترس باشد، ممکن است یک درخواست به شکل زیر باشد:

GET /userinfo HTTP/1.1
Host: myservice.example.com
Authorization: Bearer ACCESS_TOKEN

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

1. رمز دسترسی را از سربرگ Authorization استخراج کنید و اطلاعات کاربر مرتبط با نشانه دسترسی را برگردانید.
2. اگر رمز دسترسی نامعتبر است، با استفاده از سربرگ پاسخ WWW-Authenticate خطای غیرمجاز HTTP 401 را برگردانید. در زیر نمونه ای از پاسخ خطای userinfo آورده شده است:

   HTTP/1.1 401 Unauthorized
   WWW-Authenticate: error="invalid_token",
   error_description="The Access Token expired"
   

   اگر یک پاسخ خطای 401 غیرمجاز یا هر پاسخ خطای ناموفق دیگری در طول فرآیند پیوند داده شود، خطا غیرقابل بازیابی خواهد بود، رمز بازیابی شده کنار گذاشته می شود و کاربر باید دوباره فرآیند پیوند را آغاز کند.

3. اگر نشانه دسترسی معتبر است، پاسخ HTTP 200 را با شی JSON زیر در بدنه پاسخ HTTPS برگردانید:

   {
   "sub": "USER_UUID",
   "email": "EMAIL_ADDRESS",
   "given_name": "FIRST_NAME",
   "family_name": "LAST_NAME",
   "name": "FULL_NAME",
   "picture": "PROFILE_PICTURE",
   }

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

   پاسخ نقطه پایانی اطلاعات کاربر
   sub	یک شناسه منحصر به فرد که کاربر را در سیستم شما شناسایی می کند.
   email	آدرس ایمیل کاربر.
   given_name	اختیاری: نام کاربر.
   family_name	اختیاری: نام خانوادگی کاربر.
   name	اختیاری: نام کامل کاربر.
   picture	اختیاری: تصویر نمایه کاربر.

اعتبارسنجی پیاده‌سازی شما

شما می‌توانید پیاده‌سازی خود را با استفاده از ابزار OAuth 2.0 Playground اعتبارسنجی کنید.

در ابزار، مراحل زیر را انجام دهید:

1. برای باز کردن پنجره پیکربندی OAuth 2.0، پیکربندی کلیک کنید.
2. در فیلد جریان OAuth ، گزینه Client-side را انتخاب کنید.
3. در فیلد OAuth Endpoints ، گزینه Custom را انتخاب کنید.
4. نقطه پایانی OAuth 2.0 خود و شناسه کلاینتی که به گوگل اختصاص داده‌اید را در فیلدهای مربوطه مشخص کنید.
5. در بخش مرحله ۱ ، هیچ محدوده گوگلی را انتخاب نکنید. در عوض، این فیلد را خالی بگذارید یا یک محدوده معتبر برای سرور خود تایپ کنید (یا اگر از محدوده‌های OAuth استفاده نمی‌کنید، یک رشته دلخواه). وقتی کارتان تمام شد، روی Authorize APIs کلیک کنید.
6. در بخش‌های مرحله ۲ و مرحله ۳ ، جریان OAuth 2.0 را بررسی کنید و تأیید کنید که هر مرحله طبق برنامه عمل می‌کند.

شما می‌توانید پیاده‌سازی خود را با استفاده از ابزار Google Account Linking Demo اعتبارسنجی کنید.

در ابزار، مراحل زیر را انجام دهید:

1. روی دکمه ورود با گوگل کلیک کنید.
2. حسابی را که می‌خواهید پیوند دهید انتخاب کنید.
3. شناسه سرویس را وارد کنید.
4. به صورت اختیاری یک یا چند محدوده‌ای را که برای دسترسی به آنها درخواست خواهید کرد، وارد کنید.
5. روی شروع نسخه نمایشی کلیک کنید.
6. وقتی از شما خواسته شد، تأیید کنید که می‌توانید درخواست پیوند را تأیید یا رد کنید.
7. تأیید کنید که به پلتفرم خود هدایت می‌شوید.