Как вы управляете ключами API

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

Вам нужно что-то, что однозначно идентифицирует пользователя ... Просто используйте UUID или, возможно, хеш UUID.

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

Взгляните практически на любой сайт / услугу Web 2.0. Все они имеют разную степень аутентификации и управления ключами API. Flickr, Twitter, Github и т. д.

В зависимости от требований в мире веб-API предоставление вашим партнерам / разработчикам ключа API (идентификация) и требование, чтобы они подписывали вызовы (аутентификация), является довольно стандартным. Есть много способов указать сигнатуры. В наши дни довольно часто встречается; взять все параметры вызова, временную метку (+/- 5 минут покачивания), общий секрет и хэшировать его с помощью SHA-1 или MD5 (лучше SHA-1).

Вы можете реализовать это самостоятельно или найти партнера (их несколько), который сделает это за вас.

Предлагаемый здесь общий подход (использование хеша, включающего ключ API и текущее время) хорош - конечно, лучше, чем включение «пароля» в сообщение.

Однако существует крипто-стандартный способ выполнения этой операции «mung», называемый HMAC. Стоит посмотреть, если вы хотите что-то более стандартное / надежное / безопасное.

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

В качестве альтернативы вы можете использовать двусторонний SSL для транспортного уровня и просто доверять этому в приложении / API.

На самом деле зависит от того, насколько безопасно вы этого хотите ...:]