Как сохранить конфиденциальность учетных данных клиента при использовании типа предоставления OAuth2 Resource Owner Password Credentials

Question

Мы создаем службу отдыха и хотим использовать OAauth 2 для авторизации. текущий проект (v2-16 от 19 мая) описывает четыре типа грантов .Это механизмы или потоки для получения авторизации (токена доступа).

1. Код авторизации
2. Неявное предоставление
3. Учетные данные владельца ресурса
4. Учетные данные клиента

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

Итак, мои вопросы:

1. Как вы думаете, правильно ли я понял назначение различных типов грантов?
2. Как сохранить конфиденциальность ваших учетных данных клиента?И в третьем, и в четвертом случае нам нужно иметь идентификатор клиента и его секретный ключ где-то на клиенте, что не очень хорошая идея.
3. Даже если вы используете неявный тип предоставления и вы не используетене раскрываете ваш клиентский секрет, что мешает другому приложению олицетворять ваше приложение, используя тот же механизм авторизации и ваш идентификатор клиента?

Подводя итог, мы хотим иметь возможность использовать учетные данные клиента и владельца ресурса.поток учетных данных из клиентского приложения.Оба эти потока требуют, чтобы вы как-то хранили секрет клиента, но клиент является мобильным приложением или приложением JavaScript, поэтому их можно легко украсть.

Answer 1

Я сталкиваюсь с похожими проблемами, а также относительно новичок в OAuth. Я внедрил «Учетные данные пароля владельца ресурса» в нашем API для использования в нашем официальном мобильном приложении - веб-потоки просто кажутся ужасными для использования на мобильной платформе, и как только пользователь устанавливает приложение и доверяет ему что это наше официальное приложение, им должно быть удобно вводить имя пользователя и пароль непосредственно в приложение.

Проблема, как вы указываете, в том, что мой API-сервер не может безопасно проверить client_id приложения. Если я включу client_secret в код / ​​пакет приложения, он будет доступен всем, кто устанавливает приложение, поэтому требование client_secret не сделает процесс более безопасным. В общем, любое другое приложение может выдать себя за мое приложение, скопировав client_id.

Просто чтобы направить ответы на каждый из ваших пунктов:

1. Я продолжаю перечитывать различные проекты спецификации, чтобы увидеть, изменилось ли что-нибудь, и сосредоточен в основном на разделе «Учетные данные пароля владельца ресурса», но я думаю, что вы правы в этом. Учетные данные клиента (4) Я думаю, что также может использоваться внутренней или сторонней службой, которой может потребоваться доступ не только к «общедоступной» информации, например, если у вас есть аналитика или что-то, что необходимо для получения информации среди всех пользователей.

2. Я не думаю, что вы можете сохранить конфиденциальность клиента.

3. Ничто не мешает другому использовать ваш идентификатор клиента. Это тоже моя проблема. Как только ваш код покидает сервер и устанавливается как приложение или работает как Javascript в браузере, вы не можете предполагать, что что-то является секретным.

Для нашего веб-сайта у нас была проблема, аналогичная той, что вы описали в потоке учетных данных клиента. В итоге я перенес аутентификацию на серверную часть. Пользователь может пройти аутентификацию с помощью нашего веб-приложения, но токен OAuth для нашего API хранится на стороне сервера и связан с веб-сеансом пользователя. Все запросы API, которые делает код Javascript, на самом деле являются AJAX-вызовами веб-сервера. Таким образом, браузер напрямую не аутентифицируется с помощью API, а вместо этого имеет аутентифицированный веб-сеанс.

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

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

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