AWS Cognito Federated Identities для нескольких социальных сетей: лучше объединить идентификаторы или оставить их отдельно?

Aug 20 2020

Несколько федеративных удостоверений AWS Cognito (например, учетные записи Facebook и Google для одного и того же адреса электронной почты) можно объединить в одно удостоверение, передав оба имени входа в вызове Cognito. Но знание того, что я могу объединять личности, не дает ответа на вопрос, следует ли мне объединять личности.

Каковы плюсы и минусы объединения идентичностей по сравнению с их разделением? (Мы храним профили пользователей в нашей собственной базе данных; мы не используем пулы пользователей Cognito. Если мы не объединим идентификаторы, то наша внутренняя база данных сохранит сопоставление каждого идентификатора идентификатора с правильным идентификатором пользователя в нашем фоновом режиме. конец базы данных.)

Вот текущий рабочий процесс приложения, когда один и тот же пользователь пытается авторизоваться с помощью Facebook и Google:

  1. На клиенте (это веб-приложение) новый пользователь нажимает кнопку «Войти» и выбирает вход с помощью Facebook.
  2. Клиентский код регистрирует пользователя в Cognito Federated Identities и получает новый идентификатор федеративного удостоверения, который авторизован для вызова наших функций AWS Lambda.
  3. Клиент вызывает нашу getOrCreateUserProfileфункцию Lambda, которая использует идентификатор Cognito Identity ID в качестве ключа, чтобы узнать, связана ли эта идентификация Cognito с пользователем.
  4. Поскольку в нашей базе данных нет других пользователей с этим идентификатором личности, и поскольку ни один другой пользователь не имеет этого адреса электронной почты (потому что это совершенно новый пользователь), наша функция Lambda создаст новый профиль пользователя в нашей базе данных и вернет профиль. обратно к пользователю.
  5. Позднее пользователь пытается войти в систему (на том же или другом устройстве) с помощью Google.
  6. Для этого удостоверения Google создается новое федеративное удостоверение.
  7. Наша getOrCreateUserProfileфункция Lambda не может найти существующего пользователя, соответствующего этому идентификатору Identity ID, но находит другого пользователя с тем же адресом электронной почты.

На данный момент у нас есть три варианта:

  • A) Верните пользователю сообщение об ошибке, например, «Пожалуйста, войдите, используя свою учетную запись Facebook». Это текущее поведение, которое мы хотим изменить.
  • Б) Объедините идентификаторы, потребовав от пользователя входа в систему с помощью Facebook, а затем передайте оба идентификатора в Cognito, который объединит их. Видетьhttps://stackoverflow.com/a/45045123/126352
  • C) Добавьте строку сопоставления в нашу внутреннюю базу данных, чтобы сопоставить новый идентификатор с существующим профилем пользователя. Теперь у этого пользователя будет два федеративных удостоверения: одно использует поставщика Facebook, другое - поставщика Google.

Каковы плюсы и минусы варианта (B) по сравнению с вариантом (C)? Ниже приводится отправная точка для этого сравнения. Какие плюсы / минусы мне не хватает?

Слияние идентичностей

  • Pro
    • Более простой / быстрый поиск, потому что для каждого пользователя требуется индексировать только один идентификатор личности на сервере.
    • Полагаю, это самое безопасное решение?
  • Против
    • Сам процесс слияния кажется сложным и подверженным ошибкам. Например, после слияния, если новый идентификатор «выиграет» слияние, тогда нам нужно будет заменить старый идентификатор на новый в профиле пользователя ... и если что-то пойдет не так во время этого процесса, мы можем остаться в невосстановимое состояние, когда Cognito знает только о новом (объединенном) идентификаторе, а наша база данных знает только о старом.
    • Более сложный UX, где пользователь должен войти (хотя и только один раз) в учетные записи Facebook и Google в одном сеансе, чтобы связать эти учетные записи.
    • Любые последующие изменения связывания должны проходить через Cognito API.

Держитесь отдельно

  • Pro
    • Более простой UX: мы можем связать учетные записи в социальных сетях, сопоставив адреса электронной почты; нет необходимости использовать оба входа в одну сессию
    • Может управлять связыванием исключительно в нашей внутренней базе данных, что должно упростить создание инструментов администрирования, которые добавляют / удаляют / изменяют ссылки идентификация-> профиль пользователя, вместо того, чтобы вызывать API Cognito для выполнения этих действий.
    • Нет риска рассинхронизации Cognito с нашей серверной базой данных. Если связывание не удается, пользователь может просто повторить попытку.
  • Против
    • Требуется много: 1 индекс для сопоставления идентификатора личности -> Профиль пользователя вместо одного индексированного столбца
    • Это менее безопасное решение? Если да, то почему?
    • Это дороже в счетах AWS? Если да, то почему?

Я склоняюсь к решению «Keep Separate», потому что его проще реализовать (без дополнительного рабочего процесса UX) и проще для пользователей (по той же причине: нет нового рабочего процесса UX). Это ошибка?

Ответы

1 jccampanero Aug 28 2020 at 17:30

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

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

Прежде всего, укажите, что я также предпочел бы сохранить отдельное решение. Позвольте мне попытаться объяснить почему.

С точки зрения UX ясно, что решение для хранения данных - гораздо лучший подход для пользователя. Чтобы объединить идентификаторы различных социальных провайдеров, пользователю необходимо войти в систему с ними в более сложном рабочем процессе регистрации приложения. Но этот процесс мотивирован только техническим решением и никакой реальной пользы для пользователя он не принесет.

Я думаю, что гораздо лучшее и более простое решение - просто включить сопоставление между каждым идентификатором и связанным адресом электронной почты, как вы предлагаете в отдельном решении для хранения, и позволить пользователю прозрачно входить в приложение с помощью поставщика, которого он или она предпочитает » слияние ", в коде вашего приложения, все это механизмы входа. Это требование может быть легко выполнено независимо от типа базовой информационной системы, которую вы используете для хранения пользовательской информации.

Также подумайте, что произойдет, если вам нужно будет включить в свое приложение другого социального провайдера, а уже существующий пользователь захочет войти в ваше приложение с этим новым провайдером: как будут объединены идентификаторы? Следует ли пользователю повторить процесс снова?

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

Риск несинхронизации с Cognito может быть еще одной серьезной проблемой. Каков будет механизм восстановления?

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

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

Я думаю, что решение слияния лучше всего подходит для сценариев, в которых у вас есть федерация и вам нужно однозначно идентифицировать пользователя независимо от того, как он аутентифицируется, но, вероятно, для применения какой-то политики (допущение о пользовательской роли и т. Д.), Связанной с использованием ресурсов AWS на основе только для этих конкретных идентификаторов и, возможно, когда у вас нет доступного серверного приложения.

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

1 Shaho Nov 09 2020 at 05:09

С точки зрения пользователя может показаться довольно запутанным и неудобным войти в систему через второго провайдера только для того, чтобы обнаружить, что у него нет своего предыдущего контента. С этой точки зрения, слияние было бы лучшей конечной целью.

Теперь, с технической точки зрения, я попробовал это сделать и обнаружил, что это довольно хлопотно. Мне удалось объединить идентификаторы, когда пользователь сначала входит в систему с помощью электронной почты, а затем с помощью социальных сетей, но не наоборот. Я предполагаю, что единственный вариант - иметь лямбда-триггер перед регистрацией, который проверяет БД на наличие предыдущих входов в систему по этому конкретному адресу электронной почты и просит пользователя войти в систему и на них, чтобы выполнить слияние или просто продолжить вход в существующий. Однако это легче сказать, чем сделать, если уже существует более одного входа в систему.

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