一、介绍
OAuth（Open Authorization，开放授权）允许用户授权第三方网站访问他们存储在另外的服务提供者上的信息，第三方无需知道用户的账号及密码，就可获取到用户的授权信息，并且这是安全
OAuth提供了一种客户端代表资源拥有者（例如其他客户端或终端用户）访问服务器资源的方法。它通过用户代理（一般指游览器）的重定向也提供了一种最终用户在第三方访问最终用户的服务器资源而不需要共享他们的身份凭证（例如：用户名和密码）的过程。
用白话文来说就是：“A提供了基于OAUTH协议的服务，现在B想要访问用户R放在A上面的资源，B需要向A申请，而A需要询问用户R是否同意B访问这个资源，这个时候A是需要R通过用户名和密码登录的（这个用户名只是用户R在A上注册的，跟B没有一点关系）,如果用户R同意了，那么以后B就可以访问这个资源了。整个过程R都没有向B透露一点相关的用户信息。”
举一个比较形象的例子：
小王（资源拥有者）去了一次马来西亚旅游，他拍了很多照片，他把照片（受保护的资源）首先上传到了开心网（服务器端）下，小王现在在新浪的微博上想要发表一条微博，不过选择的图片是他在开心网上的旅游照片
1、小王（用户）访问新浪微博（客户端）的网站，想操作用户存放在开心网 （服务提供方）的照片（受保护的资源）。
2、 新浪微博（客户端）向开心网（服务提供方）请求一个临时令牌。
3、 开心网（服务提供方）验证新浪微博（客户端）的身份后，授予一个临时 令牌。
4、新浪微博（客户端）获得临时令牌后，将用户引导至开心网（服务提供方） 的授权页面请求用户授权。在这个过程中将临时令牌和客户端的回调连接发送给开心网（服务提供方）。
5、 小王（用户）在开心网（服务提供方）的网页上输入用户名和密码，然后 授权该客户端访问所请求的资源
6、授权成功后，开心网（服务提供方）引导小王（用户）返回新浪微博（客 户端）的网页
7、新浪微博（客户端）根据临时令牌从开心网（服务提供方）那里获取访问 令牌。 8、开心网（服务提供方）根据临时令牌和小王（用户）的授权情况授予新浪 微博（客户端）访问令牌。 9
9、新浪微博（客户端）使用获取的访问令牌访问存放在开心网（服务提供方） 上的照片（受保护的资源）
以上即是整个OAuth的身份论证和授权的全部过程
二、原理
三、认证流程
详细设计方案
二、OpenID
OpenID 系统的第一部分是身份验证，即如何通过 URI 来认证用户身份。目前的网站都是依靠用户名和密码来登录认证，这就意味着大家在每个网站都需要注册用户名和密码，即便你使用的是同样的密码。如果使用 OpenID （参见规范），你的网站地址（URI）就是你的用户名，而你的密码安全的存储在一个 OpenID 服务网站上（你可以自己建立一个 OpenID 服务网站，也可以选择一个可信任的 OpenID 服务网站来完成注册）。
问题描述:我在sina上面有一个用户名，sohu有一个,baidu有一个,google有一个。这些用户名和密码可以一样也可以不一样，要是不一样的话我还得记那么多的信息，头痛!而即使我让这些用户名和密码都一样，那么要是有一天我把密码给忘掉了，我需要通过找回功能把这些信息找回来。那么只有老老实实的一个一个网站来，头更痛。
而登录一个支持 OpenID 的网站非常简单（即便你是第一次访问这个网站也是一样）。只需要去OpenID提供商输入你注册好的 OpenID 用户名，然后你登录的网站会跳转到你的 OpenID 服务网站，在你的 OpenID 服务网站输入密码（或者其它需要填写的信息）验证通过后，你会回到登录的网站并且已经成功登录。 OpenID 系统可以应用于所有需要身份验证的地方，既可以应用于单点登录系统，也可以用于共享敏感数据时的身份认证。”
三、SSO
SSO英文全称Single Sign On，单点登录。SSO是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制。它是目前比较流行的企业业务整合的解决方案之一。
比如说某网站D，它下面有许多独立的模块，有的是视屏频道，有的是体育频道等。每个频道都有用户验证和登录这块。现在问题来了，我在频道A登录了，可以享有会员待遇，那么当我跳到频道B的时候，由于是单独的模块，我还是需要登录。这个太恶心了。那我不干了，以后不上这个网站了。
那怎么才能让用户在频道A登录以后，以后去任何一个频道都不需要再次登录呢？而sso就是为了解决这个问题而产生的。
OAuth和OpenID区别：
OAuth关注的是授权，即：“用户能做什么”；而OpenID关注的是证明，即：“用户是谁”。下面就分别来说两者的功能。
OpenID
1. 用户希望访问其在example.com的账户
2. example.com (在OpenID的黑话里面被称为“Relying Party”) 提示用户输入他/她/它的OpenID
3. 用户给出了他的OpenID，比如说”http://user.myopenid.com”
4. example.com 跳转到了用户的OpenID提供商“mypopenid.com”
5. 用户在”myopenid.com”(OpenID provider)提示的界面上输入用户名密码登录
6. “myopenid.com” (OpenID provider) 问用户是否要登录到example.com
7. 用户同意后，”myopenid.com” (OpenID provider) 跳转回example.com
8. example.com 允许用户访问其帐号
OAuth
1. 用户在使用example.com时希望从mycontacts.com导入他的联系人
2. example.com (在OAuth的黑话里面叫“Consumer”)把用户送往mycontacts.com (黑话是“Service Provider”)
3. 用户在mycontacts.com 登录(可能也可能不用了他的OpenID)
4. mycontacts.com问用户是不是希望授权example.com访问他在mycontact.com的联系人
5. 用户确定
6. mycontacts.com 把用户送回example.com
7. example.com 从mycontacts.com拿到联系人
8. example.com 告诉用户导入成功
OpenID是用来验证的，就是说可以用一个url来唯一表明身份（不用挨个记每个网站的用户密码）。OAuth是用来授权的（俺可以授权一个网站访问俺在另外一个网站的数据，而俺不用把俺的密码给第一个网站。