Ключевой вопрос - кто будет вашим провайдером идентификации?
Следующий ключевой вопрос - как вы сопоставите личность пользователя из провайдера идентификации с вашей собственной базой данных пользователей / привилегий.
Следующий ключевой вопрос для вас - какой тип OAuth 2.0 использовать.Неявный OAuth или 3-х сторонний OAuth.Неявный OAuth выполняется в браузере и включает только идентификатор клиента.OAuth с тремя ножками включает в себя веб-сервер для получения токенов и считается более безопасным.
1) Веб-интерфейс потребует от пользователя входа в свою учетную запись Google (которую я ожидаю привязать к GoogleОблачная организация) с использованием Google в качестве стороннего аутентификатора.Поскольку приложение построено с использованием узла / javascript, это легко сделать с помощью некоторого пакета npm, такого как паспорт.После того, как пользователь войдет в браузер и произойдут определенные перенаправления, Google должен предоставить бэкэнду информацию о пользователе, включая уникальный идентификатор.
Вы можете использовать любой провайдер идентификации (Google, Facebook, Auth0,Окта и т. Д.).(Примечание: см. Мой комментарий ниже о Google IAM).Реализация OAuth в браузере настолько проста, что вам действительно не нужна библиотека.Однако, если вы хотите использовать библиотеку, есть из чего выбирать.Однако выберите библиотеку, которая является собственным JavaScript, а не пакетом узлов.Пакеты узлов обычно создают огромные файлы, которые пользователи должны загружать.
После завершения потока OAuth у вас будет два токена.Токен доступа и идентификационный токен.Идентификационный токен - это то, что ваш клиентский интерфейс JavaScript будет включать в запросы.Я игнорирую токен доступа в этом ответе, но его можно использовать для прямого доступа к сервисам GCP, таким как Google Storage, если он правильно настроен на этапе аутентификации.Для этого ответа я предполагаю, что вы хотите, чтобы личность пользователя.
2) Backend (работающий на движке приложения, вычислительном движке и т. Д. Не должен иметь значения) должен иметь доступ к Google Cloudконкретный API, который должен идентифицировать пользователя и принадлежать ли пользователю группе или организации, в основном все, что могло бы помочь.Предполагается, что у машины будет служебная учетная запись со всеми необходимыми ролями для доступа к указанным API-интерфейсам и определения того, в порядке ли пользователь.
Браузер на стороне клиента будет включать маркер идентификатора в HTTPзаголовок, скрытое поле формы, состояние сеанса и т. д. при взаимодействии с вашими службами.Для проверки идентификационного токена вы вызываете конечную точку, относящуюся к провайдеру идентификации.Для Google конечная точка: https://www.googleapis.com/oauth2/v3/tokeninfo, для Auth0 это: https://<replace_with_your_account_name>.auth0.com/userinfo.Обе эти конечные точки проверяют целостность идентификатора токена.Идентификационный токен содержит сведения о пользователе, которого пользователь разрешил вам просматривать.Идентификационный токен, который является JWT, при декодировании для Google выглядит следующим образом:
iss: https://accounts.google.com
azp: <removed_for_security>.apps.googleusercontent.com
aud: <removed_for_security>.apps.googleusercontent.com
sub: <removed_for_security>
hd: example.com
email: username@example.com.com
email_verified: true
at_hash: 63I_abcdefabcdefbi5NSw
nonce: e8TP-uLoEoeXpbk5
name: User Name
picture: https://lh3.googleusercontent.com/-9PtQwhKbOPc/AAAAAAAAAAI/AAAAAAAAAAA/<removed_for_security>/s96-c/photo.jpg
given_name: User
family_name: Name
locale: en
iat: 1548357229
exp: 1548360829
jti: <removed_for_security>
Ваш сервер будет отвечать за сопоставление личности пользователя с любыми привилегиями, которые вы хотите.Вы можете использовать базу данных и т. Д. Для хранения этой информации.Если пользователь также является пользователем Google IAM, вы можете создавать учетные данные с коротким сроком действия на основе привилегий IAM, хранящихся в Google IAM.Однако я рекомендую это только в тех случаях, когда у вас всего несколько пользователей.Для сотен или тысяч пользователей не используйте Google IAM, вместо этого управляйте этим с помощью своего поставщика удостоверений с помощью пользовательских утверждений или в собственной пользовательской базе данных.
3) Если пользователь в порядке, тогда сеанс будетбыть создан в Backend для пользователя, и пока этот сеанс живет, Backend будет знать идентичность запросов, поэтому все должно быть в порядке.
Я не уверен, что вы пытаетесь сказатьВот.Для Google Cloud ваш бэкэнд будет либо отправлять запросы от имени клиента, используя свою учетную запись службы, либо бэкэнд создаст токен недолгого доступа, который предоставляет доступ.
1) мой подход имеет смысл иэто вообще возможно?
Ваш подход очень близок к тому, как это должно быть сделано. Есть некоторые тонкие детали, которые вы еще не поняли, и я надеюсь, что мои ответы укажут вам правильное направление для дальнейших исследований.
2) если да, то какие ресурсы или методы мне следует использовать, чтобы сделать это
случиться?
- Выберите тип OAuth, который вы будете использовать (неявный или 3-сторонний).
- Выберите поставщика удостоверений. Google, Facebook, Auth0 и т. Д.
- Определился с типом кода, который вы будете вставлять в браузер (простой JavaScript или библиотека)
- Определите, как вы будете передавать токены через HTTP-заголовки, скрытые поля формы и т. Д.
- Решите, как вы будете авторизовать запросы. Ваша собственная учетная запись службы или краткосрочные токены доступа, созданные для пользователя.
- Решите, как вы будете переводить идентификационные данные идентификатора токена в ваш набор разрешений.
3) если нет, то какой подход подойдет для моего варианта использования?
Ваш подход хорош и типичен для того, что мы делаем в реальном мире.