Я хотел бы добавить разъясняющую информацию к этому вопросу.Ответ «use OAuth» правильный, но также загруженный (учитывая, что спецификация довольно длинная, и люди, которые не знакомы с ней, обычно хотят убить себя, увидев ее).
Я написал историю -руководство по стилю о том, как перейти от отсутствия защиты к защите на основе HMAC при разработке защищенного REST API, здесь:
В конечном итоге это в основном то, чтоизвестный как «Двуногий OAuth»;Поскольку OAuth изначально предназначался для проверки клиентских приложений, поток состоит из трех частей, включающих службу аутентификации, пользователя, смотрящего на экран, и службы, которая хочет использовать учетные данные клиента.
2-legged OAuth (ито, что я подробно изложил в этой статье), предназначено для API-интерфейсов служб для аутентификации между собой.Например, это подход, который Amazon Web Services использует для всех своих вызовов API.
gist заключается в том, что при любом запросе по HTTP вы должны учитывать вектор атаки, когда некоторые злонамеренныеin-the-middle записывает и воспроизводит или изменяет ваши запросы.
Например, вы запускаете POST для / user / create с именем 'bob', а человек в середине может выдатьPOST для / user / delete с именем 'bob' только для того, чтобы быть противным.
Клиенту и серверу нужен какой-то способ доверять друг другу, и единственный способ, которым это может случиться, - это использование открытых / закрытых ключей.
Вы не можете просто передавать открытые / закрытые ключи взад и вперед. NOR, вы можете просто предоставить уникальный токен, подписанный закрытым ключом (обычно , что большинство людей делают и думают, что делает их безопасными), хотя при этом будет определяться исходный запрос, исходящий от реального клиента, он все равно оставляет аргументы комментария открытыми для изменения.
Например, если я отправлю: / chargeCC? user = bob & amt = 100.00 & key = kjDSLKjdasdmiUDSkjh
где ключом является мой открытый ключ, подписанный моим личным ключом, только человек в середине может перехватить этот вызов и повторно отправить его на сервер с пометкой "amt"значение" 10000.00 "вместо этого.
Ключ заключается в том, что вы должны включить ВСЕ параметры, которые вы отправляете, в вычисление хэша, поэтому, когда сервер получает его, он повторно проверяет все значения путем пересчета того жехеш на его стороне.
НАПОМИНАНИЕ: Только клиент и сервер знают закрытый ключ.
Этот стиль проверки называется "HMAC";это контрольная сумма, проверяющая содержание запроса.
Поскольку генерация хешей настолько раздражающая и должна быть сделана ИМЕННО одинаково как на клиенте, так и на сервере, чтобы получить одинаковый хеш,Существуют очень строгие правила относительно того, как именно должны объединяться все значения.
Например, эти две строки предоставляют ОЧЕНЬ разные хэши, когда вы пытаетесь подписать их с помощью SHA-1: / chargeCC & user = bob & amt = 100 /chargeCC & amt = 100 & user = bob
Большая часть спецификации OAuth посвящена описанию этого точного метода комбинирования в мучительных деталях с использованием такой терминологии, как «естественное упорядочение байтов» и другие, не читаемые человекоммусор.
Это важно, потому что, если вы ошибаетесь в этой комбинации значений, клиент и сервер не смогут корректно проверять запросы друг друга.
Вы также не можете использовать ярлыки и просто объединятьвсе в огромную строку, Amazon попробовал это с AWS Signature Version 1, и оказалось не так .
Надеюсь, все это поможет, не стесняйтесь задавать вопросы, если вы застряли.