为何无法将OAuth用作身份认证？为何需采用OpenID Connect？

嘿，让我帮你理清楚OAuth和OpenID Connect的核心差异，解答你的这两个问题：

OAuth从设计之初就是个授权框架，它的核心目标是让第三方应用获得访问用户在另一服务上资源的权限（比如允许你的App读取用户的Dropbox文件），而不是用来证明“这个用户到底是谁”。

举个实际的例子：OAuth流程里，授权服务器只会告诉你的App「这个用户同意你访问他的XX资源」，但不会标准化地返回用户的身份信息——虽然有些服务商可能会在返回的access_token附带一些用户数据，但这不是OAuth的强制约定，不同平台的返回格式、字段完全没统一标准。如果你的App依赖这种非标准的信息做身份认证，不仅兼容性极差，还会有身份伪造的安全风险，因为OAuth本身没有定义严谨的身份验证规则。

首先得纠正一个认知：在OAuth流程中，用户输入账号密码的地方是第三方授权服务器（比如Google、Facebook的官方登录页），你的应用根本碰不到这些凭证。所以你没办法“把这个当成你的App的身份认证方式”——你只是通过OAuth拿到了访问用户资源的权限，但用户的身份并没有被标准化、安全地传递给你。

至于为什么大家都推OpenID Connect（OIDC）？因为它是构建在OAuth 2.0之上的身份认证框架，专门解决了OAuth在身份验证上的短板：

• OIDC会返回一个标准化的ID Token（JSON Web Token格式），里面明确包含了用户的核心身份信息（比如用户ID、邮箱、姓名等），而且这个Token是经过授权服务器签名的，你的App可以验证它的真实性，彻底杜绝身份篡改的风险。
• 它定义了统一的流程和字段规范，不管你对接的是Google、Azure还是其他OIDC服务商，拿到的身份信息格式都是一致的，你的App不需要做额外的适配工作。
• 从用户体验来说，OIDC天然支持单点登录（SSO）：用户只要在授权服务器登录过，后续访问你的App时不需要重复输入凭证，这比你说的“每次未连接都要输入密码”体验好太多。
• 安全层面，OIDC内置了多种防攻击机制，比如nonce参数防止重放攻击，还有针对身份认证的安全扩展，而OAuth本身完全没有这些身份相关的安全规范，用它做身份认证相当于“用错了工具”，会埋下不少安全隐患。

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