שיקולים נוספים לגבי Google Workspace
קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
אם האפליקציה שלכם מיועדת למשתמשים חיצוניים, כדאי לכם לפנות לקהל רחב ככל האפשר של חשבונות Google, כולל חשבונות Google שמנוהלים על ידי ארגון Google Workspace.
אדמינים ב-Google Workspace יכולים להשתמש באמצעים לבקרת גישה ל-API כדי להפעיל או להגביל את הגישה לממשקי API של Google Workspace עבור אפליקציות וחשבונות שירות השייכים ללקוחות או לצדדים שלישיים. התכונה הזו מאפשרת לאדמינים ב-Google Workspace להגביל את הגישה רק למזהים של לקוחות OAuth שהארגון סומך עליהם, וכך להפחית את הסיכון שקשור לגישה של צד שלישי לשירותי Google.
כדי להגיע לקהל רחב ככל האפשר של חשבונות Google ולעודד אמון, מומלץ לפעול לפי ההנחיות הבאות:
- שולחים את האפליקציה לאימות על ידי Google. אם רלוונטי, עליך לשלוח את האפליקציה לאימות מותג, וגם לאימות של היקפי גישה רגישים ומוגבלים. אדמינים ב-Google Workspace יכולים לראות את הסטטוס המאומת של האפליקציה שלכם, ויכול להיות שהם יסמכו יותר על אפליקציות ש-Google מאמתת מאשר על אפליקציות עם סטטוס לא מאומת או לא ידוע.
- אדמינים ב-Google Workspace יכולים לתת למזהי הלקוח של OAuth באפליקציה שלכם גישה לשירותים מוגבלים ולהיקפי הרשאות בסיכון גבוה בתוך השירותים האלה. אם כוללים את מזהה לקוח OAuth של האפליקציה במסמכי העזרה,
אפשר לספק לאדמינים של Google Workspace ולתומכים באפליקציה בארגונים שלהם,
את המידע שדרוש כדי לתת גישה לאפליקציה. זה גם יכול לעזור להם להבין אילו
שינויים בהגדרות עשויים להידרש לפני שהאפליקציה תוכל לגשת לנתונים של הארגון.
- חשוב לעקוב באופן שוטף אחרי כתובת האימייל לתמיכה במשתמשים שסיפקתם כשקבעתם את ההגדרות של OAuth Consent Screen page. אדמינים ב-Google Workspace יכולים לראות את כתובת האימייל הזו כשהם בודקים את הגישה לאפליקציה שלכם, ויכול להיות שהם יפנו אליכם עם שאלות או חששות.
שיוך הפרויקט לארגון
אם אתם משתמשים ב-Google Workspace, מומלץ מאוד ליצור את פרויקט הפיתוח בתוך משאב ארגון בחשבון Google Workspace או Cloud Identity. כך תוכלו להשתמש בתכונות ניהול לארגונים, כמו התראות חשובות, בקרת גישה וניהול מחזור החיים של הפרויקט, בלי לקשר אותו לחשבון מפתח ספציפי. אחרת, יכול להיות שיהיה קשה (או בלתי אפשרי) להעביר את הבעלות לבעלים חדש בעתיד.
כשמגדירים את פרויקט הפיתוח, יוצרים אותו בארגון או מעבירים את הפרויקטים הקיימים לארגון.
אלא אם צוין אחרת, התוכן של דף זה הוא ברישיון Creative Commons Attribution 4.0 ודוגמאות הקוד הן ברישיון Apache 2.0. לפרטים, ניתן לעיין במדיניות האתר Google Developers. Java הוא סימן מסחרי רשום של חברת Oracle ו/או של השותפים העצמאיים שלה.
עדכון אחרון: 2025-08-31 (שעון UTC).
[null,null,["עדכון אחרון: 2025-08-31 (שעון UTC)."],[[["\u003cp\u003eApps targeting external Google Accounts should consider Google Workspace admin controls and aim for wide accessibility.\u003c/p\u003e\n"],["\u003cp\u003eVerification of your app by Google, including brand and sensitive/restricted scopes, builds trust with Google Workspace admins.\u003c/p\u003e\n"],["\u003cp\u003eTo enable access, provide your app's OAuth client ID to Google Workspace admins for configuration.\u003c/p\u003e\n"],["\u003cp\u003eAssociate your developer project with a Google Workspace or Cloud Identity organization for better management and future transitions.\u003c/p\u003e\n"],["\u003cp\u003eActively monitor your support email address for inquiries from Google Workspace admins regarding your app's access.\u003c/p\u003e\n"]]],[],null,["If your app targets an\n[external user\ntype](https://support.google.com/cloud/answer/10311615#user-type-external), you might want to address the widest possible audience of Google Accounts, which\nincludes Google Accounts administered by a Google Workspace organization.\n\nGoogle Workspace administrators can use [API\naccess controls](https://support.google.com/a/answer/7281227) to enable or restrict access to Google Workspace APIs for customer-owned and\nthird-party applications and service accounts. This feature lets Google Workspace administrators\nrestrict access to only OAuth client IDs that are trusted by the organization, which reduces the\nrisk associated with third-party access to Google Services.\n\nTo reach the widest possible audience of Google Accounts and to foster trust, we recommend the\nfollowing:\n\n- Submit your app for verification by Google. If applicable, you must submit your app for [brand\n verification](/identity/protocols/oauth2/production-readiness/brand-verification), as well as [sensitive](/identity/protocols/oauth2/production-readiness/sensitive-scope-verification) and [restricted](/identity/protocols/oauth2/production-readiness/restricted-scope-verification) scopes verification. Google Workspace admins can view your app's verified status, and they might trust apps that Google verifies more than apps with an [unverified](https://support.google.com/a/answer/9352843) or unknown status.\n- Google Workspace admins can give your app's OAuth client IDs access to restricted services and the high-risk scopes within. If you include your app's OAuth client ID in your help documents, you can provide Google Workspace admins, and advocates for your app within their organizations, the information needed to give access to your app. It can also help them understand what configuration changes might be needed before your app can access an organization's data.\n- Routinely monitor your user support email address that you provide when you configure your OAuth [Consent Screen page](https://console.developers.google.com/apis/credentials/consent). Google Workspace admins can view this email address when they review your app's access, and they might reach out to you with possible questions and concerns.\n\nAssociate your project with an organization\n\nIf you are a Google Workspace user, it is strongly recommended that your developer project is\ncreated inside a [organization resource](https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy#organizations) within your [Google Workspace](https://gsuite.google.com/)\nor [Cloud Identity](https://cloud.google.com/identity) account. This allows you to\nuse [enterprise management features](https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy#benefits_of_the_organization_resource), such as\n[important notifications](https://cloud.google.com/resource-manager/docs/managing-notification-contacts), access control and project lifecycle management, without tying it\nto an individual developer account. Otherwise, it might be difficult (or impossible) to transfer\nto a new owner in the future.\n\nWhen setting up your developer project,\n[create it in\nan organization](https://cloud.google.com/resource-manager/docs/creating-managing-projects) or\n[migrate your\nexisting projects into an organization](https://cloud.google.com/resource-manager/docs/migrating-projects-billing)."]]
