登陆机制详解

**

登陆机制

**
登陆机制可粗略分为三个部分：登陆验证、登陆保持、登出
登陆验证：登陆验证是指客户端提供用户名和密码，想服务器提出登陆请求，服务器判断客户端是否可以登陆并向客户端确认
登陆保持：是指客户端登陆后，服务器能够分辨出已登陆的用户，并为其持续提供有登陆权限的服务器
登出：是指客户端主动退出登陆状态
容易想到的方案是，客户端登录成功后， 服务器为其分配sessionId, 客户端随后每次请求资源时都带上sessionId。

**

登陆验证

**

1、密码的传输

客户端第一次发出登录请求时， 用户密码以明文的方式传输， 一旦被截获， 后果严重。因此密码需要加密，例如可采用RSA非对称加密。具体流程如下：

• 客户端向服务器第一次发送登陆请求（不传输用户名和密码）
• 服务器利用RSA算法产生一对公钥和私钥，并将公钥传给客户端，私钥自己保留
• 客户端收到公钥后，加密用户密码，向服务器第二次发送登陆请求（传输用户名和加密密码）
• 服务器利用保留的私钥对加密密码进行解密，得到真正的密码

2、登陆状态token

再仔细核对上述流程，发现判断用户是否登陆完全依赖于sessionId，一旦被截获，黑客就能模拟用户登陆请求，于是我们需要引入token概念，用户登录成功后， 服务器不但为其分配了sessionId, 还分配了token， token是维持登录状态的关键秘密数据。在服务器向客户端发送的token数据，也需要加密。于是一次登录的细节再次扩展。

• 客户端向服务器第一次发起登录请求（不传输用户名和密码）。
• 服务器利用RSA算法产生一对公钥和私钥。并保留私钥， 将公钥发送给客户端。
• 客户端收到公钥后， 加密用户密码，向服务器发送用户名和加密后的用户密码； 同时另外产生一对公钥和私钥，自己保留私钥, 向服务器发送公钥； 于是第二次登录请求传输了用户名和加密后的密码以及客户端生成的公钥。
• 服务器利用保留的私钥对密文进行解密，得到真正的密码。 经过判断， 确定用户可以登录后，生成sessionId和token， 同时利用客户端发送的公钥，对token进行加密。最后将sessionId和加密后的token返还给客户端。
• 客户端利用自己生成的私钥对token密文解密， 得到真正的token。

登陆保持

在最原始的方案中， 登录保持仅仅靠服务器生成的sessionId: 客户端的请求中带上sessionId, 如果服务器的redis中存在这个id，就认为请求来自相应的登录客户端。 但是只要sessionId被截获， 请求就可以为伪造， 存在安全隐患。

引入token后，上述问题便可得到解决。 服务器将token和其它的一些变量， 利用散列加密算法得到签名后，连同sessionId一并发送给服务器； 服务器取出保存于服务器端的token,利用相同的法则生成校验签名， 如果客户端签名与服务器的校验签名一致， 就认为请求来自登录的客户端。

登出

TOKEN失效
用户登录出系统

失效原理：
在服务器端的redis中删除相应key为session的键值对。