Я сам борюсь с теми же понятиями. Я думаю, что первое, что нужно сделать, это только HTTPS, чтобы он начинал более безопасно, чем нет.
Далее, это зависит от того, как вы собираетесь выполнять аутентификацию. Если все, что вам нужно, это ключ API (для отслеживания того, какая сущность обращается к данным), это должно быть хорошо. Если вы также хотите отслеживать информацию о пользователях, вам нужно каким-то образом связать, чтобы определенные ключи API могли обращаться к определенным типам записей, основываясь на каком-то объединении.
Я смотрю на аутентификацию форм в моем приложении и использование куки-аутентификации. К счастью, ASP.NET на IIS может сделать для вас много тяжелой работы.
Пример времени: (Я уверен, что мне нужно добавить к этому больше, но пока я на работе, это дает что-то грызть)
Форма авторизации:
Отправьте пару (или более) полей в теле формы. Это POST насквозь. Не существует необратимого хеширования, которое может сделать это безопасным. Чтобы обезопасить его, вы всегда должны быть за брандмауэром от всех посторонних глаз (да, верно), или вы должны быть через HTTPS. Достаточно просто.
Базовый аутентификатор:
Отправьте кодированную base64 строку «username: password» по каналу как часть заголовка. Обратите внимание, что base64 должен быть защищен, как экранная дверь для подводной лодки. Вы не хотите, чтобы это было необеспеченным. HTTPS требуется.
Ключ API:
Это говорит о том, что приложение предположительно XYZ. Это должно быть частным. Это не имеет ничего общего с пользователями. Предпочтительно, когда во время запроса ключа API открытый ключ предоставляется совместно с лицом, предоставляющим API, что позволяет кодировать ключ API при передаче, тем самым гарантируя, что он остается закрытым, но при этом подтверждает, что источник является тем, кем он является. Это может усложниться, но поскольку существует процесс приложения, и поскольку он не будет отличаться от поставщика, это можно сделать через HTTP. Это не означает на пользователя , это означает на каждую развивающуюся компанию, которая использует ваше приложение .
Итак, вы хотите, чтобы приложение получало доступ к вашим данным, чтобы вы были уверены, что это авторизованное приложение, и вы можете проводить переговоры, используя закрытые ключи для подписи во время выполнения. Это гарантирует, что вы говорите с приложением, с которым хотите поговорить. Но помните, это не означает, что пользователь является тем, кем они себя называют.
ОДНАКО.
Что вы можете сделать, так это то, что вы можете использовать ключ API и связанные с ним открытый / закрытый ключи, чтобы кодировать информацию об имени пользователя и пароле для отправки их по проводной связи по HTTP. Это очень похоже на работу HTTPS, но вы шифруете только конфиденциальную часть сообщения.
Но чтобы позволить пользователю отслеживать свою информацию, вам нужно будет назначить токен на основе логина на основе пользователя. Поэтому позвольте им войти в систему, отправить данные по сети, используя соответствующую систему, а затем вернуть некоторый уникальный идентификатор, который представляет пользователя обратно в приложение. Позвольте приложению отправлять эту информацию каждый раз, когда вы выполняете определенные для пользователя задачи. (обычно все время).
Способ, которым вы отправляете его по проводам, заключается в том, что вы говорите клиенту установить куки, и все реализации httpClient, которые я когда-либо видел, знают, что когда они отправляют запрос на сервер, они отправляют обратно все куки, которые есть на сервере. когда-либо установить, которые все еще действительны. Это просто происходит для вас. Таким образом, вы устанавливаете cookie в своем ответе на сервере, который содержит любую информацию, необходимую для связи с клиентом.
HTH, задайте мне больше вопросов, чтобы мы могли уточнить это.