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

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

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

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

Как это происходит? Сеансы могут включить это поведение.

🧠 Как работают сеансы?

Когда вы отправляете свое имя пользователя и пароль на сервер для аутентификации, происходит следующее:

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

2. Этот ключ отправляется обратно клиенту (браузеру, приложению и т. д.), и клиент безопасно его сохраняет. Обычно это файл cookie.

3. При каждом вызове, который делает клиент, этот сеансовый ключ также отправляется вместе с запросом. Сервер проверяет срок действия ключа и подтверждает его, позволяя пользователю выполнять необходимые действия.

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

Это называется метод аутентификации с отслеживанием состояния!

Сервер сохраняет состояние сеанса, связывая его с пользователем. Без состояния пользователь не может быть аутентифицирован.

Иногда это может быть ограничением.

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

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

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

JWT-аутентификация

Учитывая ограничения методов аутентификации с отслеживанием состояния, на сцену вышли веб-токены JWT или JSON.

Философия JWT была проста. Серверу не нужно хранить состояние пользователя. Токен должен содержать всю информацию, необходимую для идентификации пользователя.

🧠 Как работает JWT?

1. Первоначально он начинается с отправки имени пользователя и пароля на сервер, как и в методе, основанном на сеансе.

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

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

4. Этот токен отправляется обратно клиенту. Клиенты сохраняют его и отправляют на сервер с каждым запросом, обычно в заголовке запроса.

5. Сервер, получив токен, использует пароль для его расшифровки и получает сохраненную в нем информацию о пользователе.

JWT состоит из 3 частей, и каждая часть разделена точкой (.)

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

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

Где JWT становится с отслеживанием состояния?

Хотя JWT считается методом аутентификации без сохранения состояния, на самом деле он не может быть без состояния.

Рассмотрим ситуацию, когда хакер захватил токен пользователя. Хакер может притворяться пользователем и делать что-то от его имени. И сервер ничего не может с этим поделать, поскольку у него нет сохраненной сессии, на которую можно было бы сослаться!

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

Эту проблему можно решить двумя способами.

Во-первых, вы можете вести черный список токенов, которые были отозваны (например, если пользователь вышел из системы) и не разрешать их в будущих запросах.

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

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

Как вы можете видеть, это не совсем безгражданство, так как вам нужно поддерживать какое-то состояние в базе данных.

Подведение итогов

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

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

💌 Моя рассылка



Я пишу о разработке программного обеспечения и о том, как масштабировать ваши приложения в своем еженедельном информационном бюллетене. Чтобы получать такие истории прямо на почту, подпишитесь на нее! 😃

Если вам нравится мой контент и вы хотите поддержать меня, подумайте о том, чтобы купить мне кофе ☕️ ☕️