Поддерживает ли Nginx с открытым исходным кодом OpenID и JWT?
У меня есть базовый образ докера Nginx, выступающий в роли обратного прокси-сервера, который в настоящее время использует базовую аутентификацию перед моим сервером приложений. Я ищу способ интегрировать его с нашим разрабатываемым решением SSO, использующим JWT, но во всей документации говорится, что для этого требуется Nginx+. Итак, можно ли выполнить проверку JWT внутри Nginx с открытым исходным кодом, или мне нужна платная версия?
Ответы 3
Конечно, есть открытые исходные коды, которые вы можете использовать и настроить под свой случай (пример).
ИМХО, есть лучшие реализации, которые вы можете использовать в качестве «прокси-сервера аутентификации» перед вашим приложением. Мой фаворит — плащ-привратник (вы можете использовать его с любым OpenID IdP, а не только с Keycloak), который может обеспечить аутентификацию, авторизацию, шифрование токена, реализацию токена обновления, небольшой размер, ...
Для информации, keycloak-gatekeeper теперь это Louketo Proxy: github.com/louketo/louketo-прокси Не уверен, что он справится с Azure AD, но я собираюсь попробовать.
Прокси-сервер louketo является EOL, и они рекомендуют github.com/oauth2-прокси/oauth2-прокси
@joergwork, но это не замена. Мой фаворит по-прежнему гейткипер, но теперь форк github.com/gogatekeeper/привратник
@JanGaraj спасибо, не понял. Гейткипер больше соответствует моим требованиям, чем oauth2-proxy.
Также есть lua-resty-openidc: https://github.com/zmartzone/lua-resty-openidc
lua-resty-openidc is a library for NGINX implementing the OpenID Connect Relying Party (RP) and/or the OAuth 2.0 Resource Server (RS) functionality.
When used as an OpenID Connect Relying Party it authenticates users against an OpenID Connect Provider using OpenID Connect Discovery and the Basic Client Profile (i.e. the Authorization Code flow). When used as an OAuth 2.0 Resource Server it can validate OAuth 2.0 Bearer Access Tokens against an Authorization Server or, in case a JSON Web Token is used for an Access Token, verification can happen against a pre-configured secret/key .
Учитывая, что у вас настроена конфигурация без аутентификации, я нашел это и заставил его работать: https://hub.docker.com/r/tomsmithokta/nginx-oss-okta, который полностью основан на lua-resty-openidc, как упоминалось выше. Однако мне помогло то, что он уже был построен.
Сначала настройте приложение Okta в веб-интерфейсе Okta, затем заполните соответствующие поля, которые не закомментированы в примере конфигурации NGINX. Единственное предостережение — раскомментировать поле redirect_uri и заполнить его, но вместо этого закомментировать или удалить поле redirect_uri_path, которое является устаревшим. Все остальное в конфиге — это параметры, с которыми вы можете поиграться или просто принять их как есть.
По умолчанию он передает вас на страницу заголовков, но если вы настроите поле proxy_pass, вы сможете передать его в свое приложение.
Вы можете выяснить, было ли это доступно для NGINX с открытым исходным кодом? Я вижу статьи справки NGINX+ по этому поводу: docs.nginx.com/nginx/deployment-guides/single-sign-on/okta/…, но не знаю, стоит ли пытаться.