OKTA授权码PKCE流的Angular SPA Client ID与Issuer安全存储咨询

• 对接OKTA带PKCE的授权码模式时，Client ID（客户端ID）与Issuer（授权服务器地址）从协议设计层面就属于必须暴露到前端的公开配置，直接在前端暴露不存在安全威胁。
• 这类配置不需要做端侧的加密安全存储，所有试图对这两个值做“前端加密隐藏”的操作都是无意义的：前端要正常完成授权跳转、初始化OKTA SDK，必须在浏览器上下文里拿到这两个值的明文形式，哪怕你把值存在后端接口动态返回，最终还是会通过网络请求暴露在浏览器开发者工具中，没有实质的隐藏效果。
• 一定要把这类公开配置和保密凭证划清界限：Client ID不是保密密钥，它和后端服务专用的Client Secret、服务端API密钥属于完全不同安全等级的配置，后者才是需要严格保密、绝对不能出现在前端构建产物里的内容。

虽然两个值本身暴露没有直接风险，但需要在OKTA侧做好规则配置，避免Client ID被第三方恶意滥用：

• 严格限定应用允许的登录回调地址、登出回调地址白名单，未在白名单内的域名就算拿到你的Client ID，也走不通完整的授权流程，最多只能跳转到你的OKTA租户登录页，构不成实质危害。
• 强制开启应用的PKCE校验规则，禁止应用切换为无PKCE的授权码模式或隐式授权模式，从协议层面堵上授权码被拦截窃取的风险。
• 配置应用的可信域名范围，禁止第三方恶意站点伪造授权入口发起钓鱼跳转。

你目前采用的、在构建阶段根据环境动态生成environment.ts文件，注入Client ID和Issuer的方式，是Angular生态对接第三方身份服务的标准实现，完全符合PKCE公开客户端的接入要求，不需要因为值在前端产物中可见就调整实现逻辑。
需要守住的安全边界是：只要接入过程中没有把Client Secret这类高敏感凭证写入前端配置、没有在前端代码里硬编码服务端专属的API密钥，当前的实现就不存在高危安全问题。

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