במסמך הזה מוסבר איך להטמיע הרשאת OAuth 2.0 כדי לגשת ממשק ה-API של YouTube Data דרך אפליקציות שפועלות במכשירים כמו טלוויזיות, קונסולות משחקים מדפסות. באופן ספציפי יותר, התהליך הזה מיועד למכשירים שאין להם גישה לדפדפן, או שיש להם יכולות קלט מוגבלות.
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 לפרויקט:
- Open the API Library ב- Google API Console.
- If prompted, select a project, or create a new one.
- בדף ספרייה אפשר למצוא ולהפעיל את YouTube Data API. חיפוש אפליקציות אחרות ממשקי API שהאפליקציה שלכם תשתמש בהם ותפעיל גם אותם.
יצירת פרטי כניסה להרשאה
לכל אפליקציה שמשתמשת ב-OAuth 2.0 כדי לגשת ל-Google APIs חייבים להיות פרטי כניסה להרשאה שמשמש לזיהוי האפליקציה בשרת OAuth 2.0 של Google. בשלבים הבאים נסביר איך יוצרים פרטי כניסה לפרויקט. לאחר מכן האפליקציות שלך יכולות להשתמש בפרטי הכניסה כדי לגשת לממשקי API שהפעלתם עבור הפרויקט הזה.
- Go to the Credentials page.
- לוחצים על Create credentials > מזהה הלקוח ב-OAuth.
- בוחרים בסוג האפליקציה טלוויזיות ומכשירי קלט מוגבלים.
- נותנים שם ללקוח OAuth 2.0 ולוחצים על יצירה.
זיהוי של היקפי גישה
היקפי הרשאות מאפשרים לאפליקציה לבקש גישה רק למשאבים שהיא צריכה, וגם שמאפשרים למשתמשים לשלוט בכמות הגישה שהם מעניקים לאפליקציה שלכם. לכן, עשוי להיות קשר הפוך בין מספר ההיקפים המבוקשים לבין הסבירות קבלת הסכמה מהמשתמשים.
לפני שמתחילים להטמיע הרשאה מסוג OAuth 2.0, מומלץ לזהות את היקפי ההרשאות שהאפליקציה שלך תצטרך הרשאה כדי לגשת אליה.
ממשק YouTube Data API v3 משתמש בהיקפים הבאים:
טווחים | |
---|---|
https://www.googleapis.com/auth/youtube | ניהול חשבון YouTube שלך |
https://www.googleapis.com/auth/youtube.channel-memberships.creator | הצגת רשימה מעודכנת של החברים הפעילים במועדון החברים של הערוץ, הרמה הנוכחית שלהם והתאריך שבו הם הצטרפו למועדון |
https://www.googleapis.com/auth/youtube.force-ssl | הצגה, עריכה ומחיקה לצמיתות של סרטונים, דירוגים, תגובות וכתוביות ב-YouTube |
https://www.googleapis.com/auth/youtube.readonly | הצגת חשבון YouTube שלך |
https://www.googleapis.com/auth/youtube.upload | ניהול הסרטונים שלך ב-YouTube |
https://www.googleapis.com/auth/youtubepartner | הצגה וניהול של הנכסים והתכנים הקשורים שלך ב-YouTube |
https://www.googleapis.com/auth/youtubepartner-channel-audit | הצגת מידע פרטי של ערוץ YouTube שלך הרלוונטי בתהליך הביקורת של שותף YouTube. |
לרשימת היקפי ההרשאות המותרים של אפליקציות או מכשירים מותקנים.
קבלת אסימוני גישה מסוג 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 |
חובה
מזהה הלקוח של האפליקציה. אפשר למצוא את הערך הזה API Console Credentials page. |
||||||||||||||||
scope |
חובה
א' קובץ מופרד ברווחים רשימת היקפים שמזהים את המשאבים שהאפליקציה יכולה לגשת אליהם בשם המשתמש. הערכים האלה קובעים את מסך ההסכמה ש-Google מציגה משתמש. לצפייה רשימת היקפי הרשאות מותרים לאפליקציות או למכשירים מותקנים. היקפי הרשאות מאפשרים לאפליקציה לבקש גישה רק למשאבים שהיא צריכה ובמקביל גם מאפשרים למשתמשים לשלוט בכמות הגישה שהם מעניקים תרגום מכונה. כך יש קשר הפוך בין מספר ההיקפים המבוקשים והסבירות לקבל את הסכמת המשתמש. ממשק YouTube Data API v3 משתמש בהיקפים הבאים:
המסמך היקפי API של OAuth 2.0 מספק רשימה מלאה של היקפים שבהם תוכלו להשתמש כדי לגשת ל-Google APIs. |
דוגמאות
קטע הקוד הבא מציג בקשה לדוגמה:
POST /device/code HTTP/1.1 Host: oauth2.googleapis.com Content-Type: application/x-www-form-urlencoded client_id=client_id&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.readonly
בדוגמה הזו מוצגת פקודת curl
לשליחת אותה בקשה:
curl -d "client_id=client_id&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.readonly" \ 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
.
חשוב להביא בחשבון את הכללים הבאים כשמתכננים את ממשק המשתמש:
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 תקופת זמן מסוימת, הוא יוכל להשתמש באסימון הרענון כדי לקבל גישה חדשה ב-Assistant. אם לאפליקציה שלך דרושה גישה מהסוג הזה, היא צריכה לאחסן את אסימון הרענון עבור לשימוש מאוחר יותר.
הגישה נדחתה
אם המשתמש מסרב להעניק גישה למכשיר, לתגובת השרת
קוד הסטטוס של תשובת HTTP 403
(Forbidden
). התשובה תכיל את
השגיאה הבאה:
{ "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" }
שגיאות אחרות
שרת ההרשאות מחזיר גם שגיאות אם בקשת הדגימה חסרה
או שכולל ערך פרמטר שגוי. בדרך כלל, הבקשות האלה כוללות 400
(Bad Request
) או 401
(Unauthorized
) סטטוס של תגובת HTTP
דוגמאות לשגיאות כאלה:
שגיאה | קוד מצב 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
לאחר שהאפליקציה שלך מקבלת אסימון גישה, אפשר להשתמש באסימון כדי לבצע קריאות
API בשם נתון
חשבון משתמש, אם היקפי הגישה הנדרשים על ידי ה-API הוענקו. כדי לעשות את זה, צריך לכלול
אסימון הגישה בבקשה ל-API על ידי הכללת שאילתת access_token
או ערך Bearer
של כותרת HTTP בAuthorization
. כשהדבר אפשרי,
עדיף להשתמש בכותרת HTTP, כי מחרוזות השאילתה בדרך כלל גלויות ביומני השרת. במרבית
במקרים מסוימים תוכלו להשתמש בספריית לקוח כדי להגדיר את הקריאות ל-Google APIs (לדוגמה,
שליחת קריאה ל-YouTube Data API).
הערה: ממשק YouTube Data API תומך בחשבונות שירות רק עבור YouTube בעלי תוכן שהם הבעלים והמנהלים של מספר ערוצי YouTube, כמו הקלטה לייבלים ואולפני קולנוע.
אפשר לנסות את כל ממשקי ה-API של Google ולצפות בהיקף שלהם בקישור OAuth 2.0 Playground
דוגמאות ל-HTTP GET
קריאה ל
youtube.channels
נקודת קצה (ממשק YouTube Data API) באמצעות ה-HTTP Authorization: Bearer
עשויה להיראות כך. שימו לב שתצטרכו לציין אסימון גישה משלכם:
GET /youtube/v3/channels?part=snippet&mine=true HTTP/1.1 Host: www.googleapis.com Authorization: Bearer access_token
זוהי קריאה לאותו API בשביל המשתמש המאומת באמצעות access_token
פרמטר של מחרוזת שאילתה:
GET https://www.googleapis.com/youtube/v3/channels?access_token=access_token&part=snippet&mine=true
curl
דוגמאות
אפשר לבדוק את הפקודות האלה באמצעות אפליקציית שורת הפקודה curl
. הנה
דוגמה שמשתמשת באפשרות של כותרת HTTP (מועדף):
curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/v3/channels?part=snippet&mine=true
לחלופין, אפשרות הפרמטר של מחרוזת השאילתה:
curl https://www.googleapis.com/youtube/v3/channels?access_token=access_token&part=snippet&mine=true
רענון של אסימון גישה
התוקף של אסימוני הגישה פג מדי פעם והם הופכים לפרטי כניסה לא חוקיים לבקשת API קשורה. שלך יכול לרענן אסימון גישה בלי לבקש הרשאה מהמשתמש (גם כשהמשתמש לא קיים) אם ביקשת גישה אופליין להיקפי ההרשאות שמשויכים לאסימון.
כדי לרענן אסימון גישה, האפליקציה שולחת כתובת URL מסוג 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" }
חשוב לשים לב שיש הגבלות על מספר אסימוני הרענון שיונפקו. מגבלה אחת לכל שילוב של לקוח/משתמש ושילוב נוסף לכל משתמש בכל הלקוחות. עליך לשמור אסימוני רענון באחסון לטווח ארוך ולהמשיך להשתמש בהם כל עוד הם בתוקף. אם הבקשה שלכם מבקשת יותר מדי אסימוני רענון, היא עלולה להגיע למגבלות האלה. במקרה כזה, אסימוני רענון ישנים יותר יפסיקו לפעול.
ביטול אסימון
במקרים מסוימים משתמש עשוי לבטל את הגישה שניתנה לאפליקציה. משתמש יכול לבטל את הגישה על ידי ביקור בכתובת הגדרות חשבון. לצפייה הסרה קטע הגישה של האתר או האפליקציה באתרים של צדדים שלישיים אפליקציות עם גישה לחשבון מסמך תמיכה של Google לקבלת מידע נוסף.
אפשר גם שאפליקציה יכולה לבטל באופן פרוגרמטי את הגישה שהוענקה לה. ביטול פרוגרמטי חשוב במקרים שבהם משתמש מבטל את ההרשמה ומסיר או משאבי ה-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
ממשק API של YouTube
https://www.googleapis.com/auth/youtube
https://www.googleapis.com/auth/youtube.readonly
יישום הגנה על כל החשבונות
פעולה נוספת שצריך לבצע כדי להגן על המשתמשים משתמשים בחשבונות שונים הגנה על ידי שימוש בשירות ההגנה על כל החשבונות של Google. השירות הזה מאפשר לך הרשמה להתראות על פעולות שמשפיעות על אבטחת החשבון, שמספקות מידע לאפליקציה על שינויים משמעותיים בחשבון המשתמש. לאחר מכן תוכלו להשתמש במידע כדי לנקוט פעולה בהתאם האופן שבו אתם מחליטים להגיב לאירועים.
אלה כמה דוגמאות לסוגי האירועים שנשלחים לאפליקציה שלכם על ידי שירות ההגנה על כל החשבונות של Google:
-
https://schemas.openid.net/secevent/risc/event-type/sessions-revoked
-
https://schemas.openid.net/secevent/oauth/event-type/token-revoked
-
https://schemas.openid.net/secevent/risc/event-type/account-disabled
לצפייה הגנה על חשבונות משתמשים באמצעות הדף 'הגנה על כל החשבונות' כדי לקבל מידע נוסף על ההטמעה של הגנה על כל החשבונות ולרשימה המלאה של האירועים הזמינים.