Google מחויבת לקידום הון גזעני לקהילות שחורות. תראה איך.

שימוש ב- OAuth 2.0 ליישומי שרת אינטרנט

מסמך זה מסביר כיצד יישומי שרתי אינטרנט משתמשים בספריות לקוח API של Google או בנקודות קצה של Google OAuth 2.0 כדי ליישם הרשאת OAuth 2.0 לגישה לממשקי API של Google.

OAuth 2.0 מאפשר למשתמשים לשתף נתונים ספציפיים עם יישום תוך שמירה על פרטיות שמות המשתמש, הסיסמאות והמידע האחר שלהם. לדוגמה, יישום יכול להשתמש ב- OAuth 2.0 כדי להשיג הרשאה ממשתמשים לאחסון קבצים בכונני Google שלהם.

זרימת OAuth 2.0 זו מיועדת במיוחד לאישור משתמשים. הוא מיועד ליישומים שיכולים לאחסן מידע חסוי ולשמור על המצב. יישום שרתי אינטרנט מורשה כראוי יכול לגשת ל- API בזמן שהמשתמש מקיים אינטראקציה עם היישום או לאחר שהמשתמש עזב את היישום.

יישומי שרת אינטרנט משתמשים לעתים קרובות גם בחשבונות שירות כדי לאשר בקשות API, במיוחד כאשר קוראים ל- API של ענן לגשת לנתונים מבוססי פרויקט ולא לנתונים ספציפיים למשתמש. יישומי שרתי אינטרנט יכולים להשתמש בחשבונות שירות בשילוב עם הרשאת משתמש.

ספריות לקוחות

הדוגמאות הספציפיות לשפה בעמוד זה משתמשות בספריות הלקוח של Google API ליישום הרשאת OAuth 2.0. כדי להריץ את דוגמאות הקוד, תחילה עליך להתקין את ספריית הלקוחות עבור שפתך.

כאשר אתה משתמש בספריית לקוח API של Google כדי לטפל בזרימת ה- OAuth 2.0 של היישום שלך, ספריית הלקוחות מבצעת פעולות רבות שהיישום היה צריך לטפל בה בכוחות עצמה. לדוגמה, הוא קובע מתי היישום יכול להשתמש או לרענן אסימוני גישה מאוחסנים וכן מתי היישום צריך לרכוש מחדש את ההסכמה. ספריית הלקוחות מייצרת גם כתובות אתרים להפניה נכונה ועוזרת ביישום מטפלים להפניה מחדש המחליפים קודי הרשאה עבור אסימוני גישה.

ספריות לקוחות זמינות בשפות הבאות:

תנאים מוקדמים

הפעל ממשקי API לפרויקט שלך

כל יישום שמתקשר לממשקי API של גוגל צריך לאפשר את ממשקי ה- 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 שברצונך להפעיל, ואז לחץ על הלחצן הפעל .
  5. If prompted, enable billing.
  6. If prompted, read and accept the API's Terms of Service.

צור אישורי הרשאה

כל יישום שמשתמש ב- OAuth 2.0 כדי לגשת לממשקי API של Google חייב להיות בעל אישורי הרשאה המזהים את היישום לשרת OAuth 2.0 של גוגל. השלבים הבאים מסבירים כיצד ליצור אישורים לפרויקט שלך. היישומים שלך יכולים להשתמש בתעודות כדי לגשת לממשקי API שהפעלת עבור פרויקט זה.

  1. Go to the Credentials page.
  2. לחץ על צור אישורים> מזהה לקוח OAuth .
  3. בחר את סוג יישום יישום האינטרנט .
  4. מלא את הטופס ולחץ על צור . יישומים המשתמשים בשפות ומסגרות כמו PHP, Java, Python, Ruby ו- .NET חייבים לציין URI מורשים להפניה מחדש . כתובות ה- URI להפניה מחדש הן נקודות הקצה אליהן יכול שרת OAuth 2.0 לשלוח תגובות. על נקודות קצה אלה לעמוד בכללי האימות של גוגל .

    לבדיקה, תוכל לציין URIs המתייחסים למכונה המקומית, כגון http://localhost:8080 . עם זאת, שים לב כי כל הדוגמאות במסמך זה משתמשות ב- http://localhost:8080 כ- URI להפניה מחדש.

    אנו ממליצים לעצב את נקודות הקצה האימותיות של האפליקציה שלך כך שהיישום שלך לא יחשוף קודי הרשאה למשאבים אחרים בדף.

לאחר יצירת האישורים שלך, הורד את קובץ client_secret.json מה- API Console. אחסן את הקובץ בצורה מאובטחת במיקום שרק היישום שלך יכול לגשת אליו.

זהה טווחי גישה

היקפים מאפשרים ליישום שלך לבקש גישה למשאבים הדרושים לו בלבד, אך גם לאפשר למשתמשים לשלוט בכמות הגישה שהם מעניקים ליישום שלך. לפיכך, יתכן שיש קשר הפוך בין מספר ההיקפים המבוקשים לבין הסבירות לקבל הסכמת משתמש.

לפני שתתחיל ליישם הרשאת OAuth 2.0, אנו ממליצים שתזהה את ההיקפים שאליהם האפליקציה שלך תצטרך הרשאה לגשת.

אנו ממליצים גם ליישום שלך לבקש גישה להיקפי הרשאות באמצעות תהליך אישור מצטבר , שבו היישום שלך מבקש גישה לנתוני משתמש בהקשר. שיטה מומלצת זו מסייעת למשתמשים להבין ביתר קלות מדוע היישום שלך זקוק לגישה שהיא מבקשת.

מסמך ה- Scope של API של OAuth 2.0 מכיל רשימה מלאה של היקפים שבהם אתה יכול להשתמש כדי לגשת לממשקי API של Google.

דרישות ספציפיות לשפה

כדי להריץ דוגמאות קוד במסמך זה, תזדקק לחשבון Google, גישה לאינטרנט ודפדפן אינטרנט. אם אתה משתמש באחת מספריות לקוח ה- API, ראה גם את הדרישות הספציפיות לשפה להלן.

PHP

כדי להריץ את דוגמאות קוד ה- PHP במסמך זה, תצטרך:

  • PHP 5.4 ומעלה עם התקנת ממשק שורת הפקודה (CLI) ותוסף JSON.
  • הכלי לניהול תלות במלחין .
  • ספריית הלקוחות של Google APIs עבור PHP:

    php composer.phar require google/apiclient:^2.0

פִּיתוֹן

כדי להריץ את דוגמאות קוד הפייתון במסמך זה, תצטרך:

  • פייתון 2.6 ומעלה
  • הכלי לניהול חבילות pip .
  • ספריית הלקוחות של Google APIs עבור Python:
    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

אוֹדֶם

כדי להריץ את דוגמאות קוד האודם במסמך זה, תצטרך:

  • רובי 2.2.2 ומעלה
  • ספריית הלקוחות של ממשקי ה- API של גוגל עבור רובי:

    gem install google-api-client
  • מסגרת יישומי האינטרנט של סינטרה רובי.

    gem install sinatra

HTTP / REST

אין צורך להתקין ספריות כדי להתקשר ישירות לנקודות הקצה של OAuth 2.0.

השגת אסימוני גישה של OAuth 2.0

השלבים הבאים מראים כיצד האפליקציה שלך מקיימת אינטראקציה עם שרת ה- OAuth 2.0 של גוגל כדי לקבל את הסכמת המשתמש לבצע בקשת API בשמו של המשתמש. על היישום שלך להיות בעל הסכמה זו לפני שהוא יכול לבצע בקשת ממשק API של Google הדורשת הרשאת משתמש.

הרשימה שלהלן מסכמת במהירות את השלבים הבאים:

  1. היישום שלך מזהה את ההרשאות הדרושות לו.
  2. היישום שלך מפנה את המשתמש לגוגל יחד עם רשימת ההרשאות המבוקשות.
  3. המשתמש מחליט אם להעניק את ההרשאות ליישום שלך.
  4. היישום שלך מגלה מה המשתמש החליט.
  5. אם המשתמש העניק את ההרשאות המבוקשות, היישום שלך מאחזר אסימונים הדרושים לביצוע בקשות API בשם המשתמש.

שלב 1: הגדר פרמטרים להרשאה

הצעד הראשון שלך הוא ליצור את בקשת ההרשאה. בקשה זו קובעת פרמטרים המזהים את היישום שלך ומגדירים את ההרשאות שהמשתמש יתבקש להעניק ליישום שלך.

  • אם אתה משתמש בספריית לקוחות של Google לצורך אימות ואישור OAuth 2.0, אתה יוצר ומגדיר אובייקט שמגדיר פרמטרים אלה.
  • אם תתקשר ישירות לנקודת הקצה של Google OAuth 2.0, תיצור כתובת אתר ותגדיר את הפרמטרים בכתובת אתר זו.

הכרטיסיות שלמטה מגדירות את פרמטרי ההרשאה הנתמכים עבור יישומי שרתי אינטרנט. הדוגמאות הספציפיות לשפה מראות גם כיצד להשתמש בספריית לקוח או בספריית הרשאות כדי להגדיר אובייקט שקובע פרמטרים אלה.

PHP

קטע הקוד שלמטה יוצר אובייקט Google_Client() , המגדיר את הפרמטרים בבקשת ההרשאה.

אובייקט זה משתמש במידע מקובץ client_secret.json שלך כדי לזהות את היישום שלך. (ראה יצירת אישורי הרשאה לקבלת מידע נוסף על קובץ זה.) האובייקט מזהה גם את היקפי היישום שלך מבקש הרשאת גישה ואת כתובת ה- URL לנקודת הקצה האמתית של היישום שלך, אשר תטפל בתגובה משרת OAuth 2.0 של גוגל. לבסוף, את הקוד קובע את אופציונלי access_type ו include_granted_scopes פרמטרים.

לדוגמא, קוד זה מבקש גישה לקריאה בלבד ולא מקוונת לכונן Google של המשתמש:

$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 שסופק, תקבל שגיאת redirect_uri_mismatch .

לידיעתך, סכימת ה- http או https , המקרה והקו נטוי (' / ') חייבים להתאים.

כדי להגדיר ערך זה ב- PHP, התקשר לפונקציה setRedirectUri . שים לב שעליך לציין URI הפניה חוקי עבור client_id שסופק.

$client->setRedirectUri('https://oauth2.example.com/code');
scope נדרש

רשימת היקפים המופרדת מהחלל המזהה את המשאבים שאליהם היישום שלך יכול לגשת מטעם המשתמש. ערכים אלה מודיעים על מסך ההסכמה שגוגל מציגה למשתמש.

היקפים מאפשרים ליישום שלך לבקש גישה למשאבים הדרושים לו בלבד, אך גם לאפשר למשתמשים לשלוט בכמות הגישה שהם מעניקים ליישום שלך. לפיכך, קיים קשר הפוך בין מספר ההיקפים המבוקשים לבין הסבירות לקבל הסכמת משתמש.

כדי להגדיר ערך זה ב- PHP, התקשר לפונקציה addScope :

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

אנו ממליצים לבקשתך לבקש גישה להיקפי הרשאות בהקשר במידת האפשר. על ידי בקשת גישה לנתוני משתמשים בהקשר, באמצעות אישור מצטבר , אתה עוזר למשתמשים להבין ביתר קלות מדוע היישום שלך זקוק לגישה שהיא מבקשת.

access_type מוּמלָץ

מציין אם היישום שלך יכול לרענן אסימוני גישה כאשר המשתמש אינו נמצא בדפדפן. ערכי פרמטר תקפים הם online , שזה ערך ברירת המחדל, ולא offline .

הגדר את הערך למצב offline אם היישום שלך צריך לרענן את אסימוני הגישה כאשר המשתמש לא נמצא בדפדפן. זוהי שיטת רענון אסימוני הגישה המתוארת בהמשך מסמך זה. ערך זה מנחה את שרת ההרשאה של Google להחזיר אסימון רענון ו אסימון גישה לראשונה כי חילופי היישום שלך קוד אישור אסימונים.

כדי להגדיר ערך זה ב- PHP, התקשר לפונקציה setAccessType :

$client->setAccessType('offline');
state מוּמלָץ

מציין כל ערך מחרוזת שהיישום שלך משתמש בו כדי לשמור על מצב בין בקשת ההרשאה שלך לתגובת שרת ההרשאה. השרת מחזיר את הערך המדויק שאתה שולח כצמד name=value ברכיב שאילתת ה- URL ( ? ) של redirect_uri לאחר שהמשתמש מסכים או דוחה את בקשת הגישה של היישום שלך.

באפשרותך להשתמש בפרמטר זה למספר מטרות, כגון הפניית המשתמש למשאב הנכון באפליקציה שלך, שליחת אי-התאמות וזיוף בקשות בין אתרים. מכיוון שניתן לנחש את redirect_uri שלך, שימוש בערך state יכול להגביר את הביטחון שלך שחיבור נכנס הוא תוצאה של בקשת אימות. אם אתה מייצר מחרוזת אקראית או מקודד את ה- hash של קובץ cookie או ערך אחר הלוכד את מצב הלקוח, אתה יכול לאמת את התגובה כדי להבטיח בנוסף לכך שהבקשה והתגובה מקורם באותו דפדפן, תוך מתן הגנה מפני התקפות כגון cross-site בקש זיוף. עיין בתיעוד של OpenID Connect לדוגמא כיצד ליצור ולאשר אסימון state .

כדי להגדיר ערך זה ב- PHP, התקשר לפונקציה setState :

$client->setState($sample_passthrough_value);
include_granted_scopes אופציונאלי

מאפשר ליישומים להשתמש באישור מצטבר כדי לבקש גישה להיקפים נוספים בהקשר. אם תגדיר את ערך הפרמטר הזה ל- true ובקשת ההרשאה תינתן, אסימון הגישה החדש יכסה גם את כל היקפים אליהם העניק המשתמש בעבר את הגישה ליישום. עיין בסעיף הרשאות מצטבר לדוגמאות.

כדי להגדיר ערך זה ב- PHP, התקשר לפונקציה setIncludeGrantedScopes :

$client->setIncludeGrantedScopes(true);
login_hint אופציונאלי

אם היישום שלך יודע איזה משתמש מנסה לאמת, הוא יכול להשתמש בפרמטר זה כדי לספק רמז לשרת האימות של Google. השרת משתמש ברמז כדי לפשט את זרימת הכניסה באמצעות מילוי מראש של שדה הדואר האלקטרוני בטופס הכניסה או על ידי בחירת מושב הכניסה המרובה המתאים.

הגדר את ערך הפרמטר לכתובת דוא"ל או מזהה sub , שווה ערך לזהות Google של המשתמש.

כדי להגדיר ערך זה ב- PHP, התקשר לפונקציה setLoginHint :

$client->setLoginHint('None');
prompt אופציונאלי

רשימת הנחיות להצגת המשתמש מוגדרת לחלל, תלויה באותיות רישיות. אם לא תציין פרמטר זה, המשתמש יתבקש רק בפעם הראשונה שהפרויקט שלך מבקש גישה. ראה בקשת הסכמה מחודשת למידע נוסף.

כדי להגדיר ערך זה ב- PHP, התקשר לפונקציה setApprovalPrompt :

$client->setApprovalPrompt('consent');

ערכים אפשריים הם:

none אל תציג שום מסכי אימות או הסכמה. אסור לציין עם ערכים אחרים.
consent בקש מהמשתמש לקבל הסכמה.
select_account בקש מהמשתמש לבחור חשבון.

פִּיתוֹן

קטע הקוד הבא משתמש במודול google-auth-oauthlib.flow לבניית בקשת ההרשאה.

הקוד בונה אובייקט Flow , המזהה את היישום שלך באמצעות מידע מקובץ client_secret.json שהורדת לאחר יצירת אישורי הרשאה . אובייקט זה מזהה גם את היקפי היישום שלך מבקש הרשאת גישה ואת כתובת האתר לנקודת הקצה האמתית של היישום שלך, אשר תטפל בתגובה משרת OAuth 2.0 של גוגל. לבסוף, את הקוד קובע את אופציונלי access_type ו include_granted_scopes פרמטרים.

לדוגמא, קוד זה מבקש גישה לקריאה בלבד ולא מקוונת לכונן Google של המשתמש:

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.

ב- Python, התקשר לשיטת 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 שסופק, תקבל שגיאת redirect_uri_mismatch .

לידיעתך, סכימת ה- http או https , המקרה והקו נטוי (' / ') חייבים להתאים.

כדי להגדיר ערך זה בפייתון, הגדר את המאפיין redirect_uri של אובייקט flow :

flow.redirect_uri = 'https://oauth2.example.com/code'
scope נדרש

רשימה של טווחים המזהים את המשאבים שאליהם היישום שלך יכול לגשת בשם המשתמש. ערכים אלה מודיעים על מסך ההסכמה שגוגל מציגה למשתמש.

היקפים מאפשרים ליישום שלך לבקש גישה למשאבים הדרושים לו בלבד, אך גם לאפשר למשתמשים לשלוט בכמות הגישה שהם מעניקים ליישום שלך. לפיכך, קיים קשר הפוך בין מספר ההיקפים המבוקשים לבין הסבירות לקבל הסכמת משתמש.

ב- Python, השתמש באותה שיטה בה אתה משתמש כדי להגדיר את 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 אם היישום שלך צריך לרענן את אסימוני הגישה כאשר המשתמש לא נמצא בדפדפן. זוהי שיטת רענון אסימוני הגישה המתוארת בהמשך מסמך זה. ערך זה מנחה את שרת ההרשאה של Google להחזיר אסימון רענון ו אסימון גישה לראשונה כי חילופי היישום שלך קוד אישור אסימונים.

ב- Python, הגדר את הפרמטר access_type ידי ציון access_type של מילת מפתח בעת קריאה לשיטת flow.authorization_url :

authorization_url, state = flow.authorization_url(
    access_type='offline',
    include_granted_scopes='true')
state מוּמלָץ

מציין כל ערך מחרוזת שהיישום שלך משתמש בו כדי לשמור על מצב בין בקשת ההרשאה שלך לתגובת שרת ההרשאה. השרת מחזיר את הערך המדויק שאתה שולח כצמד name=value ברכיב שאילתת ה- URL ( ? ) של redirect_uri לאחר שהמשתמש מסכים או דוחה את בקשת הגישה של היישום שלך.

באפשרותך להשתמש בפרמטר זה למספר מטרות, כגון הפניית המשתמש למשאב הנכון באפליקציה שלך, שליחת אי-התאמות וזיוף בקשות בין אתרים. מכיוון שניתן לנחש את redirect_uri שלך, שימוש בערך state יכול להגביר את הביטחון שלך שחיבור נכנס הוא תוצאה של בקשת אימות. אם אתה מייצר מחרוזת אקראית או מקודד את ה- hash של קובץ cookie או ערך אחר הלוכד את מצב הלקוח, אתה יכול לאמת את התגובה כדי להבטיח בנוסף לכך שהבקשה והתגובה מקורם באותו דפדפן, תוך מתן הגנה מפני התקפות כגון cross-site בקש זיוף. עיין בתיעוד של OpenID Connect לדוגמא כיצד ליצור ולאשר אסימון state .

ב- Python, הגדר את פרמטר 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 ובקשת ההרשאה תינתן, אסימון הגישה החדש יכסה גם את כל היקפים אליהם העניק המשתמש בעבר את הגישה ליישום. עיין בסעיף הרשאות מצטבר לדוגמאות.

ב- Python, הגדר את הפרמטר 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 של המשתמש.

ב- Python, הגדר את הפרמטר login_hint ידי ציון login_hint של מילת מפתח בעת קריאה לשיטת flow.authorization_url :

authorization_url, state = flow.authorization_url(
    access_type='offline',
    login_hint='None',
    include_granted_scopes='true')
prompt אופציונאלי

רשימת הנחיות להצגת המשתמש המופרדת מהחלל. אם לא תציין פרמטר זה, המשתמש יתבקש רק בפעם הראשונה שהפרויקט שלך מבקש גישה. ראה בקשת הסכמה מחודשת למידע נוסף.

ב- Python, הגדר את פרמטר 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 שיצרת כדי להגדיר אובייקט לקוח ביישום שלך. כאשר אתה מגדיר אובייקט לקוח, אתה מציין את ההיקפים שאליהם היישום צריך לגשת, יחד עם כתובת ה- URL לנקודת הקצה האמתית של היישום שלך, שתטפל בתגובה משרת OAuth 2.0.

לדוגמא, קוד זה מבקש גישה לקריאה בלבד ולא מקוונת לכונן Google של המשתמש:

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, כגון יצירת כתובות אתרים לבקשת הרשאה והחלת אסימוני גישה לבקשות 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 שסופק, תקבל שגיאת redirect_uri_mismatch .

לידיעתך, סכימת ה- http או https , המקרה והקו נטוי (' / ') חייבים להתאים.

response_type נדרש

קובע אם נקודת הקצה של Google OAuth 2.0 מחזירה קוד הרשאה.

הגדר את ערך הפרמטר code עבור יישומי שרת אינטרנט.

scope נדרש

רשימת היקפים המופרדת מהחלל המזהה את המשאבים שאליהם היישום שלך יכול לגשת מטעם המשתמש. ערכים אלה מודיעים על מסך ההסכמה שגוגל מציגה למשתמש.

היקפים מאפשרים ליישום שלך לבקש גישה למשאבים הדרושים לו בלבד, אך גם לאפשר למשתמשים לשלוט בכמות הגישה שהם מעניקים ליישום שלך. לפיכך, קיים קשר הפוך בין מספר ההיקפים המבוקשים לבין הסבירות לקבל הסכמת משתמש.

אנו ממליצים לבקשתך לבקש גישה להיקפי הרשאות בהקשר במידת האפשר. על ידי בקשת גישה לנתוני משתמשים בהקשר, באמצעות אישור מצטבר , אתה עוזר למשתמשים להבין ביתר קלות מדוע היישום שלך זקוק לגישה שהיא מבקשת.

access_type מוּמלָץ

מציין אם היישום שלך יכול לרענן אסימוני גישה כאשר המשתמש אינו נמצא בדפדפן. ערכי פרמטר תקפים הם online , שזה ערך ברירת המחדל, ולא offline .

הגדר את הערך למצב offline אם היישום שלך צריך לרענן את אסימוני הגישה כאשר המשתמש לא נמצא בדפדפן. זוהי שיטת רענון אסימוני הגישה המתוארת בהמשך מסמך זה. ערך זה מנחה את שרת ההרשאה של Google להחזיר אסימון רענון ו אסימון גישה לראשונה כי חילופי היישום שלך קוד אישור אסימונים.

state מוּמלָץ

מציין כל ערך מחרוזת שהיישום שלך משתמש בו כדי לשמור על מצב בין בקשת ההרשאה שלך לתגובת שרת ההרשאה. השרת מחזיר את הערך המדויק שאתה שולח כצמד name=value ברכיב שאילתת ה- URL ( ? ) של redirect_uri לאחר שהמשתמש מסכים או דוחה את בקשת הגישה של היישום שלך.

באפשרותך להשתמש בפרמטר זה למספר מטרות, כגון הפניית המשתמש למשאב הנכון באפליקציה שלך, שליחת אי-התאמות וזיוף בקשות בין אתרים. מכיוון שניתן לנחש את redirect_uri שלך, שימוש בערך state יכול להגביר את הביטחון שלך שחיבור נכנס הוא תוצאה של בקשת אימות. אם אתה מייצר מחרוזת אקראית או מקודד את ה- hash של קובץ cookie או ערך אחר הלוכד את מצב הלקוח, אתה יכול לאמת את התגובה כדי להבטיח בנוסף לכך שהבקשה והתגובה מקורם באותו דפדפן, תוך מתן הגנה מפני התקפות כגון cross-site בקש זיוף. עיין בתיעוד של OpenID Connect לדוגמא כיצד ליצור ולאשר אסימון state .

include_granted_scopes אופציונאלי

מאפשר ליישומים להשתמש באישור מצטבר כדי לבקש גישה להיקפים נוספים בהקשר. אם תגדיר את ערך הפרמטר הזה ל- true ובקשת ההרשאה תינתן, אסימון הגישה החדש יכסה גם את כל היקפים אליהם העניק המשתמש בעבר את הגישה ליישום. עיין בסעיף הרשאות מצטבר לדוגמאות.

login_hint אופציונאלי

אם היישום שלך יודע איזה משתמש מנסה לאמת, הוא יכול להשתמש בפרמטר זה כדי לספק רמז לשרת האימות של Google. השרת משתמש ברמז כדי לפשט את זרימת הכניסה באמצעות מילוי מראש של שדה הדואר האלקטרוני בטופס הכניסה או על ידי בחירת מושב הכניסה המרובה המתאים.

הגדר את ערך הפרמטר לכתובת דוא"ל או מזהה sub , שווה ערך לזהות Google של המשתמש.

prompt אופציונאלי

רשימת הנחיות להצגת המשתמש המופרדת מהחלל. אם לא תציין פרמטר זה, המשתמש יתבקש רק בפעם הראשונה שהפרויקט שלך מבקש גישה. ראה בקשת הסכמה מחודשת למידע נוסף.

ערכים אפשריים הם:

none אל תציג שום מסכי אימות או הסכמה. אסור לציין עם ערכים אחרים.
consent בקש מהמשתמש לקבל הסכמה.
select_account בקש מהמשתמש לבחור חשבון.

שלב 2: הפנה מחדש לשרת OAuth 2.0 של גוגל

הפנה את המשתמש לשרת OAuth 2.0 של גוגל בכדי להתחיל את תהליך האימות וההרשאה. בדרך כלל זה קורה כאשר היישום שלך צריך לגשת לראשונה לנתוני המשתמש. במקרה של אישור מצטבר , שלב זה מתרחש גם כאשר היישום שלך צריך לגשת לראשונה למשאבים נוספים שאין לה עדיין הרשאת גישה.

PHP

  1. צור כתובת URL לבקשת גישה משרת OAuth 2.0 של גוגל:
    $auth_url = $client->createAuthUrl();
  2. הפנה את המשתמש ל- $auth_url :
    header('Location: ' . filter_var($auth_url, FILTER_SANITIZE_URL));

פִּיתוֹן

דוגמה זו מראה כיצד להפנות את המשתמש לכתובת אתר ההרשאה באמצעות מסגרת יישום האינטרנט Flask:

return flask.redirect(authorization_url)

אוֹדֶם

  1. צור כתובת URL לבקשת גישה משרת OAuth 2.0 של גוגל:
    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 של גוגל מאמת את המשתמש ומקבל הסכמה מהמשתמש ליישום שלך לגשת להיקפים המבוקשים. התגובה נשלחת חזרה ליישום שלך באמצעות כתובת האתר להפניה מחדש שציינת.

שלב 3: גוגל מבקשת מהמשתמש לקבל הסכמה

בשלב זה המשתמש מחליט אם להעניק ליישום שלך את הגישה המבוקשת. בשלב זה, גוגל מציגה חלון הסכמה המציג את שם היישום שלך ואת שירותי ה- API של גוגל שהוא מבקש הרשאה לגשת אליו באמצעות אישורי ההרשאה של המשתמש וסיכום של היקפי הגישה להענקת. לאחר מכן המשתמש יכול להסכים להעניק גישה להיקף אחד או יותר שהבקשה שלך מבקש או לסרב לבקשה.

היישום שלך לא צריך לעשות שום דבר בשלב זה מכיוון שהוא ממתין לתגובה משרת OAuth 2.0 של גוגל המציין אם ניתנה גישה כלשהי. תגובה זו מוסברת בשלב הבא.

טעויות

בקשות לנקודת סיום ההרשאה של Google OAuth 2.0 עשויות להציג הודעות שגיאה הפונות למשתמש במקום זרימת האימות וההרשאה הצפויות. קודי שגיאה נפוצים והפתרונות מוצעים מפורטים להלן.

admin_policy_enforced

חשבון Google אינו יכול לאשר היקף אחד או יותר המבוקש עקב המדיניות של מנהל סביבת העבודה שלהם ב- Google. עיין במאמר העזרה למנהל מערכת של Google Workspace קבע אילו אפליקציות צד ג 'ופנימיות ניגשות לנתוני Google Workspace למידע נוסף על האופן שבו מנהל רשאי להגביל את הגישה לכל ההיקפים או להיקפים רגישים ומוגבלים עד שתוענק גישה מפורשת לזהות הלקוח שלך ב- OAuth.

disallowed_useragent

נקודת הקצה של ההרשאה מוצגת בתוך סוכן משתמש משובץ שאינו מורשה על פי מדיניות OAuth 2.0 של גוגל.

דְמוּי אָדָם

מפתחי אנדרואיד עשויים להיתקל בהודעת שגיאה זו בעת פתיחת בקשות הרשאה ב- android.webkit.WebView . במקום זאת על מפתחים להשתמש בספריות אנדרואיד כגון כניסה של Google ל- Android או AppAuth של OpenID Foundation עבור Android .

מפתחי אתרים עשויים להיתקל בשגיאה זו כאשר אפליקציית Android פותחת קישור אינטרנט כללי בסוכן משתמש מוטבע ומשתמש מנווט לנקודת הקצה של הרשאת OAuth 2.0 מאתרך. על מפתחים לאפשר קישורים כלליים להיפתח אצל מטפל הקישורים המוגדר כברירת מחדל של מערכת ההפעלה, הכולל גם מטפלים ב-Android App Links וגם את אפליקציית הדפדפן המוגדרת כברירת מחדל. ספריית הכרטיסיות המותאמות אישית של Android היא גם אפשרות נתמכת.

iOS

מפתחי iOS ו- macOS עלולים להיתקל בשגיאה זו בעת פתיחת בקשות הרשאה ב- WKWebView . במקום זאת על מפתחים להשתמש בספריות iOS כמו כניסה של Google עבור iOS או AppAuth של OpenID Foundation עבור iOS .

מפתחי אתרים עשויים להיתקל בשגיאה זו כאשר אפליקציית iOS או MacOS פותחת קישור אינטרנט כללי בסוכן משתמש משובץ ומשתמש מנווט לנקודת הקצה של הרשאת OAuth 2.0 מאתרך. על מפתחים לאפשר קישורים כלליים להיפתח אצל מטפל הקישורים המוגדר כברירת מחדל במערכת ההפעלה, הכולל גם מטפלים שלUniversal Links וגם את אפליקציית הדפדפן המוגדרת כברירת מחדל. ספריית SFSafariViewController היא גם אפשרות נתמכת.

org_internal

מזהה הלקוח של OAuth בבקשה הוא חלק מפרויקט המגביל את הגישה לחשבונות Google בארגון ענן ספציפי של Google . לקבלת מידע נוסף אודות אפשרות תצורה זו עיין בסעיף סוג משתמש במאמר העזרה למסך הסכמת OAuth שלך.

redirect_uri_mismatch

ה- redirect_uri שהועבר בבקשת ההרשאה אינו תואם ל- URI להפניה מורשה עבור מזהה הלקוח של OAuth. עיין ב- URIs להפניה מחדש מורשית ב- 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

אתה יכול לבדוק זרימה זו על ידי לחיצה על כתובת הדוגמה הבאה, המבקשת גישה לקריאה בלבד כדי להציג מטא נתונים עבור קבצים בכונן Google שלך:

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.