Не позволяйте человеку на среднем (например, прокси) сервере притворяться, что это не так

Question

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

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

Может быть, нужна некоторая криптография?

Answer 1

Стандартный способ сделать это - сначала использовать HTTPS для веб-службы. Это означает, что сервер будет аутентифицироваться для клиента, плюс соединение будет зашифровано и аутентифицировано.

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

Хорошо настроенные прокси-серверы позволят туннелировать трафик HTTPS. Это не должно быть проблемой.

Answer 2

Мне кажется, что вы пытаетесь разрешить только одному приложению доступ к вашему веб-сервису.Один из способов сделать это - TLS с аутентификацией клиента.Для этого у клиента (вашего приложения) должна быть своя собственная пара сертификатов закрытых ключей, и сервер разрешит доступ только в том случае, если будет подтверждено владение закрытым ключом.Он использует точно такую ​​же PKI, что и для проверки сервера по умолчанию, только наоборот.

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

Большинство серверов приложений должны иметь возможность обрабатывать аутентификацию клиента.Дополнительная информация здесь в разделе «Подтверждение клиента TLS handshake».