OAuth 2.0 двухсторонняя аутентификация против SSL/TLS

У меня есть два корпоративных сервера, которым нужно безопасно общаться, и я сравниваю использование SSL (с сертификатами клиента/сервера для проверки обеих сторон) и двухстороннюю аутентификацию с использованием OAuth 2.0 (опционально с маркерами MAC или токенами JWT),

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

Единственное, о чем я могу думать, это то, что OAuth потенциально проще настроить, чем SSL, и легко ошибаться в таких вещах, как принятие неверных сертификатов SSL, которые могут поставить под угрозу безопасность. Однако я не уверен, что это достаточно, чтобы пойти с OAuth.

Обратите внимание, что я упоминаю их как отдельные параметры, но я думаю, что использование OAuth, вероятно, повлечет за собой использование его поверх HTTPS/SSL, поэтому оба будут использоваться.

Есть ли реальное преимущество использования двухсторонней схемы OAuth 2.0 для связи между серверами (без участия пользователя)?

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

+9
источник поделиться
2 ответа

Я отвечу на этот комментарий:

Мой вопрос в том, что, полагая, что я использую SSL с надлежащими сертификатами клиент/сервер, чтобы идентифицировать каждую машину, какое значение будет использовать OAuth (2 legged или аналогичный) поверх этого, чтобы разрешить серверы друг другу (при условии, что есть без участия пользователя). Спасибо - Locksleyu

Резюме: Я бы не стал заниматься этим.

Подробности: 2-legged OAUTH является настолько же безопасным, как и секрет потребителя. Аналогично, взаимный SSL-протокол SSL безопасен только как закрытый ключ. Я предполагаю, что вы будете хранить их в некотором зашифрованном хранилище на каждом сервере. Поскольку обе они хранятся в одном и том же месте, я не вижу дополнительной безопасности, связанной с добавлением OAUTH.

Теперь, если вы рассматриваете выбор между взаимным SSL и стандартным SSL с аутентификацией, возможно, OAUTH может сыграть свою роль. Я бы пошел с тем, что из этих вариантов кажется проще. Поэтому, если у вас есть система OAUTH, и вы можете легко добавить серверную аутентификацию сервера, возможно, это путь. В противном случае просто перейдите к взаимному SSL-протоколу SSL. Это, как правило, немного хлопот для настройки, но работает хорошо и быстро после настройки.

+3
источник

Извините, если вы уже знаете это, но это не ясно в вашем сообщении.

OAuth и SSL\TLS - два отдельных уровня модели OSI. OAuth предназначен для аутентификации и находится на верхнем уровне в слое 7, тогда как SSL\TLS предназначен для безопасности транспорта на уровне 4. Легко путать SSL с клиентскими сертификатами, потому что они оба используют PKI.

Вы правы в своем понимании OAuth... он используется для авторизации отдельных лиц, а не организаций\серверов. 2-legged OAuth - это термин, который выбрасывается вокруг, который охватывает различные альтернативные потоки OAuth, все из которых не соответствуют стандарту.

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

+6
источник

Посмотрите другие вопросы по меткам или Задайте вопрос