我需要帮助来了解身份验证/授权流程的工作原理。我正在参考我目前正在使用的特定技术,但我不太需要技术方面的帮助(尽管如果可以的话我会很感激),而是需要一般性的理解。
我有一个 docker compose 设置(也在生产中使用 kuberentes 集群,因此任何参考都可以)。在该设置中,我将 Traefik 作为我的反向代理。我将 Keycloak 作为我的身份提供者。我想设置中间件,以便入口路由可以受到 Keycloak 的保护。我决定选择 oauth2-proxy 作为该中间件。我尝试设置 oauth2-proxy。以下是一些示例代码:
name: example
services:
traefik:
image: traefik:v2.10
command:
- "--api.insecure=true"
- "--providers.docker=true"
- "--entryPoints.web.address=:80"
- "--entryPoints.websecure.address=:443"
- "--providers.docker.exposedByDefault=false"
ports:
- "80:80"
- "443:443"
- "8082:8080" # Traefik dashboard
volumes:
- /var/run/docker.sock:/var/run/docker.sock
depends_on:
- keycloak
- oauth2-proxy
keycloak:
container_name: keycloak
image: quay.io/keycloak/keycloak:26.0.2
environment:
KC_HTTP_RELATIVE_PATH: "/auth"
KC_BOOTSTRAP_ADMIN_USERNAME: "admin"
KC_BOOTSTRAP_ADMIN_PASSWORD: "admin"
command: "start-dev"
labels:
- "traefik.enable=true"
# keycloak will be available at localhost/auth
- "traefik.http.routers.keycloak.rule=PathPrefix(`/auth`)"
- "traefik.http.services.keycloak.loadbalancer.server.port=8080"
oauth2-proxy:
image: quay.io/oauth2-proxy/oauth2-proxy:v7.7.0
environment:
- OAUTH2_PROXY_PROVIDER=keycloak-oidc
- OAUTH2_PROXY_CLIENT_ID=${CLIENT}
- OAUTH2_PROXY_CLIENT_SECRET=${CLIENT_SECRET}
- OAUTH2_PROXY_EMAIL_DOMAINS=*
- OAUTH2_PROXY_UPSTREAMS=static://202
- OAUTH2_PROXY_HTTP_ADDRESS=0.0.0.0:4180
- OAUTH2_PROXY_REDIRECT_URL=http://localhost/oauth2/callback
- OAUTH2_PROXY_OIDC_ISSUER_URL=http://keycloak:8080/auth/realms/${REALM}
- OAUTH2_PROXY_WHITELIST_DOMAIN=localhost
- OAUTH2_PROXY_REVERSE_PROXY=true
- OAUTH2_PROXY_OIDC_EXTRA_AUDIENCES=account,${CLIENT}
- OAUTH2_PROXY_COOKIE_SECRET="12345678123456"
- OAUTH2_PROXY_COOKIE_EXPIRE=5m
- OAUTH2_PROXY_CODE_CHALLENGE_METHOD=S256
- OAUTH2_PROXY_SKIP_PROVIDER_BUTTON=true
depends_on:
- keycloak
labels:
- "traefik.enable=true"
- "traefik.http.middlewares.oauth2-proxy.forwardauth.address=http://oauth2-proxy:4180"
- "traefik.http.middlewares.oauth2-proxy.forwardauth.authResponseHeaders=Authorization"
- "traefik.http.routers.oauth2-proxy.rule=PathPrefix(`/oauth2`)"
- "traefik.http.services.oauth2-proxy.loadbalancer.server.port=4180"
myapp:
...
labels:
- "traefik.enable=true"
- "traefik.http.routers.myapp.rule=PathPrefix(`/`)"
- "traefik.http.routers.myapp.entrypoints=web,websecure"
- "traefik.http.services.myapp.loadbalancer.server.port=8080"
- "traefik.http.routers.myapp.middlewares=oauth2-proxy@docker"
我遇到的第一个问题是发行者 URL,我在尝试其他中间件时也遇到了这个问题
- OAUTH2_PROXY_OIDC_ISSUER_URL=http://keycloak:8080/auth/realms/${REALM}
如果我将其与 一起使用keycloak:8080
,oauth2-proxy
则连接没有问题。但是,当我的用户访问 时myapp
,localhost/
他们被重定向到使用 URL 的登录名keycloak:8080
,当然他们无权访问该 URL。
好的,那么如果我将发行者 URL 改为localhost/auth/...
,那么 oauth2-proxy 将无法初始化,因为它现在无权访问该 URL。
我的第一个问题是,当服务器/后端通过与用户不同的 URL 访问身份提供者时,我该如何解决这个问题?如果我使用第三方 IDP,这不会有问题,但当然事实并非如此。我觉得我在这里有一些关键的误解。无论我使用哪种中间件,是否有不同的设置方法?
继续,我最终可以通过强制 oauth2-proxy 使用正确的 URL 来使其工作,这是 oauth2-proxy 的工作设置。我还添加了一些标头传递,这与我的下一个问题有关。
environment:
- OAUTH2_PROXY_PROVIDER=keycloak-oidc
- OAUTH2_PROXY_SKIP_OIDC_DISCOVERY=true
# Client Side URL
- OAUTH2_PROXY_LOGIN_URL=http://localhost/auth/realms/${REALM}/protocol/openid-connect/auth
# Server Side URLs
- OAUTH2_PROXY_REDEEM_URL=http://keycloak:8080/auth/realms/${REALM}/protocol/openid-connect/token
- OAUTH2_PROXY_PROFILE_URL=http://keycloak:8080/auth/realms/${REALM}/protocol/openid-connect/userinfo
- OAUTH2_PROXY_VALIDATE_URL=http://keycloak:8080/auth/realms/${REALM}/protocol/openid-connect/userinfo
- OAUTH2_PROXY_OIDC_JWKS_URL=http://keycloak:8080/auth/realms/${REALM}/protocol/openid-connect/certs
- OAUTH2_PROXY_CLIENT_ID=${CLIENT}
- OAUTH2_PROXY_CLIENT_SECRET=${CLIENT_SECRET}
- OAUTH2_PROXY_EMAIL_DOMAINS=*
- OAUTH2_PROXY_UPSTREAMS=static://202
- OAUTH2_PROXY_HTTP_ADDRESS=0.0.0.0:4180
- OAUTH2_PROXY_REDIRECT_URL=http://localhost/oauth2/callback
- OAUTH2_PROXY_OIDC_ISSUER_URL=http://localhost/auth/realms/${REALM}
- OAUTH2_PROXY_WHITELIST_DOMAIN=localhost
- OAUTH2_PROXY_REVERSE_PROXY=true
- OAUTH2_PROXY_OIDC_EXTRA_AUDIENCES=account,${CLIENT}
- OAUTH2_PROXY_COOKIE_SECRET="12345678123456"
- OAUTH2_PROXY_COOKIE_EXPIRE=5m
- OAUTH2_PROXY_CODE_CHALLENGE_METHOD=S256
- OAUTH2_PROXY_SKIP_PROVIDER_BUTTON=true
# Headers
- OAUTH2_PROXY_SET_AUTHORIZATION_HEADER=true
- OAUTH2_PROXY_SET_XAUTHREQUEST=true
- OAUTH2_PROXY_PASS_AUTHORIZATION_HEADER=true
- OAUTH2_PROXY_PASS_USER_HEADERS=true
很好,现在它处于工作状态,尽管有很多硬编码 URL,并且不再使用端点/.well-known
。我不喜欢它。如果我想添加其他中间件(比如说,只允许某些组/角色访问),我必须进行另一个巨大的设置才能使其工作,只需有 1-2 行不同/添加即可。不是很 DRY- 我倾向于我在这里做错了什么。
假设我想访问 auth 标头(这可能是 oauth2-proxy 特定的问题),即使我可以找到与设置为 true 的标头相关的任何内容,但当我转到浏览器开发控制台 > 网络并检查标头时,我找不到任何此类标头。
下一个问题是,我如何访问(甚至使用)这些标头?它们在我没有注意到的地方吗?它们是否编码在 cookie 中?假设myapp
是一个简单的前端 Web 应用程序,但我希望它显示已登录用户的电子邮件和/或用户名。我应该如何使用它们?深入一点,这些标头有多可信?例如,如果我想在 中使用 Authorization 标头进行逻辑处理myapp2
,在验证 JWT 后我可以信任这些值吗?
让我们逐一解答您的问题:
大量硬编码 URL
事情复杂之处在于您在单个主机名(localhost)上运行并使用路径前缀来配置所有路由。
如果您在不同的域上运行 keycloak,那么
keycloak.franco.test
您可以将发行者 URL 设置为该域并完成。如果您确实希望所有内容都在单个域上运行,那么我们需要找到一些可以分配给 issuer_url 的 URL,用户和 oauth 代理都可以访问该 URL。
我们可以使用 DNS 来实现这一点。让我们使用 来模拟这一点
/etc/hosts
。我们将在那里添加一个条目:我们可以自由使用,
.test
因为它是为此目的保留的。现在,您将能够
franco.test
像以前一样在浏览器中访问您的应用程序localhost
。但oauth-proxy
无法访问它。因此,我们进行一些 DNS 操作,将其添加franco.test
到特定 docker 网络上的 keycloak 服务器的别名:请注意,您必须将所有容器添加到此网络。您还可以创建多个网络,在这种情况下,您必须
traefik
使用标签来指示在哪个网络上找到容器traefik.docker.network=mynetwork
。现在您的浏览器和 oauth-proxy 将能够使用相同的 url 访问 keycloak,并且您可以从 docker compose 中省略所有这些 url。
访问 auth 标头
auth 标头仅存在于traefik 和您的应用程序之间的请求中。
流程如下:浏览器 -> Traefik -> OAuth2 代理 -> 应用程序
实际情况是,traefik 收到请求后,您配置的转发身份验证会检查是否存在 oauth 会话,如果存在,则添加身份验证标头。然后您的应用会收到身份验证标头,并可以据此执行操作。
请求到达您的应用后,响应将从您的应用发回,并且不会通过 oauth 代理。该响应不包含 auth 标头,您永远不会在浏览器开发控制台中看到它们。这是一件好事。
因此,如果您想查看身份验证标头,可以从您的应用程序中记录它们。或者,如果可能的话,配置 traefik/oauth2-proxy 来记录请求。
显示用户电子邮件
您可以添加一条
/api/me
路由。在该路由中,您可以获取身份验证标头中的任何内容并返回所需的值。就像电子邮件一样。如果您正在开发传统的服务器渲染应用程序,您也可以通过 cookie 发送它,或者直接将它们包含在您的页面中。关键是您必须在应用程序中执行某些操作才能使它们在浏览器中可用。
OAuth2 代理的职责是将身份验证标头传送到您的应用。如何使用它们由您决定。
标头的可信度
它们和您的网络安全一样值得信赖。在您的应用中,您信任oauth 代理向您发送正确的标头。但实际上发送标头的不一定是 oauth 代理。它可能是有权访问您网络的恶意用户。
举例来说,您可以获取应用容器的 IP,并从本地计算机发送所需的任何标头。您的应用将顺利接受它。
所以这归结为网络安全。
您应该限制可以访问应用程序 IP 的服务/容器数量。理想情况下,只有 oauth2 代理才能向其发送请求。
并且您应该在应用中配置受信任的代理 IP 地址。并且仅接受来自该 IP 地址的请求。