Дизайн OAuth для API без разрешения пользователя

Я разрабатываю API, который будет использоваться пользователями моих клиентов. Вот как будет выглядеть поток:

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

Я ищу советы по защите этого API. Я вижу несколько вопросов:

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

Есть ли у кого-нибудь идеи о том, как это сделать?

Ответ 1

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

Это будет медленнее и потребует дополнительной работы со стороны ваших клиентов, но также и безопаснее.

Ответ 2

Два решения, которые я могу видеть, хотя я уверен, что их больше.

Использовать метод подписи RSA и использовать безопасный обмен сертификатами ключей с помощью "облачной службы" в качестве механизма обмена (или публичного поставщика сертификатов).
Внедрение службы, которая позволяет клиентам "обновлять" свой потребительский ключ/секрет автоматически, но затем защищать этот механизм с помощью RSA или другого метода шифрования с открытым ключом.

Оба из них нелегки и потребуют от ваших пользовательских приложений "позвонить домой", чтобы обновить их потребительские ключи.

В будущем я думаю, что OAuth 2 предоставит хотя бы определения протоколов для таких вещей, но пока, если вы используете OAuth 1.0a, то, что вы хотите сделать, не очень хорошо вписывается в спецификацию ( т.е. вы сами должны проектировать большую часть этого.)