במסמך הזה מוסבר איך אפליקציות שמותקנות במכשירים כמו טלפונים, טאבלטים ומחשבים משתמשות בנקודות הקצה של OAuth 2.0 של Google כדי להעניק הרשאת גישה ל-YouTube Data API.
OAuth 2.0 מאפשר למשתמשים לשתף נתונים ספציפיים עם אפליקציה תוך שמירה על הפרטיות של שמות המשתמשים, הסיסמאות והמידע הנוסף שלהם. לדוגמה, אפליקציה יכולה להשתמש ב-OAuth 2.0 כדי לקבל הרשאה לאחזר את נתוני YouTube של ערוץ.
אפליקציות מותקנות מופצות למכשירים נפרדים, ומתבססים על ההנחה שהאפליקציות האלה לא יכולות לשמור סודות. הם יכולים לגשת לממשקי Google API בזמן שהמשתמש נמצא באפליקציה או כשהיא פועלת ברקע.
תהליך ההרשאה הזה דומה לתהליך שבו נעשה שימוש באפליקציות של שרת אינטרנט. ההבדל העיקרי הוא שאפליקציות מותקנות צריכות לפתוח את דפדפן המערכת ולספק URI מקומי להפניה אוטומטית כדי לטפל בתשובות משרת ההרשאות של Google.
חלופות
באפליקציות לנייד, מומלץ להשתמש בכניסה באמצעות חשבון Google ל-Android או ל-iOS. ספריות הלקוח של Google Sign-in מטפלות באימות ובהרשאת משתמשים, ויכול להיות שיהיה קל יותר להטמיע אותן מאשר את פרוטוקול הרמה הנמוכה יותר שמתואר כאן.
לאפליקציות שפועלות במכשירים שלא תומכים בדפדפן מערכת או שיש להם יכולות קלט מוגבלות, כמו טלוויזיות, קונסולות משחקים, מצלמות או מדפסות, אפשר לעיין במאמרים OAuth 2.0 למכשירי טלוויזיה ומכשירים או כניסה לחשבון בטלוויזיות ובמכשירים עם יכולות קלט מוגבלות.
ספריות ודגימות
מומלץ להשתמש בספריות ובדוגמאות הבאות כדי להטמיע את התהליך של OAuth 2.0 שמתואר במסמך הזה:
- הספרייה AppAuth for Android
- הספרייה AppAuth for iOS
- OAuth לאפליקציות: דוגמאות ל-Windows
דרישות מוקדמות
הפעלת ממשקי API בפרויקט
כל אפליקציה שמבצעת קריאה ל-Google APIs צריכה להפעיל את ממשקי ה-API האלה ב- .
כדי להפעיל ממשק API בפרויקט:
- ב .
- בדף Library (ספרייה) אפשר למצוא את YouTube Data API ולהפעיל אותו. מוצאים ממשקי API אחרים שבהם האפליקציה תשתמש ומפעילים אותם גם כן.
יצירת פרטי כניסה להרשאה
כל אפליקציה שמשתמשת ב-OAuth 2.0 כדי לגשת ל-Google APIs חייבת לכלול פרטי כניסה שמזהים את האפליקציה לשרת OAuth 2.0 של Google. בשלבים הבאים מוסבר איך ליצור פרטי כניסה לפרויקט. לאחר מכן, האפליקציות שלכם יוכלו להשתמש בפרטי הכניסה כדי לגשת לממשקי ה-API שהפעלתם בפרויקט הזה.
- לוחצים על Create credentials (יצירת פרטי כניסה) > OAuth client ID (מזהה לקוח OAuth).
- בקטעים הבאים מתוארים סוגי הלקוחות שנתמכים בשרת ההרשאות של Google. בוחרים את סוג הלקוח המומלץ לאפליקציה, נותנים שם ללקוח ה-OAuth ומגדירים את שאר השדות בטופס בהתאם.
Android
- בוחרים את סוג האפליקציה ל-Android.
- מזינים שם ללקוח ה-OAuth. השם הזה מוצג ב- של הפרויקט כדי לזהות את הלקוח.
- מזינים את שם החבילה של אפליקציית Android. הערך הזה מוגדר ב
מאפיין
package
של האלמנט<manifest>
בקובץ המניפסט של האפליקציה. - מזינים את טביעת האצבע של אישור החתימה מסוג SHA-1 של הפצת האפליקציה.
- אם האפליקציה שלכם משתמשת בחתימה על אפליקציות ב-Google Play, צריך להעתיק את טביעת האצבע של SHA-1 מהדף של חתימת האפליקציות ב-Play Console.
- אם אתם מנהלים מאגר מפתחות ומפתחות חתימה משלכם, תוכלו להשתמש בכלי keytool שכלול ב-Java כדי להדפיס את פרטי האישור בפורמט שאפשר לקרוא אותו. מעתיקים את הערך של
SHA1
בקטעCertificate fingerprints
בפלט של keytool. למידע נוסף, ראו אימות הלקוח במסמכי העזרה של Google APIs ל-Android.
- (אופציונלי) מאמתים את הבעלות על האפליקציה ל-Android.
- לוחצים על יצירה.
iOS
- בוחרים את סוג האפליקציה iOS.
- מזינים שם ללקוח ה-OAuth. השם הזה מוצג ב- של הפרויקט כדי לזהות את הלקוח.
- מזינים את מזהה החבילה של האפליקציה. מזהה החבילה הוא הערך של המפתח CFBundleIdentifier בקובץ המשאב של רשימת מאפייני המידע של האפליקציה (info.plist). בדרך כלל הערך מוצג בחלונית General (כללי) או בחלונית Signing & Capabilities (חתימה ויכולות) של עורך הפרויקט ב-Xcode. מזהה החבילה מופיע גם בקטע General Information (מידע כללי) בדף App Information (פרטי האפליקציה) של האפליקציה באתר של Apple App Store Connect.
חשוב לוודא שאתם משתמשים במזהה החבילה הנכון של האפליקציה, כי לא תוכלו לשנות אותו אם אתם משתמשים בתכונה 'בדיקת האפליקציה'.
- (אופציונלי)
מזינים את מזהה האפליקציה ב-App Store אם האפליקציה פורסמה ב-App Store של Apple. מזהה החנות הוא מחרוזת מספרית שכלולה בכל כתובת URL של Apple App Store.
- פותחים את אפליקציית App Store של Apple במכשיר iOS או iPadOS.
- מחפשים את האפליקציה.
- בוחרים בלחצן השיתוף (סמל של ריבוע עם חץ למעלה).
- בוחרים באפשרות העתקת הקישור.
- מדביקים את הקישור בכלי לעריכת טקסט. מזהה App Store הוא החלק האחרון בכתובת ה-URL.
לדוגמה:
https://apps.apple.com/app/google/id284815942
- (אופציונלי)
מזינים את מזהה הצוות. למידע נוסף, אפשר לעיין בקטע איתור מזהה הצוות במסמכי התיעוד של חשבון הפיתוח של Apple.
הערה: השדה Team ID (מזהה צוות) נדרש אם מפעילים את App Check ללקוח. - (אופציונלי)
מפעילים את App Check באפליקציה ל-iOS. כשמפעילים את App Check, שירות האימות של אפליקציות של Apple משמש לאימות שהבקשות של OAuth 2.0 שמקורן בלקוח OAuth הן אמיתיות ומגיעות מהאפליקציה. כך אפשר לצמצם את הסיכון להתחזות לאפליקציה. מידע נוסף על הפעלת App Check לאפליקציה ל-iOS
- לוחצים על יצירה.
UWP
- בוחרים את סוג האפליקציה Universal Windows Platform.
- מזינים שם ללקוח ה-OAuth. השם הזה מוצג ב- של הפרויקט כדי לזהות את הלקוח.
- מזינים את מזהה Microsoft Store בן 12 התווים של האפליקציה. אפשר למצוא את הערך הזה בMicrosoft Partner Center בדף App identity בקטע App management.
- לוחצים על יצירה.
באפליקציות UWP, הסכימה של ה-URI בהתאמה אישית לא יכולה להיות ארוכה מ-39 תווים.
זיהוי היקפי הגישה
היקפי הרשאות מאפשרים לאפליקציה לבקש גישה רק למשאבים שנחוצים לה, וגם מאפשרים למשתמשים לקבוע את רמת הגישה שהם מעניקים לאפליקציה. לכן, יכול להיות שיש קשר הפוך בין מספר ההיקפים המבוקשים לבין הסבירות לקבלת הסכמה מהמשתמשים.
לפני שמתחילים להטמיע הרשאה מסוג OAuth 2.0, מומלץ לזהות את היקפי ההרשאות שאליהם האפליקציה תצטרך גישה.
ב-YouTube Data API גרסה 3 נעשה שימוש בהיקפי הגישה הבאים:
טווחים | |
---|---|
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. |
במסמך היקפי הרשאות API של OAuth 2.0 מופיעה רשימה מלאה של ההיקפים שבהם אפשר להשתמש כדי לגשת לממשקי Google APIs.
קבלת אסימוני גישה מסוג OAuth 2.0
השלבים הבאים מראים איך האפליקציה שלכם מקיימת אינטראקציה עם שרת OAuth 2.0 של Google כדי לקבל הסכמה מהמשתמש לבצע בקשת API מטעמו. האפליקציה שלכם צריכה לקבל את ההסכמה הזו כדי שתוכל לבצע בקשה ל-Google API שמחייבת הרשאה מהמשתמש.
שלב 1: יצירת מאמת קוד ואתגר
Google תומכת בפרוטוקול Proof Key for Code Exchange (PKCE) כדי לשפר את האבטחה בתהליך של האפליקציה המותקנת. לכל בקשת הרשאה נוצר מאמת קוד ייחודי, והערך המומר שלו, שנקרא code_challenge, נשלח לשרת ההרשאה כדי לקבל את קוד ההרשאה.
יצירת מאמת הקוד
code_verifier
היא מחרוזת קריפטוגרפית אקראית עם אנטרופיה גבוהה, שמשתמשת בתווים הלא שמורים [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~", באורך מינימלי של 43 תווים ועד אורך מקסימלי של 128 תווים.
לאימות הקוד צריכה להיות אנטרופיה מספקת כדי שיהיה בלתי מעשי לנחש את הערך.
יצירת האתגר של הקוד
יש שתי שיטות ליצירת אתגר הקוד.
שיטות ליצירת אתגרי קוד | |
---|---|
S256 (מומלץ) | אתגר הקוד הוא גיבוב SHA-256 של מאמת הקוד בקידוד Base64URL (ללא מילוי).
|
plain | האתגר של הקוד הוא אותו ערך כמו קוד המאמת שנוצר למעלה.
|
שלב 2: שולחים בקשה לשרת OAuth 2.0 של Google
כדי לקבל הרשאת משתמש, שולחים בקשה לשרת האימות של Google בכתובת https://accounts.google.com/o/oauth2/v2/auth
. נקודת הקצה הזו מטפלת בחיפוש סשנים פעילים, מבצעת אימות של המשתמש ומקבלת את הסכמת המשתמש. אפשר לגשת לנקודת הקצה רק דרך SSL, והיא דוחה חיבורי HTTP (לא SSL).
שרת ההרשאות תומך בפרמטרים הבאים של מחרוזת השאילתה לאפליקציות מותקנות:
פרמטרים | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
client_id |
חובה
מזהה הלקוח של האפליקציה. הערך הזה מופיע ב- . |
||||||||||||||||
redirect_uri |
חובה
קובעת את האופן שבו שרת ההרשאות של Google שולח תשובה לאפליקציה. יש כמה אפשרויות להפניה אוטומטית לאפליקציות מותקנות, וצריך להגדיר את פרטי הכניסה להרשאה בהתאם לשיטת ההפניה האוטומטית הרצויה. הערך צריך להתאים בדיוק לאחד מכתובות ה-URI המורשות להפניה אוטומטית של לקוח OAuth 2.0, שהגדרתם ב-
של הלקוח. אם הערך הזה לא תואם ל-URI מורשה, תופיע הודעת השגיאה בטבלה הבאה מוצג הערך המתאים של הפרמטר
|
||||||||||||||||
response_type |
חובה
הפונקציה קובעת אם נקודת הקצה של Google OAuth 2.0 מחזירה קוד הרשאה. מגדירים את ערך הפרמטר ל- |
||||||||||||||||
scope |
חובה
רשימה של היקפי הרשאות שמפרידה אותם באמצעות רווחים, ומזהה את המשאבים שהאפליקציה יכולה לגשת אליהם מטעם המשתמש. הערכים האלה מופיעים במסך ההסכמה ש-Google מציגה למשתמש. היקפי הרשאות מאפשרים לאפליקציה לבקש גישה רק למשאבים שנחוצים לה, ומאפשרים גם למשתמשים לקבוע את רמת הגישה שהם מעניקים לאפליקציה. לכן, יש קשר הפוך בין מספר ההיקפים המבוקשים לבין הסבירות לקבלת הסכמה מהמשתמשים. ב-YouTube Data API גרסה 3 נעשה שימוש בהיקפי הגישה הבאים:
במסמך היקפי API של OAuth 2.0 מופיעה רשימה מלאה של ההיקפים שבהם אפשר להשתמש כדי לגשת ל-Google APIs. |
||||||||||||||||
code_challenge |
מומלץ
מציין |
||||||||||||||||
code_challenge_method |
מומלץ
מציין את השיטה שבה נעשה שימוש לקידוד של |
||||||||||||||||
state |
מומלץ
מציין ערך מחרוזת שבו האפליקציה משתמשת כדי לשמור את המצב בין בקשת ההרשאה לבין התשובה של שרת ההרשאות.
השרת מחזיר את הערך המדויק ששלחתם כצמד אפשר להשתמש בפרמטר הזה למספר מטרות, למשל כדי להפנות את המשתמש למשאב הנכון באפליקציה, לשלוח ערכים חד-פעמיים (nonces) ולצמצם זיוף בקשות בין אתרים. מכיוון שאפשר לנחש את הערך של |
||||||||||||||||
login_hint |
אופציונלי
אם לאפליקציה ידוע איזה משתמש מנסה לבצע אימות, היא יכולה להשתמש בפרמטר הזה כדי לספק רמז לשרת האימות של Google. השרת משתמש בהצעה כדי לפשט את תהליך הכניסה, על ידי מילוי מראש של שדה האימייל בטופס הכניסה או על ידי בחירת הסשן המתאים לכניסה בכמה חשבונות. מגדירים את ערך הפרמטר ככתובת אימייל או כמזהה |
כתובות URL לדוגמה להרשאה
בכרטיסיות הבאות מוצגות כתובות URL לדוגמה להרשאה עבור האפשרויות השונות של URI להפניה אוטומטית.
כל כתובת URL מבקשת גישה להיקף שמאפשר אחזור של נתוני YouTube של המשתמש.כתובות ה-URL זהות, מלבד הערך של הפרמטר redirect_uri
. כתובות ה-URL מכילות גם את הפרמטרים הנדרשים response_type
ו-client_id
, וגם את הפרמטר האופציונלי state
. כל כתובת URL מכילה מעברי שורה ורווחים כדי לשפר את הקריאוּת שלה.
סכימה של URI בהתאמה אישית
https://accounts.google.com/o/oauth2/v2/auth? scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.force-ssl& response_type=code& state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken& redirect_uri=com.example.app%3A/oauth2redirect& client_id=client_id
כתובת IP של לולאה חוזרת
https://accounts.google.com/o/oauth2/v2/auth? scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.force-ssl& response_type=code& state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken& redirect_uri=http%3A//127.0.0.1%3A9004& client_id=client_id
שלב 3: Google מבקשת מהמשתמש להביע הסכמה
בשלב הזה, המשתמש מחליט אם להעניק לאפליקציה את הגישה המבוקשת. בשלב הזה, Google מציגה חלון הסכמה שבו מוצגים שם האפליקציה ושירותי Google API שבהם היא מבקשת הרשאת גישה באמצעות פרטי הכניסה של המשתמש, וכן סיכום של היקפי הגישה שצריך להעניק. לאחר מכן, המשתמש יכול להביע הסכמה להענקת גישה להיקף אחד או יותר שהאפליקציה ביקשה, או לדחות את הבקשה.
האפליקציה לא צריכה לעשות שום דבר בשלב הזה, אלא רק להמתין לתגובה מהשרת של OAuth 2.0 של Google, שמציינת אם הוקצה גישה כלשהי. התגובה הזו מוסברת בשלב הבא.
שגיאות
יכול להיות שבבקשות לנקודת הקצה של הרשאת OAuth 2.0 של Google יוצגו הודעות שגיאה גלויות למשתמש, במקום תהליכי האימות וההרשאה הצפויים. בהמשך מפורטים קודי שגיאה נפוצים והצעות לפתרון.
admin_policy_enforced
חשבון Google לא יכול להעניק הרשאה להיקף אחד או יותר מהיקפי הגישה המבוקשים בגלל המדיניות של האדמין ב-Google Workspace. במאמר העזרה שליטה בגישה של אפליקציות של צד שלישי ואפליקציות פנימיות לנתונים ב-Google Workspace מוסבר איך אדמין יכול להגביל את הגישה לכל ההיקפים או להיקפים רגישים ומוגבלים, עד שתוענק גישה מפורשת למזהה הלקוח של OAuth.
disallowed_useragent
נקודת הקצה של ההרשאה מוצגת בתוך סוכן משתמש מוטמע שאסור לפי כללי המדיניות של Google בנושא OAuth 2.0.
Android
מפתחי Android עשויים להיתקל בהודעת השגיאה הזו כשהם פותחים בקשות הרשאה ב-android.webkit.WebView
.
במקום זאת, המפתחים צריכים להשתמש בספריות של Android, כמו Google Sign-In ל-Android או AppAuth ל-Android של OpenID Foundation.
מפתחי אינטרנט עשויים להיתקל בשגיאה הזו כשאפליקציה ל-Android פותחת קישור אינטרנט כללי בסוכנות משתמש מוטמעת, ומשתמש מנווט מנקודת הקצה של הרשאת OAuth 2.0 של Google מהאתר שלכם. מפתחים צריכים לאפשר לקישורים כלליים להיפתח בבורר הקישורים שמוגדר כברירת מחדל במערכת ההפעלה, שכולל גם את הבוררים של קישורים לאפליקציות Android או את אפליקציית הדפדפן שמוגדרת כברירת מחדל. גם הספרייה Android Custom Tabs נתמכת.
iOS
מפתחים של iOS ו-macOS עשויים להיתקל בשגיאה הזו כשהם פותחים בקשות הרשאה ב-WKWebView
.
במקום זאת, המפתחים צריכים להשתמש בספריות ל-iOS כמו Google Sign-In ל-iOS או AppAuth ל-iOS של OpenID Foundation.
מפתחי אינטרנט עשויים להיתקל בשגיאה הזו כשאפליקציה ל-iOS או ל-macOS פותחת קישור אינטרנט כללי בסוכן משתמש מוטמע, ומשתמש מנווט מנקודת הקצה של הרשאת OAuth 2.0 של Google מהאתר שלכם. מפתחים צריכים לאפשר לקישורים כלליים להיפתח במנהל הקישורים שמוגדר כברירת מחדל במערכת ההפעלה, שכולל גם את מנהלי Universal Links או את אפליקציית הדפדפן שמוגדרת כברירת מחדל. גם הספרייה SFSafariViewController
נתמכת.
org_internal
מזהה לקוח OAuth בבקשה הוא חלק מפרויקט שמגביל את הגישה לחשבונות Google ב ארגון ספציפי ב-Google Cloud. מידע נוסף על אפשרות ההגדרה הזו זמין בקטע סוג המשתמש במאמר העזרה בנושא הגדרת מסך הסכמה ל-OAuth.
invalid_grant
אם אתם משתמשים במאמת קוד ותג קריאה, הפרמטר code_callenge
לא תקין או חסר. מוודאים שהפרמטר code_challenge
מוגדר בצורה נכונה.
כשמרעננים טוקן גישה, יכול להיות שתוקף הטוקן פג או שהוא בוטל. מאמתים שוב את המשתמש ומבקשים ממנו הסכמה לקבלת אסימונים חדשים. אם השגיאה ממשיכה להופיע, צריך לוודא שהאפליקציה מוגדרת בצורה נכונה ושאתם משתמשים באסימונים ובפרמטרים הנכונים בבקשה. אחרת, יכול להיות שחשבון המשתמש נמחק או הושבת.
redirect_uri_mismatch
הערך של redirect_uri
שהוענק בבקשת ההרשאה לא תואם לכתובת URI מורשית להפניה אוטומטית למזהה הלקוח של OAuth. בודקים את מזהי ה-URI המורשים להפניה אוטומטית בקטע .
יכול להיות שהערך של redirect_uri
שהוענק לא חוקי לסוג הלקוח.
הפרמטר redirect_uri
עשוי להתייחס לתהליך OAuth מחוץ למסגרת (OOB) שהוצא משימוש ולא נתמך יותר. כדי לעדכן את השילוב, אפשר לעיין במדריך להעברה.
invalid_request
הייתה בעיה בבקשה ששלחת. יכולות להיות לכך כמה סיבות:
- הפורמט של הבקשה שגוי
- חסרים פרמטרים נדרשים בבקשה
- הבקשה משתמשת בשיטת הרשאה ש-Google לא תומכת בה. מוודאים שהשילוב של OAuth מתבצע בשיטת שילוב מומלצת
- נעשה שימוש בסכימה מותאמת אישית עבור ה-URI להפניה אוטומטית : אם מופיעה הודעת השגיאה Custom URI scheme is not supported on Chrome apps או Custom URI scheme is not enabled for your Android client, סימן שאתם משתמשים בסכימה מותאמת אישית של URI שלא נתמכת באפליקציות Chrome ומושבתת כברירת מחדל ב-Android. מידע נוסף על חלופות לסכימת URI מותאמת אישית
שלב 4: טיפול בתגובה של שרת OAuth 2.0
האופן שבו האפליקציה מקבלת את תגובת ההרשאה תלוי בסכימה של ה-URI להפניה אוטומטית שבה היא משתמשת. ללא קשר לתוכנית, התשובה תכלול קוד הרשאה (code
) או שגיאה (error
). לדוגמה, הערך error=access_denied
מציין שהמשתמש דחה את הבקשה.
אם המשתמש מעניק גישה לאפליקציה, תוכלו להחליף את קוד ההרשאה באסימון גישה ובאסימון רענון, כפי שמתואר בשלב הבא.
שלב 5: מחליפים את קוד ההרשאה באסימוני רענון ואסימוני גישה
כדי להמיר קוד הרשאה לאסימון גישה, צריך להפעיל את נקודת הקצה https://oauth2.googleapis.com/token
ולהגדיר את הפרמטרים הבאים:
שדות | |
---|---|
client_id |
מזהה הלקוח שהתקבל מ- . |
client_secret |
סוד הלקוח שהתקבל מ- . |
code |
קוד ההרשאה שהוחזר מהבקשה הראשונית. |
code_verifier |
מאמת הקוד שיצרתם בשלב 1. |
grant_type |
כפי שמוגדר במפרט של OAuth 2.0, הערך של השדה הזה צריך להיות authorization_code . |
redirect_uri |
אחד מ-URI להפניה אוטומטית שמפורטים לפרויקט שלכם ב-
עבור client_id הנתון. |
בקטע הקוד הבא מוצגת בקשה לדוגמה:
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=http://127.0.0.1:9004& grant_type=authorization_code
בתגובה לבקשה הזו, Google מחזירה אובייקט JSON שמכיל אסימון גישה לטווח קצר ואסימון רענון.
התגובה כוללת את השדות הבאים:
שדות | |
---|---|
access_token |
האסימון שהאפליקציה שולחת כדי לאשר בקשה ל-Google API. |
expires_in |
משך החיים שנותר של אסימון הגישה, בשניות. |
id_token |
הערה: הנכס הזה מוחזר רק אם הבקשה כללה היקף זהות, כמו openid , profile או email . הערך הוא אסימון אינטרנט מסוג JSON (JWT) שמכיל פרטי זהות של המשתמש בחתימה דיגיטלית. |
refresh_token |
אסימון שאפשר להשתמש בו כדי לקבל אסימון גישה חדש. אסימוני הרענון בתוקף עד שהמשתמש מבטל את הגישה. חשוב לזכור שתמיד מוחזרים אסימוני רענון לאפליקציות מותקנות. |
scope |
היקפי הגישה שמוענקים על ידי access_token מפורטים כרשימה של מחרוזות תלויות-אותיות רישיות שמפרידות ביניהן רווחים. |
token_type |
סוג הטוקן שהוחזר. בשלב זה, הערך של השדה הזה תמיד מוגדר ל-Bearer . |
קטע הקוד הבא מציג תגובה לדוגמה:
{ "access_token": "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in": 3920, "token_type": "Bearer", "scope": "https://www.googleapis.com/auth/youtube.force-ssl https://www.googleapis.com/auth/calendar.readonly", "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI" }
שלב 6: בודקים אילו היקפי הרשאות המשתמשים העניקו
כשמבקשים כמה היקפי הרשאה בו-זמנית, יכול להיות שהמשתמשים לא יאשרו את כל ההיקפים שהאפליקציה מבקשת. האפליקציה צריכה תמיד לבדוק אילו היקפי הרשאות הוקצו על ידי המשתמש, ולטפל בכל דחייה של היקפי הרשאות על ידי השבתת התכונות הרלוונטיות. מידע נוסף זמין במאמר איך מטפלים בהרשאות מפורטות.
כדי לבדוק אם המשתמש העניק לאפליקציה גישה להיקף ספציפי, צריך לבדוק את השדה scope
בתשובה לאסימון הגישה. היקפי הגישה שמוענקים על ידי access_token מפורטים כרשימה של מחרוזות רגישות ל-case שמפרידות ביניהן רווחים.
לדוגמה, התגובה לדוגמה הבאה של אסימון הגישה מראה שהמשתמש העניק לאפליקציה שלכם גישה להרשאות 'קריאה בלבד' לפעילות ב-Drive ולאירועים ביומן:
{ "access_token": "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in": 3920, "token_type": "Bearer", "scope": "https://www.googleapis.com/auth/youtube.force-ssl https://www.googleapis.com/auth/calendar.readonly", "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI" }
קריאה ל-Google APIs
אחרי שהאפליקציה מקבלת אסימון גישה, אפשר להשתמש באסימון כדי לבצע קריאות ל-Google API מטעם חשבון משתמש נתון, אם היקפי הגישה הנדרשים ל-API הוקצו. כדי לעשות זאת, צריך לכלול את אסימון הגישה בבקשה ל-API באמצעות פרמטר של שאילתה access_token
או ערך Bearer
בכותרת Authorization
של HTTP. כשהדבר אפשרי, עדיף להשתמש בכותרת ה-HTTP, כי מחרוזות השאילתות נוטים להיות גלויות ביומנים של השרת. ברוב המקרים אפשר להשתמש בספריית לקוח כדי להגדיר את הקריאות לממשקי Google API (לדוגמה, כשקוראים ל-YouTube Live Streaming API).
חשוב לדעת ש-YouTube Live Streaming API לא תומך בתהליך של חשבון שירות. מכיוון שאין אפשרות לקשר חשבון שירות לחשבון YouTube, ניסיונות לאשר בקשות באמצעות התהליך הזה יגרמו לשגיאה NoLinkedYouTubeAccount
.
אפשר לנסות את כל ממשקי Google APIs ולראות את היקפי ההרשאות שלהם ב-OAuth 2.0 Playground.
דוגמאות לבקשות HTTP GET
קריאה לנקודת הקצה
liveBroadcasts.list
(YouTube Live Streaming API) באמצעות הכותרת Authorization: Bearer
של HTTP עשויה להיראות כך: חשוב לשים לב שצריך לציין את טוקן הגישה שלכם:
GET /youtube/v3/liveBroadcasts?part=id%2Csnippet&mine=true HTTP/1.1 Host: www.googleapis.com Authorization: Bearer access_token
זוהי קריאה לאותו ממשק API עבור המשתמש המאומת באמצעות הפרמטר access_token
של מחרוזת השאילתה:
GET https://www.googleapis.com/youtube/v3/liveBroadcasts?access_token=access_token&part=id%2Csnippet&mine=true
curl
דוגמאות
אפשר לבדוק את הפקודות האלה באמצעות אפליקציית שורת הפקודה curl
. הנה דוגמה שמשתמשת באפשרות של כותרת ה-HTTP (האפשרות המועדפת):
curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/v3/liveBroadcasts?part=id%2Csnippet&mine=true
לחלופין, אפשר לבחור באפשרות 'פרמטר של מחרוזת שאילתה':
curl https://www.googleapis.com/youtube/v3/liveBroadcasts?access_token=access_token&part=id%2Csnippet&mine=true
רענון של אסימון גישה
מדי פעם פג התוקף של אסימוני הגישה והם הופכים לפרטי כניסה לא חוקיים לבקשת API קשורה. אם ביקשת גישה אופליין להיקפי הרשאה שמשויכים לטוקן, אפשר לרענן את טוקן הגישה בלי לבקש מהמשתמש הרשאה (כולל כשהמשתמש לא נמצא).
כדי לרענן אסימון גישה, האפליקציה שולחת בקשת POST
ב-HTTPS לשרת ההרשאות של Google (https://oauth2.googleapis.com/token
) שכוללת את הפרמטרים הבאים:
שדות | |
---|---|
client_id |
מזהה הלקוח שהתקבל מ- . |
client_secret |
סוד הלקוח שהתקבל מ- .
(ה-client_secret לא רלוונטי לבקשות מלקוחות שרשומים כאפליקציות ל-Android, ל-iOS או ל-Chrome).
|
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 https://www.googleapis.com/auth/calendar.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
מוחזר יחד עם קוד שגיאה.
שיטות להפניה אוטומטית של אפליקציות
סכימת URI בהתאמה אישית (Android, iOS, UWP)
סכימות URI בהתאמה אישית הן סוג של קישור עומק שמשתמש בסכמה מוגדרת בהתאמה אישית כדי לפתוח את האפליקציה.
חלופה לשימוש בסכימות URI בהתאמה אישית ב-Android
להשתמש ב-Google Sign-In for Android SDK, שמעביר את התגובה של OAuth 2.0 ישירות לאפליקציה, וכך מבטל את הצורך ב-URI להפניה אוטומטית.
איך עוברים ל-Google Sign-In for Android SDK
אם אתם משתמשים בסכימה מותאמת אישית לשילוב OAuth ב-Android, תצטרכו לבצע את הפעולות הבאות כדי לעבור באופן מלא לשימוש ב-SDK המומלץ של Google Sign-In ל-Android:
- מעדכנים את הקוד כך שישתמש ב-Google Sign-In SDK.
- משביתים את התמיכה בסכימה בהתאמה אישית במסוף Google API.
כדי לעבור ל-Google Sign-In Android SDK:
-
מעדכנים את הקוד כך שישתמש ב-Android SDK של Google Sign-In:
-
בודקים את הקוד כדי לזהות איפה אתם שולחים בקשה לשרת OAuth 2.0 של Google. אם אתם משתמשים בסכימה מותאמת אישית, הבקשה שלכם תיראה כך:
https://accounts.google.com/o/oauth2/v2/auth? scope=<SCOPES>& response_type=code& &state=<STATE>& redirect_uri=com.example.app:/oauth2redirect& client_id=<CLIENT_ID>
com.example.app:/oauth2redirect
הוא ה-URI של ההפניה האוטומטית של הסכימה בהתאמה אישית בדוגמה שלמעלה. פרטים נוספים על הפורמט של ערך הסכימה של URI בהתאמה אישית מופיעים בהגדרת הפרמטרredirect_uri
. -
חשוב לשים לב למשתני הבקשה
scope
ו-client_id
, שנדרשים להגדרת ה-SDK של Google Sign-In. -
כדי להגדיר את ה-SDK, פועלים לפי ההוראות במאמר
תחילת השילוב של כניסה באמצעות חשבון Google באפליקציה ל-Android. אפשר לדלג על השלב קבלת מזהה הלקוח של OAuth 2.0 בשרת הקצה, כי אפשר להשתמש שוב ב-
client_id
שאוחזר מהשלב הקודם. -
פועלים לפי ההוראות במאמר
הפעלת גישה ל-API בצד השרת. מחזור החיים של התקלה כולל את השלבים הבאים:
-
משתמשים בשיטה
getServerAuthCode
כדי לאחזר קוד אימות להיקפי הגישה שבהם מבקשים הרשאה. - שולחים את קוד האימות לקצה העורפי של האפליקציה כדי להמיר אותו לטוקן גישה וטוקן רענון.
- משתמשים באסימון הגישה שאוחזר כדי לבצע קריאות ל-Google APIs מטעם המשתמש.
-
משתמשים בשיטה
-
בודקים את הקוד כדי לזהות איפה אתם שולחים בקשה לשרת OAuth 2.0 של Google. אם אתם משתמשים בסכימה מותאמת אישית, הבקשה שלכם תיראה כך:
-
משביתים את התמיכה בסכימה מותאמת אישית במסוף Google API:
- עוברים לרשימת פרטי הכניסה של OAuth 2.0 ובוחרים את לקוח Android.
- עוברים לקטע Advanced Settings, מבטלים את הסימון בתיבה Enable Custom URI Scheme ולוחצים על Save כדי להשבית את התמיכה בסכימת URI בהתאמה אישית.
הפעלת סכימה מותאמת אישית של URI
אם החלופה המומלצת לא עובדת, תוכלו להפעיל סכמות URI בהתאמה אישית בלקוח Android שלכם לפי ההוראות הבאות:- עוברים לרשימת פרטי הכניסה של OAuth 2.0 ובוחרים את לקוח Android.
- עוברים לקטע Advanced Settings (הגדרות מתקדמות), מסמנים את התיבה Enable Custom URI Scheme (הפעלת סכימת URI מותאמת אישית) ולוחצים על Save (שמירה) כדי להפעיל תמיכה בסכימת URI מותאמת אישית.
חלופה לשימוש בסכימות URI בהתאמה אישית באפליקציות של Chrome
משתמשים ב-Chrome Identity API, שמעביר את התגובה של OAuth 2.0 ישירות לאפליקציה, ומבטל את הצורך ב-URI להפניה אוטומטית.
כתובת IP של לולאה חוזרת (macOS, Linux, Windows במחשב)
כדי לקבל את קוד ההרשאה באמצעות כתובת ה-URL הזו, האפליקציה צריכה להאזין לשרת האינטרנט המקומי. אפשר לעשות זאת בפלטפורמות רבות, אבל לא בכל הפלטפורמות. עם זאת, אם הפלטפורמה תומכת בכך, זהו המנגנון המומלץ לקבלת קוד ההרשאה.
כשהאפליקציה מקבלת את תגובת ההרשאה, כדי לשפר את נוחות השימוש, היא צריכה להגיב על ידי הצגת דף HTML עם הוראה למשתמש לסגור את הדפדפן ולחזור לאפליקציה.
שימוש מומלץ | אפליקציות למחשב עם macOS, Linux ו-Windows (אבל לא Universal Windows Platform) |
ערכים בטופס | מגדירים את סוג האפליקציה בתור אפליקציה למחשב. |
העתקה/הדבקה ידנית (הוצא משימוש)
הגנה על האפליקציות
אימות הבעלות על האפליקציה (Android, Chrome)
אתם יכולים לאמת את הבעלות על האפליקציה כדי לצמצם את הסיכון להתחזות לאפליקציה.
Android
כדי להשלים את תהליך האימות, אפשר להשתמש בחשבון הפיתוח שלכם ב-Google Play אם יש לכם כזה והאפליקציה שלכם רשומה ב-Google Play Console. כדי שהאימות יושלם, צריך לעמוד בדרישות הבאות:
- צריכה להיות לכם אפליקציה רשומה ב-Google Play Console עם אותו שם חבילה וטביעת אצבע של אישור החתימה מסוג SHA-1 כמו של לקוח OAuth ל-Android שאתם מבצעים את האימות שלו.
- צריכה להיות לכם הרשאת אדמין לאפליקציה ב-Google Play Console. מידע נוסף על ניהול הרשאות גישה ב-Google Play Console
בקטע אימות הבעלות על האפליקציה בלקוח Android, לוחצים על הלחצן אימות הבעלות כדי להשלים את תהליך האימות.
אם האימות יצליח, תוצג הודעה לאישור השלמת תהליך האימות. אחרת, תוצג הודעת שגיאה.
כדי לפתור אימות שנכשל, אפשר לנסות את הפעולות הבאות:
- חשוב לוודא שהאפליקציה שאתם מאמתים רשומה ב-Google Play Console.
- חשוב לוודא שיש לכם הרשאת אדמין לאפליקציה במסוף Google Play.
Chrome
כדי להשלים את תהליך האימות, תצטרכו להשתמש בחשבון הפיתוח שלכם בחנות האינטרנט של Chrome. כדי שהאימות יושלם, צריך לעמוד בדרישות הבאות:
- צריך להיות לכם פריט רשום במרכז השליטה למפתחים של חנות האינטרנט של Chrome עם אותו מזהה פריט של לקוח OAuth של תוסף Chrome שאתם מבצעים את האימות שלו.
- עליכם להיות בעלי תוכן דיגיטלי של הפריט בחנות האינטרנט של Chrome. מידע נוסף על ניהול הרשאות גישה זמין במרכז השליטה למפתחים בחנות האינטרנט של Chrome.
בקטע אימות הבעלות על האפליקציה בלקוח של תוסף Chrome, לוחצים על הלחצן אימות הבעלות כדי להשלים את תהליך האימות.
הערה: אחרי שמעניקים גישה לחשבון, צריך להמתין כמה דקות לפני שמסיימים את תהליך האימות.
אם האימות יצליח, תוצג הודעה לאישור השלמת תהליך האימות. אחרת, תוצג הודעת שגיאה.
כדי לפתור אימות שנכשל, אפשר לנסות את הפעולות הבאות:
- צריך לוודא שיש פריט רשום במרכז השליטה למפתחים של חנות האינטרנט של Chrome עם אותו מזהה פריט כמו של לקוח OAuth של תוסף Chrome שאת האימות שלו אתם משלימים.
- חשוב לוודא שאתם בעלי תוכן דיגיטלי באפליקציה. כלומר, אתם צריכים להיות בעלי התוכן הדיגיטלי האישי באפליקציה או חברים בחשבון הקבוצתי של בעלי התוכן הדיגיטלי באפליקציה. מידע נוסף על ניהול הרשאות הגישה זמין במרכז השליטה למפתחים בחנות האינטרנט של Chrome.
- אם עדכנתם את רשימת בעלי האפליקציות בקבוצה, עליכם לוודא שרשימה הזו מסונכרנת במרכז השליטה למפתחים של חנות האינטרנט של Chrome. מידע נוסף על סנכרון רשימת המינויים של בעלי התוכן הדיגיטלי
בדיקת האפליקציה (iOS בלבד)
התכונה בדיקת האפליקציה עוזרת להגן על האפליקציות ל-iOS מפני שימוש לא מורשה באמצעות שירות האימות של אפליקציות של Apple, כדי לוודא שהבקשות שנשלחות לנקודות הקצה של Google OAuth 2.0 מגיעות מהאפליקציות המקוריות שלכם. כך תוכלו לצמצם את הסיכון להתחזות לאפליקציה.
הפעלת App Check בלקוח iOS
כדי להפעיל את App Check עבור לקוח iOS, צריך לעמוד בדרישות הבאות:- חובה לציין מזהה צוות ללקוח iOS.
- אסור להשתמש בתווים כלליים לחיפוש במזהה החבילה, כי הם יכולים להוביל ליותר מאפליקציה אחת. כלומר, מזהה החבילה לא יכול לכלול את הסמל של כוכב (*).
אחרי הפעלת App Check, תתחילו לראות מדדים שקשורים לבקשות OAuth מהלקוח שלכם בתצוגת העריכה של לקוח ה-OAuth. בקשות ממקורות לא מאומתים לא ייחסמו עד שתפעילו את אכיפת בדיקת האפליקציות. המידע בדף למעקב אחר המדדים יכול לעזור לכם לקבוע מתי להתחיל לאכוף את המדיניות.
יכול להיות שתראו שגיאות שקשורות לתכונה App Check כשתפעילו את App Check באפליקציה ל-iOS. כדי לתקן את השגיאות האלה, תוכלו לנסות את הפעולות הבאות:
- מוודאים שמזהה החבילה ומזהה הצוות שציינתם תקפים.
- מוודאים שלא משתמשים בתו כללי לחיפוש למזהה החבילה.
אכיפת בדיקת האפליקציה ללקוח iOS
הפעלת בדיקת האפליקציה לא גורמת לחסימה אוטומטית של בקשות לא מזוהות. כדי לאכוף את ההגנה הזו, עוברים לתצוגת העריכה של לקוח iOS. שם יופיעו המדדים של בדיקת האפליקציה בצד שמאל של הדף, בקטע Google Identity for iOS. המדדים כוללים את הפרטים הבאים:- מספר הבקשות המאומתות – בקשות עם אסימון תקף של בדיקת האפליקציה. אחרי שתפעילו את האכיפה של בדיקת האפליקציות, רק בקשות בקטגוריה הזו יאושרו.
- מספר הבקשות שלא אומתו: סביר להניח שמדובר בבקשות לקוח לא עדכניות – בקשות בלי אסימון של App Check. יכול להיות שהבקשות האלה מגיעות מגרסה ישנה יותר של האפליקציה שלא כוללת הטמעה של App Check.
- מספר הבקשות שלא אומתו: בקשות ממקור לא ידוע – בקשות ללא אסימון של בדיקת האפליקציה שנראות לא כאלה שמגיעות מהאפליקציה שלכם.
- מספר הבקשות שלא אומתו: בקשות לא חוקיות – בקשות עם טוקן לא תקין של בדיקת האפליקציה. יכול להיות שהבקשות האלה מגיעות מלקוח לא אותנטי שמנסה להתחזות לאפליקציה שלכם, או מסביבות מופעלות.
כדי לאכוף את בדיקת האפליקציות, לוחצים על הלחצן ENFORCE ומאשרים את הבחירה. אחרי שהאכיפה תהיה פעילה, כל הבקשות מהלקוח שלא אומתו נדחות.
הערה: אחרי שמפעילים את האכיפה, יכול להיות שיחלפו עד 15 דקות עד שהשינויים ייכנסו לתוקף.
ביטול האכיפה של בדיקת האפליקציה ללקוח iOS
אם תבטלו את האכיפה של בדיקת האפליקציה, האכיפה תיפסק וכל הבקשות מהלקוח לנקודות הקצה של Google OAuth 2.0, כולל בקשות לא מאומתות, יורשו לעבור.
כדי לבטל את האכיפה של בדיקת האפליקציות בלקוח ל-iOS, עוברים לתצוגת העריכה של הלקוח ל-iOS ולוחצים על הלחצן UNENFORCE (ביטול האכיפה) ומאשרים את הבחירה.
הערה: אחרי ביטול האכיפה של בדיקת האפליקציה, יכול להיות שיחלפו עד 15 דקות עד שהשינויים ייכנסו לתוקף.
השבתת בדיקת האפליקציה בלקוח iOS
השבתת App Check באפליקציה תגרום להפסקת כל המעקב והאכיפה של App Check. במקום זאת, כדאי להפסיק לאכוף את בדיקת האפליקציה כדי שתוכלו להמשיך לעקוב אחרי המדדים של הלקוח.
כדי להשבית את App Check עבור לקוח iOS, עוברים לתצוגת העריכה של לקוח ה-iOS ומשביתים את המתג Protect your OAuth client from abuse with Firebase App Check.
הערה: אחרי השבתת בדיקת האפליקציות, יכול להיות שיחלפו עד 15 דקות עד שהשינויים ייכנסו לתוקף.
מקורות מידע נוספים
OAuth 2.0 for Native Apps הוא המסמך של IETF שמפרט את השיטות המומלצות הנוכחיות, ורבות מהשיטות המומלצות שמפורטות כאן מבוססות עליו.
הטמעת ההגנה על כל החשבונות
כדי להגן על חשבונות המשתמשים, כדאי להטמיע הגנה על חשבונות שונים באמצעות שירות ההגנה על חשבונות שונים של 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
במאמר הגנה על חשבונות משתמשים באמצעות הגנה על כל החשבונות מוסבר איך מטמיעים את ההגנה על כל החשבונות ומופיעה רשימה מלאה של האירועים הזמינים.