Ich beziehe mich auf @MinWans wunderbare Antwort in diesem BeitragGoogle Cloud-Endpunkte und Nutzerauthentifizierung, wo er eine Möglichkeit beschreibt, einer Anfrage benutzerdefinierte Header für die Cloud-Endpunkte von App Engine hinzuzufügen.

Es wird klar, dass wir für jeden Dienst (z. B. Google, Twitter, Facebook), für den wir eine Authentifizierung durchführen möchten, einen benutzerdefinierten Header hinzufügen und einen Authentifizierer schreiben können, wobei jeder Authentifizierer einen bestimmten Header liest und sich für den Dienst authentifiziert. Wenn das Token gültig ist, gibt ein Dienst in der Regel eine Antwort mit einer E-Mail-Adresse oder einer Benutzer-ID sowie einigen zusätzlichen Informationen [A] zurück, aus denen ein com.google.api.server.spi.auth.common.User generiert wird wird später als com.google.appengine.api.users.User an die Endpoint-Methode übergeben.

Erste Frage: Warum haben wir zwei verschiedene Benutzerentitäten, z. Benutzer mit unterschiedlichen Namespaces? Es handelt sich anscheinend nicht um Sub- oder Superklassen, daher werden sie möglicherweise explizit hinter die Kulissen geworfen.

Zweite Frage: Das Problem, das mit der explizit umgesetzten Benutzerentität einhergeht und dass es kein benutzerdefiniertes Feld gibt, in das ich die vom Dienst zurückgegebenen zusätzlichen Informationen [A] einfügen könnte, besteht darin, dass die zusätzlichen Informationen verloren gehen. Solche zusätzlichen Informationen können hilfreich sein, um den oauth2-Benutzer des externen Dienstes einem lokalen Benutzer oder von anderen Diensten zurückgegebenen oauth2-Benutzern zuzuordnen.

Eine Eingabe? Wie sollen mehrere Authentifizierungsdienste behandelt werden?