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

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

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

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

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

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

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

+68
источник поделиться
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 никогда не были бы хороши в течение более одного дня. Может побудить потенциальных воров-маркеров просто зарегистрироваться вместо этого. Но какая-то боль для всех остальных, поэтому не уверен, что это того стоит.

+53
источник

Связанные вопросы


Похожие вопросы

Посмотрите другие вопросы по меткам или Задайте вопрос