Блог

Я собираюсь написать сервисы для приложения iPhone, создаваемого сторонним поставщиком.

Я буду использовать ASP.NET MVC для приема сообщений, а также возврата данных в формате JSON.

Мой вопрос в том, как вы это защищаете?

Возможно, просто используя ключ API? Будет ли этого достаточно, чтобы гарантировать, что доступ к указанным службам разрешен только данным из приложений iPhone?

Я сам как бы борюсь с теми же концепциями. Я думаю, что первое, что нужно сделать, это использовать только HTTPS, чтобы это было более безопасно, чем нет.

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

Я собираюсь выполнить аутентификацию форм в своем приложении и использовать файл cookie для аутентификации. К счастью ASP.NET IIS может выполнить за вас большую часть этой тяжелой работы.

Примерное время: (Я уверен, что мне нужно будет добавить к этому больше, но пока я на работе, это дает повод для размышлений)

Проверка подлинности форм: отправьте пару (или более) полей в теле формы. Этот ПОСТ от начала до конца. Нет такого количества необратимого хеширования, которое могло бы сделать это безопасным. Чтобы защитить его, вы должны либо всегда находиться за брандмауэром от всех посторонних глаз (да, правильно), либо вы должны быть через HTTPS. Достаточно просто.

Базовая аутентификация: отправьте строку «имя пользователя: пароль» в кодировке base64 по сети как часть заголовка. Обратите внимание, что base64 должен быть защищен, как сетчатая дверь для подводной лодки. Вы же не хотите, чтобы оно было незащищенным. Требуется HTTPS.

Ключ API:Это говорит о том, что приложение предположительно является XYZ. Это должно быть закрытым. Это не имеет никакого отношения к пользователям. Предпочтительно, чтобы во время запроса ключа API открытый ключ предоставлялся лицу, предоставляющему API, что позволяет кодировать ключ API при передаче, гарантируя, таким образом, что он остается закрытым, но при этом подтверждает, что источник является тем, кем он является. Это может усложниться, но поскольку существует процесс подачи заявки и поскольку он не зависит от поставщика, это можно сделать через HTTP. Это означает не для каждого пользователя, это означает для каждой компании-разработчика, котораяиспользует ваш api.

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

ОДНАКО.

Что вы можете сделать, так это использовать ключ API и связанные с ним открытые / приватные ключи для кодирования имени пользователя и пароля для отправки их по сети с использованием HTTP. Это очень похоже на то, как работает HTTPS, но вы шифруете только конфиденциальную часть сообщения.

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

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

HTH, задавайте мне больше вопросов, чтобы мы могли доработать это дальше.

Одним из вариантов было бы использовать проверку подлинности forms и использовать cookie-файл аутентификации. Кроме того, убедитесь, что все вызовы служб отправляются по протоколу SSL.