Google hat Einstellungen für die App-Zugriffssteuerung eingeführt, um Google Workspace for Education-Administratoren die Kontrolle des Zugriffs von Drittanbieter-Apps auf die Google-Daten ihrer Organisation zu erleichtern, wenn sich Nutzer mit ihren Google Workspace for Education-Konten anmelden. Von Entwicklern von Drittanbieter-Apps sind keine Maßnahmen erforderlich. Im Folgenden finden Sie jedoch einige Best Practices, die andere Entwickler als hilfreich empfunden haben.
Inkrementelles OAuth verwenden
Mit der inkrementellen Autorisierung können Sie anfangs nur die Bereiche anfordern, die zum Starten Ihrer App erforderlich sind, und dann zusätzliche Bereiche anfordern, wenn neue Berechtigungen erforderlich sind. Der App-Kontext gibt dann den Grund für die Anfrage an den Nutzer an.
Beim Anmelden fordert Ihre App grundlegende Bereiche wie den Anmeldebereich „profile“ und andere anfängliche Bereiche an, die für den Betrieb der App erforderlich sind. Wenn der Nutzer später eine Aktion ausführen möchte, für die zusätzliche Bereiche erforderlich sind, fordert Ihre App diese zusätzlichen Bereiche an und der Nutzer autorisiert nur die neuen Bereiche über einen Zustimmungsbildschirm.
Wenn Sie ein Google Classroom-Add-on entwickeln, sollten Sie die Richtlinien für den Google Workspace Marketplace befolgen und eine vollständige Liste der von Ihrer App benötigten OAuth-Bereiche bereitstellen. Dies ist erforderlich, damit ein Administrator nachvollziehen kann, für welche Bereiche ein Domainnutzer um Einwilligung gebeten wird.
Sicherstellen, dass alle Apps OAuth-verifiziert sind
Alle Apps, die auf Google-APIs zugreifen, müssen bestätigen, dass sie ihre Identität und Absicht gemäß der Richtlinie zu Nutzerdaten der Google API-Dienste korrekt darstellen. Wenn Sie mehrere Apps verwalten, die Google-APIs verwenden, muss jede App überprüft werden. Administratoren können alle OAuth-Client-IDs sehen, die mit Ihrer bestätigten Marke verknüpft sind. Um zu vermeiden, dass Administratoren falsche OAuth-Client-IDs konfigurieren, sollten Sie separate Google Cloud-Projekte für Tests und die Produktion verwenden und alle OAuth-Client-IDs löschen, die nicht verwendet werden.
Die OAuth-API-Bestätigung ist ein Prozess, mit dem Google Cloud Platform sicherstellt, dass Apps, die sensible oder eingeschränkte Bereiche anfordern, sicher und konform sind. Der Bestätigungsprozess trägt dazu bei, Google Cloud-Nutzer und ‑Daten vor unberechtigtem Zugriff zu schützen.
Apps, die vertrauliche oder eingeschränkte Bereiche anfordern, müssen der Nutzerdatenrichtlinie der Google API-Dienste entsprechen. Gemäß dieser Richtlinie müssen Apps Nutzerdaten schützen und dürfen sie nur für die Zwecke verwenden, für die der Nutzer seine Einwilligung erteilt hat. Apps müssen möglicherweise auch einer unabhängigen Sicherheitsbewertung unterzogen werden, um zu bestätigen, dass sie die Sicherheitsanforderungen von Google Cloud erfüllen.
Die Überprüfung von OAuth-APIs kann mehrere Wochen dauern. Sobald Ihre App bestätigt wurde, können Sie die vertraulichen oder eingeschränkten Bereiche anfordern, die Sie benötigen.
Weitere Informationen finden Sie in den FAQs zur OAuth API-Überprüfung.
Mehrere OAuth-Client-IDs verarbeiten
Ein Google Cloud-Projekt kann mehrere OAuth-Client-IDs haben. In diesem Fall muss ein Domainadministrator Ihren Zugriff möglicherweise mehrmals konfigurieren.
OAuth-Client-IDs müssen korrekt sein
Fragen Sie Ihr Entwicklungsteam, welche OAuth-Client-IDs für die Integration mit Google OAuth verwendet werden. Verwenden Sie zwei verschiedene Google Cloud-Projekte für Tests und Produktion, damit Administratoren wissen, welche OAuth-Client-IDs konfiguriert werden müssen. Löschen Sie alle veralteten oder nicht mehr unterstützten Client-IDs aus Ihren Produktionsprojekten.
CSV-Upload
Wenn Sie mehrere Client-IDs haben, empfehlen wir, die Option CSV-Bulk-Upload zu verwenden, damit Administratoren alle Ihre Apps schnell konfigurieren können.
Es gibt folgende Felder:
| Feld | Erforderlich | Hinweise |
|---|---|---|
| App-Name | Nein | Geben Sie den Namen der App ein. Änderungen am App-Namen in der CSV-Datei werden nicht in der Admin-Konsole aktualisiert. |
| Typ | Ja | Eine der folgenden Optionen: Webanwendung, Android oder iOS. |
| ID | Ja | Geben Sie für Webanwendungen die OAuth-Client-ID ein, die an die Anwendung ausgegeben wird. Geben Sie für Android- und iOS-Apps die OAuth-Client-ID oder die Paket-ID ein, die die App in Google Play oder im App Store verwendet. |
| Organisationseinheit | Ja | Vom Kunden auszufüllen. Geben Sie einen Schrägstrich ('/') ein, um die Einstellung für den App-Zugriff auf Ihre gesamte Domain anzuwenden. Wenn Sie die Zugriffseinstellungen auf bestimmte Organisationseinheiten anwenden möchten, fügen Sie für jede Organisationseinheit eine Zeile in die Tabelle ein und wiederholen Sie den App-Namen, den Typ und die ID. Beispiel: „/org_unit_1/sub_unit_1“. |
| Zugriff | Ja | Entweder trusted (Vertrauenswürdig), blocked (Blockiert) oder limited (Eingeschränkt). |
OAuth-Fehler
Mit diesen neuen Administratorsteuerungen wurden zwei Fehlermeldungen eingeführt.
- Fehler 400: access_not_configured – wird empfangen, wenn eine OAuth-Verbindung abgelehnt wird, weil Ihre App nicht konfiguriert wurde.
- Fehler 400: admin_policy_enforced – wird angezeigt, wenn eine OAuth-Verbindung abgelehnt wird, weil der Administrator Ihre Anwendung blockiert hat.
Nutzer unter 18 Jahren
Administratoren können den Zugriff auf nicht konfigurierte Drittanbieter-Apps für Nutzer unter 18 Jahren verwalten. Wenn einem Nutzer die Fehlermeldung „Zugriff blockiert: Der Administrator Ihrer Einrichtung muss [Name der App] überprüfen“ angezeigt wird, muss er aus der Fehlermeldung heraus den Zugriff anfordern. Dadurch kann der Administrator die Drittanbieteranwendung prüfen. Administratoren können entscheiden, ob Drittanbieteranwendungen zugelassen oder blockiert werden.