В чем заключается основная задача токена, и стоит ли расшифровывать токен на фронте?

Рейтинг: 0Ответов: 1Опубликовано: 29.04.2023

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

Пример 1: Пользователь входит в аккаунт и ему запросом отправляется токен вместе с фоткой,никнеймом, которые в последствии передаются в redux

Пример 2: Пользователь входит в аккаунт и ему запросом отправляется только токен, токен дешифруется и данные которые хранятся в токене передаются в redux.

Стоит ли делать дешифрацию токена на фронте, если нет , то что передавать в токен с сервера? Если да, то какие данные можно передавать вместе с токеном, потому что некоторые сервера отправляют вместе с токеном, например, почту. В таком случае почему они не закидывают почту в токен?

Эта тема для меня не понятна, сколько я не искал ответа в инете.

javascript jwt reactjs redux
Источник: Stack Overflow на русском

Ответы

▲ 0Принят

Давайте начнем с видов токена.

Существует 3 основных вида токенов: токен идентификации, токен доступа и токен обновления (Refresh Token).

Токен идентификации используется только приложением. Такие токены не должны использоваться для доступа к API. Каждый токен идентификации содержит информацию, предназначенную для определенной аудитории (audience), которой обычно является адресат (получатель, recipient) токена.

Согласно спецификации OpenID Connect аудиторией токена идентификации (указанной в настройке aud) должен быть идентификатор клиента (client ID), выполняющего запрос на аутентификацию. Если это не так, токен считается не заслуживающим доверия. Наличие идентификатора клиента означает, что только данный клиент должен потреблять (consume) этот токен.

Токен доступа используется для уведомления API о том, что его предъявитель (bearer) имеет доступ к API, т. е. выполнил все необходимые действия (в соответствии со сферами доступа — scopes).

Токены доступа не должны использоваться для аутентификации. Обычно в такой токен включается только идентификатор клиента (настройка sub).

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

Правила использования токенов

Общие рекомендации по использованию токенов могут быть сведены к следующему:

  • секретность означает безопасность: ключ, используемый для подписания токена, должен быть скрытым;
  • токен не должен содержать чувствительных данных пользователя;
  • токен должен иметь ограниченное время жизни (expiration): технически после подписания токен является валидным до тех пор, пока не изменится ключ, использованный для его подписания, или пока не истечет время его жизни;
  • для передачи токена должно использоваться только HTTPS-соединение: в противном случае, токен может быть перехвачен и скомпрометирован;
  • при необходимости для проверки токенов должна использоваться вторичная система верификации;
  • с целью уменьшения количества запросов к серверу следует предусмотреть возможность временного хранения токенов на стороне клиента (в куки или на sessionStorage, но не на localStorage)