Дизайн OAuth для API без пользовательского разрешения
Я разрабатываю API, который будет использоваться пользователями моих клиентов. Вот то, на что будет похож поток:
- Пользователь моего облачного сервиса создает ключ API.
- Пользователь встраивает ключ API в их собственные приложения.
- Пользователь развертывает приложение на их собственных конечных пользователях.
- Приложение говорит с нашим API.
Я ищу совет относительно того, как защитить этот API. Я вижу несколько проблем:
- Ключ API должен быть встроен в пользовательское приложение и поэтому уязвим для того, чтобы быть украденным и злоупотребленный.
- После того как ключ API поставлен под угрозу, он может легко быть отключен, но как мои пользователи обновят свои приложения для использования нового ключа API за исключением необходимости восстановить приложение и повторно развернуться.
У кого-либо есть какие-либо идеи о том, как разработать это?
1 ответ
Два решения, которые я могу найти для этого, хотя я уверен, что есть подробнее ..
Используйте метод подписи RSA oauth и реализуйте безопасный сертификационный обмен ключами, используя вашу «облачную службу» в качестве механизма обмена (или общедоступного поставщика сертификатов).
Внедрить службу, которая позволяет клиентам автоматически «обновлять» свой ключ / секрет потребителя, но затем защищать этот механизм с помощью RSA или другого метода шифрования с открытым ключом.
И то, и другое непросто и потребует от приложений вашего пользователя «звонить домой», чтобы обновить свои потребительские ключи.
Я думаю, что в будущем OAuth 2 будет предоставлять по крайней мере определения протоколов для подобных вещей, но сейчас, если вы используете OAuth 1.0a, то, что вы хотите сделать, не очень хорошо вписывается в спецификацию ( то есть вы должны спроектировать большую часть этого самостоятельно.)