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

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

Код авторизации
Неявный грант
Учетные данные владельца ресурса
Клиентские полномочия

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

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

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

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

Ответ 1

Я сталкиваюсь с подобными проблемами, и я также относительно новичок в OAuth. Я применил "Credentials Password Credentials" в нашем API для нашего официального приложения для мобильных устройств - потоки в Интернете просто выглядят так, как если бы они были настолько ужасны для использования на мобильной платформе, и как только пользователь установит приложение и доверяет что это наше официальное приложение, им должно быть удобно вводить имя пользователя/пароль прямо в приложение.

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

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

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

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

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

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

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