Должен ли сервер oAuth предоставлять тот же доступ к Token одному и тому же запросу клиента?

Я разрабатываю сервер oAuth2, и я наткнулся на этот вопрос.

Предположим, что сценарий, в котором мои токены установлены, истекает в течение одного часа. В этот промежуток времени один клиент проходит через неявное auth пятьдесят раз, используя тот же client_id и тот же redirect_uri. В принципе же все.

Должен ли я предоставить ему тот же accessToken, сгенерированный по первому запросу на последующих, до истечения срока его действия, или я должен выполнить новый accessToken для каждого запроса?

Преимущества отправки одного и того же токена в том, что я не оставлю устаревшие и неиспользуемые токены клиента на сервере, минимизируя окно для злоумышленника, пытающегося угадать действительный токен.

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

Однако я не уверен в недостатках этого решения и почему я пришел сюда. Это допустимое решение?

ОТВЕТЫ

Ответ 1

Я бы сказал - нет.

Причины:

  • НИКОГДА не следует хранить токены доступа в текстовом виде на стороне сервера авторизации. Ленты доступа - это учетные данные и должны храниться в хэшировании. Солить может быть не нужно, так как они все равно генерируются. См. OAuth RFC point 10.3.
  • В зависимости от того, как вы обрабатываете последующие запросы - злоумышленник, который знает, что определенный владелец ресурса использует вашу службу и повторяет запросы для используемого идентификатора клиента. Таким образом, злоумышленник сможет выдавать себя за владельца ресурса. Если вы действительно вернете один и тот же токен, по крайней мере, убедитесь, что вы каждый раз проверяете подлинность владельца ресурса.
  • Как насчет параметра "состояние"? Будете ли вы считать запросы "одинаковыми", если параметр состояния отличается? Если нет, то ботнет-атака будет просто использовать другое состояние каждый раз и заставлять вас выдавать новые токены.

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

Ответ 2

Вы можете вернуть тот же access_token, если он все еще действителен, с этим нет проблем. Единственным недостатком может быть тот факт, что вы используете неявный поток и, таким образом, повторно отправляете токен того же, действительного доступа в фрагменте URL-адреса, который считается менее безопасным, чем использование, например. поток авторизационного кода.

Ответ 3

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

Ответ 4

Вы можете отправить токен доступа другой по запросу после правильной проверки подлинности, а также отправить токен обновления по токену доступа.

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

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

PS: никогда не используйте предсказуемые токены. По крайней мере, чрезвычайно сложно атаковать грубой силой, используя полностью случайные длинные буквенно-цифровые строки. Я бы предложил bin2hex(openssl_random_pseudo_bytes(512)), если вы используете php.