Это следующая статья на тему механизмов авторизации пользователей.
Сразу сделаю ремарку - я основатель Авторизы - SaaS-сервиса аутентификации и авторизации для онлайн-систем, но давайте сразу отбросим скепсис. Я не для рекламы это пишу, а рассказать, с какими проблемами столкнулся и почему вообще затеял этот стартап. Конечно, если вдруг у меня получится этой статьей привлечь вас к использованию Авторизы - я буду рад, чего лукавить.
Давайте представлюсь - меня зовут Александр Калинин, я уже около двадцати лет в IT, работал в самых разных ролях - от сисадмина до руководителя отделов и продуктов, но большую часть я ручками кодил в web-разработке. Имею степень MBA в стратегическом менеджменте. Работал на Лукойл, Intesa SP, Banka IMI, расчетно-кассовый центр на 200 тысяч абонентов и др.
За это время мне довелось поучаствовать во многих IT-проектах. И в большинстве из них - с самого начала, с “нуля”. А с чего начинается любой проект, в котором есть дифференциация пользователей или ролей (то есть любой мало-мальски крупный)? После сбора требований, выбора стека, архитектуры и так далее, наступает момент когда надо пилить авторизацию.
Логин,
пароль,
e-mail,
роли,
сценарии,
проверки,
токены,
куки,
базы данных,
UI,
тестирование,
безопасность,
… (это далеко не полный список).
Забегая вперед скажу, что сейчас уже создано много сценариев для решения этой проблемы, но у них есть свои минусы.
Сами сможем?
А почему нет? Команда начинала это пилить. Почти всегда это сопровождалось словами “Да чё там делать?! Я сто раз так делал. За неделю максимум управимся.” А потом две недели пилила (минимум!), и еще в течении полугода неоднократно фиксила баги и дополняла функционал. Кому знакомо?
И здесь нет вины разработчика. В разработке никогда не бывает задачи “один в один” - иначе можно было бы просто скопировать пару файлов и двигаться дальше. Субъективно кажется - все просто, а если просто, то и быстро. Пока не начнется “тут забыли прикрутить, а тут в ТЗ не прописали, а об этом я не подумал”. Да и что греха таить - как бы нам всем не хотелось быть супер-мега профессионалами, которые все знают и никогда не совершают ошибок, такого не бывает.
Кто из вас без греха, пусть первым бросит в неё камень
А часто бывает еще, что такие вещи достаются разработчикам средней, или около того, квалификации.
На самом деле таких процессов в разработке много - отправка писем, сбор статистики, A/B-тесты, платежные системы, биллинг - проблемы схожие, да и функционал совсем не уникальный. Поэтому хоть я и говорю только про аутентификацию/авторизацию - проблема несколько шире.
Open Source?
Сейчас часть функционала легко восполняется с его помощью. Например, для аутентификации это часто KeyCloak. Но:
там только часть функций,
его нужно “знать и уметь”,
начинаются пляски с дополнительной инфраструктурой и поддержкой.
Он в целом дает некий прирост эффективности, но совсем не тот, как во многих случаях хотелось бы. Все равно остается аренда / сопровождение / мониторинг серверов, настройка интеграций, создание интерфейсов, тестирование и т.д.
Вернемся к истории - дальше часто происходила следующая картина: менеджер скрипит зубами и мозгами, думая, как перераспределить дефицит ресурсов. Разработчики тревожно фиксят баги за полночь. QA нервничают, но ЭТО принять не могут. Так себе получался старт для проекта.
А почему так происходит?
Здесь могут быть разные причины: Недостаток компетенций, “туннельное зрение”, привычка, неправильная оценка, недостаточно проработанные требования и тд. Эти проблемы решаемы, но на это нужны ресурсы и время - предусмотреть, обучить, уточнить, проконсультироваться и т.д.
Ок, а как это решают другие?
Идея ко мне пришла из опыта “западной” разработки. Там не создают заново кусок функциональности, если его можно взять готовый. Часто это либо опенсорс, либо SaaS. Даже такие гиганты как Amazon или Uber не стесняются воспользоваться например сервисом Twilio для телекоммуникаций, хотя что им мешало бы создать свой?
И для аутентификации там тоже есть сервисы - Auth0, Clerk, Logto. А что у нас? Несколько разрозненных OIDC-провайдеров типа Яндекса и VK, пару корпоративных on-premise решений, и все?
Я хотел бы, чтобы разработка в России развивалась также успешно как на западе (кто-то фыркнет, но вот мне хочется!). У нас отличная школа инженеров, лучшие айтишники. Если мы используем их опыт и похожую модель - мы облегчим себе жизнь, и выйдем на другой уровень эффективности. Конкретно я, конечно, не могу изменить все, но я могу начать с малого - сделать один небольшой сервис. А дальше видно будет)
Для тех, кто ценит аргументированность и наглядность, я готовлю следующую статью, так как не хочу перегружать эту контентом. Буду сравнивать сложности при реализации разных подходов к разработке этого функционала. Как только она будет готова (ближайшие дни), я добавлю сюда ссылку.
Вы можете помочь проекту, отправив эту статью стартующим проектам, или пообщавшись со мной в комментариях/личке. Мне интересно узнать, что вы используете для аутентификации и авторизации, какие вы встречаете проблемы, и как бы я мог решить их для вас.
А самым ценным будет признание, что вы хотели бы воспользоваться таким сервисом - значит я делаю что-то правильное!
У Авторизы есть промо-страница - для тех кому интересно узнать больше. Там также можно подписаться на новости, или ответить на коротенькую анкету, чтобы помочь мне построить дорожную карту для дальнейшего развития функционала проекта: https://authoriza.ru/
Сам сервис в активной разработке и скоро будет запущен.
Мой канал https://t.me/kalinin_pro_it , там же можно написать мне лично
