Подробное сравнение популярных SMS/Voice сервисов для рассылок и авторизаций / Хабр

Что такое аутентификация?

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

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

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

Основные поля

Кратко остановимся на том, какие есть стандартные полях в токене и зачем они нужны:

Что в итоге?

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

Но эта аутентификация не должна реализовываться как MVP, ее нужно сразу продумывать. Цена ошибки здесь заметно выше, чем при прямой авторизации, нужно учитывать то, что соцсети – это сторонние сервисы со своими разработчиками и регулярными изменениями.

Готовые библиотеки для OAuth2.0 и OpenID Connect сэкономят время и упростят процесс интеграции, но совсем всё на себя не возьмут. Если вы только начинаете проект, то стоит посмотреть в сторону готовых провайдеров аутентификации. Однако надо быть готовым, что при развитии проекта потребуется какая-то доработка. И своё решение с учётом перспектив окажется предпочтительнее.

Что делать?

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

1. Какие данные из соцсетей нужны вашей платформе кроме ID-пользователя/email – будет ли у вас интеграция или требуется только аутентификация?
2. Что делать если не получен email из социальной сети – как будут связываться учётные записи, зарегистрированные через разные соцсети и прямую регистрацию на платформе и нужно ли это вообще? Что делать, если нет нужно идентификатора? Например, VK использует мобильный телефон как идентификатор, а почту – как дополнительный.
3. Будет ли расширяться/меняться список социальных сетей – может быть ваша целевая аудитория сидит в одной соцсети и вам не нужно несколько интеграций?
4. Будет ли аутентификация через социальные сети на мобильных клиентах – а есть ли вообще у вас аутентификация в мобильном приложении?

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

Мы на эти вопросы ответили вот так:

Авторизация по номеру телефона

При такой авторизации требуется подтвердить номер телефона, вводом кода подтверждения, полученного по SMS. Отдельный экран «Регистрация» не требуется, так как при авторизации сервер сам может определить является ли данный пользователь новым или ранее он уже регистрировался.

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

Минусы: не подходит для приложений, которые используют миллионы, рассылка SMS требует затрат. По состоянию на 01.04.2021 средняя стоимость SMS 3,5-4 рубля.

Авторизация с применением только номера телефона очень проста, но может быть использована, если количество пользователей приложения не превышает несколько сотен. Лучше если аудитория приложения локализована в рамках одной страны. Например, России. Это связано с необходимостью рассылки SMS.

Нет необходимости реализовывать процедуру восстановления пароля (сброс пароля), так как пароль не используется.

Смена номера телефона для пользователя не доступна. Сменить номер телефона пользователя может только администратор через Админ панель.

Авторизация по номеру телефона и паролю

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

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

Авторизация через Google-аккаунт

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

Forms authentication

А в социальных сетях как?

Несмотря на детальную спецификацию, стандарты OAuth2 и OpenID Connect оставляют большой простор для конкретной реализации. И подключение различных социальных сетей для аутентификации иногда напоминает поход по минному полю. На WASD.TV мы наладили поддержку 6 соцсетей. Вот, что мы узнали о каждой из них в ходе настройки.

У VK нет поддержки OpenID Connect и refresh-токенов. Если требуется долгая сессия, пользователю будет выдан бессрочный access-токен.

Также при интеграции с VK следует учесть, здесь уже много лет основной способ идентификации пользователя – номер мобильного телефона.

Аутентификация по ключам доступа

Этот способ чаще всего используется для аутентификации устройств, сервисов или других приложений при обращении к веб-сервисам. Здесь в качестве секрета применяются ключи доступа (
access key, API key

Аутентификация по одноразовым паролям

Аутентификация по одноразовым паролям обычно применяется дополнительно к аутентификации по паролям для реализации
two-factor authentication
(2FA). В этой концепции пользователю необходимо предоставить данные двух типов для входа в систему: что-то, что он знает (например, пароль), и что-то, чем он владеет (например, устройство для генерации одноразовых паролей). Наличие двух факторов позволяет в значительной степени увеличить уровень безопасности, что м. б. востребовано для определенных видов веб-приложений.

Другой популярный сценарий использования одноразовых паролей — дополнительная аутентификация пользователя во время выполнения важных действий: перевод денег, изменение настроек и т. п.

Существуют разные источники для создания одноразовых паролей. Наиболее популярные:

1. Аппаратные или программные токены, которые могут генерировать одноразовые пароли на основании секретного ключа, введенного в них, и текущего времени. Секретные ключи пользователей, являющиеся фактором владения, также хранятся на сервере, что позволяет выполнить проверку введенных одноразовых паролей. Пример аппаратной реализаций токенов — RSA SecurID; программной — приложение Google Authenticator.
2. Случайно генерируемые коды, передаваемые пользователю через SMS или другой канал связи. В этой ситуации фактор владения — телефон пользователя (точнее — SIM-карта, привязанная к определенному номеру).
3. Распечатка или scratch card со списком заранее сформированных одноразовых паролей. Для каждого нового входа в систему требуется ввести новый одноразовый пароль с указанным номером.

Аппаратный токен RSA SecurID генерирует новый код каждые 30 секунд.

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

Аутентификация по сертификатам

Сертификат представляет собой набор атрибутов, идентифицирующих владельца, подписанный
certificate authority
(CA). CA выступает в роли посредника, который гарантирует подлинность сертификатов (по аналогии с ФМС, выпускающей паспорта). Также сертификат криптографически связан с закрытым ключом, который хранится у владельца сертификата и позволяет однозначно подтвердить факт владения сертификатом.

На стороне клиента сертификат вместе с закрытым ключом могут храниться в операционной системе, в браузере, в файле, на отдельном физическом устройстве (smart card, USB token). Обычно закрытый ключ дополнительно защищен паролем или PIN-кодом.

В веб-приложениях традиционно используют сертификаты стандарта X.509. Аутентификация с помощью X.509-сертификата происходит в момент соединения с сервером и является частью протокола SSL/TLS. Этот механизм также хорошо поддерживается браузерами, которые позволяют пользователю выбрать и применить сертификат, если веб-сайт допускает такой способ аутентификации.

Использование сертификата для аутентификации.

Во время аутентификации сервер выполняет проверку сертификата на основании следующих правил:

1. Сертификат должен быть подписан доверенным certification authority (проверка цепочки сертификатов).
2. Сертификат должен быть действительным на текущую дату (проверка срока действия).
3. Сертификат не должен быть отозван соответствующим CA (проверка списков исключения).

Пример X.509 сертификата.

После успешной аутентификации веб-приложение может выполнить авторизацию запроса на основании таких данных сертификата, как subject (имя владельца), issuer (эмитент), serial number (серийный номер сертификата) или thumbprint (отпечаток открытого ключа сертификата).

Использование сертификатов для аутентификации — куда более надежный способ, чем аутентификация посредством паролей. Это достигается созданием в процессе аутентификации цифровой подписи, наличие которой доказывает факт применения закрытого ключа в конкретной ситуации (non-repudiation).

Аутентификация по токенам

Такой способ аутентификации чаще всего применяется при построении распределенных систем
Single Sign-On
(SSO), где одно приложение (
service provider
или
relying party
) делегирует функцию аутентификации пользователей другому приложению (
identity provider
или
authentication service
). Типичный пример этого способа — вход в приложение через учетную запись в социальных сетях. Здесь социальные сети являются сервисами аутентификации, а приложение
доверяет
функцию аутентификации пользователей социальным сетям.

Реализация этого способа заключается в том, что identity provider (IP) предоставляет достоверные сведения о пользователе в виде токена, а service provider (SP) приложение использует этот токен для идентификации, аутентификации и авторизации пользователя.На общем уровне, весь процесс выглядит следующим образом:

1. Клиент аутентифицируется в identity provider одним из способов, специфичным для него (пароль, ключ доступа, сертификат, Kerberos, итд.).
2. Клиент просит identity provider предоставить ему токен для конкретного SP-приложения. Identity provider генерирует токен и отправляет его клиенту.
3. Клиент аутентифицируется в SP-приложении при помощи этого токена.

Пример аутентификации «активного» клиента при помощи токена, переданного посредством Bearer схемы.

Процесс, описанный выше, отражает механизм аутентификации активного клиента, т. е. такого, который может выполнять запрограммированную последовательность действий (например, iOS/Android приложения). Браузер же — пассивный клиент в том смысле, что он только может отображать страницы, запрошенные пользователем.

Пример аутентификации «пассивного» клиента посредством перенаправления запросов.

Существует несколько стандартов, в точности определяющих протокол взаимодействия между клиентами (активными и пассивными) и IP/SP-приложениями и формат поддерживаемых токенов. Среди наиболее популярных стандартов — OAuth, OpenID Connect, SAML, и WS-Federation. Некоторая информация об этих протоколах — ниже в статье.

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

При аутентификации с помощью токена SP-приложение должно выполнить следующие проверки:

1. Токен был выдан доверенным identity provider приложением (проверка поля issuer).
2. Токен предназначается текущему SP-приложению (проверка поля audience).
3. Срок действия токена еще не истек (проверка поля expiration date).
4. Токен подлинный и не был изменен (проверка подписи).

В случае успешной проверки SP-приложение выполняет авторизацию запроса на основании данных о пользователе, содержащихся в токене.

Боли, с которыми столкнулись

К сожалению, проблемы тоже встречались. Живое тестирование с реальными соцсетями — это весьма трудоёмкий процесс. Так что моки – наше всё, но надо их актуализировать при изменении в API соцсетей. Если есть ресурсы – стоит написать автотесты для соцсети с реальным выполнение процесса аутентификации в браузере, у нас на проекте такие есть.

Ещё одна боль – это контроль учётных записей, как сервисных, так и тестовых. Их потребуется как минимум три: для получения кред прода, для получения кред тестовых стендов и учётная запись тестового пользователя в соцсести. Ряд соцсетей требует телефонный номер для регистрации или проверки 2FA, поэтому подумайте, как несколько разработчиков и тестировщиков получат к нему доступ. Мы для этого обзавелись виртуальным номером.

Взгляд сверху

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

Выбор велосипеда

Для реализации интеграции с социальными сетями можно пойти двумя путями – выбрать готовое, коммерческое или Open Source решение, или написать своё. Далее рассмотрены плюсы и минусы разных подходов.

Готовый велосипед

Есть много готовых Open Source решений, среди широко известных — Ory/Kratos и Keycloak.

Плюсы очевидны:

Но также очевидны и минусы:

• Эти решения – комбайны, включающие, в том числе, и прямую аутентификацию, хранение и управление профилями пользователей и многое другое. Нельзя частично переехать на них, это создаст сложности для разработки и инфраструктуры. Если вы только начинаете и экспериментируете – переезд будет легким, но если у вас уже сотня тысяч и более пользователей, такой переход может окончиться провалом. Например, из-за отличий в формате хеша паролей в вашей самописной системе аутентификации и в таком комбайне.
• Поддержка не всех требуемых соцсетей. Пример с Apple наиболее наглядный, также нам не встретилось обновление токена для Twitch. Конечно, почти всегда есть API и можно сделать расширение. Но тут всё зависит от фантазии разработчиков соцсети. Возможно придётся сделать свой форк провайдера аутентификации и уже самостоятельно его поддерживать.
• Можно исследовать и другие Open Source решения, но в целом плюсы и минусы будут аналогичные.

Свой велосипед

У своего решения также очевидны плюсы и минусы:

Минус – это ваш крест и вам его нести, обеспечивая поддержку и развитие.

Оценив все плюсы и минусы, мы решили написать свой сервис.

Выбор способа авторизации

Для выбора способов авторизации надо ответить на следующие вопросы.

1. Какова потенциальная численность будущей аудитории пользователей приложения? Это сотни или миллионы людей?
2. Каковы характеристики целевой аудитории приложения (возраст, интересы)?
3. Как использует интернет потенциальная целевая аудитория?
4. Какая география будущих пользователей мобильного приложения?

Ответив на эти вопросы можно легко выбрать способ авторизации. Если планируется разработка мобильного приложения с «нуля», то лучше сразу спроектировать сервер Админ панели приложения с учетом поддержки выбранных способов авторизации.

Запрос на аутентификацию

Authentication/Token Request — процесс запроса аутентификации.

В зависимости от того какие области (scopes) запрошены, сервис выдачи токенов вернет:

1. Только Identity Token, если запрошены только Identity scopes.
2. Identity Token и Access Token, если запрошены также и Resources scopes.
3. Access Token и Refresh Token, если запрошeн Offline Access.

Более подробно про процесс аутентификации можно прочесть в разделе «

Зачем это, вообще, нужно?

Сперва, мне показался такой запрос достаточно странным, клиенты рассчитывали на раскрутку до 100-200 тыс пользователей. Учитывая, какой нужно бюджет на такую рекламу, то затраты в 1,5р на авторизацию каждого пользователя вроде не большие деньги. С другой стороны, 150-300 тыс на дороге тоже не валяются, а учитывая, что за весь LTV человек может авторизоваться несколько раз (стёр куку, удалил и поставил приложение, был авторизован в приложении и решил авторизоваться на сайте)

Получив такую обратную связь начал изучать кто ещё жалуется на неудобство авторизации СМС. Нашёл две проблемы и обе влияют на конверсию из установки в авторизацию.

Проблема №1. Куда я попал? Она чаще всего присутствует на малоизвестных проектах, которые сразу при входе просят авторизоваться по СМС. Не доверяя проекту пользователю достаточно тяжело расстаться со своим номером телефона – многие боятся, что начнут звонить спамеры.

Проблема №2. Я устал, я ухожу… Сама авторизация по СМС для человека достаточно затратная с точки зрения количества прилагаемых усилий. Все давно уже выучили, что чем меньше кликов, тем выше конверсия. Давайте посчитаем действия, которые должен выполнить пользователь, чтоб авторизоваться по СМС:

Получается, чтобы начать пользоваться сервисом, человек должен правильно выполнить все 6 действий и, при этом, мотивация получить итоговый результат должна быть крайне сильна. Многие владельцы приложений рассказывали, что из установки в регистрацию доходят всего 40% клиентов. Т.е.

Клиент

Client — устройство или программа (браузер, приложение), которым требуется либо токен для аутентификации пользователя, либо токен для доступа к какому-то ресурсу (подразумевается, что данный ресурс «знаком» с тем конкретным «

» у которого клиент запрашивает токен для доступа).

Конкуренты

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

Я думаю, что логичнее брать деньги просто за установку и передавать владельцу всю инфраструктуру (использовать его базу и АТС). При этом, у владельца будут дополнительные платежи только за АТС (600р./мес за 8-800 и 120р./мес за московский номер). Других трат нет.

Пишите мне в личку или на сайт у кого есть аналогичная задача – собрать номера, но облегчить авторизацию для клиентов.

Лайфхак напоследок

Интересный лайфак заключается в том, что даже проектам с буквенной подписью можно пользоваться сразу несколькими провайдерами SMS, что позволяет существенно экономить, создавая комбинированные схемы использования.

Область (scope)

Scope — идентификатор ресурса, к которому клиент хочет получить доступ. Список scope посылается в адрес

в составе

По умолчанию все клиенты имеют возможность запрашивать любые области, но это можно (и нужно) ограничивать в конфигурации сервиса выдачи токенов.

Scopes бывают двух видов:

1. Identity scopes — это запрос информации о пользователе. Его имя, профиль, пол, фотография, адрес электронной почты и т. д.
2. Resource scopes — имена внешних ресурсо (Web APIs), к которым клиент хочет получить доступ.

Поддержка клиента

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

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

Процесс аутентификации

Разбираемся детально ху из ху

В данный момент на слуху следующие протоколы:

1. OpenID — для проверки учетных данных пользователя (identification & authentication).
2. OAuth — про то, чтобы получать доступ к чему-то.
3. OpenID Connect — и про и то, и про другое одновременно.

Сервис выдачи токенов

Open ID Connect Provider — важнейший объект всей конструкции централизованного сервиса аутентификации, он также может называться Security Token Service, Identity Provider authorization server и т. д. Различные источники называют его по-разному, но по смыслу это сервис, который выдает токены клиентам.

Основные функции:

Сервис для аутентификации через соцсети

Микросервис для аутентификации мы назвали social-oauth2. Функционал сервиса охватывает все возможные флоу:

1. штатная аутентификация с frontend;

2. аутентификация с frontend при отсутствии ассоциации (связи) с учётной записью в социальной сети:

3. аутентификация пользователя из мобильного приложения по всем вышеперечисленным флоу.

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

Флоу штатной аутентификации

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

Код авторизации передаётся в соцсеть вместе с необходимыми сервисным кредами. В ответ получаем access-токен, с ним обращаемся в API соцсети за профилем пользователя, откуда получаем ID пользователя. По ID в соцсети ищем пользователя на нашей платформе и в случае успеха выдаём токены клиенту. Токены генерирует наш форк сервиса Hydra.

Что под капотом?

Сервис написан на go, база храниться в PostgreSQL, для реализации локов на строки в БД при обновлении токенов используется Redis. Запускается в docker-контейнере, настройки получает при запуске из переменных среды.

Способы авторизации в мобильном приложении

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

Способы оплаты

Что же касается способов оплат, то разумеется западный рынок SMS выглядит здесь более «Белым». Все представленные сервисы не работали с WM, Яндекс.Деньги или какими-либо другими российскими системами.

Надеемся пост оказался полезен для тех, кто собирается делать в своем приложении авторизацию на базе SMS или же пользоваться рассылками.

Стандарт saml

Стандарт Security Assertion Markup Language (SAML) описывает способы взаимодействия и протоколы между identity provider и service provider для обмена данными аутентификации и авторизации посредством токенов. Изначально версии 1.0 и 1.1 были выпущены в 2002 – 2003 гг., в то время как версия 2.0, значительно расширяющая стандарт и обратно несовместимая, опубликована в 2005 г.

Этот основополагающий стандарт — достаточно сложный и поддерживает много различных сценариев интеграции систем. Основные «строительные блоки» стандарта:

Стандарты ws-trust и ws-federation

WS-Trust и WS-Federation входят в группу стандартов WS-*, описывающих SOAP/XML-веб сервисы. Эти стандарты разрабатываются группой компаний, куда входят Microsoft, IBM, VeriSign и другие. Наряду с SAML, эти стандарты достаточно сложные, используются преимущественно в корпоративных сценариях.

Стандарт WS-Trust описывает интерфейс сервиса авторизации, именуемого Secure Token Service (STS). Этот сервис работает по протоколу SOAP и поддерживает создание, обновление и аннулирование токенов. При этом стандарт допускает использование токенов различного формата, однако на практике в основном используются SAML-токены.

Стандарт WS-Federation касается механизмов взаимодействия сервисов между компаниями, в частности, протоколов обмена токенов. При этом WS-Federation расширяет функции и интерфейс сервиса STS, описанного в стандарте WS-Trust. Среди прочего, стандарт WS-Federation определяет:

Можно сказать, что WS-Federation позволяет решить те же задачи, что и SAML, однако их подходы и реализация в некоторой степени отличаются.

Технологии и сервисы

Вторым важным аспектом является «А что собственно может сервис?». Для многих мобильных проектов важно наличие SDK для интеграции, более быстрой разработки голосовых сервисов и подобных решений. Некоторые будут использовать сервис только для рассылок и/или уведомлений.

Как видно из данной таблицы, российский рынок SMS-гейтов нацелен в первую очередь на массовые рассылки сообщений и уведомления пользователей. Тогда как западный рынок в первую очередь создает платформы для сервисного использования SMS. Такие вещи как мобильный SDK — практически диковинка на данном рынке.

Text-to-Speech — довольно трендовая функция для авторизации, которая заключается в обратном звонке от сервиса, когда робот проговаривает, к примеру, код авторизации. Удобная вещь для людей с ограниченными возможностями, а также в том случае, если наблюдаются проблемы с доставкой SMS.

Токен доступа

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

Токен личности

Identity Token — подтверждение аутентификации. Этот токен содержит минимальный набор информации о пользователе.

Токен обновления

Refresh Token — токен, по которому STS вернет новый Access Token. В зависимости от режима работы, Refresh Token может быть многоразовым и одноразовым. В случае с одноразовым токеном, при запросе нового Access Token будет также сформирован готовый Refresh Token, который следует использовать при повторном обновлении. Очевидно, что одноразовые токены более безопасны.

Более подробно о составе токенов в разделе «структура токена».

Удобство интеграции

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

Формат

Форматы токенов

Существует несколько распространенных форматов токенов для веб-приложений:

Экономика и деньги

Тарифные сетки SMS-гейтов различны, некоторые имеют фиксированный тариф на любой объем и вне зависимости от оператора доставки, некоторые напротив — имеют сложную тарифну сетку. Мы решили отталкиваться от самых высоких цен «в лоб» за 1 сообщение. Что интересно, даже некоторые западные сервисы, такие как Twilio, имеют разные тарифы для каждого из российских операторов.

Все расчеты приведены по ставкам за рассылки с буквенной подписью:

Заключение

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

Больше о наших решениях в мобильной разработке читайте в нашем портфолио.

Заключение первой части

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

Stay tuned.

public void Configuration(IAppBuilder app)
{
    var factory = new IdentityServerServiceFactory();
    factory.UseInMemoryClients(Clients.Get())
           .UseInMemoryScopes(Scopes.Get())
           .UseInMemoryUsers(Users.Get());

    var options = new IdentityServerOptions
    {
        SiteName = Constants.IdentityServerName,
        SigningCertificate = Certificate.Get(),
        Factory = factory,
    };

    app.UseIdentityServer(options);
}

public void Configuration(IAppBuilder app)
{
    app.UseCookieAuthentication(new CookieAuthenticationOptions
    {
        AuthenticationType = "Cookies"
    });

    app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
    {
        ClientId = Constants.ClientName,
        Authority = Constants.IdentityServerAddress,
        RedirectUri = Constants.ClientReturnUrl,
        ResponseType = "id_token",
        Scope = "openid email",
        SignInAsAuthenticationType = "Cookies",
    });
}

public void Configuration(IAppBuilder app)
{
    app.UseIdentityServerBearerTokenAuthentication(
        new IdentityServerBearerTokenAuthenticationOptions
        {
            Authority = Constants.IdentityServerAddress,
            RequiredScopes = new[] { "write" },
            ValidationMode = ValidationMode.Local,

            // credentials for the introspection endpoint
            ClientId = "write",
            ClientSecret = "secret"
        });

    app.UseWebApi(WebApiConfig.Register());
}