Create a EXTERNAL_ID column, and use it to store the identifier from the external system. You should add an EXTERNAL_TYPE column and set that to ‘GOOGLE’.. when you go to integrate further authentication-providers, this can be set to different values (eg ‘OPEN_ID’, ‘FACEBOOK’.)
When interfacing with external systems, it is always necessary to store the foreign key/ identifier for reliable access & updating to the external record.
The external key is distinct from the ID in the local database, and it’s definitely not a username.. it’s just it’s own column, and should have a reasonably generous size so that any external ID encountered, can be stored.
VARCHAR(64) might be a good start since, by definition, we are not responsible for type or content of the identifier — these are provided & defined by the external system. We just need to hold it’s value unchanged, to use when talking to the external system.
The EXTERNAL_TYPE field lets you distinguish between users “registered natively” and “registered via Google” or other external providers.
For example:
create table "USER" (
ID int not null,
USERNAME varchar(64),
DISPLAY_NAME varchar(64),
EMAIL varchar(128),
PWD_HASH varchar(32), -- "native" password, salted & hashed for security
PWD_SALT varchar(32),
EXTERNAL_TYPE varchar(16), -- external-auth Type & ID.
EXTERNAL_ID varchar(64),
primary key (ID)
);
Note that some sites use a slightly more advanced scheme, where a user can be both registered via Google and able to signin via a native password. In this case, signing in via one system of credentials detects the existing email & other system of credentials — often this prompts the user to authenticate with the other credentials, to link them & use both. This is still based on EXTERNAL_ID and EXTERNAL_TYPE but may place these on a USER_CREDENTIALS table related to USER, rather than USER table itself.
For user authentication, it’s also conceivable you might need an additional column for some kind of crypto/key/token. Not sure about that, just a possibility.