Google hat Einstellungen für die App-Zugriffssteuerung eingeführt, damit Google Workspace for Education-Administratoren leichter festlegen können, wie Drittanbieter-Apps auf die Google-Daten ihrer Organisation zugreifen, wenn sich Nutzer mit ihren Google Workspace for Education-Konten anmelden. Für Entwickler von Drittanbieter-Apps sind keine Maßnahmen erforderlich. Im Folgenden finden Sie einige Best Practices, die andere Entwickler hilfreich fanden.
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.
Bei der Anmeldung fordert Ihre Anwendung grundlegende Bereiche an, z. B. das Anmeldebereichsprofil und andere anfängliche Bereiche, die für den Betrieb der Anwendung 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 Einwilligungsbildschirm.
Wenn Sie ein Google Classroom-Add-on erstellen, sollten Sie sich an die Google Workspace Marketplace-Anleitung halten, um eine vollständige Liste der für Ihre Anwendung erforderlichen OAuth-Bereiche bereitzustellen. Dies ist erforderlich, damit ein Administrator weiß, in welchen Bereichen ein Domainnutzer um seine Einwilligung gebeten wird.
Alle Apps müssen OAuth-verifiziert sein
Alle Apps, die auf Google APIs zugreifen, müssen nachweisen, dass sie ihre Identität und Absicht gemäß der Richtlinie zu Nutzerdaten der API-Dienste von Google korrekt darstellen. Wenn Sie mehrere Anwendungen verwalten, die Google APIs verwenden, achten Sie darauf, dass jede Anwendung verifiziert wurde. Administratoren können alle OAuth-Client-IDs sehen, die mit Ihrer bestätigten Marke verknüpft sind. Damit Administratoren nicht versehentlich falsche OAuth-Client-IDs konfigurieren, sollten Sie separate Google Cloud-Projekte für Tests und die Produktion verwenden und alle nicht verwendeten OAuth-Client-IDs löschen.
Die OAuth API-Bestätigung ist ein Prozess, mit dem auf Google Cloud Platform sichergestellt wird, dass Apps, die sensible oder eingeschränkte Bereiche anfordern, sicher und konform sind. Die Überprüfung trägt dazu bei, Google Cloud-Nutzer und -Daten vor unbefugtem 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 die Daten nur für die vom Nutzer autorisierten Zwecke verwenden. Apps müssen möglicherweise auch einer unabhängigen Sicherheitsbewertung unterzogen werden, um zu prüfen, ob sie den Sicherheitsanforderungen von Google Cloud entsprechen.
Die Überprüfung der OAuth API kann mehrere Wochen dauern. Sobald Ihre App bestätigt wurde, können Sie die erforderlichen Bereiche für vertrauliche oder eingeschränkte Daten anfordern.
Weitere Informationen finden Sie in den häufig gestellten Fragen zur Bestätigung über die OAuth API.
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 der OAuth-Client-IDs sicherstellen
Erkundigen Sie sich bei Ihrem Entwicklerteam, welche OAuth-Client-IDs für die Einbindung in Google OAuth verwendet werden. Verwenden Sie zwei verschiedene Google Cloud-Projekte für Tests und die Produktion, damit Administratoren besser nachvollziehen können, welche OAuth-Client-IDs konfiguriert werden müssen. Löschen Sie verworfene oder veraltete Client-IDs aus Ihren Produktionsprojekten.
CSV-Upload
Wenn Sie mehrere Kunden-IDs haben, empfehlen wir die Option 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 Anwendung ein. Änderungen, die Sie am Anwendungsnamen in der CSV-Datei vornehmen, werden in der Admin-Konsole nicht aktualisiert. |
| Typ | Ja | Entweder eine 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 in Google Play oder im App Store verwendet wird. |
| Organisationseinheit | Ja | Vom Kunden auszufüllen. Geben Sie einen Schrägstrich (/) ein, um die Einstellung für den App-Zugriff auf die gesamte Domain anzuwenden. Wenn Sie die Zugriffseinstellungen auf bestimmte Organisationseinheiten anwenden möchten, fügen Sie der Tabelle für jede Organisationseinheit eine Zeile hinzu und wiederholen Sie den App-Namen, den Typ und die ID. (z. B. „/org_unit_1/sub_unit_1“). |
| Zugriff | Ja | Entweder trusted (Vertrauenswürdig), blocked (Blockiert) oder limited (Eingeschränkt). |
OAuth-Fehler
Mit diesen neuen Administratoreinstellungen wurden zwei Fehlermeldungen eingeführt.
- Fehler 400: access_not_configure: Erhält, wenn eine OAuth-Verbindung abgelehnt wird, weil deine Anwendung nicht konfiguriert wurde.
- Fehler 400: admin_policy_enforced: Dieser Fehler wird ausgegeben, 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 die Fehlermeldung „Zugriff blockiert: Der Administrator Ihrer Einrichtung muss [Name der App] überprüfen“ angezeigt wird, müssen Sie aus der Fehlermeldung heraus den Zugriff anfordern. So kann der Administrator die Drittanbieteranwendung prüfen. Administratoren können entscheiden, ob Drittanbieteranwendungen zugelassen oder blockiert werden.