DB4206/T 27-2021 政务服务移动端接入技术规范

ICS35.240.01

L77

DB4206

襄阳市地方标准

DB4206/T27—2021

政务服务移动端接入技术规范

Technicalspecificationformobileaccesstogovernmentservices

2021-02-05发布2021-03-04实施

襄阳市市场监督管理局发布

DB4206/T27—2021

前  言

本标准依据GB/T1.1-2020《标准化工作导则第1部分：标准的结构和编写规则》编写。

本标准由襄阳市政务服务和大数据管理局提出。

本标准由襄阳市政务信息标准化技术委员会归口。

本标准的起草单位：湖北襄测质量技术服务有限公司、湖北金正邦电子技术有限责任公司、湖北阳

光华辰网络有限公司。

本标准主要起草人：雷雨、宋剑、王大伟、李玉奎、王成文、赵俊、巨军政、王均华、黎黎、韩国

华、付其杰、郭华龙。

本标准为首次发布。

I

DB4206/T27—2021

政务服务移动端接入技术规范

1范围

本标准规定了政务服务移动端的流程、技术要求、审核要求、管理要求和运营要求等内容。

本标准适用于襄阳市政务服务移动端系统建设。

2规范性引用文件

下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文

件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。

GB/T7027信息分类和编码的基本原则与方法

GB/T19488.4电子政务标准化指南

GB/T21062政务信息资源交换体系

GB/T21063政务信息资源目录体系

GB/T34678智慧城市技术参考模型

ZWFWC0103国家政务服务平台政务服务移动端建设要求

DB11/T553政务信息资源共享交换平台技术规范

DB3301/T0169智慧电子政务数据资源共享管理规范

DB4206/Z5襄阳市政务信息化总体技术框架

国办函〔2016〕108号国务院办公厅关于印发“互联网+政务服务”技术体系建设指南的通知

国办发〔2018〕45号进一步深化“互联网+政务服务”推进政务服务“一网、一门、一次”改革实

施方案

3术语和定义

下列术语与定义适用于本规范。

3.1

政务服务移动端系统

县（市、区）、开发区和部门政务服务移动应用及资源的汇聚接入系统，面向自然人、法人和其他

组织提供全市政务服务移动端查询、咨询和移动办事服务的入口。

3.2

政务服务应用

由县（市、区）、开发区或部门为自然人、法人和其他组织提供各类网上政务服务。

3.3

1

DB4206/T27—2021

政务数据资源

各级行政机关或其他依法经授权、受委托行使行政职能的组织（以下简称各单位），在履行职责过

程中产生、采集的信息。

3.4

数据共享

各单位因履行职责适用其他单位政务数据资源，以及为其他单位履行职责提供本单位的政务数据资

源的行为。

3.5

基础数据库

具有基础性、基准性、标识性和稳定性等特征的数据资源，包括人口、法人、空间地理、宏观经济

等基础数据。

3.6

专业数据库

与社会经济发展特定主题密切相关的、基于政务数据资源形成的数据资源，包括公共信用、市场监

管、救助帮扶、电子证照、地名地址等。

3.7

政务数据资源共享交换管理平台

满足各单位政务数据资源的归集、共享和管理，部署在襄阳市政务外网，采用专有云和统一的目录

系统和交换系统，建设基础数据库和专业数据库的信息技术平台。

3.8

数据共享类别

指对数据共享程度、范围的界定，分为非受限共享类数据（可供各单位无条件共享，无需数据提供

单位审核的数据）、受限共享类数据（只能按照特定方式或提供给指定对象共享的，需数据提供单位审

核的数据）、非共享类数据（依照法律、法规、规章规定不能共享，或未经脱密、脱敏处理不能共享的

数据）。

3.9

数据共享模式

指数据共享的方式，分为数据验证方式（通过调用验证服务接口进行比对，获取数据的验证结果）、

数据查询方式（通过调用查询服务接口，获取所需条件的数据结果，提供单条或多条数据包）、数据交

换方式（通过数据交换系统等方式，提供批量数据交换）。

3.10

2

DB4206/T27—2021

政务信息资源目录管理系统

通过编目、注册、发布和维护政务信息资源目录内容，实现政务信息资源管理、发现与定位的系统。

4移动应用接入概述

4.1总则

政务服务移动端系统将不同机构单位、不同标准、不同渠道的各类政务服务、公共服务事项经过聚

合、转换，形成统一标准、统一管理、统一展现的应用单元或服务接口。

4.2系统总体架构

参考国办函〔2016〕108号文件中的平台技术架构，移动政务系统总体技术架构设计全面符合国家

政务服务移动端接入的统一技术规范、安全和运维保障规范，襄阳移动政务系统总体技术架构由基础设

施层、政务服务资源、应用支撑层以及访问层组成。总体构架示意图如图1所示。

图1总体构架示意图

4.3系统功能定位

4.3.1功能定位

功能定位主要有以下几个方面：

a)统一服务入口、提升用户体验；

3

DB4206/T27—2021

b)多地区个性化服务集约化管理；

c)为移动政务应用建立统一对接、统一运维、统一推广；

d)为政务大数据共享、融合、汇聚和挖掘奠定基础；

e)打造全市政务服务移动端建设的开放生态体系。

4.3.2系统组成

政务服务移动端系统由应用接口入驻子系统、应用开放子系统、事项管理子系统、微门户管理子系

统、运营数据统计子系统组成，各系统主要情况如下：

a)接口入驻子系统：全局监管政务服务移动端系统所有政务服务应用的原始业务接口，实时监

控接口运行状况，对出现异常的接口及时预警；

b)应用开放子系统：提供丰富的开发组件，对应用的整个生命周期进行流程化管理，统一发布各

个终端；

c)事项管理子系统：通过对接襄阳市在线办事、在线预约等事项服务，自动化生成办事表单，动

态管理前端事项展示；

d)微门户管理子系统：对移动端的页面样式、栏目结构、发布信息进行管理和变更控制；

e)运营数据统计子系统：通过服务点击量、业务办理量等关键数据进行实时统计。

4.3.3功能服务

功能服务应满足以下几个方面：

a)提供标准的接口入驻方式，输出统一域名、统一接口地址；

b)提供标准的应用开发组件，保证应用体验在移动端获得一致的体验效果；

c)制定标准的应用测试、应用上下架、应用运维管理流程，确保应用质量可靠；

d)提供安全、统一的用户信息、用户认证、业务信息等敏感数据交互服务；

e)提供统一的数据运营监控服务，打造以人为中心的服务体验。

4.4应用类型

4.4.1政务服务移动应用分为需身份信息类应用和完全开放类应用。

4.4.2需身份信息类应用，按照统一对接原则，经过用户授权，统一获取政务服务移动端系统用户信

息。

4.4.3完全开放类应用无需调用用户信息，遵循统一接入流程对接各子系统。

4.5对接方式

对接方式如下：

a)接口对接：提供业务接口，按要求进行服务应用开发；

b)数据对接：提供业务数据，先开发业务接口后再进行服务应用开发。

4.6认证方式

要求所有政务服务应用均应统一采用政务服务移动端系统的用户认证体系。包括个人/法人用户的

登录、注册、生物特征识别服务能力。所有应用涉及到登录、注册、生物特征识别功能时，应直接调用

政务服务移动端系统相关界面，操作完成后跳转回本应用。

5政务服务移动端接入流程

4

DB4206/T27—2021

5.1接入流程总览

政务服务移动端接入总体流程分为应用接入、应用开发、应用审核发布三个步骤，政务服务移动端

对接流程图见图2。

图2移动政务服务应用对接流程图

5.2数据交换

县（市、区）、开发区和部门数据要求经过市数据统一交换系统，统一处理跨网业务数据。

5.3接口入驻

5.3.1概述

按照政务服务移动端系统统一对接原则，要求各县（市、区）、开发区、各部门将政务服务应用接

口注册政务服务移动端系统接口入驻子系统，对政务服务应用接口进行统一管理，统一监控，并输出标

准的接口地址。

5.3.2接口入驻流程

5

DB4206/T27—2021

接口入驻流程如下：

a)申请账号：联系政务服务移动端系统接入管理部门获取相关账号；

b)接口注册：根据业务需求，对接口进行封装改造后注册接口入驻子系统；

c)提交审核：将注册完成的接口提交审核，审核通过后即可获取标准地址；

d)测试使用：对获取的地址进行测试后，使用接口进行服务开发。

5.4应用入驻

5.4.1概述

按照政务服务移动端系统统一对接原则，要求各县（市、区）、开发区、各部门将政务服务应用前

端页面上传政务服务移动端系统应用开放子系统，对政务服务应用前端进行统一管理，统一测试，并输

出标准的页面地址。

5.4.2应用入驻流程

应用入驻流程如下：

a)申请账号：联系项目部门获取相关账号；

b)应用开发：根据技术对接标准，使用前端语言开发业务服务；

c)应用上传：将开发好的应用压缩后上传应用开放子系统；

d)应用测试：测试人员根据审核要求进行业务测试，测试通过即可生成标准的访问地址。

6政务服务移动端技术要求

6.1用户对接要求

政务服务移动端接入建立安全可靠的信息交互流程，具体流程见图3，流程如下：

a)用户授权：需身份信息类服务通过政务服务移动端系统申请；

b)授权验证：政务服务移动端系统对用户授权请求进行验证；

c)加密用户信息：政务服务移动端系统对授权用户信息进行(SM4)加密；

d)分发授权信息：将已加密的授权用户信息分发给请求方；

e)解密用户信息：请求方使用政务服务移动端系统解密方式进行解密操作。

6

DB4206/T27—2021

图3移动政务服务应用接入基于票据获取用户信息交互图

6.2接口对接要求

6.2.1接口规范注册

县（市、区）、开发区和部门要求对接口自行封装，应用接口通过接口入驻子系统进行接口注

册和管理。

接口注册时，县（市、区）、开发区和部门应填写接入应用的源接口地址和功能描述，以及相

关请求参数与返回参数。若注册的接口属于查询类，要求提供有效的测试参数。

请求方式支持get、post和webservice方式，参数支持string和integer类型。

6.2.2接口数据缓存

为保障应用的并发能力和承载高访问量，对非必需实时请求类接口，要求对接口做缓存处理，缓存

清除周期最短为24小时。

6.2.3接口安全鉴权

通过政务服务移动端系统进行互联网交互的应用要求进行接口访问鉴权，支持两种鉴权模式：

a)安全鉴权：请求签名机制，签名算法采用SM2，双方以安全方式存储接口鉴权密钥；

b)白名单鉴权：接口白名单，要求县（市、区）、开发区和部门与移动政务系统开放对接的域名，

需加入访问白名单后方可连通；

7

DB4206/T27—2021

c)应用接口请求所需的接口鉴权密钥需要加密存储，并且不可在前端页面进行调用。接口鉴权密

钥是在接口入驻子系统与业务接口交互时进行鉴权使用。

6.2.4接口功能自测

接口提交审核前，要求各县（市、区）、开发区和部门使用接口入驻子系统的在线测试工具进

行自测；

确认业务接口正常接通，确定接口返回数据格式；

接口需要满足高并发的要求，并发数应达到1000+，响应时长不超过2s；

接口需要满足安全性的要求，涉及敏感信息应进行加密或脱敏处理。

6.2.5扩展性要求

支持支付宝、微信、生物特征识别等多种应用接口开发与对接。

6.3应用开发要求

6.3.1应用安全提交

政务服务应用使用HTML5语言开发，业务接口要求调用接口入驻子系统返回的标准。

接口地址和key码，在应用审核的时候，会进行匹配审核。

县（市、区）、开发区和部门要求按照标准流程进行政务服务移动端开发，杜绝外链直接挂载。

应用代码需封装成压缩包（.zip）提交应用开放子系统。

6.3.2底部统一标识

政务服务移动端的所有页面底部都需注明“本服务由某某单位提供”。

6.3.3图形验证码使用

接入服务应用涉及到表单提交时，应加入验证码，用户登录的服务应用必须在提交表单时加入图形

验证码。若验证码影响用户体验，县（市、区）、开发区和部门可以自行决定多少次提交表单后再显示

验证码。对于图形验证码的技术要求建议如下：

a)验证码在设计上必须要考虑到相关安全因素，常见的方式是增加背景干扰元素；

b)验证码在一次使用后应立即失效，新的请求需要重新生成验证码，防止验证码多次有效。

6.3.4表单输入校验

县（市、区）、开发区和部门开发服务应用时必须对用户产生的输入内容进行校验，不能完全依赖

于政务服务移动端系统前端校验，必须使用服务端代码对输入数据进行最终校验。前端校验只能作为辅

助手段，减少前端和服务端的信息交互次数。一旦发现数据不合法，应该告知用户输入非法并且建议用

户纠正输入。一方面是为了提升用户体验，另一方面是为了防止攻击者通过输入进行SQL注入、XSS

攻击等恶意行为。

6.3.5应用模拟测试

要求县（市、区）、开发区和部门联系政务服务移动端系统支撑人员，申请开发者工具使用权

限；

要求县（市、区）、开发区和部门应用审核前，对应用进行全面测试，确保页面正常访问；

8

DB4206/T27—2021

应用中所有涉及用户基本信息、证照信息、办事信息等系统已有数据，要求自动关联数据，避

免让用户二次输入。基本的政务应用服务接口见附录一。

6.4消息推送要求

为解决业务向用户实时精准推送各类信息、服务的需求，政务服务移动端系统向接入的政务服务应

用提供了一套标准的业务消息接口，政务服务应用要求调用标准消息通知接口，以消息推送形式及时通

知到政务服务移动端系统，在政务服务移动端系统个人中心或消息模块等县（市、区）、开发区展示，

让用户在最短时间触达消息。基本的政务应用服务接口见附录A。

6.5安全保护要求

6.5.1关键信息脱敏

个人敏感信息包括身份证号、手机号、固定电话号码、邮箱、家庭住址等，所有应用都必须妥善做

好敏感信息保护。对自动获取的敏感信息，进行信息脱敏处理，做好前端展现控制，不在用户端各交互

界面传递未脱敏的用户信息，防止因账号被盗用造成个人敏感信息泄露。信息脱敏要求参照脱敏规则见

附录B。

6.5.2身份真实性控制

对于涉及用户隐私的，应仅限高级实名用户进入；如有必要，还可发起实时人脸识别身份验证。

6.5.3用户授权确认

任何需调用用户个人隐私信息的服务，必须弹出个人信息使用授权提示，说明提取信息类型和用途，

经用户确认后方可使用。

6.5.4支持HTTPS

为防止网络劫持、页面挂码等风险，要求政务服务移动端系统支持HTTPS访问，接入单位在开发

应用服务时需保证页面加载的所有资源协议支持HTTPS访问。

7政务服务移动端审核要求

7.1原则

测试人员根据测试审核要求对应用可用性、兼容性、安全性进行全方位审核，审核通过后方可发布

上架。

7.2页面要求

为保证政务服务移动端在上架后用户体验一致，县（市、区）、开发区和部门需按照要求统一页面

设计，增强用户体验。具体页面要求如下：

a)兼容性高，能够自动适配不同（主流）手机机型；

b)交互提示友好，不同使用场景下要有对应的使用引导；

c)结构布局清晰，相同类型业务数据要归类展示，不同业务数据展示方式要有区分；

d)体验流畅高效，页面数据展示延时最长不超过2s，页面切换平滑流畅；

e)操作层级简化，完整流程页面跳转最多不超过5层，精简页面流程设计。

9

DB4206/T27—2021

7.3质量要求

7.3.1服务风格统一。

所有接入的应用保持文字大小统一、图片尺寸统一、按钮规格统一、表单样式统一、加载效果统一、

底部落款统一。

7.3.2服务功能完善。

所有接入的应用在保障业务流程可行的前提下，事项办理流程简化，使用正确控件，对接用户信息，

避免二次登录，确保结果数据展示无误。

7.3.3服务体验流畅。

所有接入的应用考虑设备兼容苹果IOS系统和安卓Android系统，避免出现空白页、错链、死链等情

况。

7.3.4服务性能稳定。

所有接入的应用接口响应快，能抗压抗并发，并准备故障解决预案。

7.3.5服务安全可靠。

所有接入的应用经过安全加密、数据脱敏等处理，并支持HTTPS安全协议。

8政务服务移动端管理要求

为保障政务服务移动端系统不断接入更加优质的服务，参考国办发〔2018〕45号文件调动社会资

源力量，鼓励开展第三方便民服务应用。加强政务新媒体监管，提升服务水平。为保证线上服务运行稳

定，建议市、县（市、区）、开发区建立相应的运维保障小组，应用上下线管理包括政务服务应用兼容

性、可用性、安全性及压力测试，并对上线的政务服务应用进行统一监控，定期对服务功能、用户体验、

系统稳定、数据安全等方面对应用进行细化检查，应做到如下几点：

a)做好信息可用性监控；

b)做好服务稳定性检查；

c)对访问数据做好监测和分析；

d)求制定可行的故障应急预案；

e)做好政务服务应用版本管理。

10

DB4206/T27—2021

AA

附录A

（规范性附录）

基本Api说明及示例

A.1网络请求

名称：xyrequest

调用参数：

参数名必选类型说明

如果是相对地址，默认拼接Nginx地址，如果是绝对地址（包含http

url是string

头），则直接使用。

type是string请求的方式，post\get，默认为post。

data是jsonstring可以为空

headers是string网络请求头

返回参数：

参数名类型说明

0为成功，1001为网络请求出错，1002为移动端数据解析出错，或者为具体的网络异

codestring

常错误码，如500等。

msgstring成功时为“成功”，失败时返回异常原因。

json

data请求返回数据，正确时返回具体业务数据,失败时为空。

string

使用示例

1.AlipayJSBridge.call('xyrequest',{

2.url:'/comment/music?id=186016&limit=1',

3.type:'get',

4.data:{},

5.headers:{

6.'Content-Type':'application/json'

7.},

8.},(result)=>{