Migrating GAE app stored user information to GAE Python 3.0 without Users API

[mar...@bluecore.com]

Hello,

We are currently tracking Google account based users in our GAE 2.7 app using the User Service's User.user_id as recommended by https://cloud.google.com/appengine/docs/standard/python/users/userobjects. 

This was beneficial over storing email addresses as it would canonicalize accounts where aliases were used or variations of emails with and without dots (e.g. joh...@gmail.com and jo...@gmail.com). 

If we migrate to the Google identity platform (GIP) as recommended by https://cloud.google.com/appengine/docs/standard/python3/python-differences, would we be able to correlate the old app engine ids to what comes out of GIP? 

Note that there's already a difference between the App Engine side user id and, if the same user is stored in our corporate Google directory, the directory side user id. Does GIP introduce a 3rd variant?

A second question: how would be able to look up the GIP user id from a given email (e.g. to find out whether  joh...@gmail.com and jo...@gmail.com are the same account)?

Thanks!
Marcel

[George (Cloud Platform Support)]

Hello Marcel, 

Documentation does not indicate restrictions on user ID's, you may check "Getting profile information" page for related details. You can choose IDs or pattern for IDs that might correlate to the old App Engine IDs. This might not prove of any advantage in the end, as in Google Identity Platform you are not supposed to use these IDs to validate user log-ins. Same applies to emails and email variants such as joh...@gmail.com and jo...@gmail.com. You may check the "Send the ID token to your server" on the "Authenticate with a backend server" page. 

To reply to your second question, on the same documentation page you'll notice that the get method for email profile.getEmail() does not allow for multiple email values within the same user identity profile. 

[NP]

Hi George,

You said - .....as in Google Identity Platform you are not supposed to use these IDs to validate user log-ins......

How then are you supposed to validate user log-ins using Google Identify Platform? GAE 2.7 User Object documentation specifically said that the User Id is stable and recommended storing that. I believe people then used it to validate logged in users. What is the recommended way for validating people in Google Identity Platform?

[mar...@bluecore.com]

To clarify our usage scenario:

We register external users with our application by storing our own user entities. To catch aliases and dot/no dot variations being the same Google account (for example a gmail account does allow aliases and people appear to log in with and without dots in their name), we convert the email to a GAE user id and store that: this way we reduce all these cases to one user we store. Granted this wasn't very straightforward to being with (given per an SO post: https://stackoverflow.com/questions/816372/how-can-i-determine-a-user-id-based-on-an-email-address-in-app-engine) but it helps the confusion of these account email variations. 

If this ability disappears we'll have to figure this out afterwards: e.g. we allow the storage of say three user entities identified by primary email, alias and potentially without dots (since the person entering the information wouldn't know), then have a batch job go through all users say daily and merge the ones that have the same id that will be provided by OpenID-Connect. 

[davidc...@google.com]

Hello Marcel,

We expect these IDs to be the same but cannot guarantee it. The best way to confirm this is to try it in your test environment; store the user ID of a user from an application using the Users API and then using the same user try to access application using Google Identity Platform to compare these IDs.

[bFlood]

has anyone tried Firebase Authentication API as a suitable replacement for GAE Python 2.7 Users api?

https://firebase.google.com/docs/auth/

this doc lays it out nicely:

https://cloud.google.com/appengine/docs/standard/python/authenticating-users-firebase-appengine

also, it looks like you can have as many Firebase Authentication users as you need for free (eg public user of your app). can someone at google confirm this as well? I had thought Firebase was priced per user?

thank you

[mar...@bluecore.com]

Yes, trying it out is indeed what we're planning to do to validate the behavior and prepare for the switch.

Thanks for the follow up David.

On Wednesday, February 20, 2019 at 8:10:54 PM UTC-5, davidc...@google.com wrote: