Блог

Я пытаюсь внедрить систему аутентификации на основе JWT в одном из моих проектов, и я застрял между двумя вариантами, где мне нужны некоторые разъяснения. Я предложил два подхода к реализации JWT следующим образом:

Подход 1

• Клиент отправляет учетные данные для входа
• Сервер проверяет учетные данные
• Сервер генерирует два токена: auth-token и refresh-token
• Сервер сохраняет эти токены на своем redis-сервере как [key] =refresh-token и [value] =auth-token
• Поскольку HTTP-соединения между клиентом и сервером всегда активны, Сервер устанавливает токен аутентификации в http-сеансы и отправляет токен обновления в ответ.
• Клиент сохраняет токен обновления в локальном хранилище браузера и использует его всякий раз, когда http-соединение между клиентом и сервером закрывается для восстановления аутентификации.
• Кроме того, с помощью refresh-token мы можем легко обновить auth-token, не выходя из системы пользователя.

Подход 2

• Клиент отправляет учетные данные для входа
• Сервер проверяет учетные данные
• Сервер генерирует auth-токен и отправляет в ответ клиенту
• Клиент устанавливает токен в заголовке запроса для каждого запроса, который он отправляет серверу

Это хорошее объяснение https://auth0.com/learn/refresh-tokens /

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

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

Если вы используете SSL, все заголовки зашифрованы.

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

Вот некоторые из моих разъяснений,

• Хранение сеансов на стороне браузера, которые являются долговечными, всегда рискованно
• Позвольте серверу выполнить РАБОТУ по проверке токена, отправленного третьей стороной или приложением. Это позволяет убедиться, что отправляемый токен является неповрежденным и действительным.
• Я предпочту подход, при котором токен всегда отправляется в заголовках через HTTPS. Это упрощает и повышает безопасность, потому что сервер будет проверять ваш токен во время сеанса пользователя.