Должен ли сервер 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.
