Когда появляется несколько внутренних сервисов, очень легко автоматически скопировать привычную схему обычного веб-продукта: кнопка "Регистрация", форма с email и паролем, подтверждение почты - и пользователь внутри. Для публичного сервиса это нормальный сценарий. Для закрытой экосистемы он может создавать больше проблем, чем решать. В True Creator мы выбрали другой путь: сначала пользователь получает право на вход, и только потом создает учетную запись.
Публичная регистрация решает не нашу задачу
Наши внутренние сервисы не предназначены для случайного посетителя сайта. Ими пользуются конкретные люди, которым действительно нужен доступ к определенным инструментам. Поэтому открытая форма регистрации создавала бы ложное обещание: любой может зарегистрироваться, хотя фактически право пользоваться системой все равно должно быть подтверждено отдельно.
Если после регистрации человека приходится дополнительно проверять вручную, сама публичная регистрация становится лишним промежуточным этапом.
Сначала разрешение, потом аккаунт
Мы зафиксировали простой сценарий. Новый пользователь сначала передает свой email владельцу или администратору. Администратор добавляет адрес в систему. После этого пользователь получает одноразовую ссылку на страницу предодобренной регистрации.
Только на этой странице он самостоятельно создает профиль, задает пароль и при необходимости привязывает дополнительные способы входа. То есть администратор определяет, кто вообще может войти в систему, но не создает учетную запись за человека и не знает его пароль.
Так проще разделить доступ и идентификацию
В обычной регистрации два разных вопроса часто смешаны. Первый: кто этот человек? Второй: имеет ли он право пользоваться сервисом? Мы разделяем их.
Email, заранее добавленный администратором, отвечает на вопрос о праве зарегистрироваться. Пароль, VK ID, Яндекс ID и другие связанные способы входа отвечают уже на вопрос идентификации пользователя при следующих посещениях.
Одноразовая ссылка убирает лишние ручные действия
Можно было бы выдавать пользователям временные пароли или создавать аккаунты вручную. Но тогда администратор становится участником чужой процедуры входа: ему нужно генерировать данные, передавать их безопасно, следить за сменой пароля.
Одноразовая ссылка позволяет избежать этого. Администратор только разрешает регистрацию конкретному адресу, а все персональные данные для входа пользователь создает самостоятельно.
Связанные способы входа добавляются после создания профиля
Мы не хотим заставлять пользователя выбирать один навсегда закрепленный способ входа. После регистрации он может связать с профилем VK ID, Яндекс ID и другие поддерживаемые варианты. В дальнейшем любой из них становится способом подтвердить ту же учетную запись.
Это удобнее, чем создавать отдельные аккаунты под каждый провайдер и потом пытаться их объединять.
Закрытая регистрация не должна превращаться в закрытую архитектуру
Важно, что речь идет только о способе допуска пользователей. Сама система авторизации при этом должна оставаться нормальным отдельным сервисом с понятными интерфейсами для других продуктов экосистемы.
Сегодня доступ нужен Task Tracker, завтра - другому внутреннему инструменту. Если каждый сервис будет самостоятельно хранить пользователей и придумывать собственный вход, проблема быстро размножится.
Для нашей экосистемы предодобренная регистрация оказалась логичнее публичной не потому, что она сложнее или безопаснее сама по себе, а потому, что соответствует реальному процессу. Внутренний сервис должен сначала понимать, кому он предназначен, и только потом предлагать человеку создать учетную запись.