Архитектура для аутентификации / авторизации мобильных и веб-пользователей - PullRequest
7 голосов
/ 17 ноября 2010

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

Требования / предположения

  1. Мобильные пользователи должны иметь возможность использоватьродное приложение без входа в систему, в том числе для добавления контента (пометки избранного, загрузки фотографий и т. д.).
  2. Мобильный пользователь должен безопасно и однозначно проходить аутентификацию в веб-сервисе даже без указания учетных данных.
  3. Мобильный пользователь может иметь несколько устройств, которые не будут знать друг о друге.
  4. Мобильный пользователь должен иметь возможность зарегистрироваться / войти, что должно включать любой контент в собственность учетной записи.Эта «синхронизация» должна происходить с каждой учетной записью, которая впоследствии вошла в систему.
  5. Не должно иметь значения, была ли учетная запись создана на мобильном телефоне или в Интернете.

Рассматриваемые архитектуры

  1. БЕЗ РУБАШКИ, БЕЗ ОБУВИ, БЕЗ ВХОДА = БЕЗ ВЗНОСОВ. Требуется логин для добавления материалов любого рода.Это исключает необходимость «синхронизировать» учетные записи устройства с основной учетной записью.Просто введите одно имя пользователя / пароль + токены, чтобы устройства могли войти в систему.Объекты сервера: пользователь, роль
  2. Самостоятельная аутентификация нескольких устройств. Сервер выполняет согласование с устройством и передает ему учетные данные, которые оно хранит.Каждое устройство проходит аутентификацию и связывается с анонимной учетной записью, пока не произойдет регистрация / вход в систему.Если происходит регистрация, анонимная учетная запись преобразуется в известную.В случае входа в систему контент из анонимной учетной записи перемещается в известную учетную запись, а затем выбрасывается.Устройства, которые теряют данные само аутентификации, получат новые данные аутентификации, а предыдущая анонимная учетная запись будет удалена (а затем, скорее всего, позже удалена) и не будет восстановлена, поскольку она никогда не была преобразована в известную учетную запись.Объекты сервера: пользователь, роль, устройство

Как вы думаете, что является хорошим решением?Один из них или что-то еще?

Ответы [ 4 ]

2 голосов
/ 30 ноября 2010

Я хотел бы предложить идею, аналогичную 2.

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

Если в любое время позже пользователь захочет создать учетную запись в Интернете, он может зарегистрироваться либов Интернете или на устройстве.Если пользователь уже владеет веб-учетной записью, он может один раз (или устройства) предоставить существующие учетные данные на своем мобильном устройстве, и устройство будет связано с его веб-учетной записью на стороне сервера.

На сервереКроме того, я бы разрешил два разных типа объектов, выступающих в качестве идентификаторов: веб-пользователи, которые аутентифицируются с помощью учетных данных (OpenID приходит мне в голову как дополнение) и устройства, которые аутентифицируются по их GUID без вмешательства пользователя.Естественно, объект веб-пользователя может владеть несколькими объектами устройства.Объект устройства связывается с учетной записью, когда пользователь решает связать свое устройство с существующей учетной записью.Контент обычно ассоциируется с идентификатором.

Связь между пользователем и устройством сохраняется и может также использоваться для отображения происхождения контента.

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

Есть еще некоторые соображения безопасности, которые остаются открытыми, в зависимости от критичности контекста вашего приложения.Без каких-либо мер безопасности злоумышленнику будет легко злоупотребить UUID.

2 голосов
/ 30 ноября 2010

Я думаю, что на это смотрят с неправильной стороны.Определите идентичность на сервере как определяемую произвольным значением.Вероятно, просто последовательность БД.Свяжите любую демографическую информацию (имя, адрес электронной почты ...) и историю использования с этим идентификатором.

Отдельно определите объект аутентификации на сервере.Это может быть пользователь / пароль.Это может быть GUID / UUID устройства.Это может быть федеративный идентификатор, такой как OpenID.Данный идентификатор может иметь (и часто будет в вашем случае) несколько связанных объектов аутентификации.Очень возможно несколько аутентификационных идентификаторов одного типа.(например, GUID для моего смартфона, GUID для моего iPad ...)

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

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

Еще одна точка, независимо от того, что сервер использует для однозначного указания идентификатора, должна иметь значение , никогда предоставляется клиенту.Клиенты знают только о механизме аутентификации и его данных.То есть GUID / UUID, имя пользователя / пароль, ...

В дополнение к методам, перечисленным выше, что-то вроде OAuth более безопасно, чем локально сгенерированный GUID.Это одно из: легко определяемое или b: легко теряемое.Если значение очень предсказуемо (скажем, номер телефона), оно легко подделывается.Если оно генерируется во время выполнения и содержит трудно предсказуемое значение, такое как хэш текущего времени, когда оно генерируется впервые, то оно должно быть сохранено на устройстве и может быть легко потеряно при стирании устройства.Хорошие идентификаторы GUID могут быть сгенерированы, но они часто очень зависят от типа устройства.Такие вещи, как серийные номера устройств, полученные из ПЗУ, IMEI, ... Это легко выполнимо.Но это намного более зависит от конкретного устройства, чем мне, вероятно, будет удобно.

Самым большим реальным препятствием, которое я вижу во всем этом подходе, является то, что будет неудобно допускать только существующее устройство (нетusername / password) пользователь должен сесть за браузер ПК и подключиться к своей существующей учетной записи.

0 голосов
/ 20 января 2012

Одно решение с биометрией. Если в мобильном устройстве есть биометрический датчик, например, сканер отпечатков пальцев, пользователь зарегистрирует биометрический датчик в устройстве (только из-за проблем конфиденциальности) во время покупки. Приложения могут быть написаны так, что каждая безопасная транзакция требует от пользователя аутентификации биометрических данных.

Это, кажется, не слишком далеко. У Motorola Atrix есть датчик отпечатков пальцев ...

0 голосов
/ 29 ноября 2010

Номер 2 достаточно хорош в качестве базового решения. Пользователи ненавидят регистрацию;) Так что возможность использовать сервис без регистрации - хорошая идея.

Вы можете использовать GUID / UUID для идентификации устройства. И используйте его как анонимный вход перед входом пользователя.

Но что делать, если 2 (или более) человека используют 1 устройство? Или устройство будет потеряно, украдено? Я думаю, что ни один из пунктов не покрывает эти случаи.

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

...