OAuth 就是一种授权机制。数据的所有者告诉系统，同意授权第三方应用进入系统，获取这些数据。系统从而产生一个短期的进入令牌（token），用来代替密码，供第三方应用使用。
那么为什么需要授权机制，这里引出另外一个词：单点登录（ Single Sign On）SSO。
单点登录解决的是：在多个应用系统中，只需要登录一次，就可以访问其他相互信任的应用系统。这也是为了解决多点登录系统中，每个站点都实现了本站专用的帐号数据库和登录模块。各站点的登录状态相互不认可，各站点需要逐一手工登录的麻烦。
因而，通过一种授权机制来实现单点登录。
2.OAuth2.0
OAuth 2.0 的标准是 RFC 6749 文件。该文件先解释了 OAuth 是什么。OAuth 的核心就是向第三方应用颁发令牌。
首先需要解释几个名词：
客户端（client）、资源所有者（Resource Owner）、资源服务器（Resource server）
OAuth 2.0 规定了四种获得令牌的流程。你可以选择最适合自己的那一种，向第三方应用颁发令牌。下面就是这四种授权方式。
授权码（authorization-code）
隐藏式（implicit）
密码式（password）
客户端凭证（client credentials）
为什么有这么多方式，每一种方式，都有不同的应用环境。
首先说一下，目前最流行的方式：
授权码（authorization code）方式，指的是第三方应用先申请一个授权码，然后再用该码获取令牌。
适用于：那些有后端的 Web 应用。授权码通过前端传送，令牌则是储存在后端，而且所有与资源服务器的通信都在后端完成。这样的前后端分离，可以避免令牌泄漏。例如：通过微信，QQ，github登录等。下图是说明请求的简单过程。
response_type=code
实例:
https://b.com/oauth/authorize? response_type=code& client_id=CLIENT_ID& redirect_uri=CALLBACK_URL& scope=read
隐藏式：有些 Web 应用是纯前端应用，没有后端。这时就不能用上面的方式了，必须将令牌储存在前端。RFC 6749 就规定了第二种方式，允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤，所以称为（授权码）"隐藏式"（implicit）。
response_type=token
实例:
https://b.com/oauth/authorize?response_type=token&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read
密码式: 如果你高度信任某个应用，RFC 6749 也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌，这种方式称为"密码式"（password）。
grant_type=password
https://b.com/token?grant_type=password&username=USERNAME&password=PASSWORD&client_id=CLIENT_ID
凭证式: 适用于没有前端的命令行应用，即在命令行下请求令牌。
grant_type=client_credentials
https://b.com/token?grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET