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

Question

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

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

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

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

У кого-нибудь есть идеи о том, как его спроектировать?

Answer 1

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

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

Answer 2

Два решения, которые я вижу в этом, хотя я уверен, что есть еще ..

1. Используйте метод подписи RSA oauth и осуществите безопасный сертификационный обмен ключами, используя ваш«облачная служба» как механизм обмена (или публичный поставщик сертификатов).

2. Реализация службы, которая позволяет клиентам автоматически «обновлять» свой ключ / секретный ключ потребителя, но затем защищать его.Механизм, использующий RSA или другой метод шифрования с открытым ключом.

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

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