У нас используется следующая схема таблиц:
Table "public.social_account"
Column | Type | Modifiers
-------------+--------------------------------+-----------
user_id | integer | not null
network | character varying(255) | not null
external_id | character varying(255) | not null
created_at | timestamp(0) without time zone | not null
updated_at | timestamp(0) without time zone | not null
id | uuid | not null
Indexes:
"social_account_pkey" PRIMARY KEY, btree (id)
"unique_social_account" UNIQUE, btree (network, external_id)
"idx_f24d8339a76ed395" btree (user_id)
Foreign-key constraints:
"fk_f24d8339a76ed395" FOREIGN KEY (user_id) REFERENCES app_user(id) ON DELETE CASCADE
То есть для каждой привязки хранится запись, в которой содержится user_id, название соцсети (google/vk/facebook/etc) и id этой соцсети (у всех произвольный формат).
Таким образом, когда пользователь аутентифицируется через одну из этих соцсетей, сначала ищется user_id по связке external_id + network. Если user_id найден - аутентифицируем текущего пользователя как этот user_id. Если нет, получаем от соцсети email и по нему ищем пользователя в таблице пользователей. Если нашли, то создаем запись в social_account и аутентифицируем юзера. Если не нашлось ничего (первый визит), то создаем пользователя и создаем запись в social_account.
