Best Practices für Entwickler im Anschluss an die Verbesserungen der Zugriffssteuerung für Drittanbieter-Apps in Google Workspace for Education

Google hat Einstellungen für die App-Zugriffssteuerung eingeführt, um die Nutzung von Google Workspace for Education zu vereinfachen. Administratoren können steuern, wie Drittanbieter-Apps auf die Dienste ihrer Organisation zugreifen Google-Daten, wenn sich Nutzer mit ihrem Google Workspace for Education-Konto anmelden. Es gibt zwar keine Erforderliche Maßnahmen von Entwicklern von Drittanbieter-Apps – im Folgenden finden Sie einige Best Practices andere Entwickler hilfreich fanden.

Inkrementelles OAuth verwenden

Sie können die inkrementelle Autorisierung verwenden, um anfangs nur die Bereiche anzufordern. erforderlich, um Ihre App zu starten, und fordern Sie dann zusätzliche Bereiche als neue Berechtigungen an sind erforderlich. Der App-Kontext identifiziert dann den Grund für die Anfrage an den Nutzer.

Bei der Anmeldung fordert Ihre App grundlegende Bereiche an, z. B. das Profil für den Anmeldebereich und andere anfängliche Bereiche, die Ihre App für den Betrieb benötigt. Später, wenn der Nutzer um eine Aktion auszuführen, die zusätzliche Bereiche erfordert, fordert Ihre App diese und der Nutzer autorisiert nur die neuen Umfänge Bildschirm.

Beim Erstellen eines Add-ons für Google Classroom sollten Sie die Google Workspace Marketplace-Anleitung zur Bereitstellung einer vollständigen Liste der OAuth-Bereiche, die Ihre Anwendung erfordert. Dies ist notwendig, damit ein Administrator versteht, in welchen Bereichen ein Domainnutzer eingewilligt hat.

Achten Sie darauf, dass alle Apps OAuth-Verifiziert sind

Alle Apps, die auf Google APIs zugreifen, müssen bestätigen, dass sie die Identität und Absicht gemäß den Nutzerdaten der API-Dienste von Google Richtlinie. Wenn Sie mehrere Apps verwalten, die Google APIs verwenden, achten Sie darauf, dass alle App wurde bestätigt. Administratoren können alle OAuth-Client-IDs sehen, die mit Ihrer bestätigten Marke. Damit Administratoren vermeiden können, falsch konfigurierte OAuth-Client-IDs, zum Testen und für die Produktion separate Google Cloud-Projekte verwenden und löschen Sie alle OAuth-Client-IDs, die nicht verwendet werden.

Mit der OAuth API-Überprüfung stellt die Google Cloud Platform sicher, dass Apps, die vertrauliche oder eingeschränkte Bereiche anfordern, sicher und konform sind. Die Überprüfung trägt dazu bei, Google Cloud-Nutzer und -Daten vor unautorisierten Zugriff.

Apps, die vertrauliche oder eingeschränkte Bereiche anfordern, müssen die Google API erfüllen Richtlinie zu Nutzerdaten für Dienste. Gemäß dieser Richtlinie müssen Apps Nutzerdaten schützen und Sie dürfen die Daten nur zu den Zwecken verwenden, die der Nutzer autorisiert hat. Apps können auch eine unabhängige Sicherheitsprüfung durchführen, Sicherheitsanforderungen von Google Cloud

Hinweis: Die Überprüfung der OAuth API kann mehrere Wochen dauern. abgeschlossen ist. Sobald Ihre App bestätigt wurde, können Sie die vertrauliche oder eingeschränkten Bereichen, die Sie benötigen.

Weitere Informationen finden Sie in den häufig gestellten Fragen zur OAuth API-Bestätigung.

Mehrere OAuth-Client-IDs verarbeiten

Ein Google Cloud-Projekt kann mehrere OAuth-Client-IDs haben, für die möglicherweise einen Domain-Administrator bitten, Ihren Zugriff mehrmals zu konfigurieren.

Genauigkeit der OAuth-Client-IDs sicherstellen

Erkundigen Sie sich bei Ihrem Entwicklerteam, welche OAuth-Client-IDs verwendet werden für die Integration in Google OAuth verwendet. Zwei verschiedene Google Cloud-Projekte für Tests und Produktion, um Administratoren dabei zu helfen zu verstehen, welcher OAuth-Client IDs, die konfiguriert werden sollen. Löschen Sie alle eingestellten oder veralteten Client-IDs aus Ihrem von Produktionsprojekten.

CSV-Upload

Wenn Sie mehrere Client-IDs haben, empfehlen wir den CSV-Bulk-Upload. , mit der 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 an Der App-Name in der CSV-Datei wird im Bereich „Verwaltung“ .
Typ Ja Entweder eine Webanwendung, Android oder iOS.
ID Ja Geben Sie bei Web-Apps die OAuth-Client-ID ein, die an den .

Geben Sie für Android- und iOS-Apps die OAuth-Client-ID oder die Paket-ID, die die App bei Google Play verwendet, oder Apple App Store herunter.
Organisationseinheit Ja Vom Kunden auszufüllen.

Geben Sie einen Schrägstrich („/“) ein, um den App-Zugriff anzuwenden für die gesamte Domain festlegen. Zugriffseinstellungen anwenden Organisationseinheiten hinzugefügt haben, fügen Sie dem Tabelle für jede Organisationseinheit, wiederholen Sie den App-Namen, Typ und ID. (z. B. '/org_unit_1/sub_unit_1').
Zugriff Ja Entweder Vertrauenswürdig, Blockiert oder Eingeschränkt.

OAuth-Fehler

Bei diesen neuen Administrator-Steuerelementen wurden zwei Fehlermeldungen eingeführt.

  • Fehler 400: access_not_configure: empfangen, wenn eine OAuth-Verbindung hergestellt wurde abgelehnt, da Ihre App nicht konfiguriert wurde.
  • Fehler 400: admin_policy_enforced – wird angezeigt, wenn eine OAuth-Verbindung hergestellt wurde. abgelehnt, da der Administrator Ihre Anwendung blockiert hat.

Nutzer unter 18 Jahren

Administratoren können den Zugriff auf nicht konfigurierte Drittanbieter-Apps für Nutzer verwalten. unter 18 Jahren. Wenn bei einem Nutzer der Fehler "Zugriff blockiert: Ihr muss der Administrator der Einrichtung [App-Name] überprüfen.“ Sie müssen aus der Fehlermeldung heraus den Zugriff anfordern. Dadurch kann ihr Administrator die Drittanbieter-App überprüfen. Administratoren können entscheiden, ob sie Anwendungen von Drittanbietern zu blockieren.