Создание службы аутентификации Google с пользователями, которые хранятся в собственной базе данных на Голанге - PullRequest
Новая
       20

Создание службы аутентификации Google с пользователями, которые хранятся в собственной базе данных на Голанге

0 голосов
/ 28 июня 2018

Первым шагом в создании моего нового набора реагирующих веб-приложений является создание простого сервера / службы аутентификации в Go, предпочтительно, где пользователи могут проходить аутентификацию с помощью своей учетной записи Google, что может привести к:

  • создание нового пользователя в базе данных
  • логин, если совпадающий пользователь найден в БД (как определить совпадение без пароля?)

Я понимаю, что получу JWT от сервера / службы аутентификации с обычными требованиями, такими как: 

{
    "iss":"accounts.google.com",
    "at_hash":"HK6E_P6Dh8Y93mRNtsDB1Q",
    "email_verified":"true",
    "sub":"10769150350006150715113082367",
    "azp":"1234987819200.apps.googleusercontent.com",
    "email":"jsmith@example.com",
    "aud":"1234987819200.apps.googleusercontent.com",
    "iat":1353601026,
    "exp":1353604926,
    "nonce": "0394852-3190485-2490358",
    "hd":"example.com"
}

Пока все хорошо, но после этого я не совсем уверен, какие поля мне нужно хранить для пользовательской "таблицы" (используя dgraph db, но я думаю, что не имеет значения, реляционный это или графический db ) в базе данных, отличной от электронной почты, которая, по моему мнению, будет идентификатором, связывающим пользователя в db с JWT?

Как вы справляетесь с интеграцией со своей собственной базой данных:

  1. Первый раз, когда пользователь проходит аутентификацию с помощью Google через сервер / сервис авторизации, и пользователь создается в БД
  2. В последующий раз пользователь аутентифицируется с помощью Google через тот же сервер / сервис авторизации и входит в систему (уже существует в БД - но как проверить это безопасным способом - не могли ли другие просто создать фальшивый токен с тем же адресом электронной почты? )

Храните ли вы токен в таблице пользователей вместе с электронной почтой? В таком случае, что делать, если токен истекает / изменяется, а как насчет безопасности?

Так что вопрос не в том, как получить токен, а в том, как связать пользователя в БД с пользователем JWT, который только что прошел аутентификацию.

В большинстве прочитанных мною учебников и статей часть базы данных не описывается подробно.

1 Ответ

0 голосов
/ 28 июня 2018

Создание нового пользователя в базе данных

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

Вход в систему, если в БД найден соответствующий пользователь (как определить соответствие без пароля?)

Одна из основных причин полагаться на внешний механизм аутентификации заключается в том, что вам не нужно выполнять хранение / проверку пароля самостоятельно.

Вам просто нужно сопоставить адрес электронной почты, который пользователь использует для аутентификации, с адресом электронной почты, который вы сохранили в своей БД.

Разве другие не могут просто создать фальшивый токен с тем же адресом электронной почты?

Нет, они не могут, иначе это было бы бесполезно.

Токены подписаны сервером аутентификации, и невозможно "подписать" токен, не имея закрытого ключа сервера аутентификации.

Как это проверить безопасным способом

Смотрите здесь: https://developers.google.com/identity/sign-in/web/backend-auth

В разделе «Проверка целостности токена идентификатора» обсуждается, как вы делаете это самостоятельно или путем вызова внешней конечной точки.

Храните ли вы токен в таблице пользователей вместе с электронным письмом?

Хранить токен пользователя нужно только в том случае, если помимо его аутентификации вы планируете использовать API Google от имени пользователя.

В таком случае, что делать, если токен истекает / изменяется, а как насчет безопасности?

Смотрите здесь: https://developers.google.com/identity/protocols/OAuth2

Вам нужно будет сохранить токен и токен обновления, и для его обновления необходимо выполнить последовательность действий.

Что касается безопасности, вам нужно убедиться, что ни один пользователь не может видеть токен другого пользователя, поскольку токен позволяет приложению отправлять запросы к API от имени этого пользователя.

...