Как добавить API с oauth2 на вершине Kong

Я думаю, что мы очень кратко говорили о Gitter, и там я уже сказал, что это зависит от вашего варианта использования. Я сделаю краткое изложение типичных вариантов использования, и где вам нужно, какой вид дополнительной реализации.

Если вам нужны две системы для связи друг с другом из бэкэндов, и эти системы доверяют друг другу, вы можете использовать OAuth2 «Поток учетных данных клиента». В этом случае отсутствует идентификация «конечного пользователя», только две системы, которые явно доверяют друг другу.

Для этого сценария Kong — это все, что вам нужно — просто спросите конечную точку API-токена Kong (<address of kong>:8443/your_api/oauth2/token для маршрутизации на основе URI, или fqdn.of.kong:8443/oauth2/token если вы используете маршрутизацию на основе хоста) для токена доступа, используя свой идентификатор клиента и секрет, и вы получите его обратно.

Пример:

curl --insecure -d 'grant_type=client_credentials&client_id=<...>&client_secret=<..>' https://<address of kong>:8443/your_api/oauth2_token

Ваш бэкэнд-сервис получит дополнительные заголовки, такие как X-Consumer-Id а также X-Custom-ConsumerId который сопоставляется с потребителем, которого вы создали в Конге.

Если вам нужно использовать свой API из конфиденциального (= классического) веб-приложения, и вам необходимо иметь контекст конечного пользователя для каждого вызова, вы можете использовать OAuth2 «Предоставление кода авторизации». В этом случае вам также понадобится Сервер авторизации, который вам нужно внедрить самостоятельно.

Задача сервера авторизации — установить личность конечного пользователя (учтите: это не в OAuth2 указано, как это делается, и решать вам; вы можете подключиться к другому IdP, вы можете запросить имя пользователя и пароль, …), а затем решить, какие права (= «области действия») пользователь получает при доступе к API. Это полностью зависит от вас, и часть вашей бизнес-логики, как решить это.

Поток идет так:

1. Вы перенаправляете пользователя на веб-страницу сервера авторизации.
2. AS аутентифицирует пользователя (какими бы то ни было средствами) и определяет объемы (любыми другими способами)

3. AS разговаривает с Kong на двух разных уровнях

   • Через API администратора Kong, чтобы получить provision_key желаемого API
   • Через [/your_api]/oauth2/authorize конечная точка, которую он использует для получения URI перенаправления, который включает в себя код авторизации, в контексте аутентифицированного пользователя и его области (scope а также authenticated_userid); для вызова этой конечной точки вам понадобится response_type=code, client_id, client_secret, provision_key, authenticated_userid (что подходит) и опционально scope (области действия также должны быть определены в API, если вы хотите использовать это)

4. В случае успеха AS перенаправляет обратно в веб-приложение, используя URI перенаправления, возвращенный Kong

5. Веб-приложение вызывает Конга [/your_api]/oauth2/token конечная точка с его client_id, client_secret а также code, с использованием grant_type=code

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

Сервер авторизации должен быть внедрен вами; это не очень сложно, но вам все равно нужно убедиться, что вы знаете, как аутентифицировать пользователя и / или как вы делегируете это какому-то другому IdP.

В случае, если вам нужен доступ к API из одностраничного приложения (например, из приложения Angular или аналогичного), вы должны взглянуть на OAuth2 «неявный поток», который является более простым потоком, чем предоставление кода авторизации, но имеет другие недостатки. Например, нельзя использовать токены обновления.

Этот поток работает следующим образом:

1. Как и в случае с кодом авторизации, вы перенаправляете пользователя на сервер авторизации.
2. AS устанавливает личность и определяет область действия (еще раз, это зависит от вас)
3. AS вызывает конечную точку авторизации, точно так же, как при использовании кода авторизации, но на этот раз с response_type=token
4. Kong, в случае успеха, вернет URI перенаправления, который уже содержит токен
5. AS перенаправляет обратно в SPA, используя URI перенаправления из Kong, который имеет токен доступа во «фрагменте» URI (например, https://your.app.com/#access_token=<...>&token_type=bearer&...)

Ваш SPA теперь сможет использовать токен доступа для доступа к API, как и в случае с кодом авторизации, от имени аутентифицированного пользователя.

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

Последний сценарий, который я хотел бы затронуть, это мобильные приложения, такие как приложения для Android или iOS. Для них можно использовать последний поток OAuth2, «Предоставление пароля владельца ресурса». Короче говоря, с помощью этого гранта вы обмениваете действительные учетные данные пользователя (имя пользователя и пароль) с токеном доступа и токеном обновления, чтобы вам не приходилось хранить имя пользователя и пароль на мобильном устройстве более, чем временно.

Для этого потока также необходим сервер авторизации, чтобы иметь возможность использовать его с Kong, хотя и на этот раз менее сложным, даже если вы должны внедрить дополнительный token конечная точка (в дополнение к тому, что имеет Конг), которая не идеально описана в документации Конга.

Было бы так:

1. Мобильное приложение использует его client_id (НЕ секрет, секрет не должен развертываться вместе с приложением), имя пользователя и пароль для вызова конечной точки токена Сервера авторизации
2. Сервер авторизации проверяет имя пользователя и пароль (каким бы образом вы ни знали историю) и определяет объем (…)
3. AS снова общается с Kong через API администратора, получая client_secret за предоставленный client_id и provision_key для желаемого API

4. AS отправляет вызов конечной точке токена Kong [/your_api]/oauth2/token, как это:

   curl —insecure -d ‘grant_type = пароль&provision_key =<…>&client_id =<…>&client_secret =<…>&authenticated_userid =<…>&scope = ‘https: //: 8443 / your_api / oauth2 / token

Обратите внимание, что этот вызов не содержать имя пользователя и пароль; они не принадлежат здесь, вы должны сверять имя пользователя и пароль с вашим собственным источником личности, Kong не поможет вам в этом.

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

Я надеюсь, что это поможет пролить некоторый свет на то, как вы можете использовать Kong с OAuth2. Это сложно и сложно, но Конг может действительно помочь понять это правильно и отделить ваши проблемы.