Google hat Einstellungen für die App-Zugriffssteuerung eingeführt, um Google Workspace for Education Administratoren die Kontrolle darüber zu erleichtern, wie Drittanbieter-Apps auf die Google-Daten ihrer Organisationen zugreifen, 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 sich für andere Entwickler als hilfreich erwiesen haben.
Inkrementelles OAuth verwenden
Mit der inkrementellen Autorisierung können Sie zunächst nur die Bereiche anfordern, die zum Starten Ihrer App erforderlich sind. Anschließend können Sie zusätzliche Bereiche anfordern, wenn neue Berechtigungen erforderlich sind. Der App-Kontext gibt dem Nutzer dann den Grund für die Anfrage an.
Bei der Anmeldung fordert Ihre App grundlegende Bereiche an, z. B. den Anmeldebereich „Profil“ und andere Bereiche, die für den Betrieb Ihrer 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. Der Nutzer autorisiert die neuen Bereiche dann über einen Zustimmungsbildschirm.
Wenn Sie ein Google Classroom-Add-on erstellen, sollten Sie die Google Workspace Marketplace Richtlinien befolgen und eine vollständige Liste der OAuth-Bereiche angeben, die Ihre App benötigt. So kann ein Administrator nachvollziehen, zu welchen Bereichen ein Domainnutzer seine Einwilligung geben muss.
Sicherstellen, dass alle Apps OAuth-bestätigt sind
Alle Apps, die auf Google APIs zugreifen, müssen bestätigen, dass sie ihre Identität und Absicht gemäß der Nutzerdatenrichtlinie für Google API-Dienste korrekt darstellen. Wenn Sie mehrere Apps verwalten, die Google APIs verwenden, müssen Sie sicherstellen, dass jede App bestätigt wurde. Administratoren können alle OAuth-Client-IDs sehen, die mit Ihrer bestätigten Marke verknüpft sind. Damit Administratoren keine falschen OAuth-Client-IDs konfigurieren, sollten Sie separate Google Cloud-Projekte für Tests und die Produktion 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 vertrauliche oder eingeschränkte Bereiche anfordern, sicher und konform sind. Der Bestätigungsprozess trägt dazu bei, Google Cloud-Nutzer und -Daten vor unbefugtem Zugriff zu schützen.
Apps, die vertrauliche oder eingeschränkte Zugriffsbereiche anfordern, müssen der Richtlinie zu Nutzerdaten für 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 gegeben hat. Apps müssen möglicherweise auch eine unabhängige Sicherheitsprüfung durchlaufen, um zu bestätigen, dass sie die Sicherheitsanforderungen von Google Cloud erfüllen.
Die OAuth API-Bestätigung kann mehrere Wochen dauern. Sobald Ihre App bestätigt wurde, können Sie die erforderlichen vertraulichen oder eingeschränkten Bereiche anfordern.
Weitere Informationen finden Sie in den FAQs zur OAuth API-Bestätigung.
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.
Genauigkeit von OAuth-Client-IDs sicherstellen
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 die Produktion, damit Administratoren nachvollziehen können, welche OAuth-Client IDs konfiguriert werden müssen. Löschen Sie alle veralteten oder nicht mehr aktuellen Client-IDs aus Ihren Produktionsprojekten.
CSV-Upload
Wenn Sie mehrere Client-IDs haben, empfehlen wir die Option für den CSV-Bulk-Upload , 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 | Entweder Webanwendung, Android oder iOS. |
| ID | Ja | Geben Sie für Web-Apps die OAuth-Client-ID ein, die der Anwendung zugewiesen wurde. Geben Sie für Android- und iOS-Apps die OAuth-Client-ID oder die Paket-ID ein, die in Google Play oder im App Store verwendet wird. |
| Organisationseinheit | Ja | Muss vom Kunden ausgefüllt werden. Geben Sie einen Schrägstrich (/) ein, um die Einstellung für den App-Zugriff auf Ihre gesamte Domain anzuwenden. Wenn Sie 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 Vertrauenswürdig , Blockiert oder Eingeschränkt. |
OAuth-Fehler
Mit diesen neuen Administratoreinstellungen wurden zwei Fehlermeldungen eingeführt.
- Fehler 400: access_not_configured : Wird angezeigt, 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 ein Nutzer die Fehlermeldung „Zugriff blockiert: Der Administrator Ihrer Einrichtung muss [App-Name] überprüfen“ erhält, muss er aus der Fehlermeldung heraus den Zugriff anfordern. So kann der Administrator die Drittanbieter-App überprüfen. Administratoren können entscheiden, ob sie Drittanbieter-Apps zulassen oder blockieren.