多租户OIDC（Okta）：交换授权码获令牌时如何识别域名

针对你遇到的IdP发起式认证回调阶段无法获取Okta租户域名（iss）的问题，有几个更合理且安全的替代方案，比存Cookie更可靠：

1. 用OAuth2的state参数传递租户标识（推荐） #

OAuth2规范里的state参数就是用来在授权流程中传递上下文信息的，你可以把租户的iss（或租户ID）加密后放到state里：

• 当收到/auth/okta?iss=https://foo.okta.com请求时：
  1. 从iss查询到对应的租户信息（client_id等）
  2. 用Phoenix的签名工具生成安全的state：

     state = Phoenix.Token.sign(MyAppWeb.Endpoint, "okta_state", %{iss: "https://foo.okta.com"})
     

  3. 重定向到Okta授权URL时，带上这个state参数
• 回调阶段（比如/auth/okta/callback）：
  1. 拿到请求里的state参数，验证并解码：

     case Phoenix.Token.verify(MyAppWeb.Endpoint, "okta_state", state, max_age: 300) do
       {:ok, %{iss: iss}} -> # 用iss查询client_id和client_secret
       {:error, reason} -> # 处理无效state的情况
     end
     

  2. 用获取到的租户信息调用Okta的/token端点交换令牌

这种方式符合OAuth2规范，且因为state经过签名，不会被篡改，安全性很高。

2. 为每个租户配置专属回调URL #

如果你的SaaS允许，可以给每个租户分配唯一的回调路径，比如：

• 租户foo的回调URL设为http://example.com/auth/okta/callback/foo
• 在Okta后台配置客户应用时，让他们填写对应的专属回调URL

回调时，你可以从URL路径中提取租户标识（比如foo），再映射到对应的iss、client_id和client_secret。如果Okta支持通配符回调URL（比如http://example.com/auth/okta/callback/*），还能减少客户配置的复杂度。

3. 优化现有Cookie方案：用服务器端Session存储租户信息 #

你现在用Cookie的思路没问题，但可以改成服务器端Session存储，避免在客户端Cookie里暴露敏感的租户域名：

• 收到/auth/okta?iss=xxx请求时，把iss存入Phoenix的服务器端Session：

  conn |> put_session(:okta_iss, "https://foo.okta.com") |> redirect(to: okta_auth_url)
  

• 回调阶段直接从Session中取出iss：

  iss = get_session(conn, :okta_iss)
  

Phoenix默认的Session是存在服务器端的，客户端Cookie只存一个session ID，安全性比直接存明文域名高很多。

补充说明：Okta在回调时确实不会主动返回iss参数，因为授权码本身和特定的client_id绑定，但你的多租户场景需要关联到具体租户，所以必须在授权流程的初始化阶段主动传递租户标识，上面的方案都是符合OAuth2和Okta最佳实践的。

内容的提问来源于stack exchange，提问作者Pete Lacey