2017-02-22 12 views
14

Я разрабатываю сервер oAuth2, и я наткнулся на этот вопрос.Должен ли сервер oAuth предоставить тот же accessToken одному и тому же запросу клиента?

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

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

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

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

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

ответ

4

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

Причины:

  1. Вы никогда не должны хранить маркеры доступа в виде текста на стороне сервера авторизации. Ленты доступа - это учетные данные и должны храниться в хэшировании. Солить может быть не нужно, так как они все равно генерируются. См. OAuth RFC point 10.3.
  2. В зависимости от того, как вы обрабатываете последующие запросы - злоумышленник, который знает, что определенный владелец ресурса использует вашу службу и повторяет запросы для используемого идентификатора клиента. Таким образом, злоумышленник сможет выдавать себя за владельца ресурса. Если вы действительно возвращаете один и тот же токен, по крайней мере, убедитесь, что вы каждый раз проверяете подлинность владельца ресурса.
  3. Как насчет параметра «состояние»? Будете ли вы считать запросы «одинаковыми», если параметр состояния отличается? Если нет, то ботнет-атака будет просто использовать другое состояние каждый раз и заставлять вас выдавать новые токены.

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

+0

Я путаюсь с вашей третьей точкой. ОП не упоминает параметр «состояние». Я не думаю, что состояние будет отправлено как параметр, чтобы получить новый токен. –

+0

@KiranShakya Клиент может отправлять или не отправлять параметр состояния. Сервер авторизации ДОЛЖЕН отправить параметр состояния, если он передан с запросом авторизации в сконфигурированный URI перенаправления. См. Https://tools.ietf.org/html/rfc6749#section-4.2.2. Так что это актуально. – vap78

+0

в пункте 2 есть больше запросов, где может замедляться время отклика. Исправьте меня, если я ошибаюсь – Prageeth

3

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

+1

хотя и не лучшая практика, другим способа смотреть на это: таким образом, вы» d хранить токен с AS, а не с клиентом –

1

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

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

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

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

2

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

Смежные вопросы