OIDC（OpenID Connect）是否完全基于REST？授权码流程下移动应用如何获码？

你提的这两个问题确实戳中了OIDC实践里容易混淆的细节，我来帮你梳理清楚：

一、移动应用如何在授权码流中获取授权码？ #

首先得澄清那个评论里的“无需浏览器”——这句话其实有点断章取义，针对用户登录的授权码流场景，本质上是需要用户完成身份验证交互的，而这种交互几乎都离不开浏览器（或浏览器组件），移动应用的常见实现方式有这些：

• 系统浏览器组件（推荐方案）：比如iOS的SFSafariViewController、Android的Custom Tabs。这种方式会调用系统自带的浏览器窗口，用户在OP提供的HTML表单里输入账号密码完成验证后，OP会将授权码重定向回你的应用。好处是可以共享系统的登录会话（如果用户之前已经在浏览器里登录过该OP），不用重复输入密码，同时也避免了应用直接接触用户密码，安全性更高。
• 静默授权复用会话：如果用户之前已经通过浏览器完成过身份验证，OP的会话cookie会保留在系统浏览器中。这时候应用发起授权请求时，OP会直接识别到已登录的会话，无需用户再次输入账号密码，自动返回授权码。这种场景下看起来“没有浏览器交互”，但其实底层还是依赖了之前的浏览器登录会话。
• 原生应用专属的PKCE增强授权码流：移动应用因为无法安全存储客户端密钥，所以通常会搭配PKCE（Proof Key for Code Exchange）来使用授权码流。流程里依然需要通过系统浏览器组件跳转至OP完成身份验证，只是在请求时会额外生成一个随机码（code verifier）来防止授权码被窃取，这个过程还是离不开浏览器的交互环节。

如果有人说“无需浏览器”，大概率是混淆了OIDC的其他授权类型（比如客户端凭证流）——那种是用于服务间的身份验证，不需要用户参与，自然也不需要浏览器，但这和你问的用户登录场景完全是两回事。

二、OIDC是否完全基于REST架构？ #

答案是不完全是，但核心的后端交互是REST风格的：

• OIDC构建在OAuth 2.0之上，它的核心端点（令牌端点、用户信息端点、注销端点等）都是符合REST设计原则的：使用标准HTTP方法（POST/GET），返回JSON格式的响应，遵循无状态的设计。
• 但授权端点的交互是个例外：这个环节需要用户在OP的页面上完成身份验证（输入账号密码、MFA验证等），涉及HTML页面展示、用户表单提交、重定向跳转，这些都不属于纯REST API的范畴，而是浏览器端的web交互。

所以准确来说，OIDC的“后端数据交互”部分是基于REST的，但用户身份验证的前端环节依赖浏览器（或浏览器组件）来完成，那个评论里的表述忽略了用户登录场景的前端交互，才会造成困惑。

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