Google متعهد به پیشبرد عدالت نژادی برای جوامع سیاهپوست است. ببینید چگونه.

استفاده از OAuth 2.0 برای برنامه های وب سرور

این سند نحوه استفاده برنامه های سرور وب از Google API Client Libraries یا Google OAuth 2.0 برای پایان دادن به مجوز OAuth 2.0 برای دسترسی به API های Google را توضیح می دهد.

OAuth 2.0 به کاربران امکان می دهد داده های خاص را با استفاده از یک برنامه به اشتراک بگذارند در حالی که نام کاربری ، گذرواژه و سایر اطلاعات خود را به صورت خصوصی حفظ می کنند. به عنوان مثال ، یک برنامه کاربردی می تواند از OAuth 2.0 برای گرفتن اجازه از کاربران برای ذخیره فایل ها در Google Drives خود از کاربران استفاده کند.

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

برنامه های وب سرور نیز به طور مکرر از حسابهای سرویس برای تأیید درخواستهای API استفاده می کنند ، به ویژه هنگام تماس با API های Cloud برای دسترسی به داده های مبتنی بر پروژه به جای داده های خاص کاربر. برنامه های وب سرور می توانند از حساب های سرویس همراه با مجوز کاربر استفاده کنند.

کتابخانه های مشتری

نمونه های خاص زبان در این صفحه برای اجرای مجوز OAuth 2.0 از کتابخانه های مشتری API Google استفاده می کنند . برای اجرای نمونه های کد ، ابتدا باید کتابخانه سرویس گیرنده را برای زبان خود نصب کنید.

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

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

پیش نیازها

API ها را برای پروژه خود فعال کنید

هر برنامه ای که با API های Google تماس بگیرد ، باید این API ها را در API Console فعال کند.

برای فعال کردن یک API برای پروژه خود:

  1. Open the API Library در Google API Console.
  2. If prompted, select a project, or create a new one.
  3. API Library تمام API های موجود را لیست می کند که براساس خانواده و محبوبیت گروه بندی شده اند. اگر API موردنظر برای فعال کردن در این لیست مشاهده نمی شود ، از جستجو برای یافتن آن استفاده کنید یا روی نمایش همه در خانواده محصول متعلق به آن کلیک کنید.
  4. API مورد نظر برای فعال کردن را انتخاب کنید ، سپس روی دکمه Enable کلیک کنید.
  5. If prompted, enable billing.
  6. If prompted, read and accept the API's Terms of Service.

اعتبارنامه ایجاد کنید

هر برنامه ای که از OAuth 2.0 برای دسترسی به Google API استفاده می کند ، باید دارای اعتبار مجوز باشد که برنامه را به سرور OAuth 2.0 Google شناسایی کند. مراحل زیر نحوه ایجاد اعتبارنامه برای پروژه شما را توضیح می دهد. سپس برنامه های شما می توانند از اعتبارنامه برای دسترسی به API هایی که برای آن پروژه فعال کرده اید استفاده کنند.

  1. Go to the Credentials page.
  2. روی ایجاد اعتبارنامه> شناسه مشتری OAuth کلیک کنید.
  3. نوع برنامه برنامه وب را انتخاب کنید.
  4. فرم را پر کنید و روی ایجاد کلیک کنید. برنامه هایی که از زبان ها و چارچوب هایی مانند PHP ، Java ، Python ، Ruby و .NET استفاده می کنند باید URI های مجاز تغییر مسیر را تعیین کنند. URI های تغییر مسیر نقاط پایانی هستند که سرور OAuth 2.0 می تواند به آنها پاسخ ارسال کند. این نقاط نهایی باید به قوانین اعتبار Google پایبند باشند.

    برای آزمایش می توانید URI هایی را که به دستگاه محلی مراجعه می کنند مانند http://localhost:8080 . با توجه به این نکته ، لطفا توجه داشته باشید که تمام مثالهای موجود در این سند از http://localhost:8080 به عنوان URI هدایت استفاده می کنند.

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

پس از ایجاد اعتبارنامه ، پرونده client_secret.json را از API Console بارگیری کنید. فایل را به راحتی در مکانی ذخیره کنید که فقط برنامه شما می تواند به آن دسترسی پیدا کند.

دامنه های دسترسی را شناسایی کنید

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

قبل از شروع اجرای مجوز OAuth 2.0 ، توصیه می کنیم دامنه هایی را که برنامه شما برای دسترسی به آنها نیاز دارد ، شناسایی کنید.

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

سند OAuth 2.0 API Scopes شامل یک لیست کامل از دامنه هایی است که می توانید برای دسترسی به Google API ها استفاده کنید.

الزامات خاص زبان

برای اجرای هر یک از نمونه های کد در این سند ، به یک حساب Google ، دسترسی به اینترنت و یک مرورگر وب نیاز دارید. اگر از یکی از کتابخانه های سرویس گیرنده API استفاده می کنید ، همچنین الزامات خاص زبان را در زیر مشاهده کنید.

PHP

برای اجرای نمونه های کد PHP در این سند ، به موارد زیر نیاز دارید:

  • PHP 5.4 یا بالاتر با رابط خط فرمان (CLI) و پسوند JSON نصب شده است.
  • ابزار مدیریت وابستگی آهنگساز .
  • Google APIs Client Library برای PHP:

    php composer.phar require google/apiclient:^2.0

پایتون

برای اجرای نمونه های کد پایتون در این سند ، به موارد زیر نیاز دارید:

  • پایتون 2.6 یا بالاتر
  • ابزار مدیریت بسته pip .
  • Google APIs Client Library برای پایتون:
    pip install --upgrade google-api-python-client
  • google-auth ، google-auth-oauthlib و google-auth-httplib2 برای مجوز کاربر.
    pip install --upgrade google-auth google-auth-oauthlib google-auth-httplib2
  • چارچوب برنامه وب Flask Python.
    pip install --upgrade flask
  • requests کتابخانه HTTP.
    pip install --upgrade requests

یاقوت

برای اجرای نمونه های کد Ruby در این سند ، به موارد زیر نیاز دارید:

  • یاقوت 2.2.2 یا بالاتر
  • Google APIs Client Library for Ruby:

    gem install google-api-client
  • چارچوب برنامه وب Sinatra Ruby.

    gem install sinatra

HTTP / REST

برای اینکه بتوانید مستقیماً با نقاط پایانی OAuth 2.0 تماس بگیرید نیازی به نصب کتابخانه نیست.

دریافت نشانه های دسترسی OAuth 2.0

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

لیست زیر سریعاً این مراحل را خلاصه می کند:

  1. برنامه شما مجوزهای لازم را مشخص می کند.
  2. برنامه شما کاربر را به همراه لیستی از مجوزهای درخواستی به Google هدایت می کند.
  3. کاربر تصمیم می گیرد که مجوزها را به برنامه شما اعطا کند یا خیر.
  4. برنامه شما می فهمد که کاربر چه تصمیمی گرفته است.
  5. اگر کاربر مجوزهای درخواستی را داده باشد ، برنامه شما نشانه های مورد نیاز برای درخواست API را از طرف کاربر بازیابی می کند.

مرحله 1: تنظیم پارامترهای مجوز

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

  • اگر برای تأیید اعتبار و مجوز OAuth 2.0 از کتابخانه سرویس گیرنده Google استفاده می کنید ، شیئی را ایجاد می کنید که این پارامترها را تعریف می کند.
  • اگر مستقیماً با Google OAuth 2.0 endpoint تماس بگیرید ، یک URL ایجاد می کنید و پارامترهای آن URL را تنظیم می کنید.

برگه های زیر پارامترهای اجازه پشتیبانی شده را برای برنامه های وب سرور تعریف می کنند. مثالهای خاص زبان همچنین نشان می دهد که چگونه می توان از کتابخانه مشتری یا کتابخانه مجوز برای پیکربندی شیئی که این پارامترها را تنظیم می کند ، استفاده کرد.

PHP

قطعه کد زیر یک Google_Client() ایجاد می کند ، که پارامترهای درخواست مجوز را تعریف می کند.

آن شی از اطلاعات پرونده client_secret.json شما برای شناسایی برنامه شما استفاده می کند. (برای اطلاعات بیشتر در مورد آن فایل ، به ایجاد اعتبار نامه مجوز مراجعه کنید.) این شی also همچنین حوزه هایی را که برنامه شما برای دسترسی به آنها درخواست می کند و URL را برای نقطه پایانی تأیید برنامه شما مشخص می کند ، که پاسخ از سرور OAuth 2.0 Google را کنترل می کند. سرانجام ، کد پارامترهای access_type اختیاری و include_granted_scopes کند.

به عنوان مثال ، این کد دسترسی فقط خواندنی و آفلاین به Google Drive کاربر را درخواست می کند:

$client = new Google_Client();
$client->setAuthConfig('client_secret.json');
$client->addScope(Google_Service_Drive::DRIVE_METADATA_READONLY);
$client->setRedirectUri('http://' . $_SERVER['HTTP_HOST'] . '/oauth2callback.php');
// offline access will give you both an access and refresh token so that
// your app can refresh the access token without user interaction.
$client->setAccessType('offline');
// Using "consent" ensures that your application always receives a refresh token.
// If you are not using offline access, you can omit this.
$client->setApprovalPrompt("consent");
$client->setIncludeGrantedScopes(true);   // incremental auth

این درخواست اطلاعات زیر را مشخص می کند:

مولفه های
client_id ضروری

شناسه مشتری برنامه شما. این مقدار را می توانید در API Console Credentials page پیدا کنید.

در PHP ، تابع setAuthConfig کنید تا اعتبارنامه ها را از پرونده client_secret.json بارگیری کنید.

$client = new Google_Client();
$client->setAuthConfig('client_secret.json');
redirect_uri ضروری

مشخص می کند که سرور API پس از تکمیل جریان مجوز توسط کاربر ، کاربر را به کجا هدایت می کند. این مقدار باید دقیقاً با یکی از URI های تغییر مسیر مجاز برای مشتری OAuth 2.0 مطابقت داشته باشد که شما در API Console Credentials page مشتری خود پیکربندی کرده اید. اگر این مقدار با URI تغییر مسیر مجاز برای client_id ارائه شده client_id ، با خطای redirect_uri_mismatch مواجه خواهید شد.

توجه داشته باشید که طرح http https ، مورد و اسلش انتهایی (' / ') همه باید مطابقت داشته باشند.

برای تنظیم این مقدار در PHP ، با تابع setRedirectUri تماس setRedirectUri . توجه داشته باشید که باید یک URI تغییر مسیر معتبر برای client_id ارائه شده client_id .

$client->setRedirectUri('https://oauth2.example.com/code');
scope ضروری

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

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

برای تنظیم این مقدار در PHP ، با تابع addScope تماس addScope :

$client->addScope(Google_Service_Drive::DRIVE_METADATA_READONLY);

ما توصیه می کنیم که برنامه شما درخواست دسترسی به محدوده مجوز را در هر زمان ممکن داشته باشد. با درخواست دسترسی به داده های کاربر در چارچوب ، از طریق مجوز افزایشی ، به کاربران کمک می کنید تا راحت تر درک کنند که چرا برنامه شما به دسترسی مورد درخواست شما نیاز دارد.

access_type توصیه شده

نشان می دهد آیا هنگام حضور کاربر در مرورگر ، برنامه شما می تواند نشانه های دسترسی را تازه کند یا خیر. مقادیر پارامتر معتبر بصورت online هستند که مقدار پیش فرض است و offline .

اگر برنامه شما نیاز به تازه کردن نشانه های دسترسی دارد ، درصورتی که کاربر در مرورگر حضور ندارد ، مقدار را offline دهید. این روش تازه کردن نشانه های دسترسی است که بعداً در این سند شرح داده شده است. این مقدار به سرور مجوز گوگل دستور می دهد که برای اولین بار که برنامه شما کد مجوز را با رمزها مبادله می کند ، یک نشانه تازه سازی و یک رمز دسترسی بازگرداند.

برای تنظیم این مقدار در PHP ، با تابع setAccessType تماس setAccessType :

$client->setAccessType('offline');
state توصیه شده

مقدار رشته ای را که برنامه شما برای حفظ وضعیت بین درخواست مجوز شما و پاسخ سرور مجوز استفاده می کند ، مشخص می کند. سرور بعد از اینکه کاربر درخواست دسترسی برنامه شما را رد کرد یا آن را رد کرد ، مقدار دقیقی را که شما به عنوان یک جفت name=value در م quلفه درخواست URL ( ? ) از redirect_uri ارسال می کنید ، برمی گرداند.

شما می توانید از این پارامتر برای اهداف مختلفی استفاده کنید ، مانند هدایت کاربر به سمت منبع صحیح در برنامه خود ، ارسال موارد غیر مجاز و کاهش جعل درخواست بین سایت. از آنجا که می توان redirect_uri شما را حدس زد ، استفاده از یک مقدار state می تواند اطمینان شما را از اینکه اتصال ورودی نتیجه درخواست احراز هویت است ، افزایش دهد. اگر یک رشته تصادفی ایجاد کنید یا هش کوکی یا مقدار دیگری را که حالت مشتری را ضبط می کند رمزگذاری کنید ، می توانید پاسخ را تأیید کنید تا علاوه بر این اطمینان حاصل کنید که درخواست و پاسخ از همان مرورگر نشات گرفته است ، در برابر حملاتی مانند cross-site محافظت می کند درخواست جعل برای نمونه ای از نحوه ایجاد و تأیید رمز state اسناد OpenID Connect مراجعه کنید.

برای تنظیم این مقدار در PHP ، با تابع setState تماس بگیرید:

$client->setState($sample_passthrough_value);
include_granted_scopes اختیاری

برنامه ها را قادر می سازد تا از مجوز افزایشی برای درخواست دسترسی به محدوده های اضافی در متن استفاده کنند. اگر مقدار این پارامتر را true بگذارید و درخواست مجوز پذیرفته شود ، رمز دسترسی جدید همچنین دامنه هایی را که کاربر قبلاً به برنامه دسترسی داده است ، پوشش می دهد. برای مثال به بخش مجوز افزایشی مراجعه کنید.

برای تنظیم این مقدار در PHP ، با تابع setIncludeGrantedScopes تماس setIncludeGrantedScopes :

$client->setIncludeGrantedScopes(true);
login_hint اختیاری

اگر برنامه شما می داند کدام کاربر در تلاش است تا احراز هویت شود ، می تواند از این پارامتر برای ارائه راهنمایی به سرور تأیید اعتبار Google استفاده کند. سرور از راهنمایی برای ساده سازی جریان ورود به سیستم یا با پر کردن قسمت ایمیل در فرم ورود به سیستم یا با انتخاب جلسه چند ورود به سیستم مناسب استفاده می کند.

مقدار پارامتر را روی آدرس ایمیل یا شناسه sub ، که معادل شناسه Google کاربر است.

برای تنظیم این مقدار در PHP ، با تابع setLoginHint تماس setLoginHint :

$client->setLoginHint('None');
prompt اختیاری

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

برای تنظیم این مقدار در PHP ، با تابع setApprovalPrompt تماس setApprovalPrompt :

$client->setApprovalPrompt('consent');

مقادیر احتمالی عبارتند از:

none صفحه های تأیید اعتبار یا رضایت را نمایش ندهید. نباید با مقادیر دیگر مشخص شود.
consent از کاربر درخواست رضایت کنید.
select_account از کاربر بخواهید یک حساب کاربری انتخاب کند.

پایتون

قطعه کد زیر از ماژول google-auth-oauthlib.flow برای ساخت درخواست مجوز استفاده می کند.

کد یک آبجکت Flow کند ، که با استفاده از اطلاعات فایل client_secret.json که پس از ایجاد اعتبارنامه ها بارگیری کردید ، برنامه شما را شناسایی می کند . این شی also همچنین محدوده هایی را که برنامه شما برای دسترسی به آنها درخواست می کند و URL را برای نقطه پایانی تأیید برنامه شما مشخص می کند ، که پاسخ از سرور OAuth 2.0 Google را کنترل می کند. سرانجام ، کد پارامترهای access_type اختیاری و include_granted_scopes کند.

به عنوان مثال ، این کد دسترسی فقط خواندنی و آفلاین به Google Drive کاربر را درخواست می کند:

import google.oauth2.credentials
import google_auth_oauthlib.flow

# Use the client_secret.json file to identify the application requesting
# authorization. The client ID (from that file) and access scopes are required.
flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file(
    'client_secret.json',
    scopes=['https://www.googleapis.com/auth/drive.metadata.readonly'])

# Indicate where the API server will redirect the user after the user completes
# the authorization flow. The redirect URI is required. The value must exactly
# match one of the authorized redirect URIs for the OAuth 2.0 client, which you
# configured in the API Console. If this value doesn't match an authorized URI,
# you will get a 'redirect_uri_mismatch' error.
flow.redirect_uri = 'https://www.example.com/oauth2callback'

# Generate URL for request to Google's OAuth 2.0 server.
# Use kwargs to set optional request parameters.
authorization_url, state = flow.authorization_url(
    # Enable offline access so that you can refresh an access token without
    # re-prompting the user for permission. Recommended for web server apps.
    access_type='offline',
    # Enable incremental authorization. Recommended as a best practice.
    include_granted_scopes='true')

این درخواست اطلاعات زیر را مشخص می کند:

مولفه های
client_id ضروری

شناسه مشتری برنامه شما. این مقدار را می توانید در API Console Credentials page پیدا کنید.

در پایتون ، با from_client_secrets_file روش from_client_secrets_file برای بازیابی شناسه سرویس گیرنده از پرونده client_secret.json . (همچنین می توانید از روش from_client_config استفاده کنید ، که پیکربندی سرویس گیرنده را همانطور که در ابتدا در پرونده اسرار سرویس گیرنده ظاهر شده بود منتقل می کند اما خود به پرونده دسترسی ندارد.)

flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file(
    'client_secret.json',
    scopes=['https://www.googleapis.com/auth/drive.metadata.readonly'])
redirect_uri ضروری

مشخص می کند که سرور API پس از تکمیل جریان مجوز توسط کاربر ، کاربر را به کجا هدایت می کند. این مقدار باید دقیقاً با یکی از URI های تغییر مسیر مجاز برای مشتری OAuth 2.0 مطابقت داشته باشد که شما در API Console Credentials page مشتری خود پیکربندی کرده اید. اگر این مقدار با URI تغییر مسیر مجاز برای client_id ارائه شده client_id ، با خطای redirect_uri_mismatch مواجه خواهید شد.

توجه داشته باشید که طرح http https ، مورد و اسلش انتهایی (' / ') همه باید مطابقت داشته باشند.

برای تنظیم این مقدار در پایتون ، خاصیت redirect_uri جسم flow را تنظیم کنید:

flow.redirect_uri = 'https://oauth2.example.com/code'
scope ضروری

لیستی از محدوده هایی که منابعی را که برنامه شما می تواند از طرف کاربر به آنها دسترسی داشته باشد شناسایی می کند. این مقادیر صفحه رضایت را نشان می دهد که Google به کاربر نشان می دهد.

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

در پایتون ، از همان روشی استفاده می کنید که برای تعیین client_id برای تعیین لیست محدوده ها استفاده می کنید.

flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file(
    'client_secret.json',
    scopes=['https://www.googleapis.com/auth/drive.metadata.readonly'])

ما توصیه می کنیم که برنامه شما درخواست دسترسی به محدوده مجوز را در هر زمان ممکن داشته باشد. با درخواست دسترسی به داده های کاربر در چارچوب ، از طریق مجوز افزایشی ، به کاربران کمک می کنید تا راحت تر درک کنند که چرا برنامه شما به دسترسی مورد درخواست شما نیاز دارد.

access_type توصیه شده

نشان می دهد آیا هنگام حضور کاربر در مرورگر ، برنامه شما می تواند نشانه های دسترسی را تازه کند یا خیر. مقادیر پارامتر معتبر بصورت online هستند که مقدار پیش فرض است و offline .

اگر برنامه شما نیاز به تازه کردن نشانه های دسترسی دارد ، درصورتی که کاربر در مرورگر حضور ندارد ، مقدار را offline دهید. این روش تازه کردن نشانه های دسترسی است که بعداً در این سند شرح داده شده است. این مقدار به سرور مجوز گوگل دستور می دهد که برای اولین بار که برنامه شما کد مجوز را با رمزها مبادله می کند ، یک نشانه تازه سازی و یک رمز دسترسی بازگرداند.

در پایتون، مجموعه ای access_type پارامتر را بوسیله access_type به عنوان یک بحث کلمه کلیدی هنگام فراخوانی flow.authorization_url روش:

authorization_url, state = flow.authorization_url(
    access_type='offline',
    include_granted_scopes='true')
state توصیه شده

مقدار رشته ای را که برنامه شما برای حفظ وضعیت بین درخواست مجوز شما و پاسخ سرور مجوز استفاده می کند ، مشخص می کند. سرور بعد از اینکه کاربر درخواست دسترسی برنامه شما را رد کرد یا آن را رد کرد ، مقدار دقیقی را که شما به عنوان یک جفت name=value در م quلفه درخواست URL ( ? ) از redirect_uri ارسال می کنید ، برمی گرداند.

شما می توانید از این پارامتر برای اهداف مختلفی استفاده کنید ، مانند هدایت کاربر به سمت منبع صحیح در برنامه خود ، ارسال موارد غیر مجاز و کاهش جعل درخواست بین سایت. از آنجا که می توان redirect_uri شما را حدس زد ، استفاده از یک مقدار state می تواند اطمینان شما را از اینکه اتصال ورودی نتیجه درخواست احراز هویت است ، افزایش دهد. اگر یک رشته تصادفی ایجاد کنید یا هش کوکی یا مقدار دیگری را که حالت مشتری را ضبط می کند رمزگذاری کنید ، می توانید پاسخ را تأیید کنید تا علاوه بر این اطمینان حاصل کنید که درخواست و پاسخ از همان مرورگر نشات گرفته است ، در برابر حملاتی مانند cross-site محافظت می کند درخواست جعل برای نمونه ای از نحوه ایجاد و تأیید رمز state اسناد OpenID Connect مراجعه کنید.

در پایتون ، هنگام تعیین فراخوانی روش flow.authorization_url ، پارامتر state با تعیین state به عنوان استدلال کلمه کلیدی flow.authorization_url :

authorization_url, state = flow.authorization_url(
    access_type='offline',
    state=sample_passthrough_value,
    include_granted_scopes='true')
include_granted_scopes اختیاری

برنامه ها را قادر می سازد تا از مجوز افزایشی برای درخواست دسترسی به محدوده های اضافی در متن استفاده کنند. اگر مقدار این پارامتر را true بگذارید و درخواست مجوز پذیرفته شود ، رمز دسترسی جدید همچنین دامنه هایی را که کاربر قبلاً به برنامه دسترسی داده است ، پوشش می دهد. برای مثال به بخش مجوز افزایشی مراجعه کنید.

در پایتون، مجموعه ای از include_granted_scopes پارامتر را بوسیله include_granted_scopes به عنوان یک بحث کلمه کلیدی هنگام فراخوانی flow.authorization_url روش:

authorization_url, state = flow.authorization_url(
    access_type='offline',
    include_granted_scopes='true')
login_hint اختیاری

اگر برنامه شما می داند کدام کاربر در تلاش است تا احراز هویت شود ، می تواند از این پارامتر برای ارائه راهنمایی به سرور تأیید اعتبار Google استفاده کند. سرور از راهنمایی برای ساده سازی جریان ورود به سیستم یا با پر کردن قسمت ایمیل در فرم ورود به سیستم یا با انتخاب جلسه چند ورود به سیستم مناسب استفاده می کند.

مقدار پارامتر را روی آدرس ایمیل یا شناسه sub ، که معادل شناسه Google کاربر است.

در پایتون ، هنگام تعیین login_hint روش login_hint پارامتر login_hint با تعیین login_hint به عنوان استدلال کلمه کلیدی flow.authorization_url :

authorization_url, state = flow.authorization_url(
    access_type='offline',
    login_hint='None',
    include_granted_scopes='true')
prompt اختیاری

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

در پایتون ، هنگام فراخوانی روش flow.authorization_url ، پارامتر prompt با تعیین prompt به عنوان یک استدلال کلمه کلیدی flow.authorization_url :

authorization_url, state = flow.authorization_url(
      access_type='offline',
      prompt='consent',
      include_granted_scopes='true')

مقادیر احتمالی عبارتند از:

none صفحه های تأیید اعتبار یا رضایت را نمایش ندهید. نباید با مقادیر دیگر مشخص شود.
consent از کاربر درخواست رضایت کنید.
select_account از کاربر بخواهید یک حساب کاربری انتخاب کند.

یاقوت

از فایل client_secrets.json که ایجاد کرده اید برای پیکربندی یک شی client مشتری در برنامه خود استفاده کنید. هنگامی که یک شی سرویس گیرنده را پیکربندی می کنید ، محدوده هایی را که برنامه شما برای دسترسی به آن نیاز دارد ، همراه با URL به نقطه پایانی برنامه خود تعیین می کنید ، که پاسخ از سرور OAuth 2.0 را کنترل می کند.

به عنوان مثال ، این کد دسترسی فقط خواندنی و آفلاین به Google Drive کاربر را درخواست می کند:

require 'google/apis/drive_v2'
require 'google/api_client/client_secrets'

client_secrets = Google::APIClient::ClientSecrets.load
auth_client = client_secrets.to_authorization
auth_client.update!(
  :scope => 'https://www.googleapis.com/auth/drive.metadata.readonly',
  :redirect_uri => 'http://www.example.com/oauth2callback',
  :additional_parameters => {
    "access_type" => "offline",         # offline access
    "include_granted_scopes" => "true"  # incremental auth
  }
)

برنامه شما از شی مشتری برای انجام عملیات OAuth 2.0 مانند تولید URL های درخواست مجوز و اعمال نشانه های دسترسی به درخواست های HTTP استفاده می کند.

HTTP / REST

نقطه پایانی OAuth 2.0 گوگل در https://accounts.google.com/o/oauth2/v2/auth . این نقطه پایانی فقط از طریق HTTPS قابل دسترسی است. ارتباطات ساده HTTP رد می شود.

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

مولفه های
client_id ضروری

شناسه مشتری برنامه شما. این مقدار را می توانید در API Console Credentials page پیدا کنید.

redirect_uri ضروری

مشخص می کند که سرور API پس از تکمیل جریان مجوز توسط کاربر ، کاربر را به کجا هدایت می کند. این مقدار باید دقیقاً مطابق با یکی از URI های تغییر مسیر مجاز برای مشتری OAuth 2.0 باشد ، که شما در API Console Credentials page مشتری خود پیکربندی کرده اید. اگر این مقدار با URI تغییر مسیر مجاز برای client_id ارائه شده client_id ، با خطای redirect_uri_mismatch مواجه خواهید شد.

توجه داشته باشید که طرح http https ، مورد و اسلش انتهایی (' / ') همه باید مطابقت داشته باشند.

response_type ضروری

تعیین می کند که آیا نقطه پایانی Google OAuth 2.0 کد مجوز را برمی گرداند.

مقدار پارامتر را برای code های وب سرور code کنید.

scope ضروری

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

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

ما توصیه می کنیم که برنامه شما درخواست دسترسی به محدوده مجوز را در هر زمان ممکن داشته باشد. با درخواست دسترسی به داده های کاربر در چارچوب ، از طریق مجوز افزایشی ، به کاربران کمک می کنید تا راحت تر درک کنند که چرا برنامه شما به دسترسی مورد درخواست شما نیاز دارد.

access_type توصیه شده

نشان می دهد آیا هنگام حضور کاربر در مرورگر ، برنامه شما می تواند نشانه های دسترسی را تازه کند یا خیر. مقادیر پارامتر معتبر بصورت online هستند که مقدار پیش فرض است و offline .

اگر برنامه شما نیاز به تازه کردن نشانه های دسترسی دارد ، درصورتی که کاربر در مرورگر حضور ندارد ، مقدار را offline دهید. این روش تازه کردن نشانه های دسترسی است که بعداً در این سند شرح داده شده است. این مقدار به سرور مجوز گوگل دستور می دهد که برای اولین بار که برنامه شما کد مجوز را با رمزها مبادله می کند ، یک نشانه تازه سازی و یک رمز دسترسی بازگرداند.

state توصیه شده

مقدار رشته ای را که برنامه شما برای حفظ وضعیت بین درخواست مجوز شما و پاسخ سرور مجوز استفاده می کند ، مشخص می کند. سرور بعد از اینکه کاربر درخواست دسترسی برنامه شما را رد کرد یا آن را رد کرد ، مقدار دقیقی را که شما به عنوان یک جفت name=value در م quلفه درخواست URL ( ? ) از redirect_uri ارسال می کنید ، برمی گرداند.

شما می توانید از این پارامتر برای اهداف مختلفی استفاده کنید ، مانند هدایت کاربر به سمت منبع صحیح در برنامه خود ، ارسال موارد غیر مجاز و کاهش جعل درخواست بین سایت. از آنجا که می توان redirect_uri شما را حدس زد ، استفاده از یک مقدار state می تواند اطمینان شما را از اینکه اتصال ورودی نتیجه درخواست احراز هویت است ، افزایش دهد. اگر یک رشته تصادفی ایجاد کنید یا هش کوکی یا مقدار دیگری را که حالت مشتری را ضبط می کند رمزگذاری کنید ، می توانید پاسخ را تأیید کنید تا علاوه بر این اطمینان حاصل کنید که درخواست و پاسخ از همان مرورگر نشات گرفته است ، در برابر حملاتی مانند cross-site محافظت می کند درخواست جعل برای نمونه ای از نحوه ایجاد و تأیید رمز state اسناد OpenID Connect مراجعه کنید.

include_granted_scopes اختیاری

برنامه ها را قادر می سازد تا از مجوز افزایشی برای درخواست دسترسی به محدوده های اضافی در متن استفاده کنند. اگر مقدار این پارامتر را true بگذارید و درخواست مجوز پذیرفته شود ، رمز دسترسی جدید همچنین دامنه هایی را که کاربر قبلاً به برنامه دسترسی داده است ، پوشش می دهد. برای مثال به بخش مجوز افزایشی مراجعه کنید.

login_hint اختیاری

اگر برنامه شما می داند کدام کاربر در تلاش است تا احراز هویت شود ، می تواند از این پارامتر برای ارائه راهنمایی به سرور تأیید اعتبار Google استفاده کند. سرور از راهنمایی برای ساده سازی جریان ورود به سیستم یا با پر کردن قسمت ایمیل در فرم ورود به سیستم یا با انتخاب جلسه چند ورود به سیستم مناسب استفاده می کند.

مقدار پارامتر را روی آدرس ایمیل یا شناسه sub ، که معادل شناسه Google کاربر است.

prompt اختیاری

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

مقادیر احتمالی عبارتند از:

none صفحه های تأیید اعتبار یا رضایت را نمایش ندهید. نباید با مقادیر دیگر مشخص شود.
consent از کاربر درخواست رضایت کنید.
select_account از کاربر بخواهید یک حساب کاربری انتخاب کند.

مرحله 2: هدایت مجدد به سرور OAuth 2.0 Google

کاربر را به سرور OAuth 2.0 گوگل هدایت کنید تا مراحل تأیید اعتبار و مجوز را آغاز کند. به طور معمول ، این اتفاق زمانی رخ می دهد که برنامه شما برای اولین بار نیاز به دسترسی به داده های کاربر داشته باشد. در مورد مجوز افزایشی ، این مرحله همچنین زمانی اتفاق می افتد که برنامه شما ابتدا نیاز به دسترسی به منابع اضافی دارد که هنوز اجازه دسترسی به آنها را ندارد.

PHP

  1. برای درخواست دسترسی از سرور OAuth 2.0 گوگل یک URL ایجاد کنید:
    $auth_url = $client->createAuthUrl();
  2. کاربر را به $auth_url :
    header('Location: ' . filter_var($auth_url, FILTER_SANITIZE_URL));

پایتون

این مثال نحوه هدایت کاربر به URL مجوز را با استفاده از چارچوب برنامه وب Flask نشان می دهد:

return flask.redirect(authorization_url)

یاقوت

  1. برای درخواست دسترسی از سرور OAuth 2.0 گوگل یک URL ایجاد کنید:
    auth_uri = auth_client.authorization_uri.to_s
  2. کاربر را به auth_uri .

HTTP / REST

تغییر مسیر نمونه به سرور مجوز گوگل

یک مثال از URL در زیر نشان داده شده است ، با وقفه های خط و فاصله برای خوانایی.

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A//www.googleapis.com/auth/drive.metadata.readonly&
 access_type=offline&
 include_granted_scopes=true&
 response_type=code&
 state=state_parameter_passthrough_value&
 redirect_uri=https%3A//oauth2.example.com/code&
 client_id=client_id

پس از ایجاد URL درخواست ، کاربر را به سمت خود هدایت کنید.

سرور OAuth 2.0 گوگل اعتبار کاربر را تأیید می کند و از کاربر برای درخواست شما برای دسترسی به محدوده های درخواستی از کاربر رضایت می گیرد. پاسخ با استفاده از URL هدایتی که تعیین کرده اید به برنامه شما ارسال می شود.

مرحله 3: Google از کاربر درخواست رضایت می کند

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

برنامه شما در این مرحله نیازی به انجام کاری ندارد زیرا منتظر پاسخ سرور OAuth 2.0 Google است که نشان می دهد آیا دسترسی داده شده است. پاسخ در مرحله زیر توضیح داده شده است.

خطاها

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

admin_policy_enforced

حساب Google به دلیل خط مشی های سرپرست Google Workspace خود ، قادر به تأیید یک یا چند محدوده درخواست شده نیست. برای کسب اطلاعات بیشتر در مورد اینکه چگونه یک مدیر می تواند دسترسی به همه محدوده ها یا محدوده های حساس و محدود را محدود کند تا دسترسی صریح به شناسه مشتری OAuth شما محدود شود ، به مقاله راهنمای سرپرست Google Workspace Google مراجعه کنید.

disallowed_useragent

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

اندروید

توسعه دهندگان Android ممکن است هنگام باز کردن درخواست های مجوز در android.webkit.WebView با این پیام خطا مواجه شوند. در عوض ، توسعه دهندگان باید از کتابخانه های Android مانند Google Sign-In for Android یا OpenID Foundation AppAuth برای Android استفاده کنند .

برنامه نویسان وب ممکن است با این خطا روبرو شوند که یک برنامه Android یک پیوند وب کلی را در یک عامل کاربر تعبیه شده باز کند و کاربر از سایت شما به نقطه پایان مجوز OAuth 2.0 Google هدایت شود. توسعه دهندگان باید اجازه دهند پیوندهای عمومی در کنترل کننده پیوند پیش فرض سیستم عامل باز شود ، که شامل هر دو کنترل کنندهپیوندهای برنامه Android یا برنامه مرورگر پیش فرض است. کتابخانه Android Custom Tabs نیز گزینه پشتیبانی شده است.

iOS

توسعه دهندگان iOS و macOS هنگام باز کردن درخواست های مجوز در WKWebView ممکن است با این خطا روبرو شوند. در عوض ، توسعه دهندگان باید از کتابخانه های iOS مانند Google Sign-In برای iOS یا OpenA Foundation AppAuth برای iOS استفاده کنند .

برنامه نویسان وب ممکن است با این خطا روبرو شوند که یک برنامه iOS یا macOS یک پیوند وب کلی را در یک عامل کاربر تعبیه شده باز کند و کاربر از سایت شما به نقطه پایانی مجوز OAuth 2.0 Google هدایت شود. توسعه دهندگان باید اجازه دهند پیوندهای عمومی در کنترل کننده پیوند پیش فرض سیستم عامل باز شود ، که شامل هر دو دستگیرهUniversal Links یا برنامه پیش فرض مرورگر است. کتابخانه SFSafariViewController نیز گزینه پشتیبانی شده است.

org_internal

شناسه مشتری OAuth در درخواست بخشی از پروژه محدود کردن دسترسی به حساب های Google در یک سازمان Google Cloud خاص است. برای کسب اطلاعات بیشتر در مورد این گزینه پیکربندی ، به بخش نوع کاربر در مقاله راهنمای تنظیم رضایت OAuth مراجعه کنید.

redirect_uri_mismatch

redirect_uri که در درخواست مجوز تصویب شده است با URI تغییر مسیر مجاز برای شناسه مشتری OAuth مطابقت ندارد. URI های تغییر مسیر مجاز را در Google API Console Credentials page مرور کنید.

مرحله 4: پاسخ سرور OAuth 2.0 را مدیریت کنید

سرور OAuth 2.0 با استفاده از URL مشخص شده در درخواست به درخواست دسترسی برنامه شما پاسخ می دهد.

اگر کاربر درخواست دسترسی را تأیید کند ، پاسخ حاوی کد اجازه است. اگر کاربر درخواست را تأیید نکند ، پاسخ حاوی یک پیام خطا است. همانطور که در زیر نشان داده شده است ، کد مجوز یا پیام خطا که به وب سرور بازگردانده می شود ، در رشته جستجو نمایش داده می شود:

پاسخ خطا:

https://oauth2.example.com/auth?error=access_denied

پاسخ کد مجوز:

https://oauth2.example.com/auth?code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7

نمونه پاسخ سرور OAuth 2.0

می توانید این جریان را با کلیک بر روی URL نمونه زیر آزمایش کنید ، که درخواست دسترسی فقط خواندنی برای مشاهده فراداده های پرونده ها در Google Drive شما را دارد:

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A//www.googleapis.com/auth/drive.metadata.readonly&
 access_type=offline&
 include_granted_scopes=true&
 response_type=code&
 state=state_parameter_passthrough_value&
 redirect_uri=https%3A//oauth2.example.com/code&
 client_id=client_id

After completing the OAuth 2.0 flow, you should be redirected to http://localhost/oauth2callback , which will likely yield a 404 NOT FOUND error unless your local machine serves a file at that address. The next step provides more detail about the information returned in the URI when the user is redirected back to your application.

Step 5: Exchange authorization code for refresh and access tokens

After the web server receives the authorization code, it can exchange the authorization code for an access token.

PHP

To exchange an authorization code for an access token, use the authenticate method:

$client->authenticate($_GET['code']);

You can retrieve the access token with the getAccessToken method:

$access_token = $client->getAccessToken();

Python

On your callback page, use the google-auth library to verify the authorization server response. Then, use the flow.fetch_token method to exchange the authorization code in that response for an access token:

state = flask.session['state']
flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file(
    'client_secret.json',
    scopes=['https://www.googleapis.com/auth/drive.metadata.readonly'],
    state=state)
flow.redirect_uri = flask.url_for('oauth2callback', _external=True)

authorization_response = flask.request.url
flow.fetch_token(authorization_response=authorization_response)

# Store the credentials in the session.
# ACTION ITEM for developers:
#     Store user's access and refresh tokens in your data store if
#     incorporating this code into your real app.
credentials = flow.credentials
flask.session['credentials'] = {
    'token': credentials.token,
    'refresh_token': credentials.refresh_token,
    'token_uri': credentials.token_uri,
    'client_id': credentials.client_id,
    'client_secret': credentials.client_secret,
    'scopes': credentials.scopes}

Ruby

To exchange an authorization code for an access token, use the fetch_access_token! method:

auth_client.code = auth_code
auth_client.fetch_access_token!

HTTP/REST

To exchange an authorization code for an access token, call the https://oauth2.googleapis.com/token endpoint and set the following parameters:

Fields
client_id The client ID obtained from the API Console Credentials page.
client_secret The client secret obtained from the API Console Credentials page.
code The authorization code returned from the initial request.
grant_type As defined in the OAuth 2.0 specification , this field's value must be set to authorization_code .
redirect_uri One of the redirect URIs listed for your project in the API Console Credentials page for the given client_id .

The following snippet shows a sample request:

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

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your_client_id&
client_secret=your_client_secret&
redirect_uri=https%3A//oauth2.example.com/code&
grant_type=authorization_code

Google responds to this request by returning a JSON object that contains a short-lived access token and a refresh token. Note that the refresh token is only returned if your application set the access_type parameter to offline in the initial request to Google's authorization server .

The response contains the following fields:

Fields
access_token The token that your application sends to authorize a Google API request.
expires_in The remaining lifetime of the access token in seconds.
refresh_token A token that you can use to obtain a new access token. Refresh tokens are valid until the user revokes access. Again, this field is only present in this response if you set the access_type parameter to offline in the initial request to Google's authorization server.
scope The scopes of access granted by the access_token expressed as a list of space-delimited, case-sensitive strings.
token_type The type of token returned. At this time, this field's value is always set to Bearer .

The following snippet shows a sample response:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "token_type": "Bearer",
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

Calling Google APIs

PHP

Use the access token to call Google APIs by completing the following steps:

  1. If you need to apply an access token to a new Google_Client object—for example, if you stored the access token in a user session—use the setAccessToken method:
    $client->setAccessToken($access_token);
  2. Build a service object for the API that you want to call. You build a service object by providing an authorized Google_Client object to the constructor for the API you want to call. For example, to call the Drive API:
    $drive = new Google_Service_Drive($client);
  3. Make requests to the API service using the interface provided by the service object . For example, to list the files in the authenticated user's Google Drive:
    $files = $drive->files->listFiles(array())->getItems();

Python

After obtaining an access token, your application can use that token to authorize API requests on behalf of a given user account or service account. Use the user-specific authorization credentials to build a service object for the API that you want to call, and then use that object to make authorized API requests.

  1. Build a service object for the API that you want to call. You build a service object by calling the googleapiclient.discovery library's build method with the name and version of the API and the user credentials: For example, to call version 2 of the Drive API:
    from googleapiclient.discovery import build
    
    drive = build('drive', 'v2', credentials=credentials)
  2. Make requests to the API service using the interface provided by the service object . For example, to list the files in the authenticated user's Google Drive:
    files = drive.files().list().execute()

Ruby

Use the auth_client object to call Google APIs by completing the following steps:

  1. Build a service object for the API that you want to call. For example, to call version 2 of the Drive API:
    drive = Google::Apis::DriveV2::DriveService.new
  2. Set the credentials on the service:
    drive.authorization = auth_client
  3. Make requests to the API service using the interface provided by the service object . For example, to list the files in the authenticated user's Google Drive:
    files = drive.list_files

Alternately, authorization can be provided on a per-method basis by supplying the options parameter to a method:

files = drive.list_files(options: { authorization: auth_client })

HTTP/REST

After your application obtains an access token, you can use the token to make calls to a Google API on behalf of a given user account if the scope(s) of access required by the API have been granted. To do this, include the access token in a request to the API by including either an access_token query parameter or an Authorization HTTP header Bearer value. When possible, the HTTP header is preferable, because query strings tend to be visible in server logs. In most cases you can use a client library to set up your calls to Google APIs (for example, when calling the Drive Files API ).

You can try out all the Google APIs and view their scopes at the OAuth 2.0 Playground .

HTTP GET examples

A call to the drive.files endpoint (the Drive Files API) using the Authorization: Bearer HTTP header might look like the following. Note that you need to specify your own access token:

GET /drive/v2/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

Here is a call to the same API for the authenticated user using the access_token query string parameter:

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

curl examples

You can test these commands with the curl command-line application. Here's an example that uses the HTTP header option (preferred):

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

Or, alternatively, the query string parameter option:

curl https://www.googleapis.com/drive/v2/files?access_token=access_token

Complete example

The following example prints a JSON-formatted list of files in a user's Google Drive after the user authenticates and gives consent for the application to access the user's Drive metadata.

PHP

To run this example:

  1. In the API Console, add the URL of the local machine to the list of redirect URLs. For example, add http://localhost:8080 .
  2. Create a new directory and change to it. For example:
    mkdir ~/php-oauth2-example
    cd ~/php-oauth2-example
  3. Install the Google API Client Library for PHP using Composer :
    composer require google/apiclient:^2.0
  4. Create the files index.php and oauth2callback.php with the content below.
  5. Run the example with a web server configured to serve PHP. If you use PHP 5.4 or newer, you can use PHP's built-in test web server:
    php -S localhost:8080 ~/php-oauth2-example

index.php

<?php
require_once __DIR__.'/vendor/autoload.php';

session_start();

$client = new Google_Client();
$client->setAuthConfig('client_secrets.json');
$client->addScope(Google_Service_Drive::DRIVE_METADATA_READONLY);

if (isset($_SESSION['access_token']) && $_SESSION['access_token']) {
  $client->setAccessToken($_SESSION['access_token']);
  $drive = new Google_Service_Drive($client);
  $files = $drive->files->listFiles(array())->getItems();
  echo json_encode($files);
} else {
  $redirect_uri = 'http://' . $_SERVER['HTTP_HOST'] . '/oauth2callback.php';
  header('Location: ' . filter_var($redirect_uri, FILTER_SANITIZE_URL));
}

oauth2callback.php

<?php
require_once __DIR__.'/vendor/autoload.php';

session_start();

$client = new Google_Client();
$client->setAuthConfigFile('client_secrets.json');
$client->setRedirectUri('http://' . $_SERVER['HTTP_HOST'] . '/oauth2callback.php');
$client->addScope(Google_Service_Drive::DRIVE_METADATA_READONLY);

if (! isset($_GET['code'])) {
  $auth_url = $client->createAuthUrl();
  header('Location: ' . filter_var($auth_url, FILTER_SANITIZE_URL));
} else {
  $client->authenticate($_GET['code']);
  $_SESSION['access_token'] = $client->getAccessToken();
  $redirect_uri = 'http://' . $_SERVER['HTTP_HOST'] . '/';
  header('Location: ' . filter_var($redirect_uri, FILTER_SANITIZE_URL));
}

Python

This example uses the Flask framework. It runs a web application at http://localhost:8080 that lets you test the OAuth 2.0 flow. If you go to that URL, you should see four links:

  • Test an API request: This link points to a page that tries to execute a sample API request. If necessary, it starts the authorization flow. If successful, the page displays the API response.
  • Test the auth flow directly: This link points to a page that tries to send the user through the authorization flow . The app requests permission to submit authorized API requests on the user's behalf.
  • Revoke current credentials: This link points to a page that revokes permissions that the user has already granted to the application.
  • Clear Flask session credentials: This link clears authorization credentials that are stored in the Flask session. This lets you see what would happen if a user who had already granted permission to your app tried to execute an API request in a new session. It also lets you see the API response your app would get if a user had revoked permissions granted to your app, and your app still tried to authorize a request with a revoked access token.
# -*- coding: utf-8 -*-

import os
import flask
import requests

import google.oauth2.credentials
import google_auth_oauthlib.flow
import googleapiclient.discovery

# This variable specifies the name of a file that contains the OAuth 2.0
# information for this application, including its client_id and client_secret.
CLIENT_SECRETS_FILE = "client_secret.json"

# This OAuth 2.0 access scope allows for full read/write access to the
# authenticated user's account and requires requests to use an SSL connection.
SCOPES = ['https://www.googleapis.com/auth/drive.metadata.readonly']
API_SERVICE_NAME = 'drive'
API_VERSION = 'v2'

app = flask.Flask(__name__)
# Note: A secret key is included in the sample so that it works.
# If you use this code in your application, replace this with a truly secret
# key. See https://flask.palletsprojects.com/quickstart/#sessions.
app.secret_key = 'REPLACE ME - this value is here as a placeholder.'


@app.route('/')
def index():
  return print_index_table()


@app.route('/test')
def test_api_request():
  if 'credentials' not in flask.session:
    return flask.redirect('authorize')

  # Load credentials from the session.
  credentials = google.oauth2.credentials.Credentials(
      **flask.session['credentials'])

  drive = googleapiclient.discovery.build(
      API_SERVICE_NAME, API_VERSION, credentials=credentials)

  files = drive.files().list().execute()

  # Save credentials back to session in case access token was refreshed.
  # ACTION ITEM: In a production app, you likely want to save these
  #              credentials in a persistent database instead.
  flask.session['credentials'] = credentials_to_dict(credentials)

  return flask.jsonify(**files)


@app.route('/authorize')
def authorize():
  # Create flow instance to manage the OAuth 2.0 Authorization Grant Flow steps.
  flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file(
      CLIENT_SECRETS_FILE, scopes=SCOPES)

  # The URI created here must exactly match one of the authorized redirect URIs
  # for the OAuth 2.0 client, which you configured in the API Console. If this
  # value doesn't match an authorized URI, you will get a 'redirect_uri_mismatch'
  # error.
  flow.redirect_uri = flask.url_for('oauth2callback', _external=True)

  authorization_url, state = flow.authorization_url(
      # Enable offline access so that you can refresh an access token without
      # re-prompting the user for permission. Recommended for web server apps.
      access_type='offline',
      # Enable incremental authorization. Recommended as a best practice.
      include_granted_scopes='true')

  # Store the state so the callback can verify the auth server response.
  flask.session['state'] = state

  return flask.redirect(authorization_url)


@app.route('/oauth2callback')
def oauth2callback():
  # Specify the state when creating the flow in the callback so that it can
  # verified in the authorization server response.
  state = flask.session['state']

  flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file(
      CLIENT_SECRETS_FILE, scopes=SCOPES, state=state)
  flow.redirect_uri = flask.url_for('oauth2callback', _external=True)

  # Use the authorization server's response to fetch the OAuth 2.0 tokens.
  authorization_response = flask.request.url
  flow.fetch_token(authorization_response=authorization_response)

  # Store credentials in the session.
  # ACTION ITEM: In a production app, you likely want to save these
  #              credentials in a persistent database instead.
  credentials = flow.credentials
  flask.session['credentials'] = credentials_to_dict(credentials)

  return flask.redirect(flask.url_for('test_api_request'))


@app.route('/revoke')
def revoke():
  if 'credentials' not in flask.session:
    return ('You need to <a href="/authorize">authorize</a> before ' +
            'testing the code to revoke credentials.')

  credentials = google.oauth2.credentials.Credentials(
    **flask.session['credentials'])

  revoke = requests.post('https://oauth2.googleapis.com/revoke',
      params={'token': credentials.token},
      headers = {'content-type': 'application/x-www-form-urlencoded'})

  status_code = getattr(revoke, 'status_code')
  if status_code == 200:
    return('Credentials successfully revoked.' + print_index_table())
  else:
    return('An error occurred.' + print_index_table())


@app.route('/clear')
def clear_credentials():
  if 'credentials' in flask.session:
    del flask.session['credentials']
  return ('Credentials have been cleared.<br><br>' +
          print_index_table())


def credentials_to_dict(credentials):
  return {'token': credentials.token,
          'refresh_token': credentials.refresh_token,
          'token_uri': credentials.token_uri,
          'client_id': credentials.client_id,
          'client_secret': credentials.client_secret,
          'scopes': credentials.scopes}

def print_index_table():
  return ('<table>' +
          '<tr><td><a href="/test">Test an API request</a></td>' +
          '<td>Submit an API request and see a formatted JSON response. ' +
          '    Go through the authorization flow if there are no stored ' +
          '    credentials for the user.</td></tr>' +
          '<tr><td><a href="/authorize">Test the auth flow directly</a></td>' +
          '<td>Go directly to the authorization flow. If there are stored ' +
          '    credentials, you still might not be prompted to reauthorize ' +
          '    the application.</td></tr>' +
          '<tr><td><a href="/revoke">Revoke current credentials</a></td>' +
          '<td>Revoke the access token associated with the current user ' +
          '    session. After revoking credentials, if you go to the test ' +
          '    page, you should see an <code>invalid_grant</code> error.' +
          '</td></tr>' +
          '<tr><td><a href="/clear">Clear Flask session credentials</a></td>' +
          '<td>Clear the access token currently stored in the user session. ' +
          '    After clearing the token, if you <a href="/test">test the ' +
          '    API request</a> again, you should go back to the auth flow.' +
          '</td></tr></table>')


if __name__ == '__main__':
  # When running locally, disable OAuthlib's HTTPs verification.
  # ACTION ITEM for developers:
  #     When running in production *do not* leave this option enabled.
  os.environ['OAUTHLIB_INSECURE_TRANSPORT'] = '1'

  # Specify a hostname and port that are set as a valid redirect URI
  # for your API project in the Google API Console.
  app.run('localhost', 8080, debug=True)

Ruby

This example uses the Sinatra framework.

require 'google/apis/drive_v2'
require 'google/api_client/client_secrets'
require 'json'
require 'sinatra'

enable :sessions
set :session_secret, 'setme'

get '/' do
  unless session.has_key?(:credentials)
    redirect to('/oauth2callback')
  end
  client_opts = JSON.parse(session[:credentials])
  auth_client = Signet::OAuth2::Client.new(client_opts)
  drive = Google::Apis::DriveV2::DriveService.new
  files = drive.list_files(options: { authorization: auth_client })
  "<pre>#{JSON.pretty_generate(files.to_h)}</pre>"
end

get '/oauth2callback' do
  client_secrets = Google::APIClient::ClientSecrets.load
  auth_client = client_secrets.to_authorization
  auth_client.update!(
    :scope => 'https://www.googleapis.com/auth/drive.metadata.readonly',
    :redirect_uri => url('/oauth2callback'))
  if request['code'] == nil
    auth_uri = auth_client.authorization_uri.to_s
    redirect to(auth_uri)
  else
    auth_client.code = request['code']
    auth_client.fetch_access_token!
    auth_client.client_secret = nil
    session[:credentials] = auth_client.to_json
    redirect to('/')
  end
end

HTTP/REST

This Python example uses the Flask framework and the Requests library to demonstrate the OAuth 2.0 web flow. We recommend using the Google API Client Library for Python for this flow. (The example in the Python tab does use the client library.)

import json

import flask
import requests


app = flask.Flask(__name__)

CLIENT_ID = '123456789.apps.googleusercontent.com'
CLIENT_SECRET = 'abc123'  # Read from a file or environmental variable in a real app
SCOPE = 'https://www.googleapis.com/auth/drive.metadata.readonly'
REDIRECT_URI = 'http://example.com/oauth2callback'


@app.route('/')
def index():
  if 'credentials' not in flask.session:
    return flask.redirect(flask.url_for('oauth2callback'))
  credentials = json.loads(flask.session['credentials'])
  if credentials['expires_in'] <= 0:
    return flask.redirect(flask.url_for('oauth2callback'))
  else:
    headers = {'Authorization': 'Bearer {}'.format(credentials['access_token'])}
    req_uri = 'https://www.googleapis.com/drive/v2/files'
    r = requests.get(req_uri, headers=headers)
    return r.text


@app.route('/oauth2callback')
def oauth2callback():
  if 'code' not in flask.request.args:
    auth_uri = ('https://accounts.google.com/o/oauth2/v2/auth?response_type=code'
                '&client_id={}&redirect_uri={}&scope={}').format(CLIENT_ID, REDIRECT_URI, SCOPE)
    return flask.redirect(auth_uri)
  else:
    auth_code = flask.request.args.get('code')
    data = {'code': auth_code,
            'client_id': CLIENT_ID,
            'client_secret': CLIENT_SECRET,
            'redirect_uri': REDIRECT_URI,
            'grant_type': 'authorization_code'}
    r = requests.post('https://oauth2.googleapis.com/token', data=data)
    flask.session['credentials'] = r.text
    return flask.redirect(flask.url_for('index'))


if __name__ == '__main__':
  import uuid
  app.secret_key = str(uuid.uuid4())
  app.debug = False
  app.run()

Redirect URI validation rules

Google applies the following validation rules to redirect URIs in order to help developers keep their applications secure. Your redirect URIs must adhere to these rules. See RFC 3986 section 3 for the definition of domain, host, path, query, scheme and userinfo, mentioned below.

Validation rules
Scheme

URIs must use the HTTPS scheme, not plain HTTP. Localhost URIs (including localhost IP address URIs) are exempt from this rule.

Host

Hosts cannot be raw IP addresses. Localhost IP addresses are exempted from this rule.

Domain
  • Host TLDs ( Top Level Domains ) must belong to the public suffix list .
  • Host domains cannot be “googleusercontent.com” .
  • URIs cannot contain URL shortener domains (eg goo.gl ) unless the app owns the domain. Furthermore, if an app that owns a shortener domain chooses to redirect to that domain, that redirect URI must either contain “/google-callback/” in its path or end with “/google-callback” .
  • Userinfo

    Redirect URIs cannot contain the userinfo subcomponent.

    Path

    Redirect URIs cannot contain a path traversal (also called directory backtracking), which is represented by an “/..” or “\..” or their URL encoding.

    Query

    Redirect URIs cannot contain open redirects .

    Characters URIs cannot contain certain characters including:
    • Wildcard characters ( '*' )
    • Non-printable ASCII characters
    • Invalid percent encodings (any percent encoding that does not follow URL-encoding form of a percent sign followed by two hexadecimal digits)
    • Null characters (an encoded NULL character, eg, %00 , %C0%80 )

    Incremental authorization

    In the OAuth 2.0 protocol, your app requests authorization to access resources, which are identified by scopes. It is considered a best user-experience practice to request authorization for resources at the time you need them. To enable that practice, Google's authorization server supports incremental authorization. This feature lets you request scopes as they are needed and, if the user grants permission for the new scope, returns an authorization code that may be exchanged for a token containing all scopes the user has granted the project.

    For example, an app that lets people sample music tracks and create mixes might need very few resources at sign-in time, perhaps nothing more than the name of the person signing in. However, saving a completed mix would require access to their Google Drive. Most people would find it natural if they only were asked for access to their Google Drive at the time the app actually needed it.

    In this case, at sign-in time the app might request the openid and profile scopes to perform basic sign-in, and then later request the https://www.googleapis.com/auth/drive.file scope at the time of the first request to save a mix.

    To implement incremental authorization, you complete the normal flow for requesting an access token but make sure that the authorization request includes previously granted scopes. This approach allows your app to avoid having to manage multiple access tokens.

    The following rules apply to an access token obtained from an incremental authorization:

    • The token can be used to access resources corresponding to any of the scopes rolled into the new, combined authorization.
    • When you use the refresh token for the combined authorization to obtain an access token, the access token represents the combined authorization and can be used for any of the scope values included in the response.
    • The combined authorization includes all scopes that the user granted to the API project even if the grants were requested from different clients. For example, if a user granted access to one scope using an application's desktop client and then granted another scope to the same application via a mobile client, the combined authorization would include both scopes.
    • If you revoke a token that represents a combined authorization, access to all of that authorization's scopes on behalf of the associated user are revoked simultaneously.

    The language-specific code samples in Step 1: Set authorization parameters and the sample HTTP/REST redirect URL in Step 2: Redirect to Google's OAuth 2.0 server all use incremental authorization. The code samples below also show the code that you need to add to use incremental authorization.

    PHP

    $client->setIncludeGrantedScopes(true);

    Python

    In Python, set the include_granted_scopes keyword argument to true to ensure that an authorization request includes previously granted scopes. It is very possible that include_granted_scopes will not be the only keyword argument that you set, as shown in the example below.

    authorization_url, state = flow.authorization_url(
        # Enable offline access so that you can refresh an access token without
        # re-prompting the user for permission. Recommended for web server apps.
        access_type='offline',
        # Enable incremental authorization. Recommended as a best practice.
        include_granted_scopes='true')

    Ruby

    auth_client.update!(
      :additional_parameters => {"include_granted_scopes" => "true"}
    )

    HTTP/REST

    GET https://accounts.google.com/o/oauth2/v2/auth?
      client_id=your_client_id&
      response_type=code&
      state=state_parameter_passthrough_value&
      scope=https%3A//www.googleapis.com/auth/drive.file&
      redirect_uri=https%3A//oauth2.example.com/code&
      prompt=consent&
      include_granted_scopes=true

    Refreshing an access token (offline access)

    Access tokens periodically expire and become invalid credentials for a related API request. You can refresh an access token without prompting the user for permission (including when the user is not present) if you requested offline access to the scopes associated with the token.

    • If you use a Google API Client Library, the client object refreshes the access token as needed as long as you configure that object for offline access.
    • If you are not using a client library, you need to set the access_type HTTP query parameter to offline when redirecting the user to Google's OAuth 2.0 server . In that case, Google's authorization server returns a refresh token when you exchange an authorization code for an access token. Then, if the access token expires (or at any other time), you can use a refresh token to obtain a new access token.

    Requesting offline access is a requirement for any application that needs to access a Google API when the user is not present. For example, an app that performs backup services or executes actions at predetermined times needs to be able to refresh its access token when the user is not present. The default style of access is called online .

    Server-side web applications, installed applications, and devices all obtain refresh tokens during the authorization process. Refresh tokens are not typically used in client-side (JavaScript) web applications.

    PHP

    If your application needs offline access to a Google API, set the API client's access type to offline :

    $client->setAccessType("offline");

    After a user grants offline access to the requested scopes, you can continue to use the API client to access Google APIs on the user's behalf when the user is offline. The client object will refresh the access token as needed.

    Python

    In Python, set the access_type keyword argument to offline to ensure that you will be able to refresh the access token without having to re-prompt the user for permission. It is very possible that access_type will not be the only keyword argument that you set, as shown in the example below.

    authorization_url, state = flow.authorization_url(
        # Enable offline access so that you can refresh an access token without
        # re-prompting the user for permission. Recommended for web server apps.
        access_type='offline',
        # Enable incremental authorization. Recommended as a best practice.
        include_granted_scopes='true')

    After a user grants offline access to the requested scopes, you can continue to use the API client to access Google APIs on the user's behalf when the user is offline. The client object will refresh the access token as needed.

    Ruby

    If your application needs offline access to a Google API, set the API client's access type to offline :

    auth_client.update!(
      :additional_parameters => {"access_type" => "offline"}
    )

    After a user grants offline access to the requested scopes, you can continue to use the API client to access Google APIs on the user's behalf when the user is offline. The client object will refresh the access token as needed.

    HTTP/REST

    To refresh an access token, your application sends an HTTPS POST request to Google's authorization server ( https://oauth2.googleapis.com/token ) that includes the following parameters:

    Fields
    client_id The client ID obtained from the API Console.
    client_secret The client secret obtained from the API Console.
    grant_type As defined in the OAuth 2.0 specification , this field's value must be set to refresh_token .
    refresh_token The refresh token returned from the authorization code exchange.

    The following snippet shows a sample request:

    POST /token HTTP/1.1
    Host: oauth2.googleapis.com
    Content-Type: application/x-www-form-urlencoded
    
    client_id=your_client_id&
    client_secret=your_client_secret&
    refresh_token=refresh_token&
    grant_type=refresh_token

    As long as the user has not revoked the access granted to the application, the token server returns a JSON object that contains a new access token. The following snippet shows a sample response:

    {
      "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
      "expires_in": 3920,
      "scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
      "token_type": "Bearer"
    }

    Note that there are limits on the number of refresh tokens that will be issued; one limit per client/user combination, and another per user across all clients. You should save refresh tokens in long-term storage and continue to use them as long as they remain valid. If your application requests too many refresh tokens, it may run into these limits, in which case older refresh tokens will stop working.

    Revoking a token

    In some cases a user may wish to revoke access given to an application. A user can revoke access by visiting Account Settings . See the Remove site or app access section of the Third-party sites & apps with access to your account support document for more information.

    It is also possible for an application to programmatically revoke the access given to it. Programmatic revocation is important in instances where a user unsubscribes, removes an application, or the API resources required by an app have significantly changed. In other words, part of the removal process can include an API request to ensure the permissions previously granted to the application are removed.

    PHP

    To programmatically revoke a token, call revokeToken() :

    $client->revokeToken();

    Python

    To programmatically revoke a token, make a request to https://oauth2.googleapis.com/revoke that includes the token as a parameter and sets the Content-Type header:

    requests.post('https://oauth2.googleapis.com/revoke',
        params={'token': credentials.token},
        headers = {'content-type': 'application/x-www-form-urlencoded'})

    Ruby

    To programmatically revoke a token, make an HTTP request to the oauth2.revoke endpoint:

    uri = URI('https://oauth2.googleapis.com/revoke')
    response = Net::HTTP.post_form(uri, 'token' => auth_client.access_token)
    

    The token can be an access token or a refresh token. If the token is an access token and it has a corresponding refresh token, the refresh token will also be revoked.

    If the revocation is successfully processed, then the status code of the response is 200 . For error conditions, a status code 400 is returned along with an error code.

    HTTP/REST

    To programmatically revoke a token, your application makes a request to https://oauth2.googleapis.com/revoke and includes the token as a parameter:

    curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
            https://oauth2.googleapis.com/revoke?token={token}

    The token can be an access token or a refresh token. If the token is an access token and it has a corresponding refresh token, the refresh token will also be revoked.

    If the revocation is successfully processed, then the HTTP status code of the response is 200 . For error conditions, an HTTP status code 400 is returned along with an error code.