Confused about how to migrate away from OAuth1
74 views
Skip to first unread message
tempy
Oct 14, 2015, 6:30:11 AM10/14/15
to Google App Engine
I have an app that makes extensive use of the Users API + OAuth1. I've been relying on the unique google identifiers produced by the Users API to identify my users. Switching to OAuth2 on it's own is not a problem, but I can't see a way in which Google-Auth-via-OAuth2 is integrated with GAE's Users API.
As I understand it, Google is suggesting that migration basically involves using Google's open-to-all OAuth2 API, which has no special integration with GAE. Is this correct? If so, then the google ID's that this API will return will not match the ones that I had previously seen with UsersAPI+OAuth1, and the app is in trouble, those IDs are keyed to existing users.
If this is not the case, then how do I go about using OAuth2 to get the same google IDs that I've been getting with the UsersAPI+OAuth1 in the past?
As I understand it, Google is suggesting that migration basically involves using Google's open-to-all OAuth2 API, which has no special integration with GAE. Is this correct? If so, then the google ID's that this API will return will not match the ones that I had previously seen with UsersAPI+OAuth1, and the app is in trouble, those IDs are keyed to existing users.
If this is not the case, then how do I go about using OAuth2 to get the same google IDs that I've been getting with the UsersAPI+OAuth1 in the past?
Many thanks!
mike
Barry Hunter
Oct 14, 2015, 8:03:17 AM10/14/15
to google-appengine
As I understand it, you need to do a sort of incremental migration.
The first time a legacy user logs in, you login via the User API (to get their old id) - then log them in again under the new Oauth api.
It wont bother most users as they used to periodically having re grant access to apps.
dont think you actully get a 'persistent' long term ID from OAuth 2 anyway, just short term access tokens, so will have to create your own id (so may as well use the old user-id as a the unique id) - although can get an email to use for cross reference. (I suppose if they on G+ you can ask for profile URL, which contains a unique id)
(note I havent actully done this migration yet, just looked into it.
--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/1153495a-82e2-4ab4-93ed-ca7a9756ff6d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Nick (Cloud Platform Support)
Oct 14, 2015, 1:48:16 PM10/14/15
to Google App Engine
@barryhunter, that's pretty much the way to manage the migration from one auth service/method to another, is to correlate the identities (one being freshly accessed/created on the "new" system, the other being the existing system's identity for this user), by having them auth to both services at the same time. At that moment, your app can migrate that user to the new system and store the new credentials / identity information.
If all access to user information within your app references cached versions of the data retrieved from the identity endpoint anyways, rather than only storing it in the session, it won't be necessary to change your auth code anywhere but in the places where sign-in, sign-out, or extra auth flows take place.
In the docs for the Users service, which is one option on the platform for auth and identity, under the heading "Accessing Account Information", you can see that the numeric id on the retrieved User object is a unique id which is shared across all App Engine apps. This is distinct from the Google+ numeric id, which is returned from interacting with the Google+ API.
@tempy, your original post raises some important questions. This is true:
The following, therefore, gets to the heart of your issue:
If you've used those old numeric IDs (or strings for that matter) as indexes (or as part of indexes) anywhere in your database, or have persisted them into the fields of any other records than a single, now-updated User record, it will create problems to leave these other indexes and records in the database, coupled to the now-deprecated ID, unchanged.
So, a migration process for each such index and record should be performed at each moment when a user performs the new auth for the first time. It should be done atomically, to ensure no trace of the old ID remains in the database. All code which runs queries against the ID (whether as an index or as a record field) should gather its ID from the User object.
This seems to be sufficient to guarantee consistency in the migration from one system of auth to another, and the parallel migration from one system of numeric IDs to another.
If all access to user information within your app references cached versions of the data retrieved from the identity endpoint anyways, rather than only storing it in the session, it won't be necessary to change your auth code anywhere but in the places where sign-in, sign-out, or extra auth flows take place.
In the docs for the Users service, which is one option on the platform for auth and identity, under the heading "Accessing Account Information", you can see that the numeric id on the retrieved User object is a unique id which is shared across all App Engine apps. This is distinct from the Google+ numeric id, which is returned from interacting with the Google+ API.
@tempy, your original post raises some important questions. This is true:
Google is suggesting that migration basically involves using Google's open-to-all OAuth2 API, which has no special integration with GAE ... the google ID's that this API will return will not match the ones that I had previously seen with UsersAPI+OAuth1
The following, therefore, gets to the heart of your issue:
... the app is in trouble, those IDs are keyed to existing users. ... how do I go about using OAuth2 to get the same google IDs that I've been getting with the UsersAPI+OAuth1 in the past?
If you've used those old numeric IDs (or strings for that matter) as indexes (or as part of indexes) anywhere in your database, or have persisted them into the fields of any other records than a single, now-updated User record, it will create problems to leave these other indexes and records in the database, coupled to the now-deprecated ID, unchanged.
So, a migration process for each such index and record should be performed at each moment when a user performs the new auth for the first time. It should be done atomically, to ensure no trace of the old ID remains in the database. All code which runs queries against the ID (whether as an index or as a record field) should gather its ID from the User object.
This seems to be sufficient to guarantee consistency in the migration from one system of auth to another, and the parallel migration from one system of numeric IDs to another.
On Wednesday, October 14, 2015 at 8:03:17 AM UTC-4, barryhunter wrote:
As I understand it, you need to do a sort of incremental migration.The first time a legacy user logs in, you login via the User API (to get their old id) - then log them in again under the new Oauth api.It wont bother most users as they used to periodically having re grant access to apps.dont think you actully get a 'persistent' long term ID from OAuth 2 anyway, just short term access tokens, so will have to create your own id (so may as well use the old user-id as a the unique id) - although can get an email to use for cross reference. (I suppose if they on G+ you can ask for profile URL, which contains a unique id)(note I havent actully done this migration yet, just looked into it.
On 14 October 2015 at 11:30, tempy <fay...@gmail.com> wrote:
I have an app that makes extensive use of the Users API + OAuth1. I've been relying on the unique google identifiers produced by the Users API to identify my users. Switching to OAuth2 on it's own is not a problem, but I can't see a way in which Google-Auth-via-OAuth2 is integrated with GAE's Users API.
As I understand it, Google is suggesting that migration basically involves using Google's open-to-all OAuth2 API, which has no special integration with GAE. Is this correct? If so, then the google ID's that this API will return will not match the ones that I had previously seen with UsersAPI+OAuth1, and the app is in trouble, those IDs are keyed to existing users.
If this is not the case, then how do I go about using OAuth2 to get the same google IDs that I've been getting with the UsersAPI+OAuth1 in the past?Many thanks!mike
--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscribe@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Nick (Cloud Platform Support)
Oct 14, 2015, 1:58:05 PM10/14/15
to Google App Engine
For more information on the topic of auth, identity and sign-in which was not linked in my last comment, you can also check out the Google Identity Platform docs. For more on using OAuth 2.0 to interact with Google APIs, you can check out the API Client Library docs for various languages (java linked).
Reply all
Reply to author
Forward
0 new messages