Аутентификация и авторизация
Наши приложения выполняют разные сценарии и для некоторых из них может быть важно, что за пользователь перед нами. То есть, для целей бизнес-логики может быть необходимо получить некоторые уникальные данные пользователя, которые позволят его отличить от других - это идентификация. Реализуется она различным способом: иногда мы можем явно спросить у пользователя, кто он, иногда мы получаем информацию из сетевых пакетов или системы. Идентификационные данные дальше могут использоваться по-разному: их можно записать в лог, использовать как ссылку на владельца при создании объектов в системе или в различных проверках внутри нашей логики.
Идентификация должна выполняться безопасно: иногда пользователь может попытаться выдать себя за другого. Процесс проверки, что пользователь не обманывает нас в том, кто он - аутентификация. Она не всегда актуальна: если мы получили сообщение от telegram, мы можем верить информации об отправителе, потому что доверяем серверам телеграма. Однако, если мы получили HTTP запрос, мы должны принять меры для обеспечения защиты от подделки личности пользователя (аутентифицировать его).
Когда пользователь первый раз обращается к нашему сайту, мы обычно отправляем его на сценарий входа (первичная аутентификация, login, sign in). Этот сценарий может быть достаточно сложным, состоять из нескольких шагов (например в случае двух- и многофакторной аутентификации), требовать использовании СУБД и внешних сервисов. Процедура входа скорее всего будет отделена от основной части приложения или даже реализовываться внешней системой (например, Keycloak). Иногда процедуру логина на сайт называют "авторизацией на сайте", но не следует это путать с авторизацией действий (см. ниже). В случае веб-приложений, после первичной аутентификации мы часто используем различные токены для того, чтобы в последующих действиях было проще его аутентифицировать. Проверка таких токенов связана с протоколом доставки, может задействовать базы данных и снова выполняется вне основной бизнес логики - адаптерами или отдельной подсистемой. В том числе, её иногда может выполнять реверс-прокси. Часто спустя какое-то время пользователя просят повторить процедуру входа.
Многие операции в нашем приложении мы не хотим разрешать выполнять кому попало. Например, мы можем разрешить редактировать какой-то объект только его владельцу, а блокировать пользователей - админам. Проверка, разрешено ли выполнять какой-то сценарий пользователю - это авторизация, часть бизнес логики. Есть разные модели авторизации, связанные с проверкой роли пользователя (RBAC), отношений пользователя и объекта (ReBAC) или даже с какими данными объекта он работает (ABAC). Выбор того или иного варианты авторизации определяется требованиями вашей системы.
С точки зрения архитектуры приложения
• Идентификация выполняется для целей бизнес-логики или логирования, адаптеры помогают её реализовать.
• Аутентификация не является частью основной бизнес-логики приложения, выполняется адаптерами или полностью отдельной частью логики.
• Авторизация выполняется только бизнес-логикой, она не может быть корректно вынесена в слой представления, но может быть отделена от основной логики интерактора.
Дополнительные материалы
• https://auth0.com/intro-to-iam/what-is-oauth-2
• https://www.cloudflare.com/learning/access-management/what-is-mutual-tls/
• https://owasp.org/Top10/A01_2021-Broken_Access_Control/
Наши приложения выполняют разные сценарии и для некоторых из них может быть важно, что за пользователь перед нами. То есть, для целей бизнес-логики может быть необходимо получить некоторые уникальные данные пользователя, которые позволят его отличить от других - это идентификация. Реализуется она различным способом: иногда мы можем явно спросить у пользователя, кто он, иногда мы получаем информацию из сетевых пакетов или системы. Идентификационные данные дальше могут использоваться по-разному: их можно записать в лог, использовать как ссылку на владельца при создании объектов в системе или в различных проверках внутри нашей логики.
Идентификация должна выполняться безопасно: иногда пользователь может попытаться выдать себя за другого. Процесс проверки, что пользователь не обманывает нас в том, кто он - аутентификация. Она не всегда актуальна: если мы получили сообщение от telegram, мы можем верить информации об отправителе, потому что доверяем серверам телеграма. Однако, если мы получили HTTP запрос, мы должны принять меры для обеспечения защиты от подделки личности пользователя (аутентифицировать его).
Когда пользователь первый раз обращается к нашему сайту, мы обычно отправляем его на сценарий входа (первичная аутентификация, login, sign in). Этот сценарий может быть достаточно сложным, состоять из нескольких шагов (например в случае двух- и многофакторной аутентификации), требовать использовании СУБД и внешних сервисов. Процедура входа скорее всего будет отделена от основной части приложения или даже реализовываться внешней системой (например, Keycloak). Иногда процедуру логина на сайт называют "авторизацией на сайте", но не следует это путать с авторизацией действий (см. ниже). В случае веб-приложений, после первичной аутентификации мы часто используем различные токены для того, чтобы в последующих действиях было проще его аутентифицировать. Проверка таких токенов связана с протоколом доставки, может задействовать базы данных и снова выполняется вне основной бизнес логики - адаптерами или отдельной подсистемой. В том числе, её иногда может выполнять реверс-прокси. Часто спустя какое-то время пользователя просят повторить процедуру входа.
Многие операции в нашем приложении мы не хотим разрешать выполнять кому попало. Например, мы можем разрешить редактировать какой-то объект только его владельцу, а блокировать пользователей - админам. Проверка, разрешено ли выполнять какой-то сценарий пользователю - это авторизация, часть бизнес логики. Есть разные модели авторизации, связанные с проверкой роли пользователя (RBAC), отношений пользователя и объекта (ReBAC) или даже с какими данными объекта он работает (ABAC). Выбор того или иного варианты авторизации определяется требованиями вашей системы.
С точки зрения архитектуры приложения
• Идентификация выполняется для целей бизнес-логики или логирования, адаптеры помогают её реализовать.
• Аутентификация не является частью основной бизнес-логики приложения, выполняется адаптерами или полностью отдельной частью логики.
• Авторизация выполняется только бизнес-логикой, она не может быть корректно вынесена в слой представления, но может быть отделена от основной логики интерактора.
Дополнительные материалы
• https://auth0.com/intro-to-iam/what-is-oauth-2
• https://www.cloudflare.com/learning/access-management/what-is-mutual-tls/
• https://owasp.org/Top10/A01_2021-Broken_Access_Control/