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

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

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

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

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

در جریان کد مجوز ، به دو نقطه پایانی نیاز دارید:

نقطه پایانی مجوز ، که رابط کاربری ورود به سیستم را به کاربرانی که هنوز وارد سیستم نشده‌اند، نمایش می‌دهد. نقطه پایانی مجوز همچنین یک کد مجوز کوتاه‌مدت ایجاد می‌کند تا رضایت کاربران برای دسترسی درخواستی را ثبت کند.
نقطه پایانی تبادل توکن ، که مسئول دو نوع تبادل است:
1. یک کد مجوز را با یک توکن به‌روزرسانی طولانی‌مدت و یک توکن دسترسی کوتاه‌مدت مبادله می‌کند. این تبادل زمانی اتفاق می‌افتد که کاربر از جریان اتصال حساب عبور می‌کند.
2. یک توکن به‌روزرسانی بلندمدت را با یک توکن دسترسی کوتاه‌مدت تعویض می‌کند. این تعویض زمانی اتفاق می‌افتد که گوگل به یک توکن دسترسی جدید نیاز دارد، زیرا توکنی که منقضی شده بود.

یک جریان OAuth 2.0 انتخاب کنید

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

دستورالعمل‌های طراحی

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

این شکل مراحل اتصال حساب گوگل کاربر به سیستم احراز هویت شما را نشان می‌دهد. تصویر اول، اتصال آغاز شده توسط کاربر از پلتفرم شما را نشان می‌دهد. تصویر دوم، ورود کاربر به گوگل را نشان می‌دهد، در حالی که تصویر سوم، رضایت و تأیید کاربر برای اتصال حساب گوگل خود به برنامه شما را نشان می‌دهد. تصویر آخر، یک حساب کاربری متصل شده با موفقیت را در برنامه گوگل نشان می‌دهد. — **شکل ۱.** حساب کاربری که ورود کاربر را به صفحات گوگل و رضایت‌نامه متصل می‌کند.

الزامات

شما باید به کاربر اطلاع دهید که حساب کاربری به گوگل متصل خواهد شد، نه به یک محصول خاص گوگل مانند گوگل هوم یا گوگل اسیستنت.

توصیه‌ها

توصیه می‌کنیم موارد زیر را انجام دهید:

سیاست حفظ حریم خصوصی گوگل را نمایش دهید. پیوندی به سیاست حفظ حریم خصوصی گوگل را در صفحه رضایت‌نامه قرار دهید.
داده‌هایی که باید به اشتراک گذاشته شوند. با زبانی واضح و مختصر به کاربر بگویید که گوگل به چه داده‌هایی از او نیاز دارد و چرا.
فراخوان عمل واضح. در صفحه رضایت خود، یک فراخوان عمل واضح مانند «موافقت و پیوند» بیان کنید. دلیل این امر این است که کاربران باید بدانند برای پیوند دادن حساب‌هایشان، چه داده‌هایی را باید با گوگل به اشتراک بگذارند.
امکان لغو. در صورتی که کاربران تمایلی به لینک دادن نداشته باشند، راهی برای بازگشت یا لغو آن فراهم کنید.
فرآیند ورود به سیستم را شفاف کنید. مطمئن شوید که کاربران روش واضحی برای ورود به حساب گوگل خود دارند، مانند فیلدهای نام کاربری و رمز عبور یا ورود با گوگل .
امکان لغو پیوند. مکانیزمی برای لغو پیوند کاربران ارائه دهید، مانند URL به تنظیمات حساب کاربری آنها در پلتفرم شما. از طرف دیگر، می‌توانید پیوندی به حساب گوگل قرار دهید که کاربران بتوانند حساب پیوند شده خود را مدیریت کنند.
امکان تغییر حساب کاربری. روشی را برای کاربران پیشنهاد دهید تا حساب(های) خود را تغییر دهند. این امر به ویژه در صورتی مفید است که کاربران تمایل به داشتن چندین حساب داشته باشند.
- اگر کاربری برای تغییر حساب کاربری باید صفحه رضایت را ببندد، یک خطای قابل بازیابی به گوگل ارسال کنید تا کاربر بتواند با پیوند OAuth و جریان ضمنی به حساب مورد نظر خود وارد شود.
لوگوی خود را قرار دهید. لوگوی شرکت خود را در صفحه رضایت‌نامه نمایش دهید. از دستورالعمل‌های سبک خود برای قرار دادن لوگوی خود استفاده کنید. اگر می‌خواهید لوگوی گوگل را نیز نمایش دهید، به بخش لوگوها و علائم تجاری مراجعه کنید.

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

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

به کنسول 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
}

Handle userinfo requests

The userinfo endpoint is an OAuth 2.0 protected resource that return claims about the linked user. Implementing and hosting the userinfo endpoint is optional, except for the following use cases:

Linked Account Sign-In with Google One Tap.
Frictionless subscription on AndroidTV.

After the access token has been successfully retrieved from your token endpoint, Google sends a request to your userinfo endpoint to retrieve basic profile information about the linked user.

userinfo endpoint request headers
`Authorization header`	The access token of type Bearer.

For example, if your userinfo endpoint is available at https://myservice.example.com/userinfo, a request might look like the following:

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

For your userinfo endpoint to handle requests, do the following steps:

Extract access token from the Authorization header and return information for the user associated with the access token.
If the access token is invalid, return an HTTP 401 Unauthorized error with using the WWW-Authenticate Response Header. Below is an example of a userinfo error response:
```
HTTP/1.1 401 Unauthorized
WWW-Authenticate: error="invalid_token",
error_description="The Access Token expired"
```
If a 401 Unauthorized, or any other unsuccessful error response is returned during the linking process, the error will be non-recoverable, the retrieved token will be discarded and the user will have to initiate the linking process again.

If the access token is valid, return and HTTP 200 response with the following JSON object in the body of the HTTPS response:

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

If your userinfo endpoint returns an HTTP 200 success response, the retrieved token and claims are registered against the user's Google account.

userinfo endpoint response
`sub`	A unique ID that identifies the user in your system.
`email`	Email address of the user.
`given_name`	Optional: First name of the user.
`family_name`	Optional: Last name of the user.
`name`	Optional: Full name of the user.
`picture`	Optional: Profile picture of the user.

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

You can validate your implementation by using the OAuth 2.0 Playground tool.

In the tool, do the following steps:

Click Configuration to open the OAuth 2.0 Configuration window.
In the OAuth flow field, select Client-side.
In the OAuth Endpoints field, select Custom.
Specify your OAuth 2.0 endpoint and the client ID you assigned to Google in the corresponding fields.
In the Step 1 section, don't select any Google scopes. Instead, leave this field blank or type a scope valid for your server (or an arbitrary string if you don't use OAuth scopes). When you're done, click Authorize APIs.
In the Step 2 and Step 3 sections, go through the OAuth 2.0 flow and verify that each step works as intended.

You can validate your implementation by using the Google Account Linking Demo tool.