1.本发明涉及一种实现主app与子应用模块之间的用户信息对接的授权方法。
背景技术：
2.移动app的功能日益丰富，通常由移动app内的不用应用模块实现不同功能。这些应用模块可能是同一个公司的同一个部门开发的，也可能是同一个公司的不同部门开发的，甚至可能是不同公司开发。但无论app内的应用模块是否是同一公司或者同一个部门开发的，其作为同一个移动app内置的模块，需要作为一个整体让用户无感知地使用，这就涉及到主app与子应用模块之间的用户信息对接的问题。
3.为实现主app与子应用模块之间的用户信息对接，现有的技术方案主要采用的方法是：将唯一的用户标识和敏感信息通过预先约定的加密方式加密后，携带入访问子应用模块的url中，再由子应用模块解密获取，从而能让子应用模块共享当前登录主app的用户的信息并提供服务。前述方案的主要问题在于用户标识和敏感信息加密后形成的加密串可反复使用，因此加密串存在意外暴露的风险。一旦加密串暴露，容易引起越权操作。为解决该问题，本领域技术人员所提出的解决方案是在加密参数内加入时间戳，加密串仅在某一特定时间段(即有效期)内有效，可被反复使用。在有效期外，加密串失效，需要对用户标识和敏感信息重新加密以生成新的加密串。显而易见的是，在有效期内，加密串仍然可以重复使用，依然无法降低其被意外暴露的风险，因此这种解决方案的安全级别仍然较低，在某些需要较高安全级别的场合并不适用。
技术实现要素：
4.本发明要解决的技术问题是：为实现主app与子应用模块之间的用户信息对接，现有的技术方案生成的加密串可以被反复使用，安全级别较低。
5.为了解决上述技术问题，本发明的技术方案是提供了一种用户静默授权方法，其特征在于，包括以下步骤：
6.步骤1、子应用模块接入主app之前：
7.由主app服务端在数据库内配置子应用模块所在厂商的厂商信息，并生成与厂商唯一对应的随机字符串consumerid、sm2非对称加密公钥consumerkey以及sm2非对称加密私钥consumerprivatekey存入数据库中，其中：随机字符串consumerid以及sm2非对称加密公钥consumerkey提供给子应用服务端使用；厂商信息至少包括厂商服务器ip；
8.由主app服务端在数据库内配置子应用模块的子应用信息，其中，子应用信息至少包括子应用id、子应用跳转url、子应用授权方式及拓展字段，其中，子应用id以consumerid开头；子应用授权方式包括authcode授权、authtoken授权以及custom授权，其中，custom授权通过拓展字段自定义主app与子应用模块的具体对接方式；
9.步骤2、主app客户端根据主app服务端的配置信息向用户展示子应用模块，供用户使用；用户点击某个子应用模块时，主app客户端通过配置的子应用信息查看所配置的子应
用授权方式：
10.若步骤1中，主app服务端在数据库内配置子应用模块的子应用授权方式为authcode授权，则跳转至步骤4；若步骤1中，主app服务端在数据库内配置子应用模块的子应用授权方式为authtoken授权，则跳转至步骤5；若步骤1中，主app服务端在数据库内配置子应用模块的子应用授权方式为custom授权，则跳转至步骤6；
11.步骤4、进行authcode授权，具体包括以下步骤：
12.步骤401、主app客户端携带当前用户的用户凭证及子应用信息内配置的子应用id向主app服务端申请访问授权码code；
13.步骤402、主app服务端通过主app客户端传入的用户凭证获得对应的用户id，将用户id及子应用id存储进redis数据库内，生成随机字符串作为redis映射的key，主app服务端将生成的随机字符串作为访问授权码code返回给主app客户端，并设置访问授权码code在redis数据库内的过期时间；
14.步骤403、主app客户端拿到访问授权码code后，将其拼接至子应用信息内的子应用跳转url，并跳转加载此子应用跳转url，此子应用跳转url指向的地址即为子应用的前端页面；
15.步骤404、子应用前端页面拿到拼接在子应用跳转url后的访问授权码code，将访问授权码code传给子应用服务端；
16.步骤405、子应用服务端接收到访问授权码code后，使用步骤1生成的sm2非对称加密公钥consumerkey对步骤1生成的随机字符串consumerid以及当前时间戳进行sm2加密，生成加密字符串；子应用服务端携带加密字符串及明文的随机字符串consumerid访问主app服务端；
17.步骤406、主app服务端接收到明文的随机字符串consumerid及加密字符串后，用随机字符串consumerid通过数据库查询到步骤1中预先配置的关联的厂商服务器ip，并对比其与当前访问的ip地址是否一致，从而鉴定是否来自白名单服务器的访问，若一致则进入下一步，若不一致，则拒绝此次访问；
18.步骤407、主app服务端用随机字符串consumerid通过数据库查询到步骤1中预先配置的关联的sm2非对称加密私钥consumerprivatekey，对加密字符串进行解密，若解密失败，则拒绝此次访问，若解密成功，则进一步当前时间戳距离解密获得的当前时间戳是否在预定时长内，若是，则鉴权成功，进入下一步，否则，则鉴权失败，拒绝此次访问；
19.步骤408、主app服务端生成一套新的sm2公私钥，将新的sm2非对称加密私钥affairssendprivatekey及随机字符串consumerid存入redis数据库中，随机生成字符串为redis映射的key，并将这个随机生成的字符串作为affairtoken，新的sm2非对称加密公钥作为affairssendkey返回至子应用服务端；
20.步骤409、步骤405中访问主app服务端的子应用服务端接收到主app服务端反馈的affairtoken以及affairssendkey后，随机生成一个字符串作为sm4加密的sm4加密秘钥，用sm4加密步骤405中获得的访问授权码code，并基于affairssendkey使用sm2加密随机生成的sm4加密秘钥作为参数一；
21.步骤410、子应用服务端将affairtoken、步骤409获得的参数一放入httpheader中，加密后的访问授权码code放入httpbody中，访问主app服务端；
22.步骤411、主app服务端接收到affairtoken、参数一以及加密后的访问授权码code后，主app服务端：
23.通过affairtoken查询到步骤408中与之关联的sm2非对称加密私钥affairssendprivatekey及随机字符串consumerid；
24.对参数一进行解密后，获得子应用服务端在步骤409中随机生成的sm4加密秘钥；
25.步骤412、主app服务端使用步骤411获得的sm4加密秘钥对加密后的访问授权码code进行解密，得到原始的访问授权码code；
26.步骤413、主app服务端通过访问授权码code查询到与之关联的用户id及子应用id，并删除访问授权码code在redis数据库内的映射，从而保证访问授权码code仅有一次使用效果；
27.步骤414、主app服务端对比步骤411中获得的随机字符串consumerid与步骤413中获得的子应用id是否为关联关系，若为关联关系，则继续下一步，否则，返回授权码与子应用不匹配；
28.步骤415、主app服务端通过步骤413中获得的用户id查询到对应的用户信息，并使用步骤411中得到的sm4加密秘钥对用户信息进行加密，然后返回给子应用服务端；
29.步骤416、子应用服务端接收到加密后的用户信息，使用步骤409中生成的sm4加密秘钥进行解密，得到用户信息，子应用服务端使用用户信息生成登录凭证，返回至子应用前端；
30.步骤417、子应用前端接收到登录凭证，可以正常处理同一用户的业务，至此authcode授权流程结束；
31.步骤5、进行authtoken授权，具体包括以下步骤：
32.步骤501、用户登录后，主app服务端将用户信息存进redis数据库，并随机生成字符串作为用户凭证authtoken返回至主app客户端，主app客户端以用户凭证authtoken作为接口交互时的用户凭证；
33.步骤502、用户点击子应用模块时，主app客户端通过配置的子应用信息查看子应用授权方式，判断为authtoken授权，则跳转至子应用信息内的子应用跳转url；
34.步骤503、主app开启javascript获取用户凭证authtoken的权限；
35.步骤504、子应用前端通过javascript交互获取主app的用户凭证authtoken；
36.步骤505、子应用前端携带用户凭证authtoken访问子应用服务端；
37.步骤506、子应用服务端通过用户凭证authtoken访问步骤501中的redis数据库获取与之对应的用户信息；
38.步骤507、子应用服务端使用用户信息生成登录凭证，返回至子应用前端；
39.步骤508、子应用前端接收到登录凭证，可以正常处理同一用户的业务，至此authtoken授权流程结束；
40.步骤6、进行custom授权：
41.通过子应用信息里的拓展字段规定的具体对接方式，形成主app与子应用模块完整的对接方案，由主app进行反向授权对接。
42.优选地，所述厂商信息还包括厂商名称以及厂商简介。
43.优选地，所述子应用信息还包括子应用的展示层级、子应用名称、子应用类型、子
应用编号、子应用所在域、子应用图标url、子应用跳转方式以及子应用的子菜单。
44.本发明提供了一种从子应用模块的配置，到临时授权凭证生成，最后到服务交互鉴权的完整解决方案，从而保障了用户信息授权的安全。与现有技术相比，本发明具有如下优点：
45.1)用户敏感信息不暴露在客户端，不通过客户端传递，使用具有时效性的用户凭证代替。整个授权交互的过程中，用户完整信息的传递仅发生在服务端与服务端之间。
46.2)使用国密非对称加密及对称加密的组合，在保证数据传输安全的同时，鉴定访问合法。
47.3)预先设置ip白名单，基于ip白名单，访问授权接口时验证ip是否合法。
48.4)设定授权码的时效，使得授权码仅可使用一次，保障使用安全。
49.本发明的整个流程在瞬间完成，流程用户无感知，使用户对接安全、便捷，本发明中的主app能够具备接入各厂商网页应用的能力。
具体实施方式
50.下面结合具体实施例，进一步阐述本发明。应理解，这些实施例仅用于说明本发明而不用于限制本发明的范围。此外应理解，在阅读了本发明讲授的内容之后，本领域技术人员可以对本发明作各种改动或修改，这些等价形式同样落于本技术所附权利要求书所限定的范围。
51.本实施例公开的一种用户静默授权方法包括以下步骤：
52.步骤1、子应用模块接入主app之前：
53.(1)由主app服务端在数据库内配置子应用模块所在厂商的厂商信息，并生成与厂商唯一对应的16位随机字符串consumerid、sm2非对称加密公钥consumerkey以及sm2非对称加密私钥consumerprivatekey存入数据库中，其中，consumerid以及sm2非对称加密公钥consumerkey提供给子应用服务端使用。本实施例中，厂商信息包括厂商名称、厂商简介、厂商服务器ip等信息。
54.(2)由主app服务端在数据库内配置子应用模块的子应用信息。本实施例中，子应用信息包括子应用的展示层级、子应用id、子应用名称、子应用跳转url、子应用类型、子应用编号、子应用所在域、子应用图标url、子应用授权方式、子应用跳转方式、子应用的子菜单及拓展等信息。配置子应用模块的子应用id时，以consumerid开头，便于后续查找所属厂商。
55.步骤1考虑了多个子应用模块可能属于同一厂商开发的情况，为不同厂商生成对应的consumerid、consumerkey以及consumerprivatekey，并基于consumerid配置子应用模块的子应用id。
56.步骤2、主app客户端根据主app服务端的配置信息向用户展示子应用模块，供用户使用。用户点击某个子应用模块时，主app客户端通过配置的子应用信息查看所配置的子应用授权方式，子应用授权方式包括authcode授权、authtoken授权以及custom授权。
57.若步骤1中，主app服务端在数据库内配置子应用模块的子应用授权方式为authcode授权，则跳转至步骤4；若步骤1中，主app服务端在数据库内配置子应用模块的子应用授权方式为authtoken授权，则跳转至步骤5；若步骤1中，主app服务端在数据库内配置
子应用模块的子应用授权方式为custom授权，则跳转至步骤6。
58.步骤4、进行authcode授权，具体包括以下步骤：
59.步骤401、主app客户端携带当前用户的用户凭证及子应用信息内配置的子应用id向主app服务端申请访问授权码code；
60.步骤402、主app服务端通过主app客户端传入的用户凭证获得对应的用户id，将用户id及子应用id存储进redis数据库内，生成随机字符串作为redis映射的key，主app服务端将生成的随机字符串作为访问授权码code返回给主app客户端，并将访问授权码code在redis数据库内映射的过期时间设置为2分钟；
61.本步骤中，对redis数据库的时效设置保证了访问授权码code的有效期；
62.步骤403、主app客户端拿到访问授权码code后，将其拼接至子应用信息内的子应用跳转url，并跳转加载此子应用跳转url，此子应用跳转url指向的地址即为子应用的前端页面；
63.步骤404、子应用前端页面拿到拼接在子应用跳转url后的访问授权码code，将访问授权码code传给子应用服务端；
64.步骤405、子应用服务端接收到访问授权码code后，使用步骤1生成的sm2非对称加密公钥consumerkey对步骤1生成的16位随机字符串consumerid以及当前时间戳进行sm2加密，生成加密字符串；子应用服务端携带加密字符串及明文的16位随机字符串consumerid访问主app服务端；
65.步骤406、主app服务端接收到明文的16位随机字符串consumerid及加密字符串后，用16位随机字符串consumerid通过数据库查询到步骤1中预先配置的关联的厂商服务器ip，并对比其与当前访问的ip地址是否一致，从而鉴定是否来自白名单服务器的访问，若一致则进入下一步，若不一致，则拒绝此次访问；
66.步骤407、主app服务端用16位随机字符串consumerid通过数据库查询到步骤1中预先配置的关联的sm2非对称加密私钥consumerprivatekey，对加密字符串进行解密，若解密失败，则拒绝此次访问，若解密成功，则进一步当前时间戳距离解密获得的当前时间戳是否在1分钟内，若是，则鉴权成功，进入下一步，否则，则鉴权失败，拒绝此次访问；
67.步骤408、主app服务端生成一套新的sm2公私钥，将新的sm2非对称加密私钥affairssendprivatekey及16位随机字符串consumerid存入redis数据库中，随机生成字符串为redis映射的key，并将这个随机生成的字符串作为affairtoken，新的sm2非对称加密公钥作为affairssendkey返回至子应用服务端；
68.本步骤是为后续服务交互的一次一密做准备，提高安全性；
69.步骤409、步骤405中访问主app服务端的子应用服务端接收到主app服务端反馈的affairtoken以及affairssendkey后，随机生成一个16位的字符串作为sm4加密的sm4加密秘钥，用sm4加密步骤405中获得的访问授权码code，并基于affairssendkey使用sm2加密随机生成的sm4加密秘钥作为参数一；
70.本步骤中，由于sm4加密秘钥为随机生成，可以做到每次都不一样，从而实现了一次一密；并本发明用affairssendkey对sm4加密秘钥加密后再传输给主app服务端，以此来保障只有主app服务端可以解密，在一次一密的同时保障秘钥的安全传递；
71.步骤410、子应用服务端将affairtoken、步骤409获得的参数一放入httpheader
中，加密后的访问授权码code放入httpbody中，访问主app服务端；
72.步骤411、主app服务端接收到affairtoken、参数一以及加密后的访问授权码code后，主app服务端：
73.(1)通过affairtoken查询到步骤408中与之关联的sm2非对称加密私钥affairssendprivatekey及16位随机字符串consumerid；
74.(2)对参数一进行解密后，获得子应用服务端在步骤409中随机生成的sm4加密秘钥；
75.步骤412、主app服务端使用步骤411获得的sm4加密秘钥对加密后的访问授权码code进行解密，得到原始的访问授权码code；
76.步骤413、主app服务端通过访问授权码code查询到与之关联的用户id及子应用id，并删除访问授权码code在redis数据库内的映射，从而保证访问授权码code仅有一次使用效果；
77.步骤414、主app服务端对比步骤411中获得的16位随机字符串consumerid与步骤413中获得的子应用id是否为关联关系(步骤1中，子应用id配置时以16位随机字符串consumerid开头)，若为关联关系，则继续下一步，否则，返回授权码与子应用不匹配；
78.本步骤是为了保障访问授权码code的作用范围仅为当前授权的子应用；
79.步骤415、主app服务端通过步骤413中获得的用户id查询到对应的用户信息，并使用步骤411中得到的sm4加密秘钥对用户信息进行加密，然后返回给子应用服务端；
80.步骤416、子应用服务端接收到加密后的用户信息，使用步骤409中生成的sm4加密秘钥进行解密，得到用户信息，子应用服务端使用用户信息生成登录凭证，返回至子应用前端；
81.步骤417、子应用前端接收到登录凭证，可以正常处理同一用户的业务，至此authcode授权流程结束。
82.步骤5、进行authtoken授权(通常为主app及子应用模块为同一公司内的不同部门开发时使用)，具体包括以下步骤：
83.步骤501、用户登录后，主app服务端将用户信息存进redis数据库，并随机生成字符串作为用户凭证authtoken返回至主app客户端，主app客户端以用户凭证authtoken作为接口交互时的用户凭证；
84.步骤502、用户点击子应用模块时，主app客户端通过配置的子应用信息查看子应用授权方式，判断为authtoken授权，则跳转至子应用信息内的子应用跳转url；
85.步骤503、主app开启javascript获取用户凭证authtoken的权限；
86.步骤504、子应用前端通过javascript交互获取主app的用户凭证authtoken；
87.步骤505、子应用前端携带用户凭证authtoken访问子应用服务端；
88.步骤506、子应用服务端通过用户凭证authtoken访问步骤501中的redis数据库获取与之对应的用户信息；
89.步骤507、子应用服务端使用用户信息生成登录凭证，返回至子应用前端；
90.步骤508、子应用前端接收到登录凭证，可以正常处理同一用户的业务，至此authtoken授权流程结束。
91.步骤6、进行custom授权。custom授权为特殊的自定义授权方式，已经形成了主app
与子应用模块完整的对接方案，需要主app反向授权对接。进行custom授权时，通过子应用信息里的拓展字段规定了具体的对接方式，在自定义的同时做到灵活配置。