Давайте немного подумаем вот над чем - верно ли мы поступаем, когда требуем от пользователя представиться приложению (зарегистрироваться)? Если рассматривать классическую модель разделения доступа, издавна применяемую в ПО, ответ очевиден - без регистрации авторизация невозможна!

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

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

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

Идентификация

Представьте себя администратором форума. Считаете ли вы конкретного, не представившегося системе пользователя таковым, или для вас важны только те пользователи, которые сообщили системе свой логин? Возможно вам следует запретить таким, “не представившимся” пользователям создавать темы или комментировать их, согласно бизнес-регламенту, но стоит ли их относит к группе - пользователи? Если подумать, то они отличаются от пользователей системы лишь ограниченными правами, следовательно, они все же являются пользователями.

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

Примечание: Я не призываю поощрять пользователя делиться своими персональными данными “за плату”. Речь о увеличении функциональности приложения для пользователя за счет добавления новых возможностей, зависящих от персональных данных пользователя. Так, функция двуфакторной аутентификация может быть предоставлена только тем пользователям, кто сообщил свой номер мобильного телефона.

Очевидна и польза данной модели для пользователя, связанная с пониманием последнего причин предоставления тех или иных персональных данных. Более того, использованием стандартов OpenID и OAuth позволяет запрашивать данные у сторонних сервисов, таких как социальные сети, что облегчает процесс представления пользователя системе. Полученные таким образом данные могут считаться “подтвержденными” (см. главу “Аутентификация”) и не требуют от пользователя дополнительных действий по аутентификации.

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

Аутентификация

Обычно одного запроса персональных данных не достаточно, необходимо так же удостовериться, что пользователь действительно является владельцем этих данных. Для этих целей применяется аутентификация. Рассматриваемая мной модель требует использования различных механизмов аутентификации, зависящих от проверяемых данных. Так, для проверки предоставленного пользователем адреса электронной почты может использоваться механизм отсылки на эту почту письма с кодом подтверждения. Аналогичная логика может быть использована для аутентификации номера телефона.

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

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

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

Стандарты OpenID и OAuth позволяют пользователю использовать сторонние сервисы для авторизации. В этом случае пользователю достаточно указать, какие именно данные использовать для аутентификации.

Авторизация

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

Выводы

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