Нужна помощь по Kong и OAuth с самоуправляемой базой данных пользователей

Мне нужно использовать Kong и OAuth для создания веб-приложения и некоторых других API.

Теперь у меня есть:

  • Сервер для Конга.
  • Сервер хранит информацию о пользователе, такую ​​как идентификатор, имя пользователя, пароль. Назвал его User-Database.

Мне необходимо:

  • Веб-приложение и некоторые другие собираются использовать API с OAuth2.0;
  • API предоставляет только Kong.

Согласно документу на Kong, я разработал учетную запись пароля владельца ресурса., И это примерно так:

(Эти API предназначены только для получения accessToken, без метода аутентификации)

  1. User-End post Имя пользователя и пароль для Kong
  2. Kong направляет его в базу данных пользователей.
  3. База данных пользователей проверяет имя пользователя и пароль и отправляет запрос в Kong. Запрос будет включать имя пользователя, пароль, provision_key, autherticated_userid. (*)
  4. Kong ответит access_token на User-Database, а также запомнит autherticated_userid, access_token и область видимости. Конг запомнит их до истечения срока действия токена доступа.
  5. После того, как User-Database получила ответ от Kong, он также ответит на шаги 1 и 2, и, наконец, User-End получит токен доступа для будущего использования.

(Получил токен доступа)

  1. User-End отправит запрос API, которым требуется аутентификация.

введите описание изображения здесь

Есть кое-что, чего я не понял на шаге 3.

Согласно документу о Конге:

$ curl https://your.api.com/oauth2/token \ --header "Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW" \ --data "client_id=XXX" \ --data "client_secret=XXX" \ --data "scope=XXX" \ --data "provision_key=XXX" \ --data "authenticated_userid=XXX" \ --data "username=XXX" \ --data "password=XXX"

The provision_key is the key the plugin has generated when it has been added to the API, while authenticated_userid is the ID of the end user whose username and password belong to.

Должен ли я хранить всю информацию о пользователях в моей самоуправляемой базе данных пользователей и в Kong обоих?

Или я что-то пропустил или могу оптимизировать?

Ссылка: Kong resource-owner-password-credentials


authentication kong api oauth
person Catscarlet    schedule 21.11.2016    source источник
comment
Я столкнулся с той же проблемой. Тебе удалось решить эту проблему?   -  person db80    schedule 09.08.2018
comment
API конга изменился в версии 1.0, и я не работал над ним, поэтому не знаю, что делать с новой версией сейчас. Ответ ниже может решить старую версию.   -  person Catscarlet    schedule 14.08.2018

Ответы (1)


arrow_upward
2
arrow_downward

Документация Kong довольно вводит в заблуждение с точки зрения предоставления пароля владельцу ресурса.

Этот поток по-прежнему требует, чтобы вы реализовали сервер авторизации, задача которого:

  • Для аутентификации пользователя, в данном случае с использованием предоставленных имени пользователя и пароля.
  • Авторизовать пользователя, то есть решить, следует ли выдавать токен доступа, и определить объем

Обратите внимание, что обе эти вещи полностью зависят от вас.

В конечном итоге ваш Сервер авторизации реализует свою собственную /authorize конечную точку, которая должна работать следующим образом:

Ваше клиентское приложение публикует:

client_id=<your client id>&
client_secret=<your client secret>&
username=<...>&
password=<...>&
grant_type=password&
(optional: scope=space delimited scopes)

Ваш сервер авторизации хранит provision_key или получает его через Kong Admin API (в зависимости от того, как выглядит ваша архитектура и можете ли вы использовать Admin API со своего сервера аутентификации).

Затем вы можете собрать фактический вызов /oauth2/token конечной точки Kong, используя как данные с сервера авторизации (т. Е. Аутентифицированный идентификатор пользователя и аутентифицированную область), provision_key и учетные данные клиента из вашего клиентского приложения:

POST https://kong:8443/yourapi/oauth2/token

grant_type=password&
client_id=(...)&
client_secret=(...)&
authenticated_userid=(...)&
authenticated_scope=(...)&
provision_key=(...)

Также обратите внимание, что для веб-приложения крайне важно быть конфиденциальным, если вы храните в нем идентификатор клиента и секрет, то есть используете только секретный секрет клиента на стороне сервера. Для ненадежных приложений (мобильных, SPA) можно разрешить серверу авторизации извлекать секрет клиента для использования с Kong через идентификатор клиента для секретного поиска (также с использованием Kong Admin API).

person donmartin    schedule 05.12.2016