OAuth(开放授权)是一个开放标准。
允许第三方网站在用户授权的前提下访问在用户在服务商那里存储的各种信息。
OAuth允许用户提供一个令牌给第三方网站，一个令牌对应一个特定的第三方网站，同时该令牌只能在特定的时间内访问特定的资源。
服务商：用户使用服务的提供方，一般用来存消息、储照片、视频、联系人、文件等(比如QQ、微信等)。
用 户：服务商的用户
第三方：通常是网站，该网站想要访问用户存储在服务商那里的信息。
在OAuth2.0的处理流程，主要分为以下四个步骤：
1）得到授权码code
2）获取access token
3）通过access token，获取OpenID
4）通过access token及OpenID调用API，获取用户授权信息
OAuth里存在三个主要角色：用户、服务提供方和服务消费方。不少文档会把服务消费方说成是客户端，对于SP来说，这个说法没什么问题，但我感觉这个说放容易引起混淆，所以我这里还是用服务消费方来描述。按流行的口号，服务提供方一般对外宣称自己是某某某开放平台，而服务消费方则是各种第三方应用。用户在平台上有一些已有资源，如好友关系，照片等。
几乎所有的OAuth平台都有类似的背景：他们原先积累了一大堆的真实用户，在互联网开放的趋势下，主动或被动的需要支持第三方应用的接入。第三方应用为了使其功能更加丰富完整，希望从平台能获取甚至操作当前用户的资源。用户很可能不希望第三方得知他原有的帐号和密码，原因很明显，安全考虑嘛。服务提供方也不希望第三方直接使用用户的帐号和密码登录平台操作用户数据，为啥？不便于数据统计和维护嘛，希望对 哪个第三方操作哪个用户数据 和 哪个用户操作自己的数据 两种处理流程有所区别。第三方很无辜，经常大喊“我觉不会使用任何途径存储用户的帐号！”。即使真有人相信这些誓言，但也很难确保第三方使用帐号敏感数据时，不被第四方所捕获，所以，认真你就输了
例如可以使用HTTPS连接，让“第四方”去证明。OAuth2使用的就是HTTPS连接，但也仅仅是服务端认证，客户端并不做保证。估计一个方面的原因是，应用的数量很多，一般都是中小规模开发商开发的，客户端也要认证的话，证书申请门槛较高，一个账号密码可以解决的问题有必要去申请证书吗？另一方面是，很多应用是没有服务端的，使用双向HTTPS认证无疑将这些应用拒之门外。
但OAuth里没有这种方式的体现，但OAuth2里有类似的方式，那就是提供用户的帐号密码换取AccessToken，名字应该叫“资源所有者密码凭据”。如果第三方应用只是开发者自娱自乐的小应用，这种方式是最简单的。
第一步，应用向服务提供方申请请求令牌(Request Token)，服务提供方验证通过后将令牌返回。这个步骤由于涉及到应用帐号密码，在应用的服务端发起，所以这个步骤对用户透明。
第二步，应用使用请求令牌让浏览器重定向到服务提供方进行登录验证和授权。服务提供方校验请求令牌，将第三方的资料显示给用户，提示用户选择同意或拒绝此次授权。如果用户同意授权，发放已授权令牌并将用户引导到当前应用的注册地址。这个步骤从重定向开始到引导回注册地址之前，应用方并不参与用户身份校验和授权过程，确保第三方不可获得用户的真实帐号密码。
第三步，用已授权令牌向服务提供方换取ATOK。第三方应用需在服务端发起请求，用帐号密码和上一步的令牌换取ATOK，这个步骤对用户而言也是透明的。如果前两步分别是让服务提供方认证应用和用户，那这步就是用户和服务提供方再次认证第三方应用。因为用户浏览器将第二步的结果重定向到第三步，除非用户DNS被劫持，否则就能确保重定向到的是合法的地址。曾经我很困惑在用户授权之后为何不直接返回ATOK而需要再次换取，估计是出于对ATOK的安全考虑，用户浏览器一端存在太多的可能性让ATOK泄漏，最安全的办法还是让第三方服务端来获取和保管ATOK。
第四步，用ATOK作为令牌访问受保护资源。很多时候，权限是有多种类别的。ATOK包含了某个用户对某个应用的授权凭据，准确的说，ATOK对应用户授权时所赋予的一系列权限的集合。所以在这一步，除了校验ATOK的合法性之外，服务提供方还需对该ATOK是否拥有足够的权限执行被保护操作进行判断。