У меня есть приложение, которое в настоящее время использует электронную почту и пароль для аутентификации учетной записи. Каждый раз, когда пользователь входит в систему, используя адрес электронной почты и пароль, серверная часть создает токен сеанса JWT и возвращает его приложению.

Это хорошо работает. Теперь я пытаюсь интегрировать вход в Google One-tap [OAuth], и я хочу сохранить свою существующую систему входа в систему.

Я не могу понять, как управлять сеансом / аутентификацией пользователя в базе данных. В моей существующей таблице пользователей есть:

Name, email, password, ...

В случае OAuth я получу только электронную почту и токен. Как только я проверю токен, у меня не будет пароля для сохранения. Итак, можно ли просто сохранить уникальный идентификатор пользователя OAuth в столбце external_unique_id и ничего не делать с паролем (например, оставить его пустым)?

Пожалуйста, помогите мне понять, как управлять такой системой. В частности, как обрабатывать поток, когда пользователь пытается войти во второй раз, когда external_unique_id уже существует. Должен ли я сравнивать уникальный идентификатор, полученный от OAuth, предоставленного с external_unique_id?

Спасибо!

0
Saarang Tiwari 15 Окт 2021 в 13:01

2 ответа

Лучший ответ

Я не знаю, лучший ли это подход, но вы можете создать новый столбец в своей таблице пользователей, который сообщает вам, какой метод входа в систему использовал пользователь (в данном случае google или api). Вам действительно не нужен уникальный идентификатор Google, вам просто нужно знать, что аутентификация прошла успешно, чтобы сгенерировать новый токен или нет. При первой аутентификации вам необходимо создать нового пользователя на основе данных Google. В следующих случаях просто введите пользователя в базу данных, используя его электронную почту, и сделайте все, что вам нужно.

1
André Luiz 15 Окт 2021 в 10:36

У нас есть несколько способов аутентификации,

  1. Сервер авторизации генерирует токен и токены аутентификации: Клиенту необходимо получить токен с сервера, введя учетные данные, сервер отправит токен обратно. Каждый раз приложение должно подключаться к серверу аутентификации, чтобы выполнить аутентификацию.

  2. Сервер авторизации разделяет базу данных с другим приложением Как только пользователь получит токен от auth. сервер. Он может использовать его на другом сервере ресурсов. Этот сервер ресурсов напрямую извлекает токены из базы данных и самостоятельно выполняет аутентификацию.

  3. Используйте JWT для авторизации. Клиент получает сгенерированный токен Jwt от auth. сервер. Сервер аутентификации может делиться открытым ключом с другим сервером ресурсов. Сервер ресурсов может использовать открытый ключ для декодирования содержимого. Поскольку только сервер авторизации имеет закрытый ключ, только auth.server может генерировать правильный контент jwt

На мой взгляд, вам нужно создать нового пользователя в своей базе данных.

1
The blank 15 Окт 2021 в 10:36