В июне мы встроили слой идентификации в приложения, которые генерирует OwlMeans.
На виду был экран входа. А за ним стояли аккаунты, сессии, права доступа и граница между теми, кто пользуется нашей платформой, и теми, кто пользуется приложением клиента.
Я хотел, чтобы эти решения с самого начала были частью архитектуры приложения.
Аккаунты и вход
Успешный вход сообщает приложению, кто пришёл. Но что этому человеку можно читать или менять, он не решает.
Клиенту может понадобиться, чтобы пользователь видел свои записи, оператор разбирал очередь, а администратор управлял доступом. Это разные обязанности, даже если экраны похожи.
Как работает протокол идентификации OpenID Connect, объясняет OpenID Foundation. А какие у кого права, всё равно решают бизнес-правила приложения.
В июне мы подключили процесс входа к генерируемому приложению и сделали единый способ описывать доступ. Остальной код получил согласованную основу.
Но политику доступа за каждого клиента эта работа не определяла.
Конечным пользователям приложения одноразовые данные для входа приходили на почту. Поэтому отдельный процесс управления паролями в сгенерированном приложении не понадобился.
Вход через почту я бы не стал называть гарантией безопасности вообще или ставить в один ряд с любым более сильным способом аутентификации.
Доставку писем, восстановление аккаунта и поведение сессий всё равно нужно продумать. Как и то, каким образом человек становится участником организации клиента.
Эти детали легко упустить, если вся приёмка сводится к тому, что форма входа отправляется.
Границы доступа
Модель прав доступа я хотел уберечь от разрозненных решений, принятых по ходу дела.
Требование к доступу может быть у экрана, но проверять его должна и операция, которая за этим экраном стоит. Спрятанная кнопка — ещё не правило авторизации.
В памятке OWASP по авторизации советуют задать границы доступа, по умолчанию отказывать в нём и проверять права при обработке запросов. А ещё — покрывать эти правила тестами.
В нашей структуре приложения требование объявляется через соглашения фреймворка о доступе. Бизнес-код должен последовательно им следовать и не придумывать свою трактовку в каждом обработчике.
В обычном рабочем инструменте я бы проверял реальные различия. Пользователь может смотреть свою запись. Оператор может обработать назначенную ему заявку. Ни тот ни другой не должен получать права администратора просто потому, что вошёл.
Такое поведение должно быть записано в требованиях к продукту и в тестах. Одно название протокола его не обеспечит.
У OwlMeans свои аккаунты. У приложения, созданного с его помощью, — свои конечные пользователи. Не смешивать одно с другим тоже было частью работы над идентификацией.
Границы клиентов, проектов и ресурсов важны, потому что личность пользователя может быть подтверждена, а конкретное действие всё равно выходит за пределы его полномочий. Одного идентификатора пользователя мало, чтобы выразить все эти границы.
Продакшену нужна и своя конфигурация входа — та, что задумана именно для него. Аккаунты и адреса перенаправления, которыми пользовались в предпросмотре, не стоит считать настройкой продакшена.
На практике вопрос в том, сможет ли нужный человек пройти задуманный сценарий и получит ли отказ тот, кто находится за этой границей.
OIDC и поставка
OIDC даёт приложению стандартный интерфейс идентификации. Но из этого не следует, что доступна любая интеграция с корпоративными системами идентификации, что проверена каждая граница между арендаторами или что опросник покупателя по безопасности заполнен.
В прежней версии статьи это звучало так, будто всё происходит само собой.
Интеграция по-прежнему зависит от провайдера и конфигурации. Роли клиента и правила его организации ещё нужно описать. А проверка сгенерированного приложения остаётся частью поставки.
Я лучше опишу то, что у нас есть, чем буду намекать на сертификацию только потому, что мы выбрали протокол.
В августе встроенная система идентификации стала единственной реализацией IAM Платформы. Июньские рассуждения о переключаемом внешнем бэкенде теперь — история.
В нынешней работе над доступом мы тоже отделяем реализованные механизмы контроля от доработок, которые ещё не закончены. Механизм подтверждают документация и код. Но доказать, что безопасно любое приложение, построенное на нём, они не могут.
Актуальное руководство по аутентификации описывает базовые компоненты фреймворка. А схему доступа приложения нужно проверять в контексте конкретного продукта.
Раз идентификация встроена, эту часть системы поддерживаем мы. Клиентам всё равно нужно описать людей, ресурсы и действия, которые требуются их продукту. У нас есть единый способ записать эти правила. Проверять их — по-прежнему часть работы.
Отредактировано 15 октября 2026 года. История июньской реализации сохранена, а прежние сравнения цен и слишком общие обещания про корпоративный уровень и безопасность исправлены.