SSO是啥

Posted 2023-03-21

什么是SSO

SSO指的是单点登录(Single Sign On)，当用户在身份认证服务器上登录了一次以后，即可获得访问单点登录系统中其他联邦系统和应用软件的权限。

同时这种实现是不需要管理员对用户的登录状态或其他信息进行修改的，这意味着在多个应用系统中，用户只需一次登录就可以访问所有相互信任的应用系统。

单点登录是多个相关但独立的软件系统的访问控制的属性。使用此属性，用户使用单个ID和密码登录，以便在不使用不同用户名或密码的情况下访问已连接的系统，或者在某些配置中在每个系统上无缝登录。

单点登录通常使用轻量级目录访问协议（LDAP）和（目录）服务器上存储的LDAP数据库来完成，可以使用cookie在IP网络上实现简单版本的单点登录。

图为一种SSO系统：

扩展资料

实现机制

当用户第一次访问应用系统1的时候，因为还没有登录，会被引导到认证系统中进行登录；根据用户提供的登录信息，认证系统进行身份校验，如果通过校验，应该返回给用户一个认证的凭据－－ticket；

用户再访问别的应用的时候就会将这个ticket带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行校验，检查ticket的合法性。如果通过校验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。

SSO的优势

1、降低访问第三方站点的风险（未在外部存储或管理的用户密码）。

2、从不同的用户名和密码组合减少密码疲劳。

3、减少重新输入相同身份的密码所花费的时间。

4、由于关于密码的IT服务台呼叫数量减少，降低了IT成本。

5、SSO共享所有其他应用程序和系统用于身份验证的集中身份验证服务器，并将其与技术相结合，以确保用户不必多次主动输入其凭据。

参考资料来源：百度百科-SSO （Single Sign On）

参考资料来源：百度百科-单一登入

参考技术A SSO英文全称Single Sign On，单点登录。SSO是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制。它是目前比较流行的企业业务整合的解决方案之一。 SSO技术实现机制 当用户第一次访问应用系统1的时候，因为还没有登录，会被引导到认证系统中进行登录；根据用户提供的登录信息，认证系统进行身份效验，如果通过效验，应该返回给用户一个认证的凭据－－ticket；用户再访问别的应用的时候就会将这个ticket带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行效验，检查ticket的合法性。如果通过效验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。 要实现SSO，需要以下主要的功能： 1、所有应用系统共享一个身份认证系统。 统一的认证系统是SSO的前提之一。认证系统的主要功能是将用户的登录信息和用户信息库相比较，对用户进行登录认证；认证成功后，认证系统应该生成统一的认证标志（ticket），返还给用户。另外，认证系统还应该对ticket进行效验，判断其有效性。 2、所有应用系统能够识别和提取ticket信息 要实现SSO的功能，让用户只登录一次，就必须让应用系统能够识别已经登录过的用户。应用系统应该能对ticket进行识别和提取，通过与认证系统的通讯，能自动判断当前用户是否登录过，从而完成单点登录的功能。 另外： 1、单一的用户信息数据库并不是必须的，有许多系统不能将所有的用户信息都集中存储，应该允许用户信息放置在不同的存储中，如下图所示。事实上，只要统一认证系统，统一ticket的产生和效验，无论用户信息存储在什么地方，都能实现单点登录。 2、统一的认证系统并不是说只有单个的认证服务器 认证服务器之间要通过标准的通讯协议，互相交换认证信息，就能完成更高级别的单点登录。如：当用户在访问应用系统1时，由第一个认证服务器进行认证后，得到由此服务器产生的ticket。当他访问应用系统2的时候，认证服务器2能够识别此ticket是由第一个服务器产生的，通过认证服务器之间标准的通讯协议（例如SAML）来交换认证信息，仍然能够完成SSO的功能。 WEB-SSO的实现 用户在访问页面1的时候进行了登录，但是客户端的每个请求都是单独的连接，当客户再次访问页面2的时候，如何才能告诉Web服务器，客户刚才已经登录过了呢？浏览器和服务器之间有约定：通过使用cookie技术来维护应用的状态。Cookie是可以被Web服务器设置的字符串，并且可以保存在浏览器中。当浏览器访问了页面1时，web服务器设置了一个cookie，并将这个cookie和页面1一起返回给浏览器，浏览器接到cookie之后，就会保存起来，在它访问页面2的时候会把这个cookie也带上，Web服务器接到请求时也能读出cookie的值，根据cookie值的内容就可以判断和恢复一些用户的信息状态。Web-SSO完全可以利用Cookie结束来完成用户登录信息的保存，将浏览器中的Cookie和上文中的Ticket结合起来，完成SSO的功能。 为了完成一个简单的SSO的功能，需要两个部分的合作： 1、统一的身份认证服务。 2、修改Web应用，使得每个应用都通过这个统一的认证服务来进行身份效验。

满意请采纳本回答被提问者采纳 参考技术B

SSO就是单点登录，即给予员工一套账号密码，就可以访问所有权限内的业务系统，也就是说员工日常仅需要记住一套账号密码就可以访问日常办公所需要登录的诸如：OA、邮箱、CRM、ERP、行业特定的saas软件等。

目前而言，玉符科技单点登录是一种简单而且强大的、以标准协议为基础的解决方案，可以为企业提供更安全的保障，是企业所采用的IAM解决方案中一个基础的组成部分。

除了SSO单点登录，诸如多因素认证、安全审计、账号的生命周期管理也是企业应用的一个范畴，单纯的SSO已经无法满足企业的需求。

SSO实现原理

参考技术C

SSO是Single Sign On的缩写，中文术语为“单点登录”。用户只需要登录一次就可以访问多个应用，此为单点登录。

常见的单点登录解决方案都是针对Web网站的“被动式”集成方案。它有两大局限：

不能处理桌面应用的单点登录。在企业中有大量桌面应用，例如SAP，金蝶用友客户端，等等。大部分国内厂商提供的SSO方案无法胜任。

企业往往存在很多难以改动代码的既有系统。大部分国内厂商的SSO方案，都要求被集成系统调用其接口，以实现SSO。这对于有大量系统的企业来说或者不现实，或者沟通、协调成本高昂。

我本人提供的面向企业的“百宝门SSO”方案，在博客园上提供了多个包括qq、vpn、csdn、cnblogs等客户端或网站零改造实现SSO的示例，大家可以搜索了解。

参考技术D 船舶保安员

微服务架构中的社交 SSO 是啥样的？

【中文标题】微服务架构中的社交 SSO 是啥样的？

【英文标题】：What does Social SSO look like in a Microservices Architecture?微服务架构中的社交 SSO 是什么样的？

【发布时间】：2017-10-11 21:44:15

【问题描述】：

晚上好

我正在尝试掌握社交 SSO（Facebook/Google 等）如何在微服务架构中工作的概念。

场景

假设我有 2 个后端微服务（订单、用户）和一个前端（WebApp）

用户：保存用户个人资料详细信息、电子邮件、姓名、地址。 订单：保存链接到用户的订单列表 WebApp：提供与两个后端服务交互的前端。

添加Social SSO，是为了简化用户注册网站http://www.myproduct.com的流程

当一个人使用社交单点登录时，我想在用户服务中创建一个用户帐户。

问题

假设用户在 WebApp 上点击“Login with Facebook”并以“John”身份登录

在我的用户中为 John 创建帐户的最佳方法是什么 服务？

以 John 身份登录后，WebApp 如何传播身份 约翰到订单服务？

Order 服务如何验证 John 是否已登录？

相互依赖的服务订单和用户如何相互信任？

疑虑

使用授权服务器（Facebook、Google），下游服务将变得非常“健谈”

谢谢

丹尼尔

【参考方案1】：

在我的用户服务中为 John 创建帐户的最佳方法是什么？

这里没什么可做的，只需从 FB 获取用户详细信息并调用您的用户创建端点。对于 RESTful API，您可能需要向 https://your_api_gateway/users 发送 POST

以 John 身份登录后，WebApp 如何将 John 的身份传播到 Order 服务？

一种选择是使用令牌微服务。在登录时，您将创建一个长期存在的身份验证令牌和一个短期访问令牌。身份验证令牌是您从不共享的信任来源。您将访问令牌返回给客户端 webapp。从客户端到您的任何微服务的所有调用都会将该访问令牌作为请求的一部分发送。另一种选择是简单地使用 FB/Google 生成的访问令牌。

Order 服务如何验证 John 是否已登录？

您的订单服务将在请求中收到访问令牌。只要访问令牌有效，您就可以假定 John 已登录。

相互依赖的服务订单和用户如何相互信任？

访问令牌由令牌微服务签名 - 这应该是一个受信任的服务 - 它可以包含可以由您的任何微服务进一步验证的其他信息

使用授权服务器（Facebook、Google），下游服务将变得非常“健谈”

生成访问令牌后，您无需再次调用 FB 或 Google，直到您的 web 应用决定用户需要再次进行身份验证。

【讨论】：

谢谢@clonq 假设令牌服务是一个微服务，该服务会将用户重定向回 WebApp... 将长期存在的令牌作为查询参数传递？这安全吗？其次，假设这个长期存在的令牌实际上是 JWT。 WebApp 会在哪里存储这个？谢谢丹尼尔

不需要重定向。 Web 应用程序将对令牌微服务进行 AJAX 调用，该服务将以 JSON 有效负载的形式返回令牌。在有效负载中发送令牌是安全的，因为无论如何通信都应该通过 HTTPS。我的建议是使用短期令牌来增加安全性，而不是长期令牌，但在任何情况下，Web 客户端都可以根据您的“客户端会话”到期策略将其存储在内存中或将其保存在 localStorage 中。

嗨@clonq WebApp和Token服务是不同的微服务。因此，我想让令牌服务处理来自 SSO 提供者的响应，例如 FB 或 google。鉴于此，我如何让 WebApp 知道它以安全方式生成的长寿命令牌？谢谢

如果您想将调用移动到令牌服务中的 SSO 提供者，您只需将长期存在的令牌返回给客户端。所以流程是这样的：WebApp 调用 TokenService。 TokenService 调用返回令牌的 SSOProvider。 TokenService 然后将令牌返回给 WebApp。有意义吗？