nodejs--JWT 在先后端分离中的应用与实践

本文主要介绍JWT（JSON Web Token）受权机制在先后端分离中的应用与实践，包括如下三部分：

1. JWT原理介绍
2. JWT的安全性
3. React.js+Flux架构下的实践（React-jwt example）

0 关于先后端分离

先后端分离是一个颇有趣的议题，它不只仅是指先后端工程师之间的相互独立的合做分工方式，更是先后端之间开发模式与交互模式的模块化、解耦化。计算机世界的经验告诉咱们，对于复杂的事物，模块化老是好的，不管是后端API开发中愈来愈成为规范的RESTful API风格，仍是Web前端愈来愈多的模板、框架（参见MVC，MVP 和 MVVM 的图示），包括移动应用中先后端自然分离的特质，都证明了先后端分离的重要性与必要性（更生动的细节与实例说明能够参看赫门分享的主题淘宝先后端分离实践）。

实现先后端分离，对于后端开发人员来讲是一件很幸福的事情，由于不须要再考虑怎样在HTML中套入数据，只关心数据逻辑的处理；而前端则须要承担接收数据以后界面呈现、用户交互、数据传递等全部任务。虽然这看起来加剧了前端的工做量，但实际上有愈来愈多丰富多样的前端框架可供选择，这让前端开发变得愈来愈结构化、系统化，前端工程师也再也不只是“套版的”。

在全部前端框架中，Facebook推出的React无疑是当下最热门（之一），然而React只负责界面渲染层面，至关于MVC中的V（View），所以只靠React没法完成一个完整的单页应用（Single Page App）。Facebook另外推出与之配套的Flux架构，主要为了不Angular.js之类MVC的架构模式，规避数据双向绑定而采用单向绑定的数据传递方式。实际上React不管是学习仍是使用都是很是简单的，而Flux则须要花更多时间去理解消化，本文第3部分我采用Flux架构的一种实现Reflux.js，作了一个基于JWT受权机制的登入、登出的例子，顺便介绍Flux架构的细节。

1 JWT 介绍及其原理

JWT是我以前作Android应用的时候了解到的一种用户受权机制，虽然原生的移动手机应用与基于浏览器的Web应用之间存在不少差别，但不少状况下后端每每仍是沿用已有的架构跟代码，因此用户受权每每仍是采用Cookie+Session的方式，也就是须要原生应用中模拟浏览器对Cookie的操做。

Cookie+Session的存在主要是为了解决HTTP这一无状态协议下服务器如何识别用户的问题，其原理就是在用户登陆经过验证后，服务端将数据加密后保存到客户端浏览器的Cookie中，同时服务器保留相对应的Session（文件或DB）。用户以后发起的请求都会携带Cookie信息，服务端须要根据Cookie寻回对应的Session，从而完成验证，确认这是以前登录过的用户。其工做原理以下图所示：

JWT是Auth0提出的经过对JSON进行加密签名来实现受权验证的方案，编码以后的JWT看起来是这样的一串字符：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ 

由.分为三段，经过解码能够获得：

// 1. Headers // 包括类别（typ）、加密算法（alg）； { "alg": "HS256", "typ": "JWT" } // 2. Claims // 包括须要传递的用户信息； { "sub": "1234567890", "name": "John Doe", "admin": true } // 3. Signature // 根据alg算法与私有秘钥进行加密获得的签名字串； // 这一段是最重要的敏感信息，只能在服务端解密； HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), SECREATE_KEY ) 

在使用过程当中，服务端经过用户登陆验证以后，将Header+Claim信息加密后获得第三段签名，而后将签名返回给客户端，在后续请求中，服务端只须要对用户请求中包含的JWT进行解码，便可验证是否能够受权用户获取相应信息，其原理以下图所示：

经过比较能够看出，使用JWT能够省去服务端读取Session的步骤，这样更符合RESTful的规范。可是对于客户端（或App端）来讲，为了保存用户受权信息，仍然须要经过Cookie或相似的机制进行本地保存。所以JWT是用来取代服务端的Session而非客户端Cookie的方案，固然对于客户端本地存储，HTML5提供了Cookie以外更多的解决方案（localStorage/sessionStorage），究竟采用哪一种存储方式，其实从Js操做上来看没有本质上的差别，不一样的选择更可能是出于安全性的考虑。

2 JWT 安全性

用户受权这样敏感的信息，安全性固然是首先须要考虑的因素。这里主要讨论在使用JWT时如何防止XSS和XSRF两种攻击。

XSS是Web中最多见的一种漏洞（咱们的**学报官网就存在这个漏洞这件事我就不说了=.=），其主要缘由是对用户输入信息不加过滤，致使用户（被误导）恶意输入的Js代码在访问该网页时被执行，而Js能够读取当前网站域名下保存的Cookie信息。针对这种攻击，不管是Cookie仍是localStorage中的信息都有可能被窃取，但防止XSS也相对简单一些，对用户输入的全部信息进行过滤便可。另外，如今愈来愈多的CDN服务，让咱们能够节省服务器流量，但同时也有可能引入不安全的Js脚本，例如前段时间Github被Great Cannon轰击的案例，则须要提升对某度之类服务的警戒。

另一种更加棘手的XSRF漏洞主要利用Cookie是按照域名存储，同时访问某域名时浏览器会自动携带该域名所保存的Cookie信息这一特征。若是执意要将JWT存储在Cookie中，服务端则须要额外验证请求来源，或者在提交表单中加入随机签名并在处理表单时进行验证。

我在后面的实例中采用将JWT保存在localStorage中的方案，请求时将JWT放入Request Header中的Authorization位。对JWT安全性问题想要了解更多能够参考下面几篇文章：

1. Where to Store Your JWTs - Cookies vs HTML5 Web Storage
2. Use JWT the Right Way!
3. 10 Things You Should Know about Tokens
4. Where to store JWT in browser? How to protect against CSRF?

3 React-jwt Example

本节源码可见Github: react-jwt-example。

前面提到的React.js框架学习成本其实很是低，只要跟着官方教程走一遍，搞清楚props、states、virtual DOM几个概念，就能够开始用了。可是只有View层什么都作不了，Facebook推出配套的Flux架构，一开始看到下面这张架构图，当时我就懵逼了。

好在Flux只是一种理论架构，虽然官方也提供了实现方案，可是我更倾向于Reflux.js的实现方式，以下图所示：

其中View Components即视图层由React负责，Stores用于存储数据，Actions则用于监听全部动做，全部数据的传递都是单向绑定的，在分割不一样模块时，能够清楚地看到数据的流动方向。

我尝试写了一个简单的登陆、登出以及获取用户我的数据的例子，除了Reflux以外，还用到以下模块：

1. react-router: SPA路由；
2. react-bootstrap: React化的Bootstrap，UI样式；
3. reqwest: Ajax请求；
4. jwt-decode: 客户端的JWT解码；

另外服务端API采用Go gin框架，依赖于jwt-go。代码目录结构以下：

tree -I 'node_modules|.git' . ├── README.md ├── gulpfile.js ├── index.html ├── package.json ├── scripts │   ├── actions │   │   └── actions.js │   ├── app.js │   ├── build │   │   └── dist.js │   ├── components │   │   └── HelloWorld.js │   ├── stores │   │   ├── loginStore.js │   │   └── userStore.js │   └── views │   ├── home.js │   ├── login.js │   └── profile.js └── server.go 

完整的页面放在view中，可复用的组件放在components，用户的动做包括login、logout以及getBalance，所以须要建立相应的action来监听这些动做：

// actions.js var actions = Reflux.createActions({ "login": {}, "updateProfile": {}, // login成功更新用户数据 "loginError": {}, // login失败错误信息 "logout": {}, "getBalance": {asyncResult: true} }); actions.login.listen(function(data){}); 

用户点击view中的Submit Button时，将表单信息提交给login action：

// views/login.js var Login = React.createClass({ ... login: function (e) { e.preventDefault(); actions.login({ name: this.refs.name.getValue(), pass: this.refs.pass.getValue(), }), ... }); // actions.js var req = require('reqwest'); actions.login.listen(function(data){ req({ url: HOST+"/user/token", method: "post", data: JSON.stringify(data), type: 'json', contentType: 'application/json', headers: {'X-Requested-With': 'XMLHttpRequest'}, success: function (resp) { if(resp.code == 200){ actions.updateProfile(resp.jwt) }else{ actions.updateProfile(resp.msg) } }, }) }); 

根据API返回结果，将再次触发updateProfile或updateProfile action，而分别由userStore和loginStore接收：

// stores/userStore.js var userStore = Reflux.createStore({ listenables: actions, // 声明userStore所监听的action updateProfile: function(jwt){ // 注册监听actions.updateProfile localStorage.setItem('jwt', jwt); this.user = jwt_decode(jwt); this.user.logd = true; this.trigger(this.user); }, }) // stores/loginStore.js var loginStore = Reflux.createStore({ listenables: actions, loginError: function(msg){ this.trigger(msg); }, }); 

store接收action数据后，经过this.trigger(msg)将处理事后的数据从新传递会view：

var Login = React.createClass({ mixins : [ Router.Navigation, Reflux.listenTo(userStore, 'onLoginSucc'), Reflux.listenTo(loginStore, 'onLoginErr') ], onLoginSucc: function(){ // 登陆成功，跳转回首页 this.transitionTo('home'); }, onLoginErr: function (msg) { // 登陆失败，显示错误信息 this.setState({ errorMsg: msg, }); }, ... }); 

至此，从用户点击登陆到登陆结果传回，整个流程数据在View->Action->Store->View中完成单向传递，这就是Flux架构的基本概念。

在完成登陆后，API会将验证经过的JWT传回：

// server.go token := jwt.New(jwt.SigningMethodHS256) // Headers token.Header["alg"] = "HS256" token.Header["typ"] = "JWT" // Claims token.Claims["name"] = validUser.Name token.Claims["mail"] = validUser.Mail token.Claims["exp"] = time.Now().Add(time.Hour * 72).Unix() tokenString, err := token.SignedString([]byte(mySigningKey)) if err != nil { c.JSON(200, gin.H{"code": 500, "msg": "Server error!"}) return } c.JSON(200, gin.H{"code": 200, "msg": "OK", "jwt": tokenString}) 

当登陆以后的用户在profile页面发起getBalance请求时，存储于本地的jwt将一块儿传递，我这里采用Header的方式传递，具体取决于API端的协议：

// actions.js actions.getBalance.listen(function(){ var jwt = localStorage.getItem('jwt'); req({ url: HOST+"/user/balance", method: "post", type: "json", headers: { 'Authorization': "Bearer "+jwt, }, success: function (resp) { if (resp.code == 200) { actions.updateProfile(resp.jwt); }else{ actions.loginError(resp.msg); } } }) }) 

而服务端面对任何须要验证权限的请求须要经过Token验证：

//server.go token, err := jwt.ParseFromRequest(c.Request, func(token *jwt.Token) (interface{}, error) { b := ([]byte(mySigningKey)) return b, nil }) 

 

  

 Go, React, 先后端分离, JWT

- END -

 

if(post.content.isHelpful){ $("button#donate").click(); }; 

 ME A CUP OF