一种安全HTTP请求Token设计和实现

需求和设想

咱们都知道在事务运用开发中，运用HTTP协议的一个首要的问题便是会话办理，因为HTTP恳求，本身是无状态的，但事务的需求，又要求在不同的HTTP恳求之间，树立某种逻辑关系(如以为它们是同一个用户发起的)，这就称为会话办理。针对这个矛盾，一般能够选用三种技能道路，来完结这一需求，它们是Cookie,Session和Token。

• Cookie:

Cookie是HTTP协议标准，它允许服务器在恳求时，运用SetCookie命令在响应信息头中，向客户端浏览器传输一些信息；在下次恳求时，浏览器就需求按照标准，在恳求时的http头信息中主动附加这些信息便于服务器进行后续处理，这样就在不同的恳求进程中树立了联系；比方假如cookie里包含了用户信息，就能够以为是同一个用户在发起这些恳求了。

显然Cookie是有一些问题的，没有HTTPS的恳求进程，这些信息或许会露出或许被假造；虽然能够控制cookie的规模(一般经过域名)，但显然很多恳求不需求这些信息(如图片、脚本文件等)，但浏览器也会主动加上cookie，也是不小的开销，所以现在一般不会用于有关权限的会话办理。

• Session

Session被以为是服务端会话办理。但笔者以为它其实不是HTTP标准协议的一部分。按照笔者的了解，一般的session技能是这样完结的：

用户登录完结后，服务端保护一个Session列表(数组，能够是在内存、Redis或许数据库)，比方为登录创建一个sessionid, 对应的一个列表元素中，就用用户信息；然后将这个sessionid写入cookie；当用户再次恳求时，会带有这个sessionid，服务端运用这个id来从会话列表中获取对应的用户信息来开展事务。

这样能够看到，本质上Session便是cookid的扩展运用，只不过用sessionid的办法完结，实践用户信息保存在服务端了而已，虽然安全性略有提高，但并没有本质上解决问题。假如攻击者拿到sessionid，他就有或许假造恳求，不需求知道用户信息，也能够进行事务操作。此外，服务端需求保存和保护会话信息，Cookie的主动提交，这些都是性能上的开销和代价。

• Token

Token的本意是”令牌”，在网络技能上的意思是在恳求进程中，附加一些认证和安全方面的信息，接收方能够运用信息安全方面(如密码学)的手段，对这些信息进行检查和验证，来确保访问进程和数据的安全性。

一般，在HTTP运用完结中，Token在技能一般不运用HTTP供给的Cookie等功能，而是自行构造恳求和内容，并经过自定义的密码学操作，来确保恳求进程的逻辑关系和安全性，其本质便是恳求进程的可控性和安全性。

特别是在前后端别离的完结模型和场景中，笔者觉得运用Token来办理会话是更加适宜的，本文的首要内容也是讨论Token机制的规划与完结。

Token结构和内容规划

依据上面的讨论， 咱们了解到，Token技能其实是一个相对独立，而且可自定义和扩展的技能，除用于客户端恳求(AJAX)之外，也能够运用到后端的通讯进程。而且，规划和完结一个杰出的token机制，关于体系通讯和运转的安全性和功率，都有比较大的促进。

那么，在一个真实的运用傍边，咱们怎么规划和完结一个比较好的Token机制呢？ 先来看看笔者以为一个杰出的Token机制，需求归纳考虑安全性、功率、可扩展性、互操作性和可开发性等方面，如应该有包含以下特点：

• Token中需求包含恳求方和服务方的相关信息(特别是后端间通讯)
• Token中包含网络相关信息，如恳求方的IP地址，能够检查作为安全机制
• Token中需求包含token的过期时刻信息，能够检查作为安全机制
• Token中实践内容(载荷)是可扩展的，并可选加密或许不加密
• Token包含签名信息，能够由颁发体系或许其他体系进行验证，确保token的完整性

为此，首先咱们需求决定和规划Token应当包含哪些信息， 具体如下：
这个Token是一个字符串的形式，大体包含三个方面的内容，运用分号分开：

[头信息];[内容信息];[签名信息]

一个实例如下：
V00AAs1666h8cizn;E1tFib82Ap12tZJyoZIs7ZVivdPdLUEuliZAkulMiqbf5pD3DZECbLIEzZMB7dX5cNn1kxRIMoVMxisGRsgx8RwJmyZRzy3UI01N6U3CDZlP59zpbA==;19ka5c3

这种Token一般长度在100~300个字符(依据内容和签名办法有所差异，当然，在这三个字符串内部，不能运用分号，其间：

• 头信息包含： token类型(一个字符)，体系信息(4个字符)，IP地址编码(若干字符)，时刻编码(能够固定为5个字符)
• 内容信息，是一个Base64字符串，能够由信息的简单编码，或许一个加密后的成果
• 签名信息，是对token前面字符串内容的私钥签名或许简单签名，签名办法和密钥由服务端确认，假如运用私钥签名，则其他体系能够对此token进行验证，不然只能由生成token的体系来验证

token类型，确认了这个token的生成办法，和依据此办法的token验证和处理办法(对应的算法)，咱们现在暂时规划了两种类型(能够随时扩展和兼容)

• V: 全私有，私有签名，token内容加密，只要生成方才能对它进行验证和解密
• P: 全揭露，运用私钥签名，公钥验证，内容虽然是base64编码，但能够以为是揭露的，只能确保这个token来源于颁发体系，当然在外部也能够进行时刻和恳求地址的有效性检查

体系信息是保存的，由事务要求确认(如表示恳求体系或许服务体系等)，IP编码和时刻编码的完结也有相应的规矩，详见完结代码。

完结和代码

Token的内容和格局确认后，咱们针对编写了一个JS程序办法，来完结以上设想和规划要求。

关键如下：

• 此办法支撑两种形式，V(私有，载荷加密，私有验证)，P(公共，载荷Base64，公钥验证)。
• 时刻为当时时刻+过期时刻， /120000的36字符编码
• IP地址格局不限制(或许有v6的地址)，一致摘要后再编码，验证时比较编码一致，当然也能够忽略检查
• 加密，签名和验证等操作，这里运用的是NaCl库，详见笔者的另一篇文章《NaCl密码学程序库运用和研究》(/post/722637…)

Token运用，生成和验证

下面是依据上述完结，在具体运用中，生成和检查token的示例代码：

    // token params 
    let 
    key  = codec.from(VK_SIGN,"base64"), // sign key and hmac key
    pkey = codec.from(PK_SIGN,"base64"), // sign key and hmac key
    ip = "192.168.9.134",
    prefix = "00AA", // sub system id
    duo = 10; // *2min
    content = { i: "1056", r: 129, n: "颜建华", o: 5101} ;
    // genarate token 
    let token3 = mtoken({ ip, content, prefix, duo, key, tmode: "V" });
    console.log("Token-V:", token3.length, token3);
    // check token
    let check3= mtoken({ ip, content, prefix, duo, key, token: token3 });
    console.log("Token Check3:", check3);

生成token的办法，需求先依据事务需求和环境装备，构造一个参数目标，包含了：

• IP(或许来自结构的req目标)，
• content，事务载荷(应该是JSON目标，如账号信息等)，
• prefix，事务前缀(四个字符，如0000)，
• duo，过期时刻(乘以2分钟)，
• key，签名密钥和加解密密钥，
• pkey，签名公钥(假如运用公钥签名的话)
• token，假如是验证形式，需求输出token的base64字符串
• tmode, 如是生成形式，需求挑选生成何种类型的token，如V或许P

在生成形式下，函数的输出是一个token字符串。在事务中就能够用于http恳求中的内容；在验证形式下，假如验证失利，则回来null，不然回来事务载荷信息(便是说验证的同时进行了解密或解码)。

在实践的HTTP运用傍边，一般在客户端完结登录认证后，服务器依据事务需求和运转环境，构造一个Token，颁发给客户端；客户端在后续的恳求进程中(一般是运用AJAX恳求服务端的API接口)，就能够附加此Token；服务端从恳求信息中别离Token，验证通往后，能够运用Token中的用户信息，来检查用户操作权限，并进一步供给操作和数据服务。

当然，依据事务场景和需求的不同，咱们能够考虑token的不同附加办法：

• 放在HTTP恳求头中，相对安全和标准，主张在前后端别离和服务器间通讯的场景运用，但开发完结稍微复杂
• 放在恳求参数中，适用性更好，比方在URL中，能够作为连接和重定向地址运用，开发和完结也比较简单

那么，具体而言，在这个进程中，安全性是怎么确保的呢？

用户登录成功拿到Token之后，一般将Token保存在浏览器的Session Store中，一般也不进行任何处理，而且只在API恳求时才运用，减少了信息露出的危险； Token的内容能够是加密的，第三方乃至客户端都不知道其间的具体内容，只要服务器解密后知晓；Token是能够经过签名来验证的，外部既不能假造内容，也不能假造签名，确保了信息和内容的完整性；假如运用公钥，第三方也能够来验证Token的有效性； Token信息中包含了原始恳求IP地址和有效时刻，服务端能够验证这些信息的有效性，并拒绝失效的Token。 这些规划，都有力的保障了HTTP运用进程中的安全可控。

小结

本文探讨了HTTP会话的完结和保障机制，特别提出了一种比较安全的Token规划思路，而且编写了相关的代码来展示其的完结和运用，最终讨论了这些规划和完结的安全性。