SSO和Oauth2的区别

一、简介和区别

SSO, single sign on,单点登录。sso多用于多个应用之间的切换，例如百度论坛、百度知道、百度云、百度文库等，在其中一个系统中登录， 切换到另一个系统的时候，不必再次输入用户名密码。

oauth2.0，开放授权，不兼容oauth1.0.允许第三方应用代表用户获得访问权限。可以作为web应用、桌面应用和手机等设备提供专门的认证流程。例如，用qq账号登录豆瓣、美团、大众点评；用支付宝账号登录淘宝、天猫等。

区别：sso和oauth2.0在应用场景上的区别在于，SSO是为了解决一个用户在鉴权服务器登陆过一次以后，可以在任何应用（通常是一个厂家的各个系统）中畅通无阻。OAuth2.0解决的是通过令牌（token）而不是密码获取某个系统的操作权限（不同厂家之间的账号共享）。

二、SSO

具体流程如下：

用户访问app1系统，app1系统没有登录

1. 用户访问app系统，app系统是需要登录的，但用户现在没有登录。
2. 跳转到CAS server，即SSO登录系统，以后图中的CAS Server我们统一叫做SSO系统。SSO系统也没有登录，弹出用户登录页。
3. 用户填写用户名、密码，SSO系统进行认证后，将登录状态写入SSO的session，浏览器（Browser）中写入SSO域下的Cookie。
4. SSO系统登录完成后会生成一个ST（Service Ticket），然后跳转到app系统，同时将ST作为参数传递给app系统。
5. app系统拿到ST后，从后台向SSO发送请求，验证ST是否有效。
6. 验证通过后，app系统将登录状态写入session并设置app域下的Cookie。
7. 至此，跨域单点登录就完成了。以后我们再访问app系统时，app就是登录的。接下来，我们再看看访问app2系统时的流程。

用户访问app2系统，app2系统没有登录，跳转到SSO。

1. 由于SSO已经登录了，不需要重新登录认证。
2. SSO生成ST，浏览器跳转到app2系统，并将ST作为参数传递给app2。
3. app2拿到ST，后台访问SSO，验证ST是否有效。
4. 验证成功后，app2将登录状态写入session，并在app2域下写入Cookie。
5. 这样，app2系统不需要走登录流程，就已经是登录了。SSO，app和app2在不同的域，它们之间的session不共享也是没问题的。

302 表示临时性重定向。访问一个Url时，被重定向到另一个url上，常用于页面跳转。

总结

• 不同域名是无法共享浏览器端本地信息，包括cookies，这即是跨域问题。
• SSO系统UserCenter、业务系统A和业务系统B都会在客户端写入标志登录状态的cookies，其中有且仅有SSO系统保存有用户密码等私密信息，业务系统A和B仅只可访问到用户标识信息，这样也很好地保证了用户信息的安全性。
• 说一下SSO单点登录的技术实现机制：
  1、需要一个统一处理用户登录的单点系统UserCenter。该系统集中处理用户信息，包括用户信息加密存储，用户注册，用户登录验证，SSO接入等；
  2、需要接入SSO单点登录的系统(例如业务系统A)不处理任何用户登录信息，服务器端在用户第一次提交请求时，跳转到SSO系统验证是否登陆，如未登录，则一般重定向SSO系统的登录页面，用户登录成功以后，再回跳到业务系统A原来的页面，业务系统A与此同时写入由SSO带回来的用户信息到session中，后续的交互过程中，业务系统A就一直保持有用户的登录信息了。
  3、假如用户由上述登录过的业务系统A跳转访问到同样接入到SSO单点登录系统UserCenter的业务系统B，此时业务系统B没有用户登录信息，同样会跳转SSO单点登录系统验证是否登录，SSO检测到用户之前已登录，又重定向到业务系统B，此时系统B从SSO带回登录信息并写入到session，这样用户就做到了，一处登录多处保持登录信息，即完成了SSO单点登录。

访问系统B的话，如何检测到用户已经登录了呢，访问系统B的话，是否需要带上参数信息

其实这里会有个重定向的过程，访问到B系统后，检测无登陆信息会重定向到sso的一个页面，这个页面会和sso服务器请求，并将单点系统sso域下的cookie中到token携带到sso服务器中，sso校验token有效则认为是已登陆状态，再重定向另一个携带code的页面去访问sso换取token并种到B系统域名下，这样B系统就为登陆态了（这只是其中的一种实现方式）

三、Oauth2

OAuth 2.0授权框架支持第三方支持访问有限的HTTP服务，通过在资源所有者和HTTP服务之间进行一个批准交互来代表资源者去访问这些资源，或者通过允许第三方应用程序以自己的名义获取访问权限。

为了方便理解，可以想象OAuth2.0就是在用户资源和第三方应用之间的一个中间层，它把资源和第三方应用隔开，使得第三方应用无法直接访问资源，从而起到保护资源的作用。

为了访问这种受保护的资源，第三方应用（客户端）在访问的时候需要提供凭证。即，需要告诉OAuth2.0你是谁你要做什么。

你可以将用户名和密码告诉第三方应用，让第三方应用直接以你的名义去访问，也可以授权第三方应用去访问。

OAuth2.0有多种模式，这里讲的是OAuth2.0授权码模式，OAuth2.0的流程跟SSO差不多，在OAuth2中，有授权服务器、资源服务器、客户端这样几个角色，当我们用它来实现SSO的时候是不需要资源服务器这个角色的，有授权服务器和客户端就够了。授权服务器当然是用来做认证的，客户端就是各个应用系统，我们只需要登录成功后拿到用户信息以及用户所拥有的权限即可

1. 用户在某网站上点击使用微信授权，这里的某网站就类似业务系统，微信授权服务器就类似单点登录系统
2. 之后微信授权服务器返回一个确认授权页面，类似登录界面，这个页面当然是微信的而不是业务系统的
3. 用户确认授权，类似填写了账号和密码，提交后微信鉴权并返回一个ticket，并重定向业务系统。
4. 业务系统带上ticket访问微信服务器，微信服务器返回正式的token，业务系统就可以使用token获取用户信息了