Нужны ли приложения Oauth2 для подключения SSL?

Question

Какие стороны Oauth 2.0 должны иметь SSL-соединение?

• Auth сервер: SSL требуется
• ресурсов сервера: SSL требуется
• Клиентские приложения: Является ли это действительно необходимо, до тех пор, как он использует SSL для связи сервера ресурсов?

Answer 1

Сервер авторизации необходимо использовать SSL/TLS в соответствии с specification, например:

Так как запросы к результату конечной точки авторизации в аутентификации пользователя и передачи открытым текстом учетных данных (в ответе HTTP ), сервер авторизации ДОЛЖЕН требовать использования TLS , как описано в Разделе 1.6, при отправке запросов на конечную точку авторизации .

Поскольку запросы к лексеме результата конечной точки в передаче ясного текст полномочий (в запросе HTTP и ответ), сервер авторизации должен потребовать использование TLS, как описано в разделе 1.6 при отправке запросов к конечная точка маркера.

То же спецификация не требует его для клиентского приложения, но в значительной степени рекомендует его:

Перенаправление конечной точке следует потребовать использования TLS, как описано в разделе 1.6, когда запрашиваемая ответ тип - это «код» или «токен», или когда запрос перенаправления приведет к передаче чувствительных учетных данных по открытой сети. В этой спецификации не требует использования TLS, поскольку на момент написания этой статьи , требующий от клиентов развертывания TLS, является значительным препятствием для многих разработчиков клиентов . Если TLS недоступен, сервер авторизации ДОЛЖЕН предупредить владельца ресурса о небезопасной конечной точке до перенаправления (например, отобразить сообщение во время авторизации ).

Отсутствие безопасности на транспортном уровне может оказать серьезное влияние на безопасность клиента и защищенных ресурсов . Использование безопасности транспортного уровня, в частности, является критически важным, когда процесс авторизации используется как форма делегированная конечная аутентификация пользователя клиентом (например, служба входа в систему стороннего поставщика).

Вызовы на сервере ресурсов содержат маркер доступа и требуют SSL/TLS: токенов учетные данные

доступа (а также любой конфиденциальный доступ лексем атрибуты) должны храниться в тайне при транспортировке и хранении, и , доступный только между сервером авторизации, серверами ресурсов является допустимый токен доступа , а клиент, которому принадлежит токен доступа .Учетные данные доступа к токену ДОЛЖНЫ быть переданы только с использованием TLS , как описано в Разделе 1.6, с аутентификацией сервера, как определено [RFC2818].

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

Вы спрашиваете, как конкретно вызывается клиентское приложение.

Приложения для клиентов: действительно ли это необходимо, если для связи с сервером ресурсов используется SSL?

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

И у вас есть ответ: это сообщение каким-то образом аутентифицировано. Как еще сервер узнает, кто звонит? Большинство веб-сайтов используют куки-файлы сеанса, которые они устанавливают в начале сеанса, и используют их для идентификации сеанса и для этого пользователя. Любой, кто может захватить этот cookie сеанса, может захватить сеанс и выдавать себя за пользователя. Если вы этого не хотите (и вам действительно этого не нужно), вы должны использовать SSL/TLS для обеспечения связи между браузером и сервером.

В некоторых случаях часть браузера клиента напрямую связана с сервером ресурсов; и серверная часть обслуживает только статический контент, такой как HTML, CSS, изображения и, наконец, JavaScript. Возможно, ваш клиент построен таким образом, и вам интересно, нужно ли загружать статический контент через SSL/TLS? Ну, если это не так, человек в середине может вставить свой собственный злой JavaScript, который крадет вам токены доступа пользователя. Вы хотите обеспечить загрузку статического контента.

И последнее, но не менее важное: ваш вопрос основан на скрытом предположении, что могут быть веские причины не использовать SSL/TLS. Часто люди утверждают, что стоимость сертификата слишком высока, или для шифрования требуется слишком большая мощность процессора, поэтому требуется больше оборудования для запуска приложения. Я не считаю, что эти затраты значительны практически во всех случаях. Они очень низкие, по сравнению с общей стоимостью строительства и запуска решения. Они также очень низки по сравнению с рисками не использовать шифрование. Не тратьте время (и деньги) на обсуждение этого, просто используйте SSL/TLS полностью.