欧易okx交易所下载

欧易交易所又称欧易OKX，是世界领先的数字资产交易所，主要面向全球用户提供比特币、莱特币、以太币等数字资产的现货和衍生品交易服务，通过使用区块链技术为全球交易者提供高级金融服务。

APP下载   官网注册

最近有一位之前找过的用户问了我们小编的一个问题，我相信这也是很多币圈朋友经常会疑惑的问题：如何保证单点登录的token不被盗用相关问题，token单点登录原理相关问题，带着这一个问题，让专业的小编告诉您原因。

单点登陆顾名思义就是所有被管设备的访问，都是通过堡垒机完成。意思就是网络内的所有主机，必须要要经过堡垒机才可以访问。那么这种安全保障的依赖就是网络限制和会话限制。而安全保障的机制就在于这种依赖上的会话监控手段，因此通过堡垒机访问设备的所有操作理论上都是有记录的。该记录可用做审计、核查违规操作人、IP、操作内容、终端信息等。

寒假学习的小课题，把之前的笔记整理整理记录一下（长文警告）因为当时看到的东西涉及很多，所以有一些地方没有深入去探讨。

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

简而言之就是用户在多个相互信任的应用系统中，只需要登录一次，就可以访问其他相互信任的应用系统。这里的关键是一次登录，以及一次退出，都对所有的系统生效。

在普通的登录中，比如典型的B/S情景，浏览器访问服务器，发送登录请求，在发送完用户名和密码之后，服务器会生成该用户的session来标准该用户的状态，比如已登录还是已注销，并给一个cookie给浏览器，因此，用户继续访问就会带上这个cookies，服务端会根据这个Cookie找到对应的session，通过session来判断这个用户的登录状态。比如php中使用phpsessid。当然也可以自定义session的生命周期，session的生命周期过长的话一旦session被盗用就会出现用户被窃取的情况。同时，生命周期过长的session配置会占用较多的服务器资源。

单点登录主要针对同平台下多应用，多系统的情景下多次登录的一种解决方案。单点登录相当于将多个应用的认证体系联通。

假设现在一个平台上有3个都带有登录功能的应用，由上面的普通登录的情况可以想到，这3台服务器都会自己的记录session。那么要想达到单点登录，一个最简单的方法就出现了：共享session。

共享session的方式来实现单点登录是最方便也是最直接的。在三个子系统中，使用同一个额外的记录session的服务器，比如我们可以使用一个redis服务器来存储三个系统的session。

用户登录了应用1，获取了应用1返回的cookies，再次访问应用1的其他功能的候携带了cookie就是已登录的状态了，但是这样又有新的问题，虽然实现了共享session，但是用户登录了应用1，获取了应用1返回的cookie，但是因为cookie是无法跨域的，因此用户无法使用应用1的cookie去访问应用2。这里我们就需要将系统的全局cookie domain的属性设置为顶级域名，比如应用1的域名是1.test.com，应用2的域名是2.test.com。在普通登录的情况下，应用1的cookie domain的属性是1.test.com，指这个cookie只能在该子域名上被使用。我们将系统的全局cookie domain设置为顶级域名，即.test.com，这样就可以实现用户登录了应用1，之后可以以已登录状态访问应用2和3。

上面的共享session的情况是三个应用都有登录功能，还有一种类似的情况是应用1和应用2都有登录模块和其他模块，还有一个单独的SSO系统，是仅有登录模块的：

共享session的方法虽然简单，但是存在局限性，因为使用了cookie顶域的特性，所以不能做到跨域。一个公司或者一个平台很可能不是所有的域名都在在一个一级域名之下的，所以同域名下的单点登录并不是完整的单点登录。

先说说openid，openid是一种认证标准，规定如何认证的标准！即其关注的是登录时身份的认证。官方给出的一个场景，其中一方是一个openid身份服务器，用来存放注册好的openid账号，另一方是受这个openid身份服务器信赖的服务或应用。openid协议就是提供openid身份服务器和被信赖的服务或应用之间的通信的。比如我们在很多网站上可以使用QQ登录，这里的腾讯的QQ就是openid的身份服务器，我们所要登录的网站就是受信赖的服务或应用。

在使用openid实现单点登录的方法有很多，可以使用上面共享session的方法，即把openid带在cookie里面，但是这样也会出现一样的cookie跨域的问题。

在实际场景中，我们在访问提供服务的应用时检测到未登录就会直接跳转到openid身份服务器，或者没有重定向而是在登录表单附近点击选择使用第三方openid登录，进行账号密码登录（这可以保证我们所登录的服务器无法获取我们的敏感身份认证信息），具体流程如下：

CAS全称为Central Authentication Service即中央认证服务，是一个企业多语言单点登录的解决方案，并努力去成为一个身份验证和授权需求的综合平台。CAS就是一个现成的单点登录的demo，企业只需要简单修改就可使用。

CAS支持各种协议，SAML，OAuth，OpenID，OIDC等等，支持LDAP，Radius，JWTX，509等等进行身份认证和授权，还有各种常用语言的客户端，Java，PHP，C# 等等。反正就是一个十分完整的，兼容性特别好的SSO框架。

简单了解CAS是如何实现单点登录的。在官网上可以看到其给出的一个 流程图 ，。这个图说的特别详细，一下就能看懂，直接原图上进行标注查看：

学习了上面几种单点登录的知识，结合实际场景可知，跨域单点登录才是真正的单点登录，因为实际情况下很多平台或者域名不可能都在一个一级域名下。在解决跨域单点登录的问题的时候，上面也给说了几种方式，但是究其根本，就是利用一个SSO认证中心来实现认证与授权的。当然，也会有其他的解决跨域单点登录的方案，但是大体流程都与cas类似。

比如在上图的11步骤，也可使用POST包，或者JSONP和iframe方法来跨域发送请求进行重定向。

在利用认证中心来实现单点登录是现在比较普遍的解决方案，那么有没有不需要使用认证中心来解决跨域单点登录的方案呢？

利用JSONP同步登录状态，大概流程流程如下：

在学习单点登录的过程中，在其中认证的过程中授权令牌的传递等相关信息没有特别详细的说明，而且在思考单点登录的时候也会有想过一个比较矛盾的问题：单点登录的目标是为了让用户可以在相互信任的系统中一次登录即可，但是如果真的是做到所有用户都可以访问所有系统，岂不是会带来越权的问题，是否需要对不同的用户以不同的授权，甚至限制访问的应用，但是这样是不是就不是原本狭义的单点认证？

在说单点登录的认证和授权之前，先谈一谈我一直想弄清楚的统一身份认证和单点登录的区别。说起单点登录可能很少听过，但是统一身份认证肯定不陌生，不管是企业还是高校都会有这种统一身份认证的系统。

统一身份认证最重要的一方面就是身份认证，另一方面就是和身份认证相关的授权控制，权限控制。而单点登录是多应用一次登录，也可以叫统一登录，可以理解为主要在认证方面。对于统一身份认证来说会有账号管理，如LDAP，认证管理OAuth，SMAL等，因此我觉得，统一身份认证一般是包括狭义的单点登录，狭义的单点登录，即只需要满足多应用一次登录即可。但是现在的单点登录，SSO系统并不仅仅是要求这些，他的范围正在慢慢扩大。

单点登录的认证和授权，前面说到的CAS实现单点登录里就会看到需要ticket来进行认证，授权。CAS支持多种认证方案，比如OAuth，OpenID，SAML等等，我们可以来比较比较用这些协议的区别，或者说是在哪些场景下使用哪些认证方案较为合适。本身单点登录是没有权限控制的功能的，但是因为这些认证协议的需求，自然支持了权限控制。

在使用SAML进行认证的过程中，可以看到下图，其是基本流程都差不多，这里需要注意的就是在用户在认证中心成功登陆之后，重定向的时候返回的是一个SAML token，一个XML节点，这里的token会包括用户的身份信息，用户名等。

在OAuth2.0的标准中流程是和上面的基本相同，但是OAuth2因为客户端并没有一点是浏览器，所以token中默认是没有签名的。这里可能没有体现出来，OAuth2的目标是授权，所以token更关注的是权限，token在向认证服务器验证的时候就会有不同的授权，但是既然是授权，就间接实现了认证。

在传统的认证中都是基于session机制的，具体的session模式上面也说了，根据其特性可知session的一些确定：

API接口的安全性主要是为了保证数据不会被篡改和重复调用，实现方案主要围绕Token、时间戳和Sign三个机制展开设计。

1. Token授权机制

用户使用用户名密码登录后服务器给客户端返回一个Token（必须要保证唯一，可以结合UUID和本地设备标示），并将Token-UserId以键值对的形式存放在缓存服务器中（我们是使用Redis），并要设置失效时间。服务端接收到请求后进行Token验证，如果Token不存在，说明请求无效。Token是客户端访问服务端的凭证。

2. 时间戳超时机制

用户每次请求都带上当前时间的时间戳timestamp，服务端接收到timestamp后跟当前时间进行比对，如果时间差大于一定时间（比如30秒），则认为该请求失效。时间戳超时机制是防御重复调用和爬取数据的有效手段。

当然这里需要注意的地方是保证客户端和服务端的“当前时间”是一致的，我们采取的对齐方式是客户端第一次连接服务端时请求一个接口获取服务端的当前时间A1，再和客户端的当前时间B1做一个差异化计算（A1-B1=AB），得出差异值AB，客户端再后面的请求中都是传B1+AB给到服务端。

3. API签名机制

将“请求的API参数”+“时间戳”+“盐”进行MD5算法加密，加密后的数据就是本次请求的签名signature，服务端接收到请求后以同样的算法得到签名，并跟当前的签名进行比对，如果不一样，说明参数被更改过，直接返回错误标识。签名机制保证了数据不会被篡改。

4. 注意事项

5. 安全保障总结

在以上机制下，

如果有人劫持了请求，并对请求中的参数进行了修改，签名就无法通过；

如果有人使用已经劫持的URL进行DOS攻击和爬取数据，那么他也只能最多使用30s；

如果签名算法都泄露了怎么办？可能性很小，因为这里的“盐”值只有我们自己知道。

本文你将看到：

**「前端存储」**这就涉及到一发、一存、一带，发好办，登陆接口直接返回给前端，存储就需要前端想办法了。

前端的存储方式有很多。

有，cookie。cookie 也是前端存储的一种，但相比于 localStorage 等其他方式，借助 HTTP 头、浏览器能力，cookie 可以做到前端无感知。一般过程是这样的：

「配置：Domain / Path」

cookie 是要限制::「空间范围」::的，通过 Domain（域）/ Path（路径）两级。

「配置：Expires / Max-Age」

cookie 还可以限制::「时间范围」::，通过 Expires、Max-Age 中的一种。

「配置：Secure / HttpOnly」

cookie 可以限制::「使用方式」::。

**「HTTP 头对 cookie 的读写」**回过头来，HTTP 是如何写入和传递 cookie 及其配置的呢？HTTP 返回的一个 Set-Cookie 头用于向浏览器写入「一条（且只能是一条）」cookie，格式为 cookie 键值 + 配置键值。例如：

那我想一次多 set 几个 cookie 怎么办？多给几个 Set-Cookie 头（一次 HTTP 请求中允许重复）

HTTP 请求的 Cookie 头用于浏览器把符合当前「空间、时间、使用方式」配置的所有 cookie 一并发给服务端。因为由浏览器做了筛选判断，就不需要归还配置内容了，只要发送键值就可以。

**「前端对 cookie 的读写」**前端可以自己创建 cookie，如果服务端创建的 cookie 没加HttpOnly，那恭喜你也可以修改他给的 cookie。调用[xss_clean]可以创建、修改 cookie，和 HTTP 一样，一次[xss_clean]能且只能操作一个 cookie。

调用[xss_clean]也可以读到 cookie，也和 HTTP 一样，能读到所有的非HttpOnly cookie。

现在回想下，你刷卡的时候发生了什么？

这种操作，在前后端鉴权系统中，叫 session。典型的 session 登陆/验证流程：

**「Session 的存储方式」**显然，服务端只是给 cookie 一个 sessionId，而 session 的具体内容（可能包含用户信息、session 状态等），要自己存一下。存储的方式有几种：

「Session 的过期和销毁」**很简单，只要把存储的 session 数据销毁就可以。****「Session 的分布式问题」**通常服务端是集群，而用户请求过来会走一次负载均衡，不一定打到哪台机器上。那一旦用户后续接口请求到的机器和他登录请求的机器不一致，或者登录请求的机器宕机了，session 不就失效了吗？这个问题现在有几种解决方式。

但通常还是采用第一种方式，因为第二种相当于阉割了负载均衡，且仍没有解决「用户请求的机器宕机」的问题。**「node.js 下的 session 处理」**前面的图很清楚了，服务端要实现对 cookie 和 session 的存取，实现起来要做的事还是很多的。在npm中，已经有封装好的中间件，比如 express-session – npm，用法就不贴了。这是它种的 cookie：

express-session – npm 主要实现了：

session 的维护给服务端造成很大困扰，我们必须找地方存放它，又要考虑分布式的问题，甚至要单独为了它启用一套 Redis 集群。有没有更好的办法？

回过头来想想，一个登录场景，也不必往 session 存太多东西，那为什么不直接打包到 cookie 中呢？这样服务端不用存了，每次只要核验 cookie 带的「证件」有效性就可以了，也可以携带一些轻量的信息。这种方式通常被叫做 token。

token 的流程是这样的：

**「客户端 token 的存储方式」 在前面 cookie 说过，cookie 并不是客户端存储凭证的唯一方式。token 因为它的「无状态性」，有效期、使用限制都包在 token 内容里，对 cookie 的管理能力依赖较小，客户端存起来就显得更自由。但 web 应用的主流方式仍是放在 cookie 里，毕竟少操心。 「token 的过期」**那我们如何控制 token 的有效期呢？很简单，把「过期时间」和数据一起塞进去，验证时判断就好。

编码的方式丰俭由人。**「base64」**比如 node 端的 cookie-session – npm 库

默认配置下，当我给他一个 userid，他会存成这样：

这里的 eyJ1c2VyaWQiOiJhIn0=，就是 {“userid”:”abb”} 的 base64 而已。 「防篡改」

是的。所以看情况，如果 token 涉及到敏感权限，就要想办法避免 token 被篡改。解决方案就是给 token 加签名，来识别 token 是否被篡改过。例如在 cookie-session – npm 库中，增加两项配置：

这样会多种一个 .sig cookie，里面的值就是 {“userid”:”abb”} 和 iAmSecret通过加密算法计算出来的，常见的比如HMACSHA256 类 (System.Security.Cryptography) | Microsoft Docs。

好了，现在 cdd 虽然能伪造出eyJ1c2VyaWQiOiJhIn0=，但伪造不出 sig 的内容，因为他不知道 secret。**「JWT」**但上面的做法额外增加了 cookie 数量，数据本身也没有规范的格式，所以 JSON Web Token Introduction – jwt.io 横空出世了。

它是一种成熟的 token 字符串生成方案，包含了我们前面提到的数据、签名。不如直接看一下一个 JWT token 长什么样：

这串东西是怎么生成的呢？看图：

类型、加密算法的选项，以及 JWT 标准数据字段，可以参考 RFC 7519 – JSON Web Token (JWT)node 上同样有相关的库实现：express-jwt – npm koa-jwt – npm

token，作为权限守护者，最重要的就是「安全」。业务接口用来鉴权的 token，我们称之为 access token。越是权限敏感的业务，我们越希望 access token 有效期足够短，以避免被盗用。但过短的有效期会造成 access token 经常过期，过期后怎么办呢？一种办法是，让用户重新登录获取新 token，显然不够友好，要知道有的 access token 过期时间可能只有几分钟。另外一种办法是，再来一个 token，一个专门生成 access token 的 token，我们称为 refresh token。

有了 refresh token 后，几种情况的请求流程变成这样：

如果 refresh token 也过期了，就只能重新登录了。

session 和 token 都是边界很模糊的概念，就像前面说的，refresh token 也可能以 session 的形式组织维护。狭义上，我们通常认为 session 是「种在 cookie 上、数据存在服务端」的认证方案，token 是「客户端存哪都行、数据存在 token 里」的认证方案。对 session 和 token 的对比本质上是「客户端存 cookie / 存别地儿」、「服务端存数据 / 不存数据」的对比。**「客户端存 cookie / 存别地儿」**存 cookie 固然方便不操心，但问题也很明显：

存别的地方，可以解决没有 cookie 的场景；通过参数等方式手动带，可以避免 CSRF 攻击。 「服务端存数据 / 不存数据」

前面我们已经知道了，在同域下的客户端/服务端认证系统中，通过客户端携带凭证，维持一段时间内的登录状态。但当我们业务线越来越多，就会有更多业务系统分散到不同域名下，就需要「一次登录，全线通用」的能力，叫做「单点登录」。

简单的，如果业务系统都在同一主域名下，比如wenku.baidu.com tieba.baidu.com，就好办了。可以直接把 cookie domain 设置为主域名 baidu.com，百度也就是这么干的。

比如滴滴这么潮的公司，同时拥有didichuxing.com xiaojukeji.com didiglobal.com等域名，种 cookie 是完全绕不开的。这要能实现「一次登录，全线通用」，才是真正的单点登录。这种场景下，我们需要独立的认证服务，通常被称为 SSO。 「一次「从 A 系统引发登录，到 B 系统不用登录」的完整流程」

**「完整版本：考虑浏览器的场景」**上面的过程看起来没问题，实际上很多 APP 等端上这样就够了。但在浏览器下不见得好用。看这里：

对浏览器来说，SSO 域下返回的数据要怎么存，才能在访问 A 的时候带上？浏览器对跨域有严格限制，cookie、localStorage 等方式都是有域限制的。这就需要也只能由 A 提供 A 域下存储凭证的能力。一般我们是这么做的：

图中我们通过颜色把浏览器当前所处的域名标记出来。注意图中灰底文字说明部分的变化。

谢谢大家哦

token是个凭条，不过它比门票温柔多了，门票丢了重新花钱买，token丢了重新操作下认证一个就可以了，因此token丢失的代价是可以忍受的——前提是你别丢太频繁，要是让用户隔三差五就认证一次那就损失用户体验了。x0dx0ax0dx0a客户端方面这个除非你有一个非常安全的办法，比如操作系统提供的隐私数据存储，那token肯定会存在泄露的问题。比如我拿到你的手机，把你的token拷出来，在过期之前就都可以以你的身份在别的地方登录。x0dx0a解决这个问题的一个简单办法x0dx0a1、在存储的时候把token进行对称加密存储，用时解开。x0dx0a2、将请求URL、时间戳、token三者进行合并加盐签名，服务端校验有效性。x0dx0a这两种办法的出发点都是：窃取你存储的数据较为容易，而反汇编你的程序hack你的加密解密和签名算法是比较难的。然而其实说难也不难，所以终究是防君子不防小人的做法。话说加密存储一个你要是被人扒开客户端看也不会被喷明文存储??x0dx0a方法1它拿到存储的密文解不开、方法2它不知道你的签名算法和盐，两者可以结合食用。x0dx0a但是如果token被人拷走，他自然也能植入到自己的手机里面，那到时候他的手机也可以以你的身份来用着，这你就瞎了。x0dx0a于是可以提供一个让用户可以主动expire一个过去的token类似的机制，在被盗的时候能远程止损。x0dx0a话说一个人连自己手机都保护不好还谈什么安全??x0dx0ax0dx0a在网络层面上token明文传输的话会非常的危险，所以建议一定要使用HTTPS，并且把token放在postbody里。

心血来潮，探讨一下cookie和session机制，以及单点登录的原理。不到之处欢迎指正。

要谈单点登录，还要从cookie机制说起。这块知识也是面试中的高频题，小马以前如有辅助也会喜欢聊。只是大部分同学不是概念模糊就是完全抛弃了这块知识点，经常被秒。

cookie机制是一种会话机制，源于HTTP协议是无状态的。当浏览器发起的http请求要和服务端保持会话状态的时候，需要借助中间介质，而cookie机制刚好合适。

我们来举个栗子，假设我现在访问王者农药官网。

1.打开浏览器输入xxx域名；

2.浏览器会在硬盘中查找关于xxx 的Cookie，一般登录态标识存储的是session_id，然后把Cookie 放到 HTTP Request 中，再把Request 发送给 Web 服务器；

3.服务端识别到cookie，会在服务端查询对应session_id的用户会话记录并校验，如果存在并且有效，则进行本次登录态数据操作（比如写基本的登录态session数据），处理用户为正常登录状态，此时浏览器看到的就是已登录的状态。如果没有相关信息，则用户处于未登录状态。

4.如果未登录，用户会在浏览器操作登录。登录成功后往浏览器写cookie（session_id），同时服务端会有相应的session_id会话记录（默认是文件存储）。当浏览器关闭或者用户操作注销（服务端删除登陆态session），则本次会话结束，本次会话信息（session_id）失效。当然，这也有例外，那就是如果设置了cookie的有效期，那么该会话消息将会保存到到期为止，客户端的cookie和服务端的session会话信息都会保持有效期 。想想我们平时登录时看到的“自动登录”勾选，下次访问就可以直接就是已登录状态，就是这个原理。

好了，以上就是cookie和session的会话机制了。

从上面可以看到cookie大致可分为两大类：会话Cookie和持久Cookie。

会话Cookie是一种临时的Cookie，它记录了用户访问站点，它记录了用户访问站点时的设置和偏好；关闭浏览器，会话Cookie 就被删除了。

持久 Cookie 存储在硬盘上，不管浏览器退出或计算机重启，持久Cookie 都继续存在。持久Cookie 有过期时间。

他们的共同点是，都是存储在客户端（浏览器）的，是存在硬盘上的，不同浏览器，不同操作系统存储 Cookie 的地方可能不一样。那么自然的session就是存储在服务端的（注意，敲黑板必考题）。session有哪几种存储方式呢？浏览器禁用cookie后session还能用吗？

session默认是存文件，当然也可以配置为DB存储或者cache存储，比如redis。浏览器禁用cookie后session还能用吗？能，将session_id放在url参数中，服务端也能识别session会话信息，但处理起来就不是那么优雅，说白了，cookie只是一种比较合适的客户端存储媒介。对于一些禁用了浏览器cookie的用户可以这样兼容，但少见，基本无视。

于是我们聊到正题，单点登录是什么？

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

先丢一个问题出来助助兴。假如我现在服务端是个集群，怎么处理登录态问题呢？比如我还是农药官网，我登录成功了网站xxx，但是第二次访问的时候又告诉我已经登录了，再刷一下，又显示已登录，这是什么鬼呢？原因是假如xxx域名下的服务端是分布式集群，并且同时又采用了默认的文件存储方式存储session会话信息。于是第一次处理请求的是机器A存储了文件会话信息，当第二次会话带着cookie去服务端，这时正好处理请求的是机器B，于是寻找不到会话信息文件，自然浏览器就认为未登录。

以上问题可以通过服务端共享登录态信息实现，修改session存储方式为DB或者redis等cache，来达到多机器共享，单域名下的分布式集群登录态共享即可解决。

如果是同一个域名下的几个server，把cookie的路径设置成顶级域名下（比如域名xxx下面有a.xxx，b.xxx子域名），这样所有子域都能读取cookie中的token(或者是session-id)即可。但这里有个问题，如果是跨域，那取不到cookie，要怎么办呢？

因为cookie没有跨域性质，如果不同域名xxx和ccc要共享登录态无法通过共享同一个cookie来解决。于是就有了令牌的机制，统一用一个令牌凭证来在各个系统之间保持登录态。

采用令牌验证机制

要实现SSO，需要以下主要的功能（本段描述参考自百科）：

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

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

小马认为有点类似微信接口调用的access_token机制。

如何保证单点登录的token不被盗用的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于token单点登录原理、如何保证单点登录的token不被盗用的信息别忘了在本站进行查找喔。