Что такое аутентификация?

Мы все хотя бы раз в жизни слышали об аутентификации. И мы все можем получить хорошее представление о том, что такое аутентификация. Это «базовый» процесс проверки или идентификации того, кто пытается запросить доступ к некоторой части информации в системе, сети или любом устройстве. Это также гарантирует, что любая конфиденциальная информация будет показана только тому человеку, который на самом деле владеет этой информацией или имеет надлежащее разрешение на доступ к этой информации. Другими словами, я не могу просматривать набор информации для Джона Доу, я должен иметь возможность просматривать только набор информации для Хулио Чазари (Я). Это также приводит к дальнейшему обсуждению того, почему аутентификация важна в первую очередь, и без нее не было бы ни одной компании или организации, которые бы сегодня существовали, если бы пользователи знали, что их данные не защищены.

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

Старые добрые сессии

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

Кроме того, сеансы имеют состояние, а это означает, что сервер должен поддерживать текущее состояние и сеанс приложения. И это делается, как упоминалось ранее, путем сохранения пользовательских данных в памяти на стороне сервера и сравнения их с файлом cookie при отправке со стороны клиента. Это поднимает вопросы о масштабируемости, поскольку потенциально ваше приложение будут использовать тысячи пользователей, а это означает, что тысячи сеансов должны быть сохранены в памяти на вашем сервере. Теперь, конечно, в реальном мире у вас, вероятно, не будет только одного сервера, а вместо этого у вас будет несколько серверов и распределение нагрузки между ними. Но даже в этом случае хранение сеансов со временем становится проблемой, если пользовательская база значительно увеличивается. Существует также аргумент, что можно просто использовать серверную часть, такую ​​​​как memcached или redis, которая будет кэшировать ваши сеансы, и это обеспечит масштабируемость без каких-либо проблем.

JWT: веб-токены JSON

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

Итак, как обычно, пользователь вводит свое имя пользователя и пароль и нажимает «Отправить», после чего на сервер отправляется запрос POST. Сервер получает этот запрос и приступает к аутентификации пользователя. После аутентификации сервер создает JWT с некоторой информацией внутри, такой как идентификатор пользователя и все, что вам нужно, и отправляет его обратно на сторону клиента (браузер). Теперь каждый последующий запрос, который делает пользователь, тот же самый JWT отправляется с этим запросом, и серверы проверяют, является ли это тем же токеном, который он изначально создал. И если это так, то он продолжит обработку запроса, отправленного от клиента.

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

С другой стороны, одним недостатком JWT является размер. Мы знаем, что как сеансы, так и JWT могут хранить внутри себя информацию о пользователе, такую ​​как идентификатор пользователя при отправке клиенту. Разница в том, что при отправке по сеансу с идентификатором пользователя размер этих данных составляет около 6 байт. С другой стороны, делая то же самое с JWT, размер теперь составляет около 304 байт. Теперь это кажется не таким уж большим, когда ваш веб-сайт использует всего несколько пользователей, но когда эти цифры начинают расти до тысяч или сотен тысяч, ваша пропускная способность начинает быстро съедаться. И это только сохранение идентификатора пользователя, когда на самом деле в JWT обычно хранится гораздо больше информации, что в конечном итоге значительно увеличивает использование полосы пропускания.

Безопасность

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