Введение

На этой странице будет справочник терминов. Чтобы был под рукой и можно было ссылаться на него из других статей.

Auth

идентификация (identification)

Это когда клиент заявляет что он - это он. Например, сообщает системе свой логин по которому можно однозначно найти учетную запись.

Идентификация - процесс в результате которого система получит идентификатор, однозначно определяющий клиента в системе.

ввод логина в системе и поиск учетной записи пользователя по логину.

Если идентификация выполняется не из доверенного источника, то она не имеет смысла без аутентификации так как нет гарантии подлинности предоставленных данных.

Идентифицировать можно не только пользователя (анонима заявляет что он пользователь) но и аутентифицированного пользователя (когда анонима предоставляет секрет полученный после аутентификации).

аутентификация (authentication)

Процедура подтверждения того, что пользователь является тем, кем представляется. Может быть выполнена через проверку пароля или иного секрета, предоставленного пользователем.

проверка пароля пользователя
проверка кода смс (OTP)

Аутентификация может быть выполнена только после идентификации.

Пример:

1. Клиент (пользователь или система) передает логин и пароль системе которая проводит аутентификацию.
2. Системе проводящая аутентификацию находит учетную запись (идентифицирует клиента) и проверяет подлинность пароля (аутентифицирует клиента). Если всё в порядке, то будет создан и передан клиенту секретный идентификатор. В роли секретного идентификатора может выступать auth cookie по значению которой можно найти учетную запись клиента, JWT токен или что-то еще.
3. Клиент получает идентификатор от аутентифицирующей системы и может предъявлять его для авторизации при обращении к функциям системы.

authorization (авторизация)

Определение того какие права в системе есть у клиента, какие действия ему разрешено выполнять.

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

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

Авторизация может быть выполнена на основе ролей RBAC или на основе атрибутов ABAC. Подтверждение прохождения аутентификации без дополнительных данных о правах тоже может применять если доступ предоставляется для всех аутентифицированных клиентов без дополнительных ограничений.

Пример:

Для аутентифицированного клиента:

Клиент обращается к функции системы (делает вызов API) и предъявляет секретный идентификатор, полученный после аутентификации.

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

1. auth cookie: авторизация проводится путем вызова сервиса аутентификации и проверки переданного значения. Если значение auth cookie является действующим аутентификационным секретом, то считаем, что клиент аутентифицирован. Дополнительные данные для процесса авторизации с auth cookie могут быть запрошены у системы хранящей права пользователей.
2. JWT: обращение к аутентифицирующей системе не требуется так как любой сервис может самостоятельно проверить JWT токен на подлинность (путем проверки подписи) и актуальность (путем проверки времени жизни токена). В случаях когда нужен более жесткий контроль за токенами может выполняться запрос к аутентифицирующей системе на проверку токена. Такое может применяться если нам нужна возможность отозвать токен или ограничить количество его применений, избегая replay attack. Дополнительные данные для процесса авторизации с JWT могут содержаться внутри токена или предоставляться через отдельное обращение к системе хранящей или вычисляющей права пользователей.