有许多实用并且具有哲学性的方法来讨论这两个术语的区别。但是这里确实有一些困惑，我想要从如今普遍用于构建应用的基于 token 的协议的“通常猜测”的角度去看待它。特别是我想要解析清楚 OAuth2 和 OpenID Connect 各自的适用场景。
首先看一下“正式”定义：
认证 是个人或者计算机程序为了获取信息而证实他们身份的过程。
授权 是许可个人或者实体权限从而在一个安全的环境使用资源的行为。通常与认证紧密相关。
认证
我的经验法则是，当应用请求 identity token 供它自己使用以提供个性化或者应用访问控制的特性时，那就是认证。或者从技术上来讲，请求到的 token 的受众是请求者本身，而且请求的应用能够解析和验证 token 以当中包含的信息。
用于认证的典型协议有：Kerberos, WS-Federation, SAML2p, OpenID (Connect) 。得到的 token 常称为 identity token 。
授权
相反，当应用请求 token 供第三方而非自己使用的时候——比如，后台，属于授权存储区。这个 token 对于请求者是不透明的并且只在受众（也就是后台）的上下文中才有意义。后台可以解析并验证 token ，可以根据里面的内容实现访问控制的管理。
用于授权的典型协议有：Kerberos, WS-Trust, OAuth2 。得到的 token 常称为 access token 。
但是——怎么使用 OAuth2 进行认证？
一些提供商建议使用 OAuth2 来完成登录——但这适合吗？当你进一步了解 OAuth2 的时候会发现它本身并不能提供认证服务，你可以看到这些提供商会使用一些自定义的扩展来完成这个工作。引用一下 Google 的文档（链接）:
“这里所述的 Google 端点与 OpenID Connect 规范保持一致，目前，它还处于草案阶段。作为参考，OpenID Connect 规范与 OAuth 2.0 协议很相似。在规范完善的过程中，Google 端点将会不断进行更新。”
分享一些能够告诉你 OAuth2 认证骗局的文章，推荐阅读 Tim Bray 的 这篇 文章，OpenID Connect 规范 ，以及 这篇 和 这篇 解释了为什么 OAuth2 本身是不够的。