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

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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