Как сохранить конфиденциальность учетных данных клиента при использовании типа предоставления учетных данных пароля владельца ресурса OAuth2
Мы создаем сервис отдыха и хотим использовать OAauth 2 для авторизации. Текущий проект (v2-16 от 19 мая) описывает четыре типа предоставления . Это механизмы или потоки для получения авторизации (токена доступа).
- Код авторизации
- Неявное предоставление
- Учетные данные владельца ресурса
- Учетные данные клиента
Кажется, нам необходимо поддерживать все четыре из них, поскольку они служат разным целям. Первые два (и, возможно, последний) можно использовать из сторонних приложений, которым нужен доступ к API. Код авторизации - это стандартный способ авторизации веб-приложения, которому посчастливилось находиться на защищенном сервере, в то время как неявный поток предоставления был бы выбором для клиентского приложения, которое не может полностью сохранить конфиденциальность своих учетных данных (например, мобильный / настольный компьютер). приложение, клиент JavaScript и т. д.).
Мы сами хотим использовать третий механизм, чтобы обеспечить лучший пользовательский интерфейс на мобильных устройствах - вместо того, чтобы выводить пользователя в диалоговое окно входа в систему в веб-браузере и т. Д., Пользователь просто вводит свое имя пользователя и пароль непосредственно в приложении. и авторизуйтесь.
Мы также хотим использовать тип предоставления Client Credentials для получения токена доступа, который можно использовать для просмотра общедоступных данных, не связанных с каким-либо пользователем. В данном случае это не столько авторизация, сколько нечто похожее на ключ API, который мы используем для предоставления доступа только зарегистрированным у нас приложениям, что дает нам возможность при необходимости отозвать доступ.
Итак, мои вопросы:
- Как вы думаете, я правильно понял назначение различных типов грантов?
- Как вы можете сохранить конфиденциальность ваших учетных данных клиента? И в третьем, и в четвертом случае нам нужно иметь идентификатор клиента и секрет клиента где-то на клиенте, что не похоже на хорошую идею.
- Даже если вы используете неявный тип предоставления и не раскрываете секрет вашего клиента, что мешает другому приложению олицетворять ваше приложение с использованием того же механизма авторизации и вашего идентификатора клиента?
Подводя итог, мы хотим иметь возможность использовать учетные данные клиента и учетные данные владельца ресурса, передаваемые из клиентского приложения. Оба этих потока требуют, чтобы вы каким-то образом сохранили секрет клиента, но клиент - это мобильное приложение или приложение JavaScript, поэтому его можно легко украсть.