基于JWT的RESTful API角权限验证方案设计
项武铭;鲍亮;俞少华
【摘 要】在分布式Web应用系统中,JSON Web Token作为一种无状态服务器的验证方式得到广泛关注.传统服务器session方式的权限验证流程需要特定服务器验证状态,耦合度较高,根据RESTful设计思想的角权限访问控制设计以及改进的JWT验证方式,能够更为简洁有效地实现资源为主的API权限验证.设计实现一种权限验证方案,利用JWT载荷携带角权限信息,在资源服务器端设置访问规则控制,能够有效地对不同资源进行角鉴别来控制其访问行为.
【期刊名称】《现代计算机（专业版）》
【年(卷),期】2018(000)034
【总页数】4页(P82-85)
【关键词】JWT;RESTful;访问控制;权限验证
【作 者】项武铭;鲍亮;俞少华
【作者单位】公安部第三研究所,上海200031;公安部第三研究所,上海200031;公安部第三研究所,上海200031
【正文语种】中 文
0 引言
随着Web 应用规模的逐渐增大，单服务器无法满足业务需求，分布式服务器架构成为发展的必然趋势。从LAMP 到资源分类的服务器集，其原有的服务模式也需要随之改进。以Web 应用的验证方式为例，传统的cookie-session 模式是基于有状态服务器的验证，即服务器上保存用户的登录session，用户发送请求时附带服务器签发的cookie，服务器根据存储的session 内容与cookie 对比来验证用户的身份。在分布式服务器架构中，用户请求可能就会由不同服务器进行处理，必然会出现session 如何获取的问题，在这个问题上，目前也有一些解决方案，例如采用粘性session，所有服务器同步session，用Redis 缓存session 以及将session 持久化到本地再读取，等等[1]。而对于采用HTTP 无状态设计理念
的RESTful API 来说，token 验证模式更加适应前后端分离的分布式应用的验证，它可以不用在服务器端存储状态，用户登录以后，请求中携带服务器加密生成的token，服务端验证token 的有效性来判断用户是否已经登录。验证环节相比于session模式节省了多服务器之间的认证信息交换，在网络流量安全上也有一定程度的提升。
在目前的token 验证方式中，越来越多的是使用JWT 验证，它基于JSON 格式数据并采用加密算法进行签名。由于JWT 是带签名的token，其携带数据在一定程度上可以作为可信来源[2]，服务器对于用户信息不经常修改且需要多次查询的部分内容放入JWT 的载荷中，可以降低对该部分数据库的查询频率，减少网络中流量碎片。而对于角权限验证，传统的方式多为与用户验证分离，往往是通过用户ID 去查表得到用户角，再根据用户角查表得到操作权限。顺应RESTful 以资源为主的理念，本文对RESTful API 的设计中嵌入权限访问控制，利用JWT 携带权限信息实现用户的权限验证。
1 JWT验证机制
JWT（JSON Web Token）是由国际互联网工程任务组（IETF）提出的一个行业标准（RFC 7519）。在官方简介中，JWT 被定义为在通讯双方之间一种紧凑和安全的传递协
议，其原始声明可以是一个JWS（JSON Web Signature）结构来描述的载荷，也可以是采用JWE（JSON Web Encryption）方式进行加密的明文数据。标准的JWT 采用三段式的声明，用英文点号（.）进行分段，内容依次为头部信息（Header）、载荷信息（Payload）以及签名（Signature），典型形式如。其中头部信息给出了该token 的类型以及加密或签名的算法，载荷信息部分可以使用预置的声明，例如发行者、过期时间、主题、接受者，等等，也可以使用公共或者私人定制的声明，这两个部分均以Base64Url 进行加密。签名部分则是使用头部信息中指定的算法将编码后的头部、载荷以及服务端密钥进行加密，形成签名，如图1 所示[3]。
图1 HSA256算法签名形成的JWT
其验证流程也十分简明，客户端使用用户凭据登录系统，服务器验证通过后，依据上述规则生成jwt 返回给客户端。客户端之后在向服务器请求时，通过header 中的Authorization 字段以Bearer 形式携带此token 来发送至服务器端验证身份和权限。一般的token流程可以由图2 来表示，申请为1～2 步骤进行，请求资源以3～6 步骤进行。
图2 Token验证过程
2 基于JWT的角权限验证方案
在安全要求等级较高的应用系统中，用户的权限会被严格划分，并且按照最小需求权限进行分配可操作资源，并且系统一般会禁用或者不存在最高权限的用户。例如，网络安全等级保护要求下的三员设置，存在系统管理员，安全保密管理员以及安全审计员等标准角，各个角的不能互相访问其对应的资源。将JWT 应用于RESTful API 权限进行验证，需要对资源对象的访问规则进行定制以及对JWT 进行内容和加密方式改进。
2.1 资源对象访问控制设计
以上述系统为例，在对各类资源API 进行操作需要鉴定请求者的资源访问权限时，可以参照强制访问控制方式（Mandatory Access Control，MAC），从资源对象（URL）角度进行权限分配，对不同的资源对象设置可访问角以及对应操作权限[4]。对应于资源的增删改查，请求的方式method 也依据RESTful 设计规范分别用post、delete、put、get 来定义。例如对某一资源events 的访问规则策略可以用以下方式描述：session如何设置和读取
上述规则也是按照JSON 格式来定义，一级属性字段描述了对应的API 接口，其值为策略
对象，内部属性为用户角和对应的权限数组。上图中，events 资源可以被系统管理员生成和查看，安全保密管理员仅可以查看，审计员可以查看和删除；针对某一具体event 资源，该资源创建者具有查看，更新以及删除权限，系统管理员和安全保密员具有查询权限，审计管理员具有查看和删除权限，而未授权者没有任何权限。
资源服务器对接收的请求先读取资源对象的控制列表，根据请求角在列表中所拥有的权限，判断是否进行资源操作，其角就以JWT 中信息来识别。
2.2 JWT载荷扩展
在用户登录时，权限验证服务器对用户凭证进行数据库查询，得到用户id，用户角以及其他基本信息，生成JWT 时除了用户id、过期时间、刷新时间等信息之外，还将用户的角信息写入到JWT 载荷中。若有需求临时增加该用户角之外权限，权限验证服务器还可以再签发具有扩展权限的token，短期内有效。资源服务器只验证用户所提供的JWT 是否有效，读取其中的用户角和临时权限信息判断是否提供对应资源。相比于传统token 验证，减少了用户角和权限查表的次数，仅需要在申请JWT 时做一次查询。
图3 基于JWT的用户权限验证流程
标准JWT 格式中的载荷部分是由Base64Url 方式加密，具有不可读性，但不具备保密性；签名部分是可选签名算法，一般在头部信息中指定。在一些安全要求更高的场合，JWT 载荷部分信息也需要加密处理，可以采用非对称加密对该部分信息进行加密，同样可以在头部信息添加对应字段描述为何种加密算法，这样用来保障JWT 本地存储和读取过程中数据安全，在通讯过程中的数据安全可以采用HTTPS 协议方式来保障。
3 实验过程及结果
本案例实验采用基于Node.js 的Express 框架实现RESTful API 服务器，自定义users 和events 两个资源项，其下各具有多个实例对象，访问控制规则ACL 作为中间件，取app 为express 的实例，利用app.use()引入该中间件[5]，按以下步骤验证角权限：①验证JWT 签名是否有效，无效则返回默认401 状态，有效则进行下一步；②读取ACL 规则，得到JWT 中携带的角在规则中所限定的权限；③判断该用户访问API 的权限是否符合规则。
其判断权限部分的具体实现代码为：
在图3 所设计的访问规则下，system administrator角用户对event 资源仅有查询和新增
权限，其余操作均为禁止，则当以用户system administrator 对events 资源进行增删改查操作，如图4 结果（本例使用IDEA 的mocha 测试可视化插件），对号为成功返回预期结果，惊叹号为未能返回结果。其他用户和不同权限的情况与本例类似，不再重复测试。
图4 Events资源的RESTful API访问控制测试结果
4 结语
根据JWT 携带的角权限信息，使用对应的中间件，对RESTful API 进行权限验证，对资源服务器不同操作权限进行判断。相比于传统角权限判断方式，该方式减少了查表过程，有利于网络数据传输安全，其模块化插件化的实现形式，降低了与系统耦合度，非常适应于应用扩展。JWT 的token 验证机制携带的信息签名能保证数据不被篡改，为用户角权限等特征信息提供安全可靠保障，在分布式、大规模的Web 应用中得到广泛应用，基于此基础设计的权限验证方案也具有一定的应用场景。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。