OAuth 是一套被大量应用在很多端的验证方式。
OAuth 的出现是为了解决授权的应用场景。
假设用户 A 为了使用应用 B 需要使用应用 C 的数据，这是应该怎么实现呢？最粗暴的想法，就是直接让用户 A 把应用 C 的账号和密码给应用 B，应用 B 就直接用这个账号密码访问应用 C 了。这个做法显然是不行的。因为此时应用 B 不应该知道应用 C 的所有数据，也不被信任去做所有的事情。这个时候，OAuth 流程就应运而生了。
什么是OAuth的做法呢？
从用户体验的角度，一个例子就是微信账号的登陆。在浏览第三方网站，比如优酷视频。登陆时，我们可以选择使用微信账号登陆。这时，优酷网站会出一个二维码，用户使用微信扫描二维码，接着用户需要在微信中点击授权登陆，优酷就可以用微信的用户信息了。这里就是一个典型的 OAuth 流程。优酷需要使用微信的用户信息，需要用户授权这个信息被优酷使用。
一点点历史
OAuth 这个协议最早开始于 2006 年，Twitter 某工程师需要实现第三方登录的协议，发现当时没有一种公开的公认的授权 API 访问的协议。于是，一个小组被建立起来，2007 年底提出了草稿，2010 年发布了公开协议。2012 年，OAuth 2.0 也被提出了。OAuth 2.0 的一个主要优化是协议完全基于 TLS，有更好的安全性。目前 OAuth 2.0 协议被主流的互联网公司大量使用。比如，Facebook’s Graph API 只支持 OAuth 2.0. Google，Microsoft，Amazon 等公司也支持 OAuth 2.0 授权。
常见具体流程
当用户想要在应用 A 中使用应用 B 的信息时。
应用 A 需要访问应用 B 的一个 URL。该 URL 需要包含，用户的信息和想要访问的内容。应用 B 会返回给应用 A 或者直接在应用 B 中弹出一个可交互的用户界面，让用户确认授权。收到用户的确认后，应用 A 会给应用 B 返回一个 access token。应用 B 可以使用这个 token 来访问应用 A 的服务器，获取得到授权的信息。注意，这个 access token 通常是有限制时间的，token 过期以后一种常用的方式是使用 refresh token 刷新 access token。
流程图如下：
更多阅读资料
要了解协议的所有内容可以参照发布的协议文档。
https://tools.ietf.org/html/rfc6749
Google 的官方 OAuth 2.0 使用文档。
https://developers.google.com/identity/protocols/OAuth2
微信的官方 OAuth 2.0 文档
http://qydev.weixin.qq.com/wiki/index.php?title=OAuth%E9%AA%8C%E8%AF%81%E6%8E%A5%E5%8F%A3
