您的API似乎在扮演基于浏览器的应用程序的前端后端的角色。这种类型的解决方案并不特定于Keycloak或Kubernetes。考虑在https://www.product.com的URL处登录Web应用程序。

代码流消息

代码流以这样的请求开始，后端产生两个随机值，分别为state和code_verifier。它将两者存储在一个临时加密的仅限HTTP的cookie中，然后形成一个授权请求URL。然后前端使用此URL将浏览器重定向到授权服务器：

GET https://login.example.com/oauth/v2/authorize?
   client_id=my-web-client&
   redirect_uri=https://www.product.com/callback&
   response_type=code&
   scope=openid profile&
   code_challenge=WhmRaP18B9z2zk...&
   code_challenge_method=S256&
   state=CfDJ8Nxa-YhPzjpBilDQz2C...

字符串
用户在授权服务器上登录，可以通过多种方式完成。然后，向前端返回响应，后端处理URL。

GET https://www.product.com/callback?
  code=I9xL9DY9jAYHPuHSiW2OpWUaNRW4otei&
  state=CfDJ8Nxa-YhPzjpBilDQz2C...

型
此时，BFF读取临时cookie并返回先前生成的两个随机值。它验证响应状态，然后发送授权代码授予请求，以将代码交换为令牌：

POST https://login.example.com/oauth/v2/token

client_id=my-web-client&
client_secret=***************&
code=I9xL9DY9jAYHPuHSiW2OpWUaNRW4otei&
grant_type=authorization_code&
redirect_uri=http://www.product.com/callback&
code_verifier=HlfffYlGy7SIX3pYHOMJfhnO5AhUW1eOIKfjR42ue28

型

饼干处理

通过使用cookie，BFF可以处理多个并发调用者。它也是无状态的，易于管理。没有不方便的托管限制，例如需要粘性会话，如果服务器出现故障，可能会导致可用性问题。
唯一的要求是使用相同的cookie加密密钥部署BFF的所有示例，以便示例api1可以解密示例api2发出的cookie。这可能是一个如下生成的值，并与加密算法（如AES256-GCM）一起使用：

openssl rand 32 | xxd -p -c 64

型

组件角色

我建议在OAuth架构中以不同的方式描述这些组件：

• API通常是资源服务器，其唯一的安全责任是验证访问令牌和实现基于声明的授权。
• BFF充当OAuth客户端，为基于浏览器的应用程序提供服务，并将令牌排除在浏览器之外。通常的结果是基于浏览器的应用程序将每个API请求与仅HTTP的cookie凭据一起发送。BFF不是资源服务器，但可以实现为实用程序API。它们需要与基于浏览器的应用程序具有相同的父域关系，以便将cookie视为第一方，而不是因为浏览器cookie限制而被删除。例如，BFF可能在https://api.product.com这样的域中运行。

如果我对这个问题有任何误解，请回复...