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. לוחצים על Create credentials > OAuth client ID.
  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 הזו ממסמך Discovery באמצעות ערך המטא-נתונים 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" \
         https://oauth2.googleapis.com/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 (Forbidden) 403. התשובה כוללת את השגיאה הבאה:

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

ההרשאה בהמתנה

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

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

סקרים בתדירות גבוהה מדי

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

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

שגיאות אחרות

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

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

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

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

invalid_grant 400 ערך הפרמטר code לא חוקי, נתבעה עליו בעלות או שאי אפשר לנתח אותו.
unsupported_grant_type 400 ערך הפרמטר grant_type לא חוקי.
org_internal 403 מזהה הלקוח ב-OAuth שצוין בבקשה הוא חלק מפרויקט שמגביל את הגישה לחשבונות Google ב ארגון Google Cloud ספציפי. מאשרים את ההגדרה של סוג המשתמש באפליקציית ה-OAuth.

קריאה ל-Google APIs

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

אתם יכולים לנסות את כל ממשקי Google API ולראות את ההיקף שלהם במגרש המשחקים של 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 קשורה. אם ביקשת גישה אופליין להיקפי ההרשאות המשויכים לאסימון, אפשר לרענן את אסימון הגישה בלי לבקש מהמשתמש הרשאה (גם כשהמשתמש לא נוכח).

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

שדות
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. במצבי שגיאה, מוחזר קוד המצב 400 של HTTP יחד עם קוד שגיאה.

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

תהליך 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

ממשק API של YouTube

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