Я намерен создать делегированную систему входа для существующего приложения. Я буду реализовывать как клиент 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, а не секретов, если это делает ситуацию лучше.
Итак, если я правильно понимаю, проблема заключается не в том, что код авторизации отправляется в ясности, но что эти ресурсы отправляются в ящик от клиента к браузеру? (Скажем, сервер ресурсов пытался сохранить приватные личные данные с использованием TLS на подключении клиент-сервер, но тогда клиент нарушает это, передавая в ящике соединение браузера-клиента.) –
@ Shtééf Файл cookie - это код авторизации , Если HTTP-запросы отправляются в виде обычного текста, каждый, кто может видеть этот трафик, должен получить доступ к веб-приложению. Если вы не защищаете файл cookie, тогда ничего не безопасно. – rook
Я не думаю, что мы на одной странице. Под «кодом авторизации» я понимаю, что спецификация означает токен, сгенерированный сервером после того, как была предоставлена авторизация, которую сервер присоединяет к запросу в URI перенаправления и отправляет его пользователю-агенту. Затем клиент получает это в запросе перенаправления, возможно, через простой HTTP. В cookie не участвует * еще *, но клиент может получить токен доступа и связать его с файлом cookie. Однако мой вопрос касается маркера авторизации. Я знаю, что cookie может быть скомпрометирован. –