Аутентификация пользователей в приложении iPhone

Я разрабатываю HTTP-api для нашего веб-приложения. Первоначально основным потребителем API будет iPhone-приложение, которое мы разрабатываем, но я разрабатываю его с учетом будущего использования (например, мобильных приложений для других платформ). Я пытаюсь выбрать лучший способ аутентификации пользователей, чтобы они могли получать доступ к своим учетным записям с iPhone. У меня есть дизайн, который, я думаю, работает хорошо, но я не эксперт по безопасности, поэтому я подумал, что было бы неплохо попросить обратную связь здесь.

Дизайн аутентификации пользователя имеет три основные цели:

  • Хороший пользовательский интерфейс. Мы хотим разрешить пользователям вводить свои учетные данные один раз и оставаться в журнале неограниченно, пока они явно не выйдут из системы. Я бы рассмотрел OAuth, если бы не тот факт, что опыт приложения iPhone довольно ужасен, из того, что я слышал (т.е. он запускает форму входа в Safari, а затем говорит пользователю вернуться к приложению при успешной аутентификации).
  • Не нужно хранить учетные записи пользователей с помощью приложения. Я всегда ненавижу идею того, что пароль пользователя хранится в текстовом или симметричном шифровании в любом месте, поэтому я не хочу, чтобы приложение необходимо сохранить пароль, чтобы передать его API для будущих запросов API.
  • Безопасность. Нам определенно не нужна интенсивная безопасность банковского приложения, но я, очевидно, хотел бы, чтобы это было безопасно.

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

Текущая стратегия:

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

API будет иметь конечную точку login, которая получает имя пользователя/пароль и, если они соответствуют учетной записи, регистрирует пользователя, создавая запись api_sessions для данного ключа API и идентификатора устройства. Будущие запросы API будут искать api_session, используя ключ API и идентификатор устройства, и, если запись найдена, обработайте запрос как зарегистрированный в учетной записи пользователя, на который ссылается запись api_session.

Также будет конечная точка API logout, которая удаляет запись из таблицы api_sessions.

Кто-нибудь видит какие-либо очевидные дыры в безопасности в этом?

Ответ 1

Я согласен с комментариями oAuth - вы, конечно же, можете сделать oAuth красиво на iPhone - UX полностью зависит от вас. Существуют механизмы (jQuery), чтобы отменить PIN-код от oAuth и использовать его (без повторного ввода PIN-кода в приложение). Это уменьшает UX до

1) Показать веб-страницу (встроенный элемент управления) 2) пользователь вводит пользователя и пароль и нажимает кнопку 3) страница ответа на аут анализируется автоматически.

Этот твиттер oAuth implmentation делает это http://github.com/bengottlieb/Twitter-OAuth-iPhone с использованием уже существующей библиотеки oAuth.

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