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

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

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

هر ادغام Cloud-to-cloud باید دارای مکانیزمی برای احراز هویت کاربران باشد.

احراز هویت به شما امکان می‌دهد حساب‌های Google کاربران خود را با حساب‌های کاربری در سیستم احراز هویت خود پیوند دهید. این به شما این امکان را می دهد که کاربران خود را هنگامی که تحقق شما هدف خانه هوشمند دریافت می کند شناسایی کنید. خانه هوشمند Google فقط از OAuth با جریان کد مجوز پشتیبانی می کند.

این صفحه نحوه راه‌اندازی سرور OAuth 2.0 را توضیح می‌دهد تا با ادغام Cloud-to-cloud شما کار کند.

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

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

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

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

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

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

الزامات

باید اعلام کنید که حساب کاربر به Google مرتبط خواهد شد، نه یک محصول خاص Google مانند Google Home یا Google Assistant.
شما باید یک بیانیه مجوز Google مانند "با ورود به سیستم، به Google اجازه کنترل دستگاه های خود را می دهید" داشته باشید. به بخش مجوز کنترل دستگاه Google در خط‌مشی‌های برنامه‌نویس Google Home مراجعه کنید.
باید صفحه پیوند Web OAuth را باز کنید و مطمئن شوید که کاربران روشی واضح برای ورود به حساب Google خود دارند، مانند فیلدهایی برای نام کاربری و رمز عبور. از روش Google Sign-In (GSI) استفاده نکنید که به کاربران امکان می دهد بدون اینکه به صفحه پیوند OAuth Web منتقل شوند، پیوند دهند. این نقض خط‌مشی Google است.
شما باید حداقل یکی از موارد زیر را در صفحه پیوند OAuth برای نشان دادن ادغام که کاربر به آن پیوند می دهد، قرار دهید:
- لوگوی شرکت
- نام شرکت
- نام ادغام
- نماد برنامه

توصیه ها

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

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

جریان کد مجوز

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

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

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

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

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

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

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

برای مثال، اگر نقطه پایانی مجوز شما در 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

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

تأیید کنید که 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` باشد، این پارامتر توکن تازه‌سازی است که گوگل از نقطه پایانی تبادل توکن شما دریافت کرده است.

نحوه ارسال اعتبارنامه‌ها توسط گوگل به سرور خود را پیکربندی کنید

بسته به پیاده‌سازی آن، سرور تأیید شما انتظار دارد که اعتبارنامه‌های کلاینت را یا در بدنه درخواست یا در هدر درخواست دریافت کند.

به طور پیش‌فرض، گوگل اعتبارنامه‌ها را در بدنه درخواست ارسال می‌کند. اگر سرور تأیید شما نیاز دارد که اعتبارنامه‌های کلاینت در هدر درخواست باشد، باید ادغام Cloud-to-cloud خود را بر این اساس پیکربندی کنید:

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

از لیست پروژه‌ها، روی «باز کردن» در کنار پروژه‌ای که می‌خواهید با آن کار کنید کلیک کنید.
در بخش «ابر به ابر» ، «توسعه» را انتخاب کنید.
روی «باز کردن» کلیک کنید و سپس ادغام خود را انجام دهید.
به پایین اسکرول کنید تا به بخش مجوزها (اختیاری) برسید و کادر انتخاب «آیا گوگل شناسه کلاینت و رمز را از طریق هدر احراز هویت پایه HTTP ارسال کند؟» را انتخاب کنید.
برای ذخیره تغییرات، روی ذخیره کلیک کنید.

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

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

برای این درخواست‌ها، مقدار 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 که توسط گوگل آغاز شده است، جریان زیر را دارد:

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

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

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

برای مثال، اگر نقطه پایانی مجوز شما در 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

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

تأیید کنید که 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` باشد، این پارامتر توکن تازه‌سازی است که گوگل از نقطه پایانی تبادل توکن شما دریافت کرده است.

نحوه ارسال اعتبارنامه‌ها توسط گوگل به سرور خود را پیکربندی کنید

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

از لیست پروژه‌ها، روی «باز کردن» در کنار پروژه‌ای که می‌خواهید با آن کار کنید کلیک کنید.
در بخش «ابر به ابر» ، «توسعه» را انتخاب کنید.
روی «باز کردن» کلیک کنید و سپس ادغام خود را انجام دهید.
به پایین اسکرول کنید تا به بخش مجوزها (اختیاری) برسید و کادر انتخاب «آیا گوگل شناسه کلاینت و رمز را از طریق هدر احراز هویت پایه HTTP ارسال کند؟» را انتخاب کنید.
برای ذخیره تغییرات، روی ذخیره کلیک کنید.

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

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

تأیید کنید که 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
}

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

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

تأیید کنید که 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
}

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

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

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

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",
}

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

قبلی

چک لیست توسعه دهندگان

بعدی

ایجاد پروژه ابر به ابر، ایجاد پروژه ابر به ابر، ایجاد پروژه ابر به ابر، ایجاد پروژه ابر به ابر

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

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

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

الزامات

توصیه ها

جریان کد مجوز

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

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

نحوه ارسال اعتبارنامه‌ها توسط گوگل به سرور خود را پیکربندی کنید

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

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

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

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

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

نحوه ارسال اعتبارنامه‌ها توسط گوگل به سرور خود را پیکربندی کنید

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

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

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

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