Как сказал Бантар в своем комментарии, проверка авторизации всегда должна выполняться на сервере.
Стандартным способом реализации такого рода вещей является использование токена : клиент отправляет имя пользователя и пароль на сервер.Если учетные данные, предоставленные клиентом, успешно проходят проверку подлинности, то сервер генерирует токен безопасности, сохраняет его где-то для последующих проверок, а также отправляет токен обратно клиенту.Для каждого следующего запроса к серверу клиент должен отправить токен вместе с параметрами запроса, позволяя серверу проверить, является ли токен действительным.Сервер выполняет запрос, только если он может проверить, что токен является легитимным и авторизованным, любые сомнения должны привести к тому, что сервер аннулирует токен.
Этот метод очень похож на тот, который вы описали в последней частиyour post.
Токен, сгенерированный сервером, должен быть значением, которое нельзя подделать: оно не может быть простым целочисленным значением, увеличенным для каждого сгенерированного токена, поскольку хакер может легко предсказать допустимое значение.Он не может быть построен с использованием только информации, доступной клиенту, по той же причине (хотя для хакера это потребует дополнительной работы, он может в конечном итоге подделать действительный токен).Кроме того, на сервере к токену должна быть приложена информация, позволяющая серверу легко и однозначно проверить токен: небольшое изменение в информации о соединении должно привести к отзыву токена.Значения токена никогда не должны использоваться повторно (с токеном конечной длины все равно будет вероятность повторного использования значения токена, поэтому определите длину, которая является хорошим компромиссом между безопасностью и практичностью).Наконец, токен для действительного сеанса должен регулярно обновляться во время сеанса, чтобы злонамеренный пользователь не стал его использовать.
Существует много способов реализовать это, но детали зависят от уровня безопасности, который вы пытаетесьдостигать.Использование какого-либо секретного ключа для генерации токена на сервере, как правило, является плохой идеей, поскольку всегда существует вероятность утечки ключа.Время создания токена также может быть предсказуемым.Генераторы псевдослучайных чисел, доступные для любых языков программирования, должны быть правильно отсеяны, чтобы последовательность чисел не могла быть предсказана.
Наконец, обратите внимание, что никакая логика аутентификации никогда не бывает полностью безопасной: повышая безопасность только в вашей логикеусложняет работу хакеру.Подумайте о стимуле для хакера проникнуть в вашу систему и продумайте свою логику так, чтобы объем работы для взлома системы не стоил затрат ресурсов (время, деньги, специальное оборудование ...).И никогда не забывайте, что безвестность не означает безопасность: пусть люди просматривают ваш процесс и комментируют его, они могут подумать о каком-то недостатке, которого вы не видели.