能否在命令行CLI工具中运行OIDC流程获取访问令牌？

OIDC/OAuth2 体系本身就为命令行这类公共客户端定义了标准化的授权流程，完全可以获取到和单页应用权限、受众完全一致的access token与ID token，调用现有后端API不需要做额外适配，以下是按推荐度排序的可行方案：

方案1：本地环回回调的授权码+PKCE流程（优先选，和SPA逻辑一致性最高） #

这是RFC8252（原生应用OAuth2.0规范）明确指定的CLI场景标准实现，和你当前SPA用的授权码+PKCE流程逻辑几乎完全对齐，拿到的token属性和浏览器环境完全无差异：

• 具体流程：
  1. CLI启动时临时在本地127.0.0.1监听一个随机可用端口，启动一个极简HTTP服务作为OIDC授权回调接收端
  2. 自动唤起系统默认浏览器，跳转到和SPA完全相同的OneLogin授权端点，携带和SPA一致的client_id、scope、audience（如果你的后端做了受众校验）参数，同时带上PKCE流程生成的code_challenge，回调地址填刚才的本地环回地址（比如http://127.0.0.1:54321/callback）
  3. 用户在浏览器中完成登录、授权操作——如果用户本来就在浏览器里登录过OneLogin，这一步甚至不需要重复输入账号密码，会直接完成跳转
  4. OneLogin校验通过后，会把授权码code拼到回调地址上做重定向，本地临时HTTP服务收到请求后，立刻给浏览器返回一个“登录成功，可关闭当前页面”的静态提示，同时提取出URL里的授权码
  5. CLI拿着拿到的授权码、之前本地暂存的code_verifier调用OneLogin的token端点，就能换到access token和ID token，后续调用后端API的逻辑和SPA完全一致
• 配置注意点：
  • 提前在OneLogin的应用回调地址配置里加http://127.0.0.1:*，支持通配端口，不用每次换端口都改配置
  • 整个流程不需要给CLI配置client_secret，和SPA同属公共客户端，安全模型和现有方案完全对齐，没有额外的密钥泄露风险
  • 主流编程语言的成熟OIDC SDK基本都内置了这个流程的封装，不用自己手写本地HTTP服务、参数拼接逻辑，几行代码就能跑通

方案2：设备授权流（适合无法唤起本地浏览器的场景） #

这是RFC8628定义的、专门为输入受限/无本地GUI的设备、远程CLI场景设计的标准流程，同样可以拿到合规的token：

• 具体流程：
  1. CLI调用OneLogin的设备授权端点，提交和SPA一致的client_id、scope、audience参数
  2. 拿到返回的验证地址、用户码、设备码后，直接在命令行输出提示，让用户在任意有浏览器的设备上打开对应地址，输入屏幕上显示的用户码完成登录授权
  3. CLI按固定间隔轮询OneLogin的token端点，带上设备码，等用户完成授权后就能拿到access token和ID token
• 注意点：
  • 这个流程同样不需要client_secret，属于公共客户端安全模型
  • 缺点是需要用户手动打开链接、输入验证码，交互体验比方案1差，只适合SSH远程连服务器、没法直接拉起本地浏览器的场景
  • 需要提前在OneLogin后台开启对应应用的设备授权流开关

方案3：客户端凭证流（仅适合无用户身份的服务类调用场景） #

如果你的CLI不需要代表具体登录用户操作，只是作为工具本身调用后端接口，可以选这个流程：

• 具体流程：给CLI单独分配一个机密客户端的client_id和client_secret，CLI直接调用token端点，通过客户端凭证换取应用身份的access token
• 注意点：这个流程拿到的token不携带用户身份信息，没有ID token，access token里的主体是应用本身而非具体用户，和SPA代表用户操作的token语义完全不同，只有不需要用户身份的时候才用

不建议使用的实现方式 #

• 不要在CLI里嵌入浏览器控件跑SPA登录流程：嵌入式webview容易被恶意程序hook截获账号密码、token，不符合OIDC安全规范，主流身份提供商也在逐步拦截这类嵌入式授权请求
• 不要用密码授权流（Resource Owner Password Grant）让用户直接在命令行输入账号密码换token：这个流程已经被OAuth2.1正式废弃，需要用户把账号密码直接暴露给CLI，安全风险极高，OneLogin等主流IdP默认就会禁用这个流程

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