2011-12-04 2 views
2

Я намерен создать делегированную систему входа для существующего приложения. Я буду реализовывать как клиент OAuth (в веб-приложении), так и сервер OAuth (простой сервер авторизации и ресурсов, который на данный момент имеет только ресурс пользователя).Действительно ли нужен клиент OAuth 2 TLS?

Имея это в виду, я наткнулся на следующий раздел в текущей OAuth 2 draft (версия 22):

3.1.2.1. Endpoint Request Confidentiality 

    If a redirection request will result in the transmission of an 
    authorization code or access token over an open network (between the 
    resource owner's user-agent and the client), the client SHOULD 
    require the use of a transport-layer security mechanism. 

    Lack of transport-layer security can have a severe impact on the 
    security of the client and the protected resources it is authorized 
    to access. The use of transport-layer security is particularly 
    critical when the authorization process is used as a form of 
    delegated end-user authentication by the client (e.g. third-party 
    sign-in service). 

Это специально предупреждает меня, что я должен использовать TLS на клиенте. будет использовать HTTPS на сервере, конечно, но включение HTTPS на всех клиентов будет затруднительным, если не невозможным.

Из моего ограниченного понимания безопасности я предполагаю, что кто-то может украсть разрешение на предоставление разрешения. Это подводит меня к вопросу:

Не аутентификации клиента (используя секрет клиента) предотвратить подслушиватель от использования гранта авторизации? (Потому что злоумышленник не будет знать секрет клиента, надеюсь).

Если это не так, или если здесь есть другой вектор атаки, я не вижу, есть ли что-нибудь, что я могу сделать, чтобы сделать эту работу безопасно без HTTPS на клиентах? Будет ли, например, помощь OAuth 1? (Возможно, потому, что он имеет дополнительный шаг маркера запроса.)

P.S .: Я планировал выполнять аутентификацию клиента с использованием клиентских сертификатов TLS, а не секретов, если это делает ситуацию лучше.

ответ

2

Я думаю, что вы неверно истолковываете часть этого предупреждения. Это предупреждение OAuth адресует OWASP A9 нарушений. Это говорит о том, что даже если вы используете OAuth, вам по-прежнему нужен безопасный транспортный уровень для связи с клиентом. Клиент не требует пары ключей для аутентификации, OAuth - это форма аутентификации клиента. Однако браузер все еще аутентифицируется с вашим приложением, используя идентификатор сеанса, сохраненный как значение cookie. Вызывает беспокойство то, что, если злоумышленник может перехватить это значение, он будет иметь тот же доступ, что и жертвой клиента.

+0

Итак, если я правильно понимаю, проблема заключается не в том, что код авторизации отправляется в ясности, но что эти ресурсы отправляются в ящик от клиента к браузеру? (Скажем, сервер ресурсов пытался сохранить приватные личные данные с использованием TLS на подключении клиент-сервер, но тогда клиент нарушает это, передавая в ящике соединение браузера-клиента.) –

+0

@ Shtééf Файл cookie - это код авторизации , Если HTTP-запросы отправляются в виде обычного текста, каждый, кто может видеть этот трафик, должен получить доступ к веб-приложению. Если вы не защищаете файл cookie, тогда ничего не безопасно. – rook

+0

Я не думаю, что мы на одной странице. Под «кодом авторизации» я понимаю, что спецификация означает токен, сгенерированный сервером после того, как была предоставлена ​​авторизация, которую сервер присоединяет к запросу в URI перенаправления и отправляет его пользователю-агенту. Затем клиент получает это в запросе перенаправления, возможно, через простой HTTP. В cookie не участвует * еще *, но клиент может получить токен доступа и связать его с файлом cookie. Однако мой вопрос касается маркера авторизации. Я знаю, что cookie может быть скомпрометирован. –

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