SSO和OAuth2.0的简介

单点登录
单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

企业应用集成

通常情况下运维内控审计系统、4A系统都包含此项功能，目的是简化账号登录过程并保护账号和密码安全，对账号进行统一管理。

企业应用集成（EAI, Enterprise Application Integration）。企业应用集成可以在不同层面上进行：例如在数据存储层面上的“数据大集中”，在传输层面上的“通用数据交换平台”，在应用层面上的“业务流程整合”，和用户界面上的“通用企业门户”等等。事实上，还有一个层面上的集成变得越来越重要，那就是“身份认证”的整合，也就是“单点登录”。

在信息安全管理中，访问控制(Access Controls)环绕四个过程：Identification；Authentication；Authorization；Accountability。单点登录（Single Sign On）属于Authentication认证系统，除单点登录外还包括：Lightweight Directory Access Protocol 和 Authorization ticket。（Michael E. Whitman (2011) Management Of Information Security Kennesaw University)

技术实现机制

当用户第一次访问应用系统的时候，因为还没有登录，会被引导到认证系统中进行登录；根据用户提供的登录信息，认证系统进行身份校验，如果通过校验，应该返回给用户一个认证的凭据－－ticket；用户再访问别的应用的时候，就会将这个ticket带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行校验，检查ticket的合法性。如果通过校验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。

要实现SSO，需要以下主要的功能：
      所有应用系统共享一个身份认证系统。
　    统一的认证系统是SSO的前提之一。认证系统的主要功能是将用户的登录信息和用户信息库相比较，对用户进行登录认证；认证成功后，认证系统应该生成统一的认证标志  （ticket），返还给用户。
      另外，认证系统还应该对ticket进行效验，判断其有效性。

      所有应用系统能够识别和提取ticket信息

　   要实现SSO的功能，让用户只登录一次，就必须让应用系统能够识别已经登录过的用户。应用系统应该能对ticket进行识别和提取，通过与认证系统的通讯，能自动判断当前  用  户是否登录过，从而完成单点登录的功能。

OAuth2.0

OAuth2.0是OAuth协议的下一版本，但不向后兼容OAuth 1.0即完全废止了OAuth1.0。 OAuth 2.0关注客户端开发者的简易性。要么通过组织在资源拥有者和HTTP服务商之间的被批准的交互动作代表用户，要么允许第三方应用代表用户获得访问的权限。同时为Web应用，桌面应用和手机，和起居室设备提供专门的认证流程。2012年10月，OAuth 2.0协议正式发布为RFC 6749^[1]

中文名

开放授权

外文名

OAuth2.0

定    义

协议的下一版本

简易性

OAuth1.0。 OAuth 2.0

编号

RFC6749

应用领域

计算机网路、认证

娱    乐

视频

前言

OAuth 1.0已经在IETF尘埃落定，编号是RFC5849

这也标志着OAuth已经正式成为互联网标准协议。

OAuth 2.0早已经开始讨论和建立的草案。OAuth2.0很可能是下一代的“用户验证和授权”标准。现在百度开放平台，腾讯开放平台等大部分的开放平台都是使用的OAuth 2.0协议作为支撑。

OAuth（开放授权）是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。

OAuth

允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的网站（例如，视频编辑网站)在特定的时段（例如，接下来的2小时内）内访问特定的资源（例如仅仅是某一相册中的视频）。这样，OAuth允许用户授权第三方网站访问他们存储在另外的服务提供者上的信息，而不需要分享他们的访问许可或他们数据的所有内容。

OAuth是OpenID的一个补充，但是完全不同的服务。

OAuth 2.0

是OAuth协议的下一版本，但不向后兼容OAuth 1.0。 OAuth 2.0关注客户端开发者的简易性，同时为Web应用，桌面应用和手机，和起居室设备提供专门的认证流程。2012年10月，OAuth 2.0协议正式发布为RFC 6749^[1]

Facebook的新的Graph API只支持OAuth 2.0，Google在2011年3月亦宣布Google API对OAuth 2.0的支持。

认证授权过程

在认证和授权的过程中涉及的三方包括：

1、服务提供方，用户使用服务提供方来存储受保护的资源，如照片，视频，联系人列表。

2、用户，存放在服务提供方的受保护的资源的拥有者。

3、客户端，要访问服务提供方资源的第三方应用，通常是网站，如提供照片打印服务的网站。在认证过程之前，客户端要向服务提供者申请客户端标识。

使用OAuth进行认证和授权的过程如下所示:

用户想操作存放在服务提供方的资源。

用户登录客户端向服务提供方请求一个临时令牌。

服务提供方验证客户端的身份后，授予一个临时令牌。

客户端获得临时令牌后，将用户引导至服务提供方的授权页面请求用户授权。在这个过程中将临时令牌和客户端的回调连接发送给服务提供方。

用户在服务提供方的网页上输入用户名和密码，然后授权该客户端访问所请求的资源。

授权成功后，服务提供方引导用户返回客户端的网页。

客户端根据临时令牌从服务提供方那里获取访问令牌。

服务提供方根据临时令牌和用户的授权情况授予客户端访问令牌。

客户端使用获取的访问令牌访问存放在服务提供方上的受保护的资源。

简单历史回顾

OAuth 1.0在2007年的12月底发布并迅速成为工业标准。

2008年6月，发布了OAuth 1.0 Revision A，这是个稍作修改的修订版本，主要修正一个安全方面的漏洞。

2010年四月，OAuth 1.0的终于在IETF发布了，协议编号RFC 5849。

OAuth 2.0的草案是在2011年5月初在IETF发布的。

OAuth is a security protocol that enables users to grant third-party access to their web resources without sharing their passwords.

OAuth是个安全相关的协议，作用在于，使用户授权第三方的应用程序访问用户的web资源，并且不需要向第三方应用程序透露自己的密码。

OAuth 2.0是个全新的协议，并且不对之前的版本做向后兼容，然而，OAuth 2.0保留了与之前版本OAuth相同的整体架构。

这个草案是围绕着 OAuth2.0的需求和目标，历经了长达一年的讨论，讨论的参与者来自业界的各个知名公司，包括Yahoo!, Facebook, Salesforce, Microsoft, Twitter, Deutsche Telekom, Intuit, Mozilla, and Google。

OAuth 2.0的新特性：

6种全新流程

User-Agent Flow – 客户端运行于用户代理内（典型如web浏览器）。

Web Server Flow – 客户端是web服务器程序的一部分，通过http request接入，这是OAuth 1.0提供的流程的简化版本。

Device Flow – 适用于客户端在受限设备上执行操作，但是终端用户单独接入另一台电脑或者设备的浏览器

Username and Password Flow – 这个流程的应用场景是，用户信任客户端处理身份凭据，但是仍然不希望客户端储存他们的用户名和密码，这个流程仅在用户高度信任客户端时才适用。

Client Credentials Flow – 客户端适用它的身份凭据去获取access token，这个流程支持2-legged OAuth的场景。

Assertion Flow – 客户端用assertion去换取access token，比如SAML assertion。

可以通过使用以上的多种流程实现Native应用程序对OAuth的支持（程序运行于桌面操作系统或移动设备）

application support (applications running on a desktop or mobile device) can be implemented using many of the flows above.

持信人token

OAuth 2.0 提供一种无需加密的认证方式，此方式是基于现存的cookie验证架构，token本身将自己作为secret，通过HTTPS发送，从而替换了通过 HMAC和token secret加密并发送的方式，这将允许使用cURL发起APIcall和其他简单的脚本工具而不需遵循原先的request方式并进行签名。

签名简化：

对于签名的支持，签名机制大大简化，不需要特殊的解析处理，编码，和对参数进行排序。使用一个secret替代原先的两个secret。

短期token和长效的身份凭据

原先的OAuth，会发行一个 有效期非常长的token(典型的是一年有效期或者无有效期限制)，在OAuth 2.0中，server将发行一个短有效期的access token和长生命期的refresh token。这将允许客户端无需用户再次操作而获取一个新的access token，并且也限制了access token的有效期。

角色分开

OAuth 2.0将分为两个角色：

Authorization server负责获取用户的授权并且发布token。

Resource负责处理API calls。