OAuth 2.0 לאפליקציות טלוויזיה ולקלט קלט מוגבל

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

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

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

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

חלופות

אם כותבים אפליקציה לפלטפורמה כמו Android , iOS , macOS , Linux או Windows (כולל Universal Windows Platform) שיש לה גישה לדפדפן וליכולות קלט מלאות, צריך להשתמש בתהליך OAuth 2.0 לאפליקציות לנייד ולמחשבים. (יש להשתמש בתהליך הזה גם אם האפליקציה היא כלי בשורת הפקודה בלי ממשק גרפי).

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

דרישות מוקדמות

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

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

  1. Go to the Credentials page.
  2. לוחצים על יצירת פרטי כניסה > מזהה לקוח ב-OAuth.
  3. בוחרים בסוג האפליקציה טלוויזיות ומכשירי קלט מוגבלים.
  4. נותנים שם ללקוח OAuth 2.0 ולוחצים על יצירה.

זיהוי היקפי גישה

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

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

ברשימה היקפים מותרים של אפליקציות או מכשירים מותקנים.

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

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

  1. האפליקציה שלך שולחת בקשה לשרת ההרשאות של Google המאפשר זיהוי של היקפי ההרשאות שהאפליקציה שלך תבקש לגשת אליהם.
  2. השרת מגיב עם מספר קטעי מידע המשמשים בשלבים הבאים, כמו קוד מכשיר וקוד משתמש.
  3. אפשר להציג מידע שהמשתמש יכול להזין במכשיר נפרד כדי לאשר את האפליקציה שלך.
  4. האפליקציה שלך מתחילה לבדוק שרת ההרשאות של Google כדי לקבוע אם המשתמש אישר את האפליקציה שלך.
  5. המשתמש עובר למכשיר עם יכולות קלט עשירות יותר, מפעיל דפדפן אינטרנט, מנווט לכתובת ה-URL המוצגת בשלב 3 ומזין קוד שמוצג גם בשלב 3. המשתמש יוכל להעניק (או לדחות) את הגישה לאפליקציה שלך.
  6. התגובה הבאה לבקשת הסקר שלך כוללת את האסימונים שהאפליקציה שלך צריכה להעניק להם הרשאה בשם המשתמש. (אם המשתמש דחה את הגישה לאפליקציה שלך, התגובה לא מכילה אסימונים).

התמונה שלמטה ממחישה את התהליך:

המשתמש מתחבר לחשבון במכשיר אחר שיש בו דפדפן

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

שלב 1: מבקשים קודי מכשירים ומשתמשים

בשלב זה, המכשיר שולח בקשת HTTP POST לשרת ההרשאות של Google, בכתובת https://oauth2.googleapis.com/device/code, שמזהה את האפליקציה שלך, וכן את היקפי הגישה שהאפליקציה שלך מבקשת לגשת אליהם בשם המשתמש. יש לאחזר את כתובת ה-URL הזו ממסמך הגילוי באמצעות ערך המטא-נתונים של device_authorization_endpoint. יש לכלול את הפרמטרים הבאים של בקשות HTTP:

פרמטרים
client_id נדרש

מזהה הלקוח של האפליקציה. ניתן למצוא את הערך הזה ב- API Console Credentials page.

scope נדרש

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

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

דוגמאות

בקטע הבא מוצגת בקשה לדוגמה:

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

client_id=client_id&scope=email%20profile

בדוגמה הבאה מוצגת פקודה אחת (curl) לשליחת אותה בקשה:

curl -d "client_id=client_id&scope=email%20profile" \
     https://oauth2.googleapis.com/device/code

שלב 2: טיפול בתגובת שרת ההרשאות

שרת ההרשאות יחזיר אחת מהתגובות הבאות:

תשובה מוצלחת

אם הבקשה תקפה, התשובה שלך תהיה אובייקט JSON שמכיל את המאפיינים הבאים:

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

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

expires_in משך הזמן (בשניות) שהפעולות device_code ו-user_code יהיו חוקיות. אם בפרק הזמן הזה המשתמש לא ישלים את תהליך ההרשאה והמכשיר גם לא יבצע סקר כדי לאחזר מידע על החלטת המשתמש, ייתכן שיהיה צורך להתחיל מחדש בתהליך הזה משלב 1.
interval משך הזמן (בשניות) שבו המכשיר יחכה בין בקשות הסקרים. לדוגמה, אם הערך הוא 5, המכשיר צריך לשלוח בקשת סקר לשרת ההרשאות של Google בכל חמש שניות. פרטים נוספים זמינים בשלב 3.
user_code ערך תלוי אותיות רישיות שמזהה ל-Google את ההיקפים שאליהם האפליקציה מבקשת גישה. ממשק המשתמש מורה למשתמש להזין את הערך הזה במכשיר נפרד עם יכולות קלט עשירות יותר. לאחר מכן Google משתמשת בערך כדי להציג את הקבוצה הנכונה של היקפי ההרשאות כשהיא מבקשת מהמשתמש להעניק גישה לאפליקציה שלך.
verification_url כתובת URL שהמשתמש צריך לעבור אליה, במכשיר אחר, כדי להזין את user_code ולתת לו גישה לאפליקציה שלך או לדחות אותה. גם ממשק המשתמש יציג את הערך הזה.

בקטע הבא מוצגת דוגמה לתגובה:

{
  "device_code": "4/4-GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8",
  "user_code": "GQVQ-JKEC",
  "verification_url": "https://www.google.com/device",
  "expires_in": 1800,
  "interval": 5
}

חריגה מהמכסה

אם הבקשות לקוד המכשיר חרגו מהמכסה המשויכת למספר הלקוח שלך, תישלח אליך תגובה 403, שתכלול את השגיאה הבאה:

{
  "error_code": "rate_limit_exceeded"
}

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

שלב 3: מציגים את קוד המשתמש

הצגה של verification_url ושל user_code שהתקבלו בשלב 2 למשתמש. שני הערכים יכולים להכיל כל תו להדפסה ממערך התווים US-ASCII. התוכן שמוצג למשתמש צריך להפנות את המשתמש אל verification_url במכשיר אחר ולהזין את user_code.

מעצבים את ממשק המשתמש (UI) לפי הכללים הבאים:

  • user_code
    • השדה user_code צריך להופיע בשדה שיכול להכיל עד 15 'W' מידה. כלומר, אם אפשר להציג את הקוד WWWWWWWWWWWWWWW בצורה נכונה, ממשק המשתמש שלך תקין ואנחנו ממליצים להשתמש בערך המחרוזת הזה כשבודקים את האופן שבו user_code מוצג בממשק המשתמש.
    • השדה user_code הוא תלוי אותיות רישיות ואין לשנות אותו בשום צורה, כמו שינוי הפנייה או הוספת תווי עיצוב אחרים.
  • verification_url
    • השטח שבו מוצגים ה-verification_url חייב להיות רחב מספיק כדי לטפל במחרוזת של כתובות URL שאורכה 40 תווים.
    • אין לשנות את verification_url בשום צורה, מלבד להסיר את הסכמה לתצוגה. אם תכננת להסיר את הסכמה (למשל https://) מכתובת ה-URL מסיבות הקשורות לתצוגה, עליך לוודא שהאפליקציה מסוגלת לטפל גם בוריאנטים של http וגם ב-https.

שלב 4: סקר שרת ההרשאות של Google

מאחר שהמשתמש ישתמש במכשיר נפרד כדי לנווט אל verification_url ולהעניק לו גישה (או לדחות אותה), הוא לא יקבל התראה אוטומטית כשהמשתמש יגיב לבקשת הגישה. לכן, המכשיר המבקש צריך לסקור את שרת ההרשאות של Google כדי לקבוע מתי המשתמש השיב לבקשה.

המכשיר המבקש צריך להמשיך לשלוח בקשות לקלפי עד לקבלת תגובה המציינת שהמשתמש השיב לבקשת הגישה או עד שיפוג התוקף של device_code ושל user_code שהתקבלו ב שלב 2. הinterval שמוחזר בשלב 2 מציין את משך הזמן (בשניות) להמתנה בין בקשות.

כתובת ה-URL של נקודת הקצה לסקר היא https://oauth2.googleapis.com/token. בקשת הסקר כוללת את הפרמטרים הבאים:

פרמטרים
client_id מזהה הלקוח של האפליקציה. ניתן למצוא את הערך הזה ב- API Console Credentials page.
client_secret סוד הלקוח עבור ה-client_id שסופק. ניתן למצוא את הערך הזה ב- API Console Credentials page.
device_code ה-device_code הוחזר על ידי שרת ההרשאות בשלב 2.
grant_type יש להגדיר את הערך הזה כ-urn:ietf:params:oauth:grant-type:device_code.

דוגמאות

בקטע הבא מוצגת בקשה לדוגמה:

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

client_id=client_id&
client_secret=client_secret&
device_code=device_code&
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code

בדוגמה הבאה מוצגת פקודה אחת (curl) לשליחת אותה בקשה:

curl -d "client_id=client_id&client_secret=client_secret& \
         device_code=device_code& \
         grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code" \
         -H "Content-Type: application/x-www-form-urlencoded" \
         /token

שלב 5: המשתמש מגיב לבקשת הגישה

התמונה הבאה מציגה דף הדומה למה שהמשתמשים רואים כשהם מנווטים אל verification_url המוצג בשלב 3:

חיבור מכשיר על ידי הזנת קוד

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

דוגמה למסך הסכמה ללקוח במכשיר

שלב 6: טיפול בתגובות לסקר

שרת ההרשאות של Google מגיב לכל בקשת סקר באחת מהתשובות הבאות:

הגישה הותרה

אם המשתמש קיבל גישה למכשיר (בלחיצה על Allow במסך ההסכמה), התגובה מכילה אסימון גישה ואסימון רענון. האסימונים מאפשרים למכשיר שלך לגשת ל-Google APIs בשם המשתמש. (הנכס scope בתגובה קובע אילו ממשקי API יכולים לגשת למכשיר.)

במקרה כזה, תגובת ה-API מכילה את השדות הבאים:

שדות
access_token האסימון שהאפליקציה שלך שולחת כדי לאשר בקשת Google API.
expires_in משך החיים הנותרים של אסימון הגישה בשניות.
refresh_token אסימון שניתן להשתמש בו כדי לקבל אסימון גישה חדש. אסימוני הרענון יהיו בתוקף עד שהמשתמש יבטל את הגישה. הערה: אסימוני רענון תמיד מוחזרים למכשירים.
scope היקפי הגישה שהוענקו על ידי access_token מבוטאים כרשימה של מחרוזות תלויות-רווחים.
token_type סוג האסימון הוחזר. נכון לעכשיו, הערך של השדה הזה תמיד מוגדר Bearer.

בקטע הבא מוצגת דוגמה לתגובה:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "openid https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email",
  "token_type": "Bearer",
  "refresh_token": "1/xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

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

הגישה נדחתה

אם המשתמש מסרב להעניק גישה למכשיר, לתגובת השרת יש קוד סטטוס תגובת HTTP של 403 (Forbidden). התגובה מכילה את השגיאה הבאה:

{
  "error": "access_denied",
  "error_description": "Forbidden"
}

בהמתנה לאישור

אם המשתמש עדיין לא השלים את תהליך ההרשאה, השרת יחזיר 428 קוד סטטוס תגובת HTTP (Precondition Required). התגובה מכילה את השגיאה הבאה:

{
  "error": "authorization_pending",
  "error_description": "Precondition Required"
}

ניהול סקרים לעיתים קרובות מדי

אם המכשיר שולח בקשות סקרים לעיתים קרובות מדי, השרת יחזיר 403 קוד סטטוס של תגובת HTTP (Forbidden). התגובה מכילה את השגיאה הבאה:

{
  "error": "slow_down",
  "error_description": "Forbidden"
}

שגיאות אחרות

שרת ההרשאות מחזיר גם שגיאות אם בבקשת הסקר חסרים פרמטרים נדרשים או שיש בו ערך פרמטר שגוי. לבקשות האלה יש בדרך כלל קוד סטטוס תגובת 400 (Bad Request) או 401 (Unauthorized). השגיאות האלה כוללות:

שגיאה קוד סטטוס HTTP תיאור
invalid_client 401 לקוח OAuth לא נמצא. לדוגמה, השגיאה הזו מתרחשת אם ערך הפרמטר client_id לא חוקי.
invalid_grant 400 ערך הפרמטר code אינו חוקי.
unsupported_grant_type 400 ערך הפרמטר grant_type אינו חוקי.

קריאה ל-Google APIs

אחרי שהאפליקציה תקבל אסימון גישה, תהיה לך אפשרות להשתמש באסימון כדי לבצע קריאות ל-API של Google בשם חשבון משתמש נתון, אם היקפי הגישה הנדרשים ל-API אושרו. כדי לעשות זאת, צריך לכלול את אסימון הגישה בבקשה ל-API, על ידי הוספת פרמטר של שאילתה מסוג access_token או ערך Bearer של כותרת HTTP מסוג Authorization. כשהדבר אפשרי, מומלץ להשתמש בכותרת HTTP כי מחרוזות שאילתה בדרך כלל גלויות ביומני השרת. ברוב המקרים, אפשר להשתמש בספריית לקוח כדי להגדיר את הקריאות שלך ל-Google APIs (לדוגמה, בעת קריאה ל-Drive Files API).

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

דוגמאות ל-HTTP GET

קריאה לנקודת הקצה drive.files (ב-Drive Files API) באמצעות כותרת ה-HTTP Authorization: Bearer עשויה להיראות כך. לתשומת ליבכם, עליכם לציין אסימון גישה משלכם:

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

זו קריאה ל-API זהה למשתמש המאומת באמצעות פרמטר access_token של מחרוזת השאילתה:

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

curl דוגמאות

אפשר לבדוק את הפקודות האלה בעזרת שורת הפקודה curl. הנה דוגמה שמשתמשת באפשרות כותרת HTTP (מועדפת):

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

לחלופין, אפשרות הפרמטר של מחרוזת השאילתה:

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

רענון אסימון גישה

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

כדי לרענן אסימון גישה, האפליקציה שלך שולחת בקשת HTTPS של POST לשרת ההרשאות של Google (https://oauth2.googleapis.com/token) שכולל את הפרמטרים הבאים:

שדות
client_id מספר הלקוח שהתקבל מה- API Console.
client_secret סוד הלקוח שהתקבל מה- API Console.
grant_type כפי שמוגדר במפרט OAuth 2.0, יש להגדיר את הערך של השדה הזה כ-refresh_token.
refresh_token אסימון הרענון הוחזר מהמרת קוד ההרשאות.

בקטע הבא מוצגת בקשה לדוגמה:

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

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

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

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

ביטול אסימון

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

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

כדי לבטל אסימון באופן פרוגרמטי, האפליקציה שולחת בקשה https://oauth2.googleapis.com/revoke וכוללת את האסימון כפרמטר:

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

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

אם הביטול יסתיים בהצלחה, קוד סטטוס ה-HTTP של התגובה הוא 200. במקרה של שגיאות, מוחזר קוד סטטוס HTTP 400 יחד עם קוד שגיאה.

היקפי הרשאות מותרים

תהליך OAuth 2.0 למכשירים נתמך רק בהיקף הזה:

OpenID Connect, כניסה באמצעות חשבון Google

  • email
  • openid
  • profile

Drive API

  • https://www.googleapis.com/auth/drive.appdata
  • https://www.googleapis.com/auth/drive.file

YouTube API

  • https://www.googleapis.com/auth/youtube
  • https://www.googleapis.com/auth/youtube.readonly