Вам нужно создавать собственную систему аутентификации для приложений?

Бэкграунд#

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

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

Введение#

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

Это было незначительной частью, так как все было прямолинейно еще 20 лет назад:

• Реализовать систему регистрации и входа с использованием имени пользователя и пароля.
• Создать механизм для поддержания сессии пользователя.
• Что касается безопасности? Ответ - MD5.

Вот и все. Тогда я мог сконцентрироваться на "реальном бизнесе". Не слышали о MD5? Вы упустили "хорошие времена" разработки программного обеспечения. В наше время разработчикам приходится сталкиваться с большим количеством проблем при создании системы входа/регистрации.

Это звучит пугающе, но позвольте мне объяснить на примере.

Пример: Интернет-магазин книг#

Допустим, вы пытаетесь создать интернет-магазин книг со службой API и веб-приложением.

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

Я написал статью CIAM 101: Аутентификация, Идентификация, Единый вход для обсуждения этих концепций подробно.

Выберите методы аутентификации#

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

• Без пароля, то есть динамический проверочный код (через электронную почту или SMS)
• Вход через социальные сети (Google, Facebook и т.д.)

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

• Для метода без пароля вам нужно найти поставщика, который будет отправлять проверочные коды по электронной почте или SMS; затем интегрироваться с вашим API-сервисом (может потребоваться новые API).
• Для входа через соцсети вы должны придерживаться инструкций по интеграции поставщиков социальной идентификации, которых вы хотите использовать. Кроме того, вы должны создать соответствие между ID пользователей вашего магазина книг и ID поставщика идентификации.
  • Например, когда пользователь входит в систему с аккаунтом Gmail [email protected], вы можете связать этот электронный адрес с пользователем foo в магазине книг. Этот процесс помогает вам создать единую систему идентификации и позволяет пользователю изменять или разрывать связь с их социальной идентификацией в будущем.

Проектирование и реализация входа в систему#

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

Когда я работал в Airbnb, была целая команда, которая занималась оптимизацией процесса входа в систему на разных платформах. Они проводили много A/B-тестов, чтобы определить, какое сочетание обладает наибольшей конверсией.

Делать это на ранних стадиях бизнеса не практично. Но мы все равно должны стараться сделать все правильно. На каких платформах вы хотели бы запустить магазин книг? Возможно, вы начнете с мобильных устройств, веб-версии или обоих. Точное проектирование будет зависеть от выбранных вами методов аутентификации:

• Имя пользователя и пароль: Это самый простой способ, просто несколько полей для ввода и кнопок.
• Без пароля: Введите номер телефона / электронную почту, затем отправьте и проверьте динамический код.
• Вход через соцсети: Прочитайте документацию от выбранного поставщика социальной идентификации, следуйте визуальному руководству, обработайте логику перенаправления и, наконец, свяжите социальную идентификацию с идентификацией в магазине книг.

Есть еще несколько вещей, которые стоит учесть, чтобы сделать все еще лучше:

• Вам нужно соединить процесс входа в систему и регистрации для конкретного метода?
• Вам нужен процесс "забыл пароль", чтобы позволить клиентам самостоятельно сбрасывать пароли?

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

Безопасность и обмен токенами#

Безопасность может быть скрытым айсбергом. Было бы здорово, если бы вы ознакомились с OpenID Connect или OAuth 2.0, так как они широко используются и проверены временем. OpenID Connect относительно новый, но предназначен для "проверки подлинности пользователей", что очень подходит для интернет-магазина книг.

Не вдаваясь в подробности стандартов, все же есть некоторые вещи, которые стоит учесть:

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

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

Модель авторизации#

В качестве магазина книг вам нужно разделить ресурсы для клиентов и продавцов. Например, клиенты могут просматривать все книги, а продавцы могут управлять своими книгами на продажу. Нормально начать с простых проверок if-else; однако по мере роста бизнеса, вы, возможно, захотите использовать более гибкую модель, такую как Role-based Access Control (RBAC) или Attribute-based Access Control (ABAC).

Я также написал статью CIAM 102: Авторизация и доступ на основе ролей, чтобы обсудить основные концепции авторизации и модель RBAC.

Принятие решения#

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

Чтобы принять решение, я задам себе следующие вопросы:

• Насколько срочен проект?
• Сколько усилий я ожидаю вложить в аутентификацию по сравнению с бизнесом?
• Каков приоритет пользовательского опыта, безопасности и поддерживаемости?
• Над какой(ими) частью(ями) мне нужен полный контроль? Насколько хорошо я должен их знать?
• Если я выбираю некоторые фреймворки / решения, насколько они подходят для настройки или расширения?
• Если бизнес растет, мне нужно ли вводить новую модель аутентификации?
• Если я нашел подходящего поставщика, насколько безопасно его использование? Нужен ли мне план по выходу, если с поставщиком что-то случится?

Учитывая эти вопросы, я обнаружил два факта:

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

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

Надеюсь, эта статья будет вам полезна.