Связывание настраиваемого поставщика аутентификации с Firebase

Я прочитал, что с помощью Firebase я могу разрешить пользователям входить в мое приложение с использованием нескольких поставщиков аутентификации, связав учетные данные поставщика аутентификации с существующей учетной записью пользователя. Можно ли связать настраиваемого поставщика аутентификации, такого как Linkedin? Я прочитал, что мне нужно передать объект AuthCredential в метод linkWithCredential вошедшего в систему пользователя, но я не нашел настраиваемого AuthCredential.


firebase firebase-authentication android linkedin custom-authentication
person mary    schedule 21.10.2016    source источник

Ответы (2)


arrow_upward
10
arrow_downward

Один из способов связать нестандартный токен неподдерживаемого поставщика с существующей учетной записью - получить идентификатор пользователя учетной записи Firebase и идентификатор пользователя неподдерживаемого поставщика и сохранить хэш-карту, которая принимает неподдерживаемый идентификатор поставщика и возвращает uid firebase, с которым вы хотите связать . Когда пользователь входит в неподдерживаемый поставщик с настраиваемым токеном, вы получаете соответствующий uid firebase с карты и возвращаете настраиваемый токен с этим uid, который в signInWithCustomToken разрешается с исходным пользователем firebase.

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

person bojeil    schedule 21.10.2016
comment
Чтобы прояснить этот ответ, просто uid токена должен совпадать с текущим идентификатором пользователя. Например, пользователь вошел в систему как анонимный с идентификатором пользователя V5T0SE15mublW3gTr9lr04q7uxG3. Теперь вы можете создать новый токен с uid: V5T0SE15mublW3gTr9lr04q7uxG3, потому что вы знаете текущий идентификатор пользователя. И как только вы получите новый токен, вы можете снова войти в систему: signInWithCustomToken( newToken ). Эти два пользователя объединились. - person beytarovski; 27.07.2017
comment
@dino только этот комментарий, я не шучу, был единственным во всем Интернете, что предоставило мне нужную мне информацию. У меня есть обычный API-интерфейс для отдыха, но мои пользователи сначала создают учетную запись на основе поставщика firebase на клиенте и используют проверенные полезные данные jwt для поиска / создания. Я пытался выяснить, как использовать REST auth apis для администрирования учетных записей, но мне нужно было обменять пользовательский токен на idtoken. Как только я начал подписывать свой собственный jwt с идентификатором firebase и подписывать их, теперь я наконец могу обменять пользовательский токен на idToken - person Ryan Romanchuk; 17.05.2019
comment
Я думаю, что путаница возникла из-за невозможности связать существующую учетную запись с customToken, поэтому я предположил, что повторная подписка пользователя с моим собственным jwt приведет к дублированию учетной записи, мне даже не приходило в голову использовать тот же идентификатор - person Ryan Romanchuk; 17.05.2019
comment
Это мне очень помогло, и реализация оказалась проще, чем я ожидал. Я бы никогда не ожидал, что смогу создать новый токен, используя существующий идентификатор пользователя Firebase ... - person Rafal Zawadzki; 06.07.2019

arrow_upward
1
arrow_downward

Я хотел бы расширить ответ bojeil.

Существует firebaseUser.linkWithCredential(credential) для поддерживаемых поставщиков, но не эквивалент для customProvider. Связывание customProvider должно выполняться бэкэнд (или, может быть, что-то вроде функций Firebase). Потому что link означает одно из следующих:

  • добавить электронную почту
  • Добавьте номер телефона
  • настраиваемая логика (добавить заявку пользователя)

объекту Firebase User.

Flow выглядит так:

  1. Клиент получает email, phone или некоторую уникальную информацию от customProvider (Line, LinkedIn, Huawei ...) и отправляет их в Backend, включая firebaseToken.
  2. (Backend может проверить эти данные, запросив customProvider). Затем Backend добавляет эту информацию к объекту FirebaseUser. (Также серверная часть должна проверить, не прикреплены ли эти данные к какому-то другому пользователю. Вы можете отклонить ссылку, поскольку уже есть другой пользователь с этим адресом электронной почты, телефоном ...)
  3. Бэкэнд где-то сохраняет <CustomProviderId-FirebaseUserId> пару (например: FireStore). Это сделано потому, что в будущем, когда пользователь захочет войти в систему с помощью customProvider, серверные части должны будут создать CustomToken (чтобы клиент мог вызывать firebaseAuth.signInWithCustomToken), используя Firebase Id этого пользователя. Итак, это отображение - решение этой проблемы.
  4. Серверная часть ответит кодом ответа HTTP 200, чтобы указать, что связывание прошло успешно.
  5. Клиент звонит firebaseUser.reload(), чтобы получить новые прикрепленные данные (электронная почта, телефон и т. Д.)
  6. Если утверждения пользователей обновляются на шаге 2, клиент также должен вызвать firebaseUser.getIdToken(force=true), чтобы получить обновленные утверждения пользователей.

Есть проблемы:

  • Если customProvider выдает только email, вам нужно проверить, прикреплен ли этот адрес электронной почты к любому другому пользователю.
  • Если customProvider выдает только phone, вам нужно проверить, подключен ли этот телефон к любому другому пользователю.
  • Если customProvider может выдавать и email, и phone, сложность возрастает, так как вам нужно проверить, не привязаны ли какие-либо из них к любому другому пользователю.
  • Если customProvider не предоставляет email или phone, тогда вам нужна уникальная информация для этого пользователя для этого настраиваемого поставщика (например, идентификатор пользователя Huawei).
  • CustomProvider не будет в списке firebaseUser.providerData, поэтому вы можете добавить утверждения пользователей. (например, {kakaoTalk:true, huawei:true}). В зависимости от случая вам это не нужно. Например, если customProvider - это WhatsApp, то если phone существует в firebaseUser.phoneNumber, это означает, что WhatsApp подключен (даже телефон добавлен с использованием другого поставщика услуг входа).
  • Если вы разрешите Anonymous пользователей, то связывание customProvider может не обновлять firebaseUser.isAnonymous на клиенте, если адрес электронной почты / телефон не обновлен, клиент по-прежнему будет видеть firebaseUser как анонимный. Одно из решений - проверить, пусты ли connectedProviders, чтобы рассматривать пользователя как анонимного, если это соответствует вашей бизнес-логике. Другое решение - изменение статуса анонимного пользователя, когда вы входите в систему с помощью signInWithCustomToken. Поэтому после успешного связывания customProvider выйдите из системы и войдите в систему с помощью customToken, чтобы пользователь не стал анонимным.
  • Если вы свяжете customProvider с email с анонимным пользователем, поле email этого пользователя будет обновлено. Это заставит клиента выйти из системы и выбросить FirebaseAuthInvalidUserException с кодом ошибки ERROR_USER_TOKEN_EXPIRED. Пользователь должен снова войти в систему.
person Jemshit Iskenderov    schedule 14.03.2021