Ответ 1
[the] poster говорит, что если мы не используем клиентский сервер сертификации SSL, он действительно не знает, с кем его разговаривают.
Это не то, что я сказал:) Вот что я сказал:
Если вы не используете аутентификацию клиента TLS, только SSL не является жизнеспособным механизмом аутентификации для REST API.
один является ключевым словом здесь. Также:
Если вы не используете аутентификацию клиента TLS, вам нужно использовать что-то вроде схемы аутентификации на основе дайджеста (например, пользовательской схемы Amazon Web Service) или OAuth или даже обычной HTTP-аутентификации (но только через SSL).
Другими словами, аутентификация клиента TLS является одним из способов аутентификации клиента REST API. Поскольку исходный вопрос SO касался собственно SSL, я упоминал, что TLS-клиент authc является единственной "встроенной" формой аутентификации, если вы полагаетесь только на TLS. Поэтому, если вы используете TLS и не используете клиентскую лицензию TLS, вы должны использовать другую форму аутентификации для аутентификации вашего клиента.
Существует много способов аутентификации клиентов REST. TLS client authc - это только один из них (единственный "встроенный" для TLS и обычно очень безопасный). Однако TLS является протоколом сетевого уровня и, по мнению большинства, слишком сложна для многих конечных пользователей для настройки. Таким образом, большинство предложений REST API выбирают простой в использовании протокол уровня приложения, такой как HTTP, потому что его легче использовать (например, просто установить HTTP-заголовок).
Итак, если вы собираетесь использовать маршрут заголовка HTTP, вам нужно использовать значение заголовка для аутентификации клиента REST.
В HTTP-аутентификации у вас есть заголовок, Authorization и его значение (имя заголовка довольно неудачно, потому что оно обычно используется для аутентификации, а не так часто для контроля доступа, а также авторизации). Значением заголовка Authorization является то, что используется сервером для выполнения аутентификации, и оно составлено (обычно) из трех токенов
- Имя схемы аутентификации HTTP, за которой следует
- пробел (почти всегда пробельный символ), за которым следует
- Текстовое значение, специфичное для схемы.
Одна общая схема проверки подлинности HTTP - это схема Basic, которая очень... ну... базовая:). Текстовое значение, специфичное для схемы, представляет собой просто следующее вычисляемое значение:
String concatenated = username + ":" + raw_password;
String schemeSpecificTextValue = base_64_encode(concatenated.toCharArray());
Итак, вы можете видеть, что соответствующий заголовок выглядит следующим образом:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Сервер знает, как разбирать значение. В нем говорится: "Эй, я знаю схему Basic, поэтому я собираюсь взять конечное текстовое значение, base64 декодирует его, а затем у меня будет имя пользователя и пароль. Тогда я вижу, соответствуют ли эти значения тем, что Я сохранил."
И это по существу Basic аутентификация. Поскольку эта схема, в частности, включает в себя исходный необработанный пароль base64, он не считается безопасным, если вы не используете соединение TLS. TLS гарантирует (главным образом), что любопытные глаза не могут перехватывать заголовки (например, через проверку пакетов) и видеть, что такое пароль. Вот почему вы никогда не должны использовать аутентификацию HTTP Basic, если она не связана с TLS-соединением. Всегда - даже в среде интрасети компании.
Существуют и другие, более безопасные схемы аутентификации HTTP, конечно. Примером может служить любая схема, использующая аутентификацию на основе дайджеста.
Схемы аутентификации на основе дайджеста лучше, потому что их текстовое значение схемы не содержит введенный пароль. Вместо этого вычисляется байт-хэш определенных данных (часто другие поля и значения заголовков) и результат помещается в значение заголовка Authorization. Сервер вычисляет один и тот же пароль на основе пароля, используя пароль, который он хранит локально. Если вычисленное значение сервера соответствует значению заголовка запроса, сервер может считать запрос аутентифицированным.
Вот почему этот метод более безопасен: передается только хеш - не сам сырой пароль. Это означает, что этот метод может использоваться для аутентификации запросов даже по каналам clear-text (non TLS) (но вы хотели бы сделать это, только если сами данные запроса не чувствительны).
Некоторые схемы проверки подлинности на основе дайджеста:
- OAuth 1.0a, также известный как RFC 5849.
- HTTP-дайджест-доступ аутентификация (используется браузерами изначально).
- Пользовательская схема Stormpath (полное раскрытие, я технический директор Stormpath).
- Пользовательская схема Amazon AWS.
Stormpath и Amazon более безопасны для REST, чем OAuth 1.0a, потому что они всегда аутентифицируют полезную нагрузку на объект запроса. OAuth 1.0a делает это только для содержимого application/x-www-form-urlencoded, которое не имеет отношения к API REST, которые используют полезную нагрузку application/xml или application/json (которая в наши дни кажется наиболее REST API).
Интересно, что OAuth2 не основывается на дайджесте - он использует то, что я считаю менее безопасным, называемое "токенами-носителями", которое, на мой взгляд, является симптомом OAuth 2 проблемы.
Наконец, да, это бесстыдный плагин, но если вы не хотите беспокоиться об этом, просто используйте Stormpath (многие варианты использования бесплатны). Мы автоматизируем этот материал, чтобы ваши приложения не нуждались.