Мобильная авторизация. Продолжение доступно только участникам

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

Как в сексе: чем позже - тем лучше

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

Основные способы входа в приложение, которые сегодня широко используются, это логин + пароль, соцсети, телефон + код из SMS. Разберем подробнее первый из названных способов.

Логин + пароль

Если пользователю приходится вводить личные данные, наша задача - упросить для него этот процесс.

Подсказки к полям ввода

В простых формах, например, если мы используем привычный ввод логина и пароля, мы можем расположить названия полей в placeholders, это достаточно очевидно для пользователя. В более сложной форме, где есть ограничения на ввод данных, мы должны использовать labels и placeholder, например, пояснение к длине пароля. Labels и placeholders лучше размещать над полем ввода, так для пользователя в любой момент очевидно, что он заполняет, и как это следует делать.

В мобильных приложениях не лучшая практика - располагать label в одной строке с полем ввода. Это съедает полезное горизонтальное пространство. Например, форма регистрации Lamoda iPhone.

Две качественные статьи на тему: Placeholders in Form Fields Are Harmful , Mobile Form Usability: Never Use Inline Labels .

Автодополнения

Автодополнение популярных доменов. iOS библиотека от HotelTonight ускоряет ввод e-mail на основе базы популярных почтовых доменов. В Android можно сделать то же самое вручную. Все это приятно ускоряет ввод e-mail.

Автодополнение популярных почтовых доменов

Автодополнение e-mail по аккаунтам Google. Android-приложение может получить список Google-аккаунтов устройства и предлагать пользователю автодополнение. Так делают, к примеру, Evernote и Instagram. Можно действовать по-другому: автоматически заполнять поле ввода одним из электронных адресов. Так как у большинства пользователей один аккаунт Google, велика вероятность, что мы угадаем. Так поступают Facebook и Twitter. iOS не даёт доступа к e-mail пользователя, поэтому сделать такой автокомплит нельзя.

Автоподолнение почты по аккаунтам Google в Evernote

Автодополнение имени. На стороне сервера или в приложении можно сохранить базу популярных имён и предлагать пользователю автодополнение. В Android, опять же, может помочь Google+. Но это все же неоднозначный способ - ведь ввод имени занимает пару секунд, а любой автокомплит в какой-то степени отвлекает пользователя.

Автодополенение ранее использованного логина при авторизации. Если в приложении нет переключения между аккаунтами, как в официальном Twitter или Gmail, полезно при входе автодополнять ранее использованные e-mail/логины. Например, Instagram показывает последний использованный логин. Правда, такой способ не подходит для финансовых приложений, так как в них важна безопасность. Если пользователь вышел из приложения, то никто не должен знать, какой логин он использовал.

Автоопределение ♀ ♂. Приложения могут определять пол по введённому имени. Сервис genderize.io содержит базу из 200 000+ имён, 79 стран и 89 языков. 100 000 запросов в месяц стоят $9. Есть SDK для обеих платформ. В Android можно попробовать получить пол из аккаунта Google+. К сожалению, он не всегда проставлен пользователем, а в России G+ вообще мало используют.

Автодополнение адреса ускоряет ввод в формах оформления заказа, иногда такое поле присутствует в форме регистрации. Есть хороший обзор сервисов , решающих задачу.

Пароли

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

Пароль при вводе принято скрывать точками. Полезна кнопка «показать пароль» - она особенно важна на экране регистрации, если мы не просим пользователя ввести пароль дважды. Это интересно реализовано в спортивных трекерах Runtastic : пароль отображается, кнопка «глаз» зажата.

Восстановление пароля - задача не первостепенная. В большинстве топовых приложений пользователя для этого отправляют на веб-страницу. Восстановление не должно быть отдельным экраном, открывающимся в браузере, его можно реализовать на экране авторизации с помощью простых анимаций. Отличные примеры: Airbnb , Tumblr , Runtastic .

Восстановление пароля в Tumblr iOS

Проверка полей, клавиатуры и оферта

Правильность заполнения полей важно проверять в самом приложении. Валидация на стороне сервера занимает время пользователя, и это его раздражает. Это правило относится и к проверке доступных логинов/e-mail, которая должна работать «на лету». Хорошие примеры -  Яндекс Музыка , Twitter.

Для всех разных типов полей важно использовать соответствующие типы клавиатуры: iOS , Android . Если пользователь вводит почту, на клавиатуре должен быть знак @, цифры для ввода номера и т.д.

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

Соц. сети

Это простейший для пользователя способ входа: ему не нужно заполнять логин и пароль вручную. Кнопки соцсетей резонно сортировать по частоте использования в зависимости от платформы и страны. Google+ удобнее для Android, VK есть у большинства пользователей в России, и т.д. Так поступает сервис Foursquare в Android.

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

Схема работы официальных SDK

Номер телефона и код подтверждения

В Android можно сделать автокомплит номера из SIM-карты, однако это работает не на всех устройствах, поэтому в коде нужно учитывать возможные ошибки. На практике я не нашёл приложений, которые так делают, но применение такого способа вполне допустимо.

После ввода и отправки номера пользователю нужно ввести код из SMS. Android-приложение может делать это автоматически. Этот прием используют Viber, Telegram, Rocketbank. Важно лишь объяснить пользователю, что скоро придёт SMS, нужно только немного подождать.

Fabric Digits. У Twitter есть бесплатное готовое решение для авторизации через телефонный номер. Это SMS-шлюз + мобильные и веб SDK. Внешний вид интерфейса в определённых рамках можно настраивать. Это наиболее простое решение задачи из коробки.

Fabric Digits

Заключение

Здесь я постарался изложить все мысли по поводу входа в приложение и работы с формами, которые сформулировал за последнее время. Эта заметка - своего рода чек-лист, надеюсь, она будет вам полезна. Если есть вопросы, пишите: [email protected]

, PHP , Системы обмена сообщениями

Мы рады представить сообществу сервис PushAuth , который позволяет Вашим клиентам авторизироваться с помощью PUSH-сообщений на мобильном устройстве!



Эта идея не новая и многие компании в своих приложениях уже используют эту технологию. Всё выглядит достаточно просто, пока не рассматриваешь вопросы: безопасности, менеджмента устройств и клиентов, совместимости и комфортной работы.

Как возникла идея?

Мы используем очень много сервисов: email, социальные сети, CRM-системы, системы контроля доступа, клиент-банки и тд. У каждого из сервисов, как правильно, для доступа необходимо использовать логин/email и пароль . Можно уже сделать вывод, что:

  1. Практически у каждого из нас есть email.
  2. Пароли в большинстве случаев везде одинаковые. (Будем считать, что мы не используем сторонние сервисы, такие как 1password и другие)

Исходя из двух пунктов, хотелось:

  1. Использовать этот один email для авторизации.
  2. Не использовать пароли вообще.

Что из этого вышло?

Мы в мобильных приложениях для регистрации не используем паролей вообще . Да, нет необходимости запоминать ещё один пароль. Для регистрации/авторизации в мобильном приложении достаточно ввести только email, на который прийдёт письмо со ссылкой для подтверждения действия. После следующего ввода email - Вы автоматически войдёте в приложение без регистрации.

Какие виды авторизации?

Сейчас доступно два основных вида запросов на авторизацию:

  1. Push вопрос на авторизацию, в котором клиенту необходимо дать ответ: Да или Нет. Для данного способа доступен сервис routing , о котором чуть ниже.
  2. Безопасный Push-код , которые владелец сервиса сам отправляет в мобильное приложение клиента по средству сервиса PushAuth.
  3. QR-авторизация , которая позволяет сканировать код мобильным приложением клиента и пройти авторизацию. Данный способ уже на стадии закрытого тестирования мобильными приложениями и в ближайшее время так же станет доступен.

Мобильные приложения

  • Для доставки PUSH-сообщений на Android & iOS мы используем FireBase Cloud Messaging. Все данные передаваемые от мобильного приложения к серверу PushAuth подписываются HMAC SHA-256, персональными приватными ключами.
  • Мобильное приложение имеет дополнительно защиту PIN-кодом (TouchID-паролем), что повышает уровень безопасности от несанкционированного доступа.
  • Мы планируем разрабатывать SDK, которое позволит использовать функционал API в Ваших мобильных приложениях.
  • Клиенты могут иметь сразу 10 устройств, на которые смогут прийти PUSH-запросы. Ответив на одном из устройств, на остальных устройствах ответы на Push игнорируются. Мы планируем прятать Push-сообщения на других устройствах при ответе на одном.


Push-вопрос



Безопасный Push-код


Приложения уже доступны:

Backend


Для владельцев сервисов доступна детальная статистика об статусах авторизации их клиентов. Вы можете создавать для каждого сервиса свой отдельный Application и следить за его использованием. Кроме того, Вы можете настроить Web-хуки, которые будут отправлять данные об авторизации:

  • QR-кодов
  • Push-запросов
  • TimeOut ответов клиентов

Где это можно использовать?

CRM

Начнём наш полёт фантазии с IT-сервисов, например тех же CRM-систем, где есть необходимость подтверждать действие сотрудника. Например, благодаря сервису routing , возможно сделать так, что для подписания документа, необходимо подтверждение руководства. Таким образом картина в целом выглядит так:

  1. Сотрудник инициирует действие и получает PUSH-запрос и отвечает Да .
  2. Его непосредственный начальник получает PUSH-запрос и отвечает Да .
  3. Выше стоящий руководитель получает PUSH-запрос и отвечает Да .
  4. Результатом всех действий будет Да

Если на каком-то этапе кто-то ответит Нет , то следующее вышестоящее звено не получит PUSH-запрос и общим результатом запросов будет ответ Нет


Выше мы описали работу сервиса routing с очерёдностью. Но данный сервис возможно использовать и без очерёдности. Это означает, что все звенья цепочки (сотрудники) получат одновременно PUSH-запрос. И только если все из них ответят положительно, только тогда общий результат запросов будет положительным.

Web-site

Двух-факторная или простая одно-факторная авторизация на сайте может упростить или обезопасить доступ к внутренним ресурсам. Например для доступа к web-панели администратора того же WordPress, когда Вы даёте доступ своему подрядчику/разработчику и хотите строго контролировать его по средству Push-запросов авторизации.

OS

Используете SSH/telnet доступ? Либо хотите открывая крышку ноутбука получать запрос об авторизации? Тогда этот сервис будет просто идеальным вариантом.

Инженерия и оборудование

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

Безопасность


Это самый важный вопрос в этом сервисе. Стоит обратить на такие вещи, как обмен данными между Сервисом пользователя <--> Сервер PushAuth <--> Приложение клиента.
Все данные передаются over HTTPS (TLS), с подписью HMAC, алгоритмом SHA-256. У каждого клиента и пользователя сервиса есть своя пара Public & Private Key. Публичный ключ в нашем случае необходим для идентификации в общем сетевом хранилище и может передаваться в открытом виде. Приватный ключ передаётся надёжным способом. В случае мобильного приложения - все ключи передаются только через APN/GCM. Таким образом мы обеспечиваем дополнительную защиту на уровне сертификатов данных сервисов.

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

Intro

Основа любой персонализации - это собственный аккаунт для каждого пользователя. Но так уж устроен человек, что мало кто захочет тратить время на скучную регистрацию, - у пользователей уже есть Instagram, Twitter и Facebook, для новых аккаунтов в голове места может и не хватить. Тут даже незачем далеко ходить за примером - загляни в свое сердце:). Представь, что ты пользователь, - на одного тебя в Google Play приходятся десятки полезных приложений, но регистрироваться в каждом из них у тебя наверняка нет никакого желания.

Так появилась технология OAuth - механизм авторизации пользователя на сторонних ресурсах с помощью доверенной третьей стороны. Этот сервис стал чрезвычайно популярным: Instagram, Facebook и многие другие крупные проекты теперь позволяют своим пользователям быстро пройти авторизацию на стороннем ресурсе. Присоединяйся и ты: даже в небольшом проекте сегодня имеет смысл реализовать OAuth - пользователи уже привыкли к этому механизму.

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

Замечу, что OAuth пришел в мобильные устройства из Web’а, поэтому, даже если ты далек от Java и Android, информация о том, как устроен такой механизм авторизации, все равно может тебе пригодиться.

Устройство OAuth

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

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

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

При этом аутентификация здесь тоже есть и происходит на этапах 1–3, но протекает незримо для нас с помощью встроенного в OAuth протокола OpenID. В этом протоколе реализовано немного криптографической магии, описание которой потребует нескольких таких статей, поэтому ее мы сегодня затрагивать не будем.

Реализация

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

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «сайт», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score!