Архитектура без гражданства и с сохранением состояния

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

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

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

Аутентификация без сохранения состояния

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

Этот токен хранится на стороне клиента (браузер), поэтому сервер имеет возможность проверить достоверность токена только путем подтверждения соответствия полезных данных и подписи.

Аутентификация без сохранения состояния JWT

JSON Web Token (JWT) — это ключи со стандартами, установленными в RFC-7519, содержащие сущности в виде объявлений, которые являются независимыми, без необходимости вызова сервер для повторной проверки токена.

Закодированы ли строки в стандарте Base64 с использованием секретного ключа, как в примере:

Преимущества и недостатки

Преимущества:

• Низкое потребление памяти сервера.
• Отлично с точки зрения масштабируемости.
• Идеально подходит для распределенных приложений, таких как API и микросервисы.
• Генерация и распространение токена в изолированном приложении, без зависимости от третьих лиц.
• Простая интерпретация и проверка пользовательских данных токена.

Недостатки:

• Сложность контроля доступа.
• Отозвать токен в любой момент невозможно.
• Это может облегчить проникновение злонамеренных третьих лиц, если у кого-то есть доступ к токену.
• Сеанс нельзя изменить до истечения срока действия токена.
• Токен JWT более сложен и может стать ненужным в централизованных приложениях, таких как монолиты.

Аутентификация с отслеживанием состояния

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

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

Пример токена: 8c90e55a-e867-45d5-9e42-8fcbd9c30a74

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

Преимущества и недостатки

Преимущества:

• Логика централизованной реализации.
• Упрощенное управление и контроль доступа.
• Отлично подходит для монолитов, приложений MVC и внутренних процессов.
• Более безопасен от злонамеренных третьих лиц.

Недостатки:

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

Когда использовать каждый подход?

Когда использовать токен JWT и аутентификацию без сохранения состояния

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

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

• Если необходим полный контроль доступа пользователей системы, главным образом для определения иерархии доступа.
• В централизованном приложении, без распределенных сервисов и без связи с внешними сервисами.

Заключительные соображения:

• В некоторых местах, например «Стресс API», для ясности этот термин можно заменить на «Накладные расходы API».
• Раздел «Токен JWT» может включать более подробное объяснение того, что такое «объявления», упомянутые в RFC-7519, если целевой аудитории требуется больше контекста.
• В разделе об аутентификации с отслеживанием состояния фразу «одна часть приложения будет генерировать токен» можно было бы уточнить, объяснив, какая конкретная часть приложения за это отвечает.