(19)中华 人民共和国 国家知识产权局 (12)发明 专利申请 (10)申请公布号 (43)申请公布日 (21)申请 号 202111495633.0 (22)申请日 2021.12.09 (71)申请人 江苏网进科技股份有限公司 地址 215300 江苏省苏州市昆山市玉山 镇 登云路288号 (72)发明人 李参宏　陈力　韩平军　 (74)专利代理 机构 苏州佳博知识产权代理事务 所(普通合伙) 32342 代理人 罗宏伟 (51)Int.Cl. H04L 9/40(2022.01) H04L 67/02(2022.01) (54)发明名称 一种基于Oauth协议的门户系统用户共享方 法 (57)摘要 本发明公开了一种基于Oauth协议的门户系 统用户共享方法， 包括准入应用认证， 以及在 Oauth协议的基础下密钥分发； 提供web服务层， 供预定待接入本共享用户体系的应用提供申请 入口， 待审核后， 分发其应用身份和密钥， 并由用 户保存； 其中， web服务层对接入 方的密钥由随机 字符串变更为A ES字串密钥， 在https协议的通信 基础上， 对消息整体通过AES 对称算法进行加密； 消息进入web服务层之后， web服务层对消息进行 AES解密处理， 并向内网推送已签名的明文数据； 应用程序接口对明文数据授权鉴权以及调用； 登 录授权。 有益效果在于黑客没有办法对所获取到 进行AES加密的信息， 因此在重发该信息的时候 会被web服 务拦截， 提高服 务安全性。 权利要求书1页 说明书4页 CN 114301634 A 2022.04.08 CN 114301634 A 1.一种基于Oauth协议的门户系统用户共享方法， 其特 征在于， 其 步骤为： S1， 准入应用认证， 以及 在Oauth协议的基础下密钥分发； 提供web服务层， 供预定待接入本共享用户体系的应用提供申请入口， 待审核后， 分发 其应用身份和密钥， 并由用户保存； 其中， web服务层对接入方的密钥由随机字符串变更为 AES字串密钥， 在https协议的通信基础上， 对消息整体通过AES对称算法进行加密； 消 息进 入web服务层之后， web服 务层对消息进行AES解密处 理， 并向内网推送已签名的明文数据； S2， 应用程序接口对明文数据授权鉴权以及调用； S3， 登录授权 。 2.如权利要求1所述的基于Oauth协议的门户系统用户共享方法， 其特征在于： 所述应 用身份为 一个16‑byte的UUID， 算法是基于 机器的网卡， 当地时间， 以及随机数生成。 3.如权利要求1所述的基于Oauth协议的门户系统用户共享方法， 其特征在于： 所述密 钥为256位的AES算法key的base64编码值。 4.如权利要求1所述的基于Oauth协议的门户系 统用户共享方法， 其特征在于： 上述S2 步骤中， 当准入应用经过审核获取了应用身份和密钥过后， 当用户提出申请， 通过client Id 验证用户是否为标识用户； 通过验证用户的合法性； 通过域名验证其来源的方式， 确认是否 对请求访问的接口进行授权， 若均验证通过， 则在Oauth协议的基础下通过用户申请授权 。 5.如权利要求4所述的基于Oauth协议的门户系统用户共享方法， 其特征在于： 准入应 用通过https  get请求获取临时准入令牌， Oauth协议对准入令牌进行了保护， 该令牌在预 设时间内是唯一， 用于确认授权应用请求的准入， 降低secret 暴露的风险； 准入应用在请求 中携带临时准入令牌， 并准予调用。 6.如权利要求5所述的基于Oauth协议的门户系统用户共享方法， 其特征在于： 其调用 步骤包括： S21： 通过准入令牌生成二维码， 生成随机字符串作为redis  key， redis  key过期时间 作为二维码的超时时间， 将更新该缓存的接口连同该redis  key， 作为二维码内容返回前 台； S22： 根据用户扫 描二维码信息， 二维码触发更新接口， 将对应key的内存形键值存储数 据库缓存的value 更新为已扫码； S23： 根据获取的已扫码信息， 进行信息登录， 并跳转确认页面， 更新 二维码状态； S24： 轮询请求二维码状态， 超时返回状态， 根据返回的二维码状态执行响应的操作， 超 时状态结束轮询重新发起登录流 程。权　利　要　求　书 1/1 页 2 CN 114301634 A 2一种基于 Oauth协议的门户系统用户共享方 法 技术领域 [0001]本发明涉及用户体系共享， 尤其涉及一种基于Oauth协议的门户系统用户共享方 法。 背景技术 [0002]现有技术中， 通过企业信息化建设来满足企业在生产经营过程中所碰到的问题， 由于管理职能的划分和组织细化， 绝大部 分公司会将一些完整的业务链划分为一个个独立 的企业管 理系统， 如资源规划(ERP)， 客户关系管理(CRM)， 供应链管 理(SCM)等。 但随着企业 信息化进程的深入， 各个系统开发时间的落差， 开发队伍的经验， 服务范围的限制， 开发平 台的不统一 等问题正在逐渐制约信息系统间的兼容 性和集成性问题。 [0003]其中最主要的问题是， 不同系统， 不同应用， 不同技术平台， 构成了一个个 “信息孤 岛”， 使得企业本身深 陷其中， 这一问题不会随着企业信息化水平的提高而有所改善， 反而 会由于企业引入更多的应用系统而不断恶化。 其中尤其以不同业务系统中维护的用户信息 最为严重， 高层管理人员有时不得不维护大量的管理员账号， 而用户体系的不统一也会直 接导致业务流在不同系统中的流 转困难， 制约企业的行政效率。 [0004]Oauth作为下一代的 “用户验证和授权 ”标准， 现有技术基于O auth协议的门户系统 用户共享处 理流程大致如下， 以密码模式为例： [0005]首先， 接入方申请接入授权， 供应方下发应用身份(appId)和密码(Secret)， 两者 均是随机 字符串， 前者用于表示用户的身份， 后者则作为密码的概念校验用户的准入。 [0006]然后， 接入方申请或购买应用方的部分服务功能， 由供应方下发对应功能的资源 标识(SecretId)和密钥(SecretKey)， 其中SecretId作为随机字符串用于对应用户所拥有 并使用的资源标识， SecretKey则是非对称加密算法的密钥部分， 用于对用户信息请求进 行 防篡改， 防抵 赖。 [0007]上述流程要求在 https协议下完成传 输， 因为https能保证在网络上的通信是加密 的。 [0008]https(全称： Hyper  Text Transfer  Protocol  over SecureSocket  Layer)是以 安全为目标的HTTP通道， 在HTTP的基础上通过传输加密和身份认证 保证了传输过程的安全 性。 [0009]由此可以看出， Oauth协议是严重依赖https的， 假设https被破解， 将会直接暴露 appid(应用身份)、 以及secretId。 secretKey由于不参与网络传输 所以显得相对安全。 然而 secretKey的作用仅 仅是对请求的字段以及时间戳说验证操作。 这 就给了攻击者可乘之机 。 [0010]故， 有必要提出一种基于Oauth协议的门户系统用户共享方法来 解决上述问题。 发明内容 [0011]针对上述提出的问题， 本发明目的在于提供一种基于Oauth协议的门户系统用户 共享方法， 用以提高服 务安全性。说　明　书 1/4 页 3 CN 114301634 A 3