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

هر یکپارچه‌سازی Cloud-to-cloud باید شامل مکانیزمی برای احراز هویت کاربران باشد.

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

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

اتصال حساب گوگل با OAuth

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.

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.

This figure shows the steps for a user to link their Google account to your authentication system. The first screenshot shows user-initiated linking from your platform. The second image shows user sign-in to Google, while the third shows the user consent and confirmation for linking their Google account with your app. The final screenshot shows a successfully linked user account in the Google app.
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.
  2. You must have a Google authorization statement such as "By signing in, you are authorizing Google to control your devices." See the Google Device Control Authorization section of the Google Home Developer Policies.
  3. You must open the Web OAuth linking page and ensure users have a clear method for signing in to their Google Account, such as fields for their username and password. Don't use the Google Sign-In (GSI) method that enables users to link without being taken to the Web OAuth Linking page. It is a violation of Google policy.
  4. You must include at least one of the following items in the OAuth linking page to indicate the integration to which the user is linking:
    • Company logo
    • Company name
    • Integration name
    • App icon

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 a 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.

  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.

جریان کد مجوز

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

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

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

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

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

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

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

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

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

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

  1. از لیست پروژه‌ها، روی «باز کردن» در کنار پروژه‌ای که می‌خواهید با آن کار کنید کلیک کنید.

  2. در بخش «ابر به ابر» ، «توسعه» را انتخاب کنید.

  3. روی «باز کردن» کلیک کنید و سپس ادغام خود را انجام دهید.

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

  5. برای ذخیره تغییرات، روی ذخیره کلیک کنید.

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

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

برای این درخواست‌ها، مقدار 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
}

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:

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:

  1. Extract access token from the Authorization header and return information for the user associated with the access token.
  2. 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.

  3. 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.
،

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

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

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

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

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

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

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

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

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

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

  1. از لیست پروژه‌ها، روی «باز کردن» در کنار پروژه‌ای که می‌خواهید با آن کار کنید کلیک کنید.

  2. در بخش «ابر به ابر» ، «توسعه» را انتخاب کنید.

  3. روی «باز کردن» کلیک کنید و سپس ادغام خود را انجام دهید.

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

  5. برای ذخیره تغییرات، روی ذخیره کلیک کنید.

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

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

برای این درخواست‌ها، مقدار 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
}

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:

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:

  1. Extract access token from the Authorization header and return information for the user associated with the access token.
  2. 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.

  3. 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.
قبلی
چک لیست توسعه دهندگان
بعدی
ایجاد پروژه ابر به ابر، ایجاد پروژه ابر به ابر، ایجاد پروژه ابر به ابر، ایجاد پروژه ابر به ابر