Базовая аутентификация HTTP против секретного ключа
После создания довольно простого API я начал изучать аутентификацию, где базовая HTTP-аутентификация по SSL с простой комбинацией имени пользователя и пароля может показаться слабой для того, кто его использует, хотя различные обсуждения здесь показывают, что все должно быть в порядке.
Поскольку это так, я изучил API-интерфейсы из похожих решений, которые вместо этого предоставляют своим пользователям идентификатор пользователя и ключ API. Проблема в том, что я не вижу, насколько это сильнее. Я предполагаю, что Ключ все еще сохраняется так же, как и пароль, где, с моей точки зрения, похоже, что они называют пароль ключом.
Пример:
Как работает &api_key=hiperz_api_key&gs_id=3873 args предлагает какую-либо дополнительную безопасность, чем просто пароль пользователя? Я определенно хотел бы реализовать что-то более сильное, чем просто пользователь / передача поверх базовой HTTP-аутентификации, и предоставить конечному пользователю какой-то тип токена / ключа, который будет использоваться для доступа, но я не вижу дополнительной силы от таких подходов.
Решение
Базовая аутентификация Не рекомендуется защищать API, как я пытался объяснить в мой ответ здесь.
Вы правы в том, что использование идентификатора клиента и секрета клиента очень похоже на аутентификацию имени пользователя и пароля. Разница в том, что в последнем случае вы аутентифицируете пользователя (человека), а в первом — аутентификацию клиента (приложения).
Хотите ли вы защитить свой API с помощью идентификатора и секрета клиента, зависит от того, можете ли вы доверять клиенту, чтобы хранить их в секрете.
В любом случае, есть ли у вас доверенный клиент, например, веб-приложение (живущее на защищенном сервере) или ненадежный клиент, такой как приложение JavaScript или мобильное приложение (живущее в сфере пользователя), схемы аутентификации на основе токенов (например, OAuth2) обеспечить более безопасный способ защиты вашего API, чем обычная аутентификация. Увидеть мой ответ здесь для получения дополнительной информации о различных способах получения токенов с помощью OAuth 2.0
Другие решения
Что ж, всегда есть двухэтапная аутентификация, которую можно выполнить (отправив сообщение на свой телефон … или, возможно, предоставив каждому пользователю случайно сгенерированный код для заполнения). Кроме того, вы можете создать свой собственный механизм шифрования и добавить его к функциональности ваших веб-страниц. Например, вы можете зашифровать данные, используя свой составной ключ шифрования, а затем, когда он достигнет нужного вам места, вы узнаете только ключ и сможете его расшифровать.
Сейчас я изучаю API. Насколько я понимаю, с помощью ключа API вы можете лучше контролировать, какие разрешения имеет пользователь. Также ключ API может быть повторно вызван в любое время. Кроме того, это сэкономит клиенту время от ввода подробных сведений о каждом использовании API. Я не уверен, что ответил на ваш вопрос или нет.