Как элегантно реализовать неосознанное обновление токена (мини-программа + одностраничное приложение)

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

предисловие

В обычной работе мы неизбежно столкнемся со сценой использования Токена, вообще говоря, фон дает нам Токен, и мы храним этот Токен локально и переносим его с каждым запросом, но какие будут проблемы?

апплет сцена

Что делать после истечения срока действия токена

Если мы сейчас сохранили Токен в апплете, то каждый запрос будет приносить Токен, возвращаемый нам фоном:

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

Тогда самое глупое решение — позволить пользователю снова войти в систему после истечения срока действия токена, а затем повторно сгенерировать токен, но, очевидно, это очень плохой опыт!

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

Когда будут проблемы из-за истечения?

Для сервера подавляющее большинство должно нести токен, затем, как только токен означает, что этот интерфейс может быть запросом на отказ, мы рассматриваем сравнениекрайний, если срок действия этого токена составляет1 час, а затем соответствующий этому токену пользователь заходил в течение этого часа (в этот период он не выходил из апплета), а затем в 59 минут и 59 секунд он запрашивает токен, который только что был действителен всего 1 час Если сервер подключен к серверу, то поскольку http занимает много времени, срок его действия должен был истечь после достижения сервера, и тогда сервер обязательно получит просроченный токен.доступ запрещен, сказав, что срок действия этого токена истек, то это даст пользователям очень плохой опыт в это время. Я считаю, что проблема здесь расширена, и у каждого должны быть свои решения. Давайте поговорим о вышеизложенном.Как реализован механизм вторичной ретрансляции?

Механизм вторичной ретрансляции

Второй механизм повторной отправки — позволить пользователю получить лучший пользовательский опыт (автоматически и бессознательно помочь ему обновить токен вместо повторного входа в систему).

На самом деле, этого тоже очень легко добиться.Общая идея такова:

Сохраняйте API каждого запроса и повторно получайте новый токен после того, как полученный токен недействителен, а затем повторно запрашивайте неудачный API в соответствии с сохраненным статусом запрошенного API.

Псевдокод выглядит следующим образом (только для справки):

_request(url, resolve, reject, data = {}, method = 'GET', noRefetch = false) {
    wx.request({
      url: api.url,
      method: method,
      data: data,
      header: {
        Authorization: wx.getStorageSync('token');
      },
      success: (res) => {
        const code = res.statusCode
          if (code === 403) {
            if (!noRefetch) {
              _refetch(
                url,
                resolve,
                reject,
                data,
                method
              )
            }
          }
        }
    })
  }
  _refetch(...param) {
    getTokenFromServer((token) => {
      this._request(...param, true);
    });
  }

Подобно этой блок-схеме нижеЗатем, поскольку апплет не требует пароля учетной записи и поддерживается официальным интерфейсом входа в систему WECHAT, мы можем сделать это, но что, если это обычное веб-приложение?

Двойной токен Access_token и refresh_token для входа в систему без осведомленности

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

На самом деле, мы использовали вышеуказанное название нашегоМеханизм двойного жетона

access_token

этоaccess_tokenКак понять это? Можно понять, что он используется для проверки личности пользователя, передачи его на бэкенд, а бэкенд вам это скажетaccess_tokenэто эффективно

refresh_token

этоrefresh_tokenКак понять это? Он играет роль освежителя, поэтому позволяет избежать повторного ввода пользователем учетной записи и пароля для повторной аутентификации,

Как использовать эти два вместе?

если мы встретимсяaccess_tokenистек, то нам нужно использоватьrefresh_tokenчтобы получить новыйaccess_token, не правда ли, это звучит очень просто, теперь, еслиrefresh_tokenтоже истек? Затем, если срок его действия истечет, мы можем только позволить пользователю снова ввести пароль учетной записи для строгой аутентификации, а затем снова побеспокоить пользователя в это время, поэтому давайте поговорим о том, как сделать это разумным.Скоординированный двойной токен:

Тогда правильно было бы сделать так, чтобы оба токена имели свое время истечения срока действия, потому чтоaccess_tokenнеобходимо использоватьrefresh_tokenОбновить получить, такrefresh_tokenaccess_tokenrefresh_tokenистекший? Как мы используемrefresh_tokenобновленныйaccess_tokenПосле этого, ставяrefresh_tokenСрок годности также продлевается.

Как правило, мы можемaccess_tokenВремя истечения установлено на 2 часа,refresh_tokenВремя истечения установлено на 1 месяц, а затем пользователь заходит в первый раз, и это занимает некоторое время.access_tokenСрок действия истек, передняя часть будет нести его после истечения срока действияrefresh_tokenполучить новыйaccess_token, который возвращает новыйaccess_tokenЭто все еще 2 часа, тогда, кроме того, что этоrefresh_tokenОн снова обновляется, и после обновления у него все еще есть срок действия 1 месяц (не кумулятивно), что гарантирует, что пользователь может наслаждаться незаметным опытом, пока он получает доступ к приложению в течение месяца.

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

Суммировать