Detaillierte Berechtigungen

Übersicht

Mit detaillierten Berechtigungen haben Nutzer mehr Kontrolle darüber, welche Kontodaten sie für die einzelnen Apps freigeben. Das bietet sowohl Nutzern als auch Entwicklern Vorteile, da mehr Kontrolle, Transparenz und Sicherheit gewährleistet werden. In dieser Anleitung erfahren Sie, welche Änderungen und Schritte erforderlich sind, um Ihre Anwendungen für die Verwendung detaillierter Berechtigungen zu aktualisieren.

Was sind detaillierte Berechtigungen?

Stellen Sie sich vor, Sie entwickeln eine Produktivitäts-App, die sowohl E‑Mail- als auch Kalenderbereiche anfordert. Ihre Nutzer möchten Ihre Anwendung möglicherweise nur für Google Kalender, nicht aber für Gmail verwenden. Mit detaillierten OAuth Berechtigungen können Nutzer nur die Berechtigung für Google Kalender erteilen, nicht aber für Gmail. Wenn Nutzer den Zugriff auf bestimmte Daten gewähren, wird die Datenexposition minimiert, das Vertrauen gestärkt und Nutzer erhalten mehr Kontrolle über ihr digitales Leben. Es ist wichtig, dass Ihre Anwendung für solche Szenarien konzipiert ist.

Wenn mehr als ein Bereich angefordert wird, der nicht für die Anmeldung erforderlich ist

Bei Anwendungen, die sowohl Bereiche für die Anmeldung als auch andere Bereiche anfordern, sehen Nutzer zuerst die Zustimmungsseite für Bereiche für die Anmeldung (email, profile, und openid). Nachdem Nutzer zugestimmt haben, ihre grundlegenden Identitätsinformationen (Name, E‑Mail-Adresse und Profilbild) freizugeben, sehen sie einen detaillierten Zustimmungsbildschirm für die anderen Bereiche. In diesem Fall muss die Anwendung prüfen, welche Bereiche von den Nutzern gewährt wurden. Sie kann nicht davon ausgehen, dass Nutzer alle angeforderten Bereiche gewähren. Im folgenden Beispiel fordert die Webanwendung alle drei Bereiche für die Anmeldung und einen Google Drive-Bereich an, der nicht für die Anmeldung erforderlich ist. Nachdem Nutzer den Bereichen für die Anmeldung zugestimmt haben, sehen sie den detaillierten Zustimmungsbildschirm für die Google Drive-Berechtigung:

Ein detaillierter Zustimmungsbildschirm wird Nutzern angezeigt, wenn Anwendungen mehr als einen Bereich anfordern, der nicht für die Anmeldung erforderlich ist. Nutzer können auswählen, welche Berechtigungen sie erteilen möchten, um sie für die Anwendung freizugeben. Das folgende Beispiel zeigt einen detaillierten Zustimmungsbildschirm, auf dem der Zugriff auf Gmail-Nachrichten und Google Kalender-Daten des Nutzers angefordert wird:

Bei Anwendungen, die nur Bereiche für die Anmeldung anfordern (email, profile, und openid), ist der detaillierte Zustimmungsbildschirm nicht relevant. Nutzer genehmigen oder lehnen die gesamte Anmeldeanfrage ab. Wenn Anwendungen also nur Bereiche für die Anmeldung anfordern (einen, zwei oder alle drei), ist der detaillierte Zustimmungsbildschirm nicht relevant.

Bei Anwendungen, die nur einen Bereich anfordern, der nicht für die Anmeldung erforderlich ist, ist der detaillierte Zustimmungsbildschirm nicht relevant. Nutzer genehmigen oder lehnen die gesamte Anfrage ab. Auf dem Zustimmungsbildschirm ist kein Kästchen zu sehen. In der folgenden Tabelle ist zusammengefasst, wann der detaillierte Zustimmungsbildschirm angezeigt wird.

Anzahl der Bereiche für die Anmeldung	Anzahl der Bereiche, die nicht für die Anmeldung erforderlich sind	Detaillierter Zustimmungsbildschirm
1-3	0	Nicht zutreffend
1-3	1+	Zutreffend
0	1	Nicht zutreffend
0	2+	Zutreffend

Feststellen, ob Ihre Anwendungen betroffen sind

Überprüfen Sie alle Bereiche in Ihrer Anwendung, in denen Google OAuth 2.0-Autorisierungsendpunkte für Berechtigungsanfragen verwendet werden. Achten Sie besonders auf Bereiche, in denen mehrere Bereiche angefordert werden, da dadurch detaillierte Zustimmungsbildschirme für Nutzer aktiviert werden. In solchen Fällen muss Ihr Code den Fall berücksichtigen, dass Nutzer nur einige der Bereiche autorisieren.

Feststellen, ob Ihre Anwendung mehrere Bereiche verwendet

Prüfen Sie Ihren App-Code oder den ausgehenden Netzwerkaufruf, um festzustellen, ob die Google OAuth 2.0 Autorisierungsanfragen Ihrer App dazu führen, dass der detaillierte Zustimmungsbildschirm angezeigt wird.

Anwendungscode prüfen

Überprüfen Sie die Bereiche Ihres Anwendungscodes, in denen Sie Google OAuth Autorisierungsendpunkte aufrufen, um Berechtigungen von Nutzern anzufordern. Wenn Sie eine der Google API Clientbibliotheken verwenden, können Sie oft in den Schritten zur Client Initialisierung sehen, welche Bereiche Ihre Anwendung anfordert. Einige Beispiele finden Sie im folgenden Abschnitt. In der Dokumentation der SDKs, die Ihre Anwendung für Google OAuth 2.0 verwendet, können Sie feststellen, ob Ihre Anwendung betroffen ist. Verwenden Sie dazu die Anleitung in den folgenden Beispielen als Referenz.

Google Identity Services

Das folgende Code-Snippet der Google Identity Services JavaScript-Bibliothek initialisiert den TokenClient mit mehreren Bereichen, die nicht für die Anmeldung erforderlich sind. Der detaillierte Zustimmungsbildschirm wird angezeigt, wenn die Web App eine Autorisierung von Nutzern anfordert.

const client = google.accounts.oauth2.initTokenClient({
  client_id: 'YOUR_CLIENT_ID',
  scope: 'https://www.googleapis.com/auth/calendar.readonly \
  https://www.googleapis.com/auth/contacts.readonly',
  callback: (response) => {
    ...
  },
});

Python

Im folgenden Code-Snippet wird das google-auth-oauthlib.flow Modul verwendet, um die Autorisierungsanfrage zu erstellen. Der scope Parameter enthält zwei Bereiche, die nicht für die Anmeldung erforderlich sind. Der detaillierte Zustimmungsbildschirm wird angezeigt, wenn die Web anwendung eine Autorisierung von Nutzern anfordert.

import google.oauth2.credentials
import google_auth_oauthlib.flow

# Use the client_secret.json file to identify the application requesting
# authorization. The client ID (from that file) and access scopes are required.
flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file(
    'client_secret.json',
    scopes=['https://www.googleapis.com/auth/calendar.readonly',
                    'https://www.googleapis.com/auth/contacts.readonly'])

Node.js

Das folgende Code-Snippet erstellt ein google.auth.OAuth2-Objekt, das die Parameter in der Autorisierungsanfrage definiert. Der Parameter scope enthält zwei Bereiche, die nicht für die Anmeldung erforderlich sind. Der detaillierte Zustimmungsbildschirm wird angezeigt, wenn die Web-App eine Autorisierung von Nutzern anfordert.

const {google} = require('googleapis');

/**
  * To use OAuth2 authentication, we need access to a CLIENT_ID, CLIENT_SECRET, AND REDIRECT_URI
  * from the client_secret.json file. To get these credentials for your application, visit
  * https://console.cloud.google.com/apis/credentials.
  */
const oauth2Client = new google.auth.OAuth2(
  YOUR_CLIENT_ID,
  YOUR_CLIENT_SECRET,
  YOUR_REDIRECT_URL
);

// Access scopes for read-only Calendar and Contacts.
const scopes = [
  'https://www.googleapis.com/auth/calendar.readonly',
  'https://www.googleapis.com/auth/contacts.readonly']
];

// Generate a url that asks permissions
const authorizationUrl = oauth2Client.generateAuthUrl({
  // 'online' (default) or 'offline' (gets refresh_token)
  access_type: 'offline',
  /** Pass in the scopes array defined above.
    * Alternatively, if only one scope is needed, you can pass a scope URL as a string */
  scope: scopes,
  // Enable incremental authorization. Recommended as best practices.
  include_granted_scopes: true
});

Ausgehenden Netzwerkaufruf prüfen

Die Methode zum Prüfen von Netzwerkaufrufen variiert je nach Clienttyp Ihrer Anwendung.

Webanwendung - Netzwerkaktivität in Chrome prüfen
Android - Netzwerkverkehr mit dem Netzwerkprüfer prüfen
Chrome-Apps
- Rufen Sie die Seite mit den Chrome-Erweiterungen auf.
- Klicken Sie rechts oben auf der Seite mit den Erweiterungen auf das Kästchen Entwicklermodus.
- Wählen Sie die Erweiterung aus, die Sie überwachen möchten.
- Klicken Sie auf der Seite mit den Erweiterungen im Bereich Ansichten prüfen auf den Link Hintergrundseite.
- Ein Pop-up-Fenster mit den Entwicklertools wird geöffnet, in dem Sie den Netzwerkverkehr auf dem Tab Netzwerk überwachen können.
iOS - HTTP-Traffic mit Instruments analysieren
Desktop-Apps : Verw101}enden Sie ein Tool zur Netzwerkerfassung, das für das Betriebssystem verfügbar ist, für das die App entwickelt wurde.

Suchen Sie beim Prüfen von Netzwerkaufrufen nach Anfragen, die an die Google OAuth Autorisierungsendpunkte gesendet wurden, und prüfen Sie den scope Parameter.

Diese Werte führen dazu , dass der detaillierte Zustimmungsbildschirm angezeigt wird.

Der Parameter scope enthält Bereiche für die Anmeldung und andere Bereiche.

Die folgende Beispielanfrage enthält alle drei Bereiche für die Anmeldung und einen Bereich, der nicht für die Anmeldung erforderlich ist, um die Metadaten der Google Drive-Dateien des Nutzers aufzurufen:

https://accounts.google.com/o/oauth2/v2/auth?
access_type=offline&
scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile%20openid%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fdrive.metadata.readonly&
include_granted_scopes=true&
response_type=code&
redirect_uri=YOUR_REDIRECT_URL&
client_id=YOUR_CLIENT_ID

Der Parameter scope enthält mehr als einen Bereich, der nicht für die Anmeldung erforderlich ist.

Die folgende Beispielanfrage enthält zwei Bereiche, die nicht für die Anmeldung erforderlich sind, um die Google Drive Metadaten des Nutzers aufzurufen und bestimmte Google Drive-Dateien zu verwalten:

https://accounts.google.com/o/oauth2/v2/auth?
access_type=offline&
scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fdrive.metadata.readonly%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fdrive.file&
include_granted_scopes=true&
response_type=code&
redirect_uri=YOUR_REDIRECT_URL&
client_id=YOUR_CLIENT_ID

Best Practices für den Umgang mit detaillierten Berechtigungen

Wenn Sie feststellen, dass Ihre Anwendung für die Verwendung detaillierter Berechtigungen aktualisiert werden muss, sollten Sie die erforderlichen Änderungen an Ihrem Code vornehmen, um die Zustimmung für mehrere Bereiche richtig zu verarbeiten. Alle Anwendungen sollten die folgenden Best Practices einhalten:

Lesen Sie die Richtlinie zu Nutzerdaten für Google API-Dienste und achten Sie darauf, dass Sie sie einhalten.
Fordern Sie bestimmte Bereiche an, die für eine Aufgabe erforderlich sind. Sie müssen die Google OAuth 2.0-Richtlinie einhalten, die besagt, dass Sie nur die Bereiche anfordern dürfen, die Sie benötigen. Sie sollten bei der Anmeldung nicht mehrere Bereiche anfordern, es sei denn, dies ist für die Hauptfunktion Ihrer App unbedingt erforderlich. Wenn Sie mehrere Bereiche zusammenfassen, insbesondere für Erstnutzer, die mit den Funktionen Ihrer Anwendung's Funktionen nicht vertraut sind, kann es für sie schwierig sein, die Notwendigkeit dieser Berechtigungen zu verstehen. Das kann zu Warnungen führen und Nutzer davon abhalten, Ihre Anwendung weiter zu verwenden.
Begründen Sie die Autorisierungsanfrage, bevor Sie sie stellen. Erklären Sie deutlich, warum Ihre Anwendung die angeforderte Berechtigung benötigt, was Sie mit den Daten des Nutzers tun und wie der Nutzer davon profitiert, wenn er die Anfrage genehmigt. Unsere Untersuchungen zeigen, dass diese Erklärungen das Vertrauen und die Interaktion der Nutzer erhöhen.
Verwenden Sie die inkrementelle Autorisierung wenn Ihre Anwendung Bereiche anfordert, damit Sie nicht mehrere Zugriffstokens verwalten müssen.
Prüfen Sie , welche Bereiche Nutzer gewährt haben. Wenn Sie mehrere Bereiche gleichzeitig anfordern, gewähren Nutzer möglicherweise nicht alle Bereiche, die Ihre App anfordert. Ihre App sollte immer prüfen, welche Bereiche vom Nutzer gewährt wurden, und alle Ablehnungen von Bereichen verarbeiten, indem sie die entsprechenden Funktionen deaktiviert. Halten Sie sich an die Google OAuth 2.0-Richtlinien zu r Verarbeitung der Zustimmung für mehrere Bereiche und fordern Sie den Nutzer erst dann wieder zur Zustimmung auf, wenn er eindeutig angegeben hat, dass er die bestimmte Funktion verwenden möchte, für die der Bereich erforderlich ist.

Anwendung für die Verwendung detaillierter Berechtigungen aktualisieren

Android-Anwendungen

Lesen Sie die Dokumentation der SDKs, die Sie für die Interaktion mit Google OAuth 2.0 verwenden, und aktualisieren Sie Ihre Anwendung für die Verwendung detaillierter Berechtigungen gemäß den Best Practices.

Wenn Sie auth.api.signin SDK von Play Services für die Interaktion mit Google OAuth 2.0 verwenden, können Sie mit der requestPermissions Funktion die kleinste Gruppe der erforderlichen Bereiche anfordern und mit der hasPermissions Funktion prüfen, welche Bereiche der Nutzer bei der Anforderung detaillierter Berechtigungen gewährt hat.

Chrome-Erweiterungsanwendungen

Sie sollten die Chrome Identity API verwenden, um gemäß den Best Practices mit Google OAuth 2.0 zu arbeiten.

Das folgende Beispiel zeigt, wie Sie detaillierte Berechtigungen richtig verarbeiten.

manifest.json

In der Beispielmanifestdatei werden zwei Bereiche deklariert, die nicht für die Anmeldung der Chrome-Erweiterungsanwendung erforderlich sind.

{
  "name": "Example Chrome extension application",
  ...
  "permissions": [
      "identity"
    ],
  "oauth2" : {
      "client_id": "YOUR_CLIENT_ID",
      "scopes":["https://www.googleapis.com/auth/calendar.readonly",
                "https://www.googleapis.com/auth/contacts.readonly"]
  }
}

Falscher Ansatz

Alles oder nichts

Nutzer klicken auf die Schaltfläche, um den Autorisierungsprozess zu starten. Das Code-Snippet geht davon aus, dass Nutzern ein Zustimmungsbildschirm mit der Option „Alles oder nichts“ für die beiden Bereiche angezeigt wird, die in der Datei manifest.json angegeben sind. Es wird nicht geprüft, welche Bereiche Nutzer gewährt haben.

oauth.js

...
document.querySelector('button').addEventListener('click', function () {
  chrome.identity.getAuthToken({ interactive: true },
      function (token) {
          if (token === undefined) {
            // User didn't authorize both scopes.
            // Updating the UX and application accordingly
            ...
          } else {
            // User authorized both or one of the scopes.
            // It neglects to check which scopes users granted and assumes users granted all scopes.

            // Calling the APIs, etc.
            ...
          }
      });
});

Richtiger Ansatz

Kleinste Bereiche

Kleinste Gruppe der erforderlichen Bereiche auswählen

In diesem Beispiel wird davon ausgegangen, dass die beiden in der manifest.json Datei deklarierten Bereiche die kleinste Gruppe der erforderlichen Bereiche sind. Die Datei oauth.js verwendet die Chrome Identity API, um den Autorisierungsprozess mit Google zu starten. Sie sollten detaillierte Berechtigungen aktivieren, damit Nutzer mehr Kontrolle darüber haben, welche Berechtigungen sie Ihrer Anwendung erteilen. Ihre Anwendung sollte die Antwort von Nutzern richtig verarbeiten, indem sie prüft, welche Bereiche Nutzer autorisieren.

oauth.js

...
document.querySelector('button').addEventListener('click', function () {
  chrome.identity.getAuthToken({ interactive: true, enableGranularPermissions: true },
      function (token, grantedScopes) {
          if (token === undefined) {
            // User didn't authorize any scope.
            // Updating the UX and application accordingly
            ...
          } else {
            // User authorized the request. Now, check which scopes were granted.
            if (grantedScopes.includes('https://www.googleapis.com/auth/calendar.readonly'))
            {
              // User authorized Calendar read permission.
              // Calling the APIs, etc.
              ...
            }
            else
            {
              // User didn't authorize Calendar read permission.
              // Update UX and application accordingly
              ...
            }

            if (grantedScopes.includes('https://www.googleapis.com/auth/contacts.readonly'))
            {
              // User authorized Contacts read permission.
              // Calling the APIs, etc.
              ...
            }
            else
            {
              // User didn't authorize Contacts read permission.
              // Update UX and application accordingly
              ...
            }
          }
      });
});

iOS-, iPadOS- und macOS-Anwendungen

Wenn Sie die Google Sign-In for iOS and macOS-Bibliothek zur Interaktion mit Google OAuth 2.0 verwenden, sollten Sie die Dokumentation zur Verarbeitung detaillierter Berechtigungen lesen.

Webanwendungen

Serverseitiger (Offline-)Zugriff

Für den serverseitigen (Offline-)Zugriffsmodus müssen Sie Folgendes tun:

Richten Sie einen Server ein und definieren Sie einen öffentlich zugänglichen Endpunkt, um den Autorisierungscode zu empfangen.
Konfigurieren Sie den Weiterleitungs-URI Ihres öffentlichen Endpunkts auf der Seite „Clients“ in der Google Cloud Console.

Das folgende Code-Snippet zeigt ein NodeJS-Beispiel, in dem zwei Bereiche angefordert werden, die nicht für die Anmeldung erforderlich sind. Nutzer sehen den detaillierten Zustimmungsbildschirm.

Falscher Ansatz

Alles oder nichts

Nutzer werden zur Autorisierungs-URL weitergeleitet. Das Code-Snippet geht davon aus, dass Nutzern ein Zustimmungsbildschirm mit der Option „Alles oder nichts“ für die beiden Bereiche angezeigt wird, die im scopes Array angegeben sind. Es wird nicht geprüft, welche Bereiche Nutzer gewährt haben.

main.js

...
const oauth2Client = new google.auth.OAuth2(
  YOUR_CLIENT_ID,
  YOUR_CLIENT_SECRET,
  YOUR_REDIRECT_URL
);

// Access scopes for two non-Sign-In scopes - Google Calendar and Contacts
const scopes = [
  'https://www.googleapis.com/auth/contacts.readonly',
  'https://www.googleapis.com/auth/calendar.readonly'
];

// Generate a url that asks permissions for the Google Calendar and Contacts scopes
const authorizationUrl = oauth2Client.generateAuthUrl({
  // 'online' (default) or 'offline' (gets refresh_token)
  access_type: 'offline',
  // Pass in the scopes array defined above
  scope: scopes,
  // Enable incremental authorization. Recommended as best practices.
  include_granted_scopes: true
});

async function main() {
  const server = http.createServer(async function (req, res) {
    // Example on redirecting user to Google OAuth 2.0 server.
    if (req.url == '/') {
      res.writeHead(301, { "Location": authorizationUrl });
    }
    // Receive the callback from Google OAuth 2.0 server.
    if (req.url.startsWith('/oauth2callback')) {
      // Handle the Google OAuth 2.0 server response
      let q = url.parse(req.url, true).query;

      if (q.error) {
        // User didn't authorize both scopes.
        // Updating the UX and application accordingly
        ...
      } else {
        // User authorized both or one of the scopes.
        // It neglects to check which scopes users granted and assumes users granted all scopes.

        // Get access and refresh tokens (if access_type is offline)
        let { tokens } = await oauth2Client.getToken(q.code);
        // Calling the APIs, etc.
        ...
      }
    }
    res.end();
  }).listen(80);
}

Richtiger Ansatz

Kleinster Bereich

Kleinste Gruppe der erforderlichen Bereiche auswählen

Die Anwendung sollte nur die kleinste Gruppe der erforderlichen Bereiche anfordern. Es wird empfohlen dass Ihre Anwendung jeweils einen Bereich anfordert, wenn er für die Ausführung einer Aufgabe erforderlich ist. Wenn Ihre Anwendung Bereiche anfordert, sollte sie die inkrementelle Autorisierung verwenden, damit Sie nicht mehrere Zugriffstokens verwalten müssen.

Wenn Ihre Anwendung mehrere Bereiche anfordern muss, die nicht für die Anmeldung erforderlich sind, sollten Sie immer die inkrementelle Autorisierung verwenden und prüfen, welche Bereiche Nutzer gewährt haben.

In diesem Beispiel wird davon ausgegangen, dass beide Bereiche erforderlich sind, damit die App richtig funktioniert. Sie sollten detaillierte Berechtigungen aktivieren, damit Nutzer mehr Kontrolle darüber haben, welche Berechtigungen sie Ihrer Anwendung erteilen. Ihre Anwendung sollte die Antwort von Nutzern richtig verarbeiten, indem sie prüft, welche Bereiche sie autorisiert haben.

main.js

...
const oauth2Client = new google.auth.OAuth2(
  YOUR_CLIENT_ID,
  YOUR_CLIENT_SECRET,
  YOUR_REDIRECT_URL
);

// Access scopes for two non-Sign-In scopes - Google Calendar and Contacts
const scopes = [
  'https://www.googleapis.com/auth/contacts.readonly',
  'https://www.googleapis.com/auth/calendar.readonly'
];

// Generate a url that asks permissions for the Google Calendar and Contacts scopes
const authorizationUrl = oauth2Client.generateAuthUrl({
  // 'online' (default) or 'offline' (gets refresh_token)
  access_type: 'offline',
  // Pass in the scopes array defined above
  scope: scopes,
  // Enable incremental authorization. Recommended as best practices.
  include_granted_scopes: true,
  // Set to true to enable more granular permissions for Google OAuth 2.0 client IDs created before 2019.
  // No effect for newer Google OAuth 2.0 client IDs, since more granular permissions is always enabled for them.
  enable_granular_consent: true
});

async function main() {
  const server = http.createServer(async function (req, res) {
    // Redirect users to Google OAuth 2.0 server.
    if (req.url == '/') {
      res.writeHead(301, { "Location": authorizationUrl });
    }
    // Receive the callback from Google OAuth 2.0 server.
    if (req.url.startsWith('/oauth2callback')) {
      // Handle the Google OAuth 2.0 server response
      let q = url.parse(req.url, true).query;

      if (q.error) {
        // User didn't authorize both scopes.
        // Updating the UX and application accordingly
        ...
      } else {
        // Get access and refresh tokens (if access_type is offline)
        let { tokens } = await oauth2Client.getToken(q.code);
        oauth2Client.setCredentials(tokens);

        // User authorized the request. Now, check which scopes were granted.
        if (tokens.scope.includes('https://www.googleapis.com/auth/calendar.readonly'))
        {
          // User authorized Calendar read permission.
          // Calling the APIs, etc.
          ...
        }
        else
        {
          // User didn't authorize Calendar read permission.
          // Calling the APIs, etc.
          ...
        }

        // Check which scopes user granted the permission to application
        if (tokens.scope.includes('https://www.googleapis.com/auth/contacts.readonly'))
        {
          // User authorized Contacts read permission.
          // Calling the APIs, etc.
          ...
        }
        else
        {
          // User didn't authorize Contacts read permission.
          // Update UX and application accordingly
          ...
        }
      }
    }
    res.end();
  }).listen(80);
}

Lesen Sie die Anleitung für serverseitige Webanwendungen, um zu erfahren, wie Sie von serverseitigen Anwendungen aus auf Google APIs zugreifen.

Nur clientseitiger Zugriff

Bei Anwendungen, die die Google Identity Services JavaScript-Bibliothek für die Interaktion mit Google OAuth 2.0 verwenden, lesen Sie diese Dokumentation zur Verarbeitung detaillierter Berechtigungen.
Bei Anwendungen, die direkt mit JavaScript Google OAuth 2.0-Autorisierungsendpunkte aufrufen, lesen Sie diese Dokumentation zur Verarbeitung detaillierter Berechtigungen.

Aktualisierte Anwendung für die Verarbeitung detaillierter Berechtigungen testen

Beschreiben Sie alle Fälle, in denen Nutzer auf Berechtigungsanfragen antworten können, und das erwartete Verhalten Ihrer Anwendung. Wenn der Nutzer beispielsweise nur zwei von drei angeforderten Bereichen autorisiert, sollte sich Ihre Anwendung entsprechend verhalten.
Testen Sie Ihre Anwendung mit aktivierten detaillierten Berechtigungen. Es gibt zwei Möglichkeiten, detaillierte Berechtigungen zu aktivieren:
1. Prüfen Sie die OAuth 2.0-Zustimmungsbildschirme Ihrer Anwendung, um zu sehen, ob detaillierte Berechtigungen bereits für Ihre Anwendung aktiviert sind. Sie können auch eine neue Google OAuth 2.0-Client-ID für Web, Android oder iOS über die Google Cloud Console für Testzwecke erstellen, da detaillierte Berechtigungen für diese immer aktiviert sind.
2. Setzen Sie den Parameter enable_granular_consent auf true, wenn Sie die Google OAuth Autorisierungsendpunkte aufrufen. Einige SDKs unterstützen diesen Parameter explizit. Bei anderen finden Sie in der Dokumentation Informationen dazu, wie Sie diesen Parameter und seinen Wert manuell hinzufügen können. Wenn Ihre Implementierung das Hinzufügen des Parameters nicht unterstützt, können Sie eine neue Google OAuth 2.0-Client-ID für Web, Android oder iOS über die Google Cloud Console nur für Testzwecke erstellen, wie im vorherigen Punkt beschrieben.
  Wichtig: Wenn Google detaillierte Berechtigungen für eine Anwendung aktiviert, hat der enable_granular_consent Parameter keine Auswirkungen mehr.
Verwenden Sie beim Testen Ihrer aktualisierten Anwendung ein privates Google-Konto (@gmail.com) anstelle von einem Workspace-Konto. Das liegt daran, dass Workspace Enterprise-Apps mit domainweiter Delegation der Berechtigung oder als vertrauenswürdig gekennzeichnete Apps derzeit nicht von den Änderungen an detaillierten Berechtigungen betroffen sind. Wenn Sie also ein Workspace Konto Ihrer Organisation verwenden, wird der neue detaillierte Zustimmungsbildschirm möglicherweise nicht wie vorgesehen angezeigt.

Detaillierte Berechtigungen Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Übersicht

Was sind detaillierte Berechtigungen?

Wenn mehr als ein Bereich angefordert wird, der nicht für die Anmeldung erforderlich ist

Bereiche für die Anmeldung und andere Bereiche

Mehr als ein Bereich, der nicht für die Anmeldung erforderlich ist

Feststellen, ob Ihre Anwendungen betroffen sind

Feststellen, ob Ihre Anwendung mehrere Bereiche verwendet

Anwendungscode prüfen

Google Identity Services

Python

Node.js

Ausgehenden Netzwerkaufruf prüfen

Best Practices für den Umgang mit detaillierten Berechtigungen

Anwendung für die Verwendung detaillierter Berechtigungen aktualisieren

Android-Anwendungen

Chrome-Erweiterungsanwendungen

Falscher Ansatz

Alles oder nichts

Richtiger Ansatz

Kleinste Bereiche

Kleinste Gruppe der erforderlichen Bereiche auswählen

iOS-, iPadOS- und macOS-Anwendungen

Webanwendungen

Serverseitiger (Offline-)Zugriff

Falscher Ansatz

Alles oder nichts

Richtiger Ansatz

Kleinster Bereich

Kleinste Gruppe der erforderlichen Bereiche auswählen

Nur clientseitiger Zugriff

Aktualisierte Anwendung für die Verarbeitung detaillierter Berechtigungen testen

Detaillierte Berechtigungen