این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

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

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

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

在隐式流程中，Google 会在用户的浏览器中打开您的授权端点。成功登录后，您会向 Google 返回长期有效的访问令牌。此访问令牌现在包含在 Google 发送的每个请求中。

在 授权码 流程中，您需要两个端点：

授权端点，用于向尚未登录的用户显示登录界面。授权端点还会创建一个短期有效的授权代码，以记录用户对所请求访问权限的同意情况。
令牌交换 端点，负责两种类型的交换：
1. 将授权代码交换为长期有效的刷新令牌和短期有效的访问令牌。当用户完成账号关联流程时，会发生此交换。
2. 将长期有效的刷新令牌交换为短期有效的访问令牌。当 Google 需要新的访问令牌（因为其拥有的访问令牌已过期）时，会发生此交换。

选择 OAuth 2.0 流程

虽然隐式流程的实现方式较为简单，但 Google 建议通过隐式流程颁发的访问令牌永不过期。这是因为，如果令牌通过隐式流程过期，用户就必须再次关联其账号。如果您出于安全原因需要令牌过期，我们强烈建议您改用 授权码 流程。

设计准则

本部分介绍了您为 OAuth 关联流程托管的用户界面的设计要求和建议。在 Google 的应用调用后，您的平台会向用户显示“登录 Google”页面和账号关联同意屏幕。用户同意关联账号后，系统会将用户重定向回 Google 的应用。

此图显示了用户将其 Google 账号与您的身份验证系统相关联的步骤。第一个屏幕截图显示了用户从您的平台发起的关联。第二张图片显示了用户登录 Google 的界面，第三张图片显示了用户同意并确认将自己的 Google 账号与您的应用相关联的界面。最后一张屏幕截图显示了 Google 应用中成功关联的用户账号。 — **图 1.**账号关联用户登录 Google 和同意屏幕。

要求

您必须告知用户，其账号将与 Google 关联， 而不是与 Google Home 或 Google 助理等特定 Google 产品关联。

建议

建议您执行以下操作：

显示 Google 的隐私权政策。在权限请求页面上添加指向 Google 隐私权政策的链接。
要分享的数据。 使用清晰简洁的语言告知用户 Google 需要哪些用户数据以及原因。
明确的号召性用语。 在同意屏幕上添加明确的号召性用语，例如“同意并关联”。这是因为用户需要了解他们需要与 Google 分享哪些数据才能关联其账号。
能够取消。 为用户提供返回或取消的方式，以便用户选择不关联。
清晰的登录流程。 确保用户有清晰的 Google 账号登录方法，例如用于输入用户名和密码的字段，或使用 Google 账号登录。
能够取消关联。 为用户提供取消关联的机制，例如指向您平台上账号设置的网址。或者，您可以添加指向 Google 账号的链接，用户可以在其中管理其关联的账号。
能够更改用户账号。 为用户提供切换账号的方法。如果用户倾向于拥有多个账号，这一点尤其有用。
- 如果用户必须关闭权限请求页面才能切换账号，请向 Google 发送可恢复的错误，以便用户可以使用 OAuth 关联 和隐式流程登录所需的账号。
添加您的徽标。 在权限请求页面上显示您的公司徽标。使用您的样式指南放置徽标。如果您还想显示 Google 的徽标，请参阅徽标和商标。

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

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

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

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

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

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

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

صفحه‌ی رضایت‌نامه‌ی OAuth را در کنسول Google APIs باز کنید.
در صورت درخواست، پروژه‌ای را که تازه ایجاد کرده‌اید انتخاب کنید.
در صفحه «صفحه رضایت OAuth»، فرم را پر کنید و روی دکمه «ذخیره» کلیک کنید.
نام برنامه: نام برنامه‌ای که درخواست رضایت می‌کند. این نام باید دقیقاً منعکس‌کننده برنامه شما باشد و با نام برنامه‌ای که کاربران در جاهای دیگر می‌بینند، مطابقت داشته باشد. نام برنامه در صفحه رضایت‌نامه پیوند حساب نمایش داده خواهد شد.
لوگوی برنامه: تصویری در صفحه رضایت‌نامه که به کاربران کمک می‌کند برنامه شما را بشناسند. این لوگو در صفحه رضایت‌نامه پیوند حساب و در تنظیمات حساب نمایش داده می‌شود.
ایمیل پشتیبانی: برای اینکه کاربران بتوانند در مورد رضایت خود با شما تماس بگیرند.
حوزه‌های دسترسی برای APIهای گوگل: حوزه‌ها به برنامه شما اجازه می‌دهند تا به داده‌های خصوصی گوگل کاربر دسترسی داشته باشد. برای مورد استفاده اتصال حساب گوگل، حوزه پیش‌فرض (ایمیل، نمایه، شناسه باز) کافی است، نیازی به اضافه کردن هیچ حوزه حساسی ندارید. به طور کلی، بهترین روش این است که حوزه‌ها را به صورت تدریجی، در زمانی که دسترسی مورد نیاز است، درخواست کنید، نه اینکه از ابتدا درخواست دهید. اطلاعات بیشتر .
دامنه‌های مجاز: برای محافظت از شما و کاربرانتان، گوگل فقط به برنامه‌هایی که با استفاده از OAuth احراز هویت می‌شوند، اجازه استفاده از دامنه‌های مجاز را می‌دهد. لینک‌های برنامه‌های شما باید در دامنه‌های مجاز میزبانی شوند. اطلاعات بیشتر .
لینک صفحه اصلی برنامه: صفحه اصلی برنامه شما. باید روی یک دامنه مجاز میزبانی شود.
پیوند سیاست حفظ حریم خصوصی برنامه: در صفحه رضایت‌نامه پیوند حساب گوگل نشان داده می‌شود. باید در یک دامنه مجاز میزبانی شود.
لینک شرایط خدمات برنامه (اختیاری): باید روی یک دامنه مجاز میزبانی شود.
شکل ۱. صفحه رضایت‌نامه اتصال حساب گوگل برای یک برنامه جعلی، Tunery
«وضعیت تأیید» را بررسی کنید، اگر درخواست شما نیاز به تأیید دارد، روی دکمه «ارسال برای تأیید» کلیک کنید تا درخواست شما برای تأیید ارسال شود. برای جزئیات بیشتر به الزامات تأیید OAuth مراجعه کنید.

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

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

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

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

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

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

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

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

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

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

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

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

وقتی نیاز دارید که با استفاده از جریان کد مجوز 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

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

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

تأیید کنید که URL مشخص شده توسط پارامتر redirect_uri به شکل زیر باشد:

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

مرورگر کاربر را به آدرس اینترنتی مشخص شده توسط پارامتر 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 پاسخ می‌دهد:

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

شیء 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 پاسخ می‌دهد:

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

شیء JSON زیر را در بدنه پاسخ HTTPS برگردانید:

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

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

نقطه پایانی 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

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

رمز دسترسی را از سربرگ Authorization استخراج کنید و اطلاعات کاربر مرتبط با نشانه دسترسی را برگردانید.
اگر رمز دسترسی نامعتبر است، با استفاده از سربرگ پاسخ WWW-Authenticate خطای غیرمجاز HTTP 401 را برگردانید. در زیر نمونه ای از پاسخ خطای userinfo آورده شده است:
```
HTTP/1.1 401 Unauthorized
WWW-Authenticate: error="invalid_token",
error_description="The Access Token expired"
```
اگر یک پاسخ خطای 401 غیرمجاز یا هر پاسخ خطای ناموفق دیگری در طول فرآیند پیوند داده شود، خطا غیرقابل بازیابی خواهد بود، رمز بازیابی شده کنار گذاشته می شود و کاربر باید دوباره فرآیند پیوند را آغاز کند.

اگر نشانه دسترسی معتبر است، پاسخ 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 工具验证您的实现。

在该工具中，执行以下步骤：

点击配置以打开“OAuth 2.0 配置”窗口。
在 OAuth flow（OAuth 流程）字段中，选择 Client-side（客户端）。
在 OAuth Endpoints 字段中，选择 Custom。
在相应字段中指定您的 OAuth 2.0 端点以及您分配给 Google 的客户端 ID。
在第 1 步部分中，请勿选择任何 Google 范围。请将此字段留空，或输入适用于您服务器的范围（如果您不使用 OAuth 范围，则输入任意字符串）。完成后，点击 Authorize APIs。
在第 2 步和第 3 步部分中，完成 OAuth 2.0 流程，并验证每个步骤是否按预期运行。

您可以使用 Google 账号关联演示工具验证您的实现。