במסמך הזה מוסבר איך להטמיע הרשאת OAuth 2.0 כדי לגשת ל-Google APIs דרך אפליקציות שפועלות במכשירים כמו טלוויזיות, קונסולות משחקים ומדפסות. באופן ספציפי, התהליך הזה מיועד למכשירים שאין להם גישה לדפדפן או שיש להם יכולות קלט מוגבלות.
פרוטוקול OAuth 2.0 מאפשר למשתמשים לשתף נתונים ספציפיים עם אפליקציה תוך שמירה על הפרטיות של שמות המשתמשים, הסיסמאות ומידע אחר. לדוגמה, אפליקציית טלוויזיה יכולה להשתמש ב-OAuth 2.0 כדי לקבל הרשאה לבחירת קובץ המאוחסן ב-Google Drive.
מאחר שהאפליקציות שמשתמשות בתהליך הזה מופצות לכל מכשיר בנפרד, ההנחה היא שהן לא יכולות לשמור סודות. יש להם גישה ל-Google APIs בזמן שהמשתמש נמצא באפליקציה או בזמן שהאפליקציה פועלת ברקע.
חלופות
אם כותבים אפליקציה לפלטפורמה כמו Android, iOS, macOS, Linux או Windows (כולל פלטפורמת Universal Windows), שיש לה גישה לדפדפן ויכולות קלט מלאות, צריך להשתמש בתהליך OAuth 2.0 לאפליקציות לנייד ולמחשב. (עליך להשתמש בתהליך הזה גם אם האפליקציה היא כלי שורת פקודה ללא ממשק גרפי).
אם ברצונך רק להיכנס למשתמשים עם חשבונות Google שלהם ולהשתמש באסימון מזהה של JWT כדי לקבל מידע בסיסי על פרופיל המשתמש, כדאי לעיין במאמר כניסה בטלוויזיות ובמכשירי קלט מוגבלים.
דרישות מוקדמות
הפעלת ממשקי API בפרויקט
כל אפליקציה שקוראת ל-Google APIs צריכה להפעיל את ממשקי ה-API האלה ב- API Console.
כדי להפעיל API בפרויקט:
- Open the API Library ב Google API Console.
- If prompted, select a project, or create a new one.
- בטבלה API Library מפורטים כל ממשקי ה-API הזמינים, בקיבוץ לפי משפחת מוצרים ופופולריות. אם ממשק ה-API שרוצים להפעיל לא מופיע ברשימה, משתמשים בחיפוש כדי למצוא אותו או לוחצים על הצגת הכול במשפחת המוצרים שאליה הוא שייך.
- בוחרים את ממשק ה-API שרוצים להפעיל ולוחצים על הלחצן Enable (הפעלה).
- If prompted, enable billing.
- If prompted, read and accept the API's Terms of Service.
יצירת פרטי כניסה להרשאה
לכל אפליקציה שמשתמשת ב-OAuth 2.0 כדי לגשת אל Google APIs, צריכות להיות פרטי כניסה להרשאה שמזהים את האפליקציה לשרת OAuth 2.0 של Google. בשלבים הבאים נסביר איך ליצור פרטי כניסה לפרויקט. לאחר מכן האפליקציות שלך יוכלו להשתמש בפרטי הכניסה כדי לגשת לממשקי API שהפעלת בפרויקט הזה.
- Go to the Credentials page.
- לוחצים על יצירת פרטי כניסה > מזהה לקוח OAuth.
- בוחרים בסוג האפליקציה טלוויזיות ומכשירי קלט מוגבלים.
- נותנים שם ללקוח OAuth 2.0 ולוחצים על יצירה.
זיהוי היקפי גישה
היקפי הרשאות מאפשרים לאפליקציה לבקש גישה רק למשאבים שנחוצים לה, וגם מאפשרים למשתמשים לשלוט בכמות הגישה שהם מעניקים לאפליקציה. לכן יכול להיות קשר הפוך בין מספר ההיקפים המבוקשים לבין הסבירות לקבלת הסכמת המשתמש.
לפני שמתחילים להטמיע הרשאת OAuth 2.0, מומלץ לזהות את ההיקפים שאליהם האפליקציה תצטרך הרשאה כדי לגשת.
ברשימת היקפי ההרשאות המותרים מוסבר איך משתמשים באפליקציות או במכשירים מותקנים.
קבלת אסימוני גישה מסוג OAuth 2.0
האפליקציה שלך פועלת במכשיר עם יכולות קלט מוגבלות, אבל למשתמשים חייבת להיות גישה נפרדת למכשיר עם יכולות קלט עשירות יותר כדי להשלים את תהליך ההרשאה הזה. התהליך כולל את השלבים הבאים:
- האפליקציה שולחת לשרת ההרשאות של Google בקשה שמזהה את ההיקפים שאליהם האפליקציה מבקשת הרשאה.
- בתגובה, השרת מספק כמה פרטים שמשמשים בשלבים הבאים, כמו קוד המכשיר וקוד המשתמש.
- מוצג מידע שהמשתמש יכול להזין במכשיר נפרד כדי לתת הרשאה לאפליקציה.
- האפליקציה מתחילה לבדוק את שרת ההרשאות של Google כדי לקבוע אם המשתמש אישר את האפליקציה.
- המשתמש עובר למכשיר שיש בו יכולות קלט מגוונות יותר, מפעיל דפדפן אינטרנט, עובר לכתובת ה-URL שמוצגת בשלב 3 ומזין קוד שמוצג גם בשלב 3. לאחר מכן המשתמש יוכל להעניק (או לדחות) גישה לאפליקציה שלכם.
- התשובה הבאה לבקשת הסקר תכלול את האסימונים שהאפליקציה צריכה כדי לאשר בקשות בשם המשתמש. (אם המשתמש סירב לגשת לאפליקציה, התשובה לא תכיל אסימונים).
התמונה הבאה ממחישה את התהליך:
בחלקים הבאים נרחיב על השלבים האלה. בהתאם למגוון היכולות וסביבות זמן הריצה שעשויות להיות במכשירים, בדוגמאות שמוצגות במסמך הזה נעשה שימוש בכלי שורת הפקודה curl. צריך לתת את הדוגמאות האלה בקלות, בכל מיני שפות ושעות פעילות שונות.
שלב 1: מבקשים קודים של המכשיר והמשתמשים
בשלב הזה, המכשיר שולח בקשת HTTP POST לשרת ההרשאות של Google, בכתובת https://oauth2.googleapis.com/device/code, שמזהה את האפליקציה וגם את היקפי הגישה שהאפליקציה רוצה לגשת אליהם בשם המשתמש.
צריך לאחזר את כתובת ה-URL הזו
ממסמך Discovery באמצעות
ערך המטא-נתונים device_authorization_endpoint. כוללים את הפרמטרים הבאים של בקשת HTTP:
| פרמטרים | |
|---|---|
client_id |
חובה
מזהה הלקוח באפליקציה שלכם. הערך הזה מופיע ב Credentials page API Console. |
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 |
מזהה הלקוח באפליקציה שלכם. הערך הזה מופיע ב Credentials page API Console. |
client_secret |
סוד הלקוח עבור ה-client_id שצוין. הערך הזה מופיע ב Credentials page
API Console. |
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, ואם עדיין לא בוצעה התחברות, המשתמש יראה מסך הסכמה כמו זה שמוצג כאן:
שלב 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"
}
בהמתנה להרשאה
אם המשתמש עדיין לא השלים את תהליך ההרשאה, השרת יחזיר קוד סטטוס של תגובת HTTP 428 (Precondition Required). התגובה מכילה את השגיאה הבאה:
{
"error": "authorization_pending",
"error_description": "Precondition Required"
}
סקרים בתדירות גבוהה מדי
אם המכשיר שולח בקשות סקרים בתדירות גבוהה מדי, השרת מחזיר את קוד הסטטוס של תגובת HTTP 403 (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 לא נמצא. לדוגמה, השגיאה הזו מתרחשת אם
ערך הפרמטר סוג הלקוח ב-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 או ערך Authorization של כותרת HTTP Bearer. כשאפשר, עדיף להשתמש בכותרת ה-HTTP, כי מחרוזות השאילתה מופיעות בדרך כלל ביומני השרת. ברוב המקרים,
אפשר להשתמש בספריית לקוח כדי להגדיר את הקריאות ל-Google APIs (לדוגמה,
בקריאה ל-Drive Files API).
אפשר לנסות את כל ממשקי ה-API של Google ולראות את ההיקף שלהם ב-OAuth 2.0 Playground.
דוגמאות GET של HTTP
קריאה לנקודת הקצה
drive.files (ה-API של Drive Files) באמצעות כותרת ה-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 קשורה. אם ביקשתם גישה אופליין להיקפי ההרשאות שמשויכים לאסימון, אפשר לרענן את אסימון הגישה בלי לבקש מהמשתמש הרשאה (גם אם המשתמש לא נוכח).
כדי לרענן אסימון גישה, האפליקציה שלך שולחת בקשת POST מסוג HTTPS לשרת ההרשאות של 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
emailopenidprofile
Drive API
https://www.googleapis.com/auth/drive.appdatahttps://www.googleapis.com/auth/drive.file
ממשק API של YouTube
https://www.googleapis.com/auth/youtubehttps://www.googleapis.com/auth/youtube.readonly