CN116633630A - 一种基于OAuth2.0的授权扩展优化的方案和系统 - Google Patents

Abstract

提供一种基于OAuth2.0的授权扩展优化的方案和系统，包括有：在业务应用中存储的可访问授权地址url列表，业务应用服务器的存同样的授权服务器列表，授权地址可以对到授权服务器；前端设备在发起请求授权url地址前的自动检测直接访问授权服务器的网络能力，判断用户设备是否需要设置专用访问通道；网络配置专门的访问通道到后端服务器以支持不能访问授权服务器的前端设备通过后端服务器访问目标授权url；前端访问授权url和后端服务器目标授权服务器表匹配，确认支持OAuth2.0流程可分在前端设备和后台服务器合作完成；支持使用OAuth里规定的可选参数实现多用户访问同一个平台或者多个平台的区分识别；完成了授权流程后的前端设备网络访问通道的配置自动清除。

Description

一种基于OAuth2.0的授权扩展优化的方案和系统

技术领域

本发明涉及授权登录技术领域，具体为基于OAuth2.0协议，根据使用环境和条件优化OAuth 2.0的实际应用，涉及了软件方法、硬件系统及电子设备。应用于大量的业务应用用户授权给该应用管理访问多个目标网站。

背景技术

全球大部分网站或者社交媒体APP通过OAuth2.0协议授权方式提供很多的API接口，方便更多的第三方代理人使用、集成它们的网络服务，使用集成的业务应用为用户提供服务。

由于众多的用户同时使用业务应用的诉求，还有集成众多目标网站的诉求。所以在实际业务应用中需要创新和优化OAuth2.0协议的使用方法。

再由于用户设备所在的网域不同，在不同网域的用户设备访问目标网授权受限，创新可以使用的授权流程方案，本发明需要解决的就是使用普遍的OAuth2.0流程，解决不同网域的OAuth2.0授权访问权限，使它满足符合当前网络实际使用环境。

对于业务应用需要开放给更多的用户使用，所以本发明的优化，在OAuth2.0的协议中找到如何开放给更多用户使用的方法。

发明内容

本发明的主要目的在于提供一种基于OAuth2 .0协议的授权登录方法及系统，以解在一些环境下登录有的困难。

图1中Client在协议中确定是一个业务Application，它运行硬件系统是未指明的，在本发明中的硬件系统由用户的终端设备和后台服务器组成。

图1中的OAuth2.0协议中步骤（A）和（B）需要用户终端设备主要就是提供用户输入和确认，本发明确保用户设备访问授权服务器的能力。

图1中User-Agent在业务应用上设置，安装有业务应用的用户终端设备需具有访问授权服务器（Authorization Server）的能力，才能发起授权协议的步骤（A）：开始一个用户代理授权请求和步骤；（B）：接收Authorization Server的响应和输入登录信息。

图1中对于每个目标网站都只设置一个Redirection URI，如果是多个业务应用的用户需要利用本应用访问同一个目标网站，需要解决授权服务器发回的Authorizationcode和Access Token不会混淆。

为了实现上述目的，本发明的第一方面提供了一种基于OAuth2 .0协议的授权登录方法，包括：

本发明的OAuth2.0中的User-Agent与授权服务器请求由业务应用的用户发起，用户发起请求，在业务应用中通过按键形式显示一张请求url列表，当监控到用户进入表格页面读取授权url时，业务应用自动检测终端设备访问目标授权服务器的能力，如果检测到不能访问授权服务器，则开始配置网络提供专用访问通道，帮助用户终端访问目标授权服务器。

见上条，提供帮助用户访问授权通道，本发明在用户终端设备到授权服务器之间利用应用的后台服务器做一个特别通道，可以在用户终端设备不能访问授权服务器的情况下提供网络的访问能力，在实现技术上可以是多种形式的，比如虚拟专用网络（VPN）、网络代理（http proxy）和其它技术，该服务功能实体上可以和业务应用后台服务器一体的。

图1中从完成用户设备的输入和访问权限的确认，从（C）步骤开始，所有的授权流程不需要业务应用用户参与，这部分流程可以不在用户终端设备上处理，授权服务器重定向到先前请求中设置好的参数redirect_uri，该redirect_uri是设置到业务应用的服务器上。

授权流程从重定向到后台服务器后，直到最后完成授权以获得Access Token所有的步骤流程全部在业务应用的服务器器上实现，Access Token也存于服务器上，并且可以利用目标网站的API开始访问网站资源。

为了使在前端服务器发起的授权流程能在前端设备上和后台服务器上分别完成，需要保证配置在前端中请求url列表和后台服务器访问目标授权网站的能力列表一致，通过前端选择授权地址url，后台服务器匹配答复前端方式，确保不出现前端请求的授权url地址超出后台服务器访问能力范围。

在用户终端设备的业务应用中，请求授权获得Access Token目的就是需要用到一些目标网站的API，本发明在授权访问的流程后就可以清除访问配置，由业务应用的后台系统使用Access Token帮助用户开始资源访问。

业务应用是开放给多用户使用的，需要解决不同用户请求Access Token的识别问题；同时业务应用应该是可以运用同样方法访问多个不同的Authorization Server的，所以解决不同目标网的识别问题。

请求中需要设置回调地址参数redirect_uri地址接收Authorization Server的响应，回调地址在多用户的情况下，但是一个目标网络只能设置采用同一个redirect_uri，每一个访问这个目标网的用户都在这个回调地址中获取token，所以需要在请求必须带有用户识别码和目标网站标识。

为了实现业务应用可以给多用户使用和融合多个平台，本发明利用OAuth2.0中可选参数state，在请求中实现用户的识别和访问目标网络识别。可以基于该技术扩大业务应用的用户范围。

用户确认权限后，业务应用就中断用户设备和目标网站服务器的访问权限，也就是图1的步骤B后的流程全部由业务应用的后台服务器完成；可选地，所述中断用户设备到目标网站服务器访问权限可以放在完成整个OAuth2.0授权流程。

业务应用使用Access Token开始访问目标网站的资源服务器，使用用户的授予的权限访问用户在资源服务器上的资源，根据授予权限，可以编辑、删除、发布等等活动。

发明设计了一种可用的用户授权流程方案，它包含有以下主要能力：

OAuth2.0协议授权流程的Client没有清楚定义运行要求硬件系统，实际应用中都是单设备完成全部流程，本发明首次使用前端和后台服务器分开处理方式。

终端设备应用发起了授权流程，通过使用规定操作步骤，保障授权的前端设备和后台服务器访问能力一致，以最终保障每次授权流程都可以执行完整。

根据终端设备网络访问能力，可以采用多种的服务器中间代理技术，如VPN或者proxy或者私有的代理等技术，使业务应用可以获得授权，但是在业务API使用时独立于授权，不需要网络服务器代理。

本发明中重要的使用OAuth2.0协议的选择性参数，设定了用户识别和平台识别组合，便于了业务应用的可以开放给所有用户使用。

组合以上创新点，就可以利用本发明开发新的服务用户的应用，把原来完全不能用到社交媒体网站合理地开放给业务应用用户使用。使许多的用户在中国现在的网络环境下安全地访问用户终端设备网域外的网络，最后实现直播视频推送、视频管理、直播等业务功能。

附图说明

为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1 OAuth 2.0协议的代理用户授权流程；

图2 改进后的OAuth2.0协议授权登录系统流程图；

图3 使用同一个Redirect_uri重定向的State参数使用；

图4 为本发明中提供一种配置授权网络访问能力流程图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的图2授权登录系统框图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是本说明书的授权服务器和Authorization Server都是指目标的网的授权中心。

业务应用采用OAuth2.0协议访问其它网域的网站以获取服务的时候，问题点就在于如何获得用户授权，在用户终端设备是否有网络访问能力可以支持OAuth2.0授权流程，并且如何在实际操作实现授权，一个用户同时访问多个不同的授权目标和多个用户如何同时访问同一个授权平台？创新方法实现它可以访问一些这些网站，且又不带来风险的，是我们具体实施的原则。

可以结合图2：改进后的OAuth2.0协议授权登录系统流程来说明。

为了解决上面问题，Client的应用的运行硬件系统设备上，需要把为客户端处理OAuth2.0授权流程的设备灵活处理，本实施时候采用一部分为业务应用的用户终端设备，如手机、pad等终端和用户可以使用、操作的带输入设备，包含各类直播设备，其中的Client的业务应用前端部分就运行在这个设备上；另外一部分为支持OAuth2.0授权后的业务应用服务器。

访问的硬件系统上分成了两个部分处理，就需要去匹配前端和后台服务器访问目标授权服务能力，本发明实施引入了前端的预存入授权服务器url地列表，后台的服务器配置好包含前端授权url地址的列表，保证前端发起访问时候的范围不超过后台服务器访问能力范围。

从上图2步骤1之前，本发明在业务应用里添加一个保存的访问授权服务器url列表——见图5，用列表实际限制了访问范围，匹配后台服务器的访问能力。

这个列表是由服务器访问能力更新的，服务器在特定时段去自动测试本身能获取哪些授权服务器访问能力。

如图4的步骤1用户在业务应用中进入可访问的服务器地址列表，通过对应的图标按键，选择了一个授权服务器地址。

如图4的步骤2.1和2.2应用前端需要做两个事情，应用前端马上把选择的地址送到服务器中去，请服务器确认是否能访问该url地址，判断前端设备是否能访问授权服务器地址

服务器中也预存了一张访问授权服务器的能力表格，服务器通过检索表格，匹配应用前端发过来的地址，给前端访问能力回复。

在加载url前，如图4步骤2.2如果用户的终端设备没有访问目标网络能力时，业务应用先通过配置网络配置方式使终端设备能够访问到目标网络授权服务器。

配置访问目标授权服务器方式有很多种，可以是http proxy、也可以是专用虚拟网，或者是其它的私有协议的方式，也就是在业务应用的前端设备到后台服务器之间建立一个通道，这个通道使得后台服务器可以利用自身能力帮助前端设备访问目标网的授权服务器。

见图4的步骤2.2到2.2.1如果前端设备有访问授权服务器能力，还是需要把请求的url地址和后台服务器访问能力列表做匹配，但是就可以跳过网络配置步骤，直接开始请求授权服务器，

见图4，如果是需要网络配置情况下，步骤2.2.1完成网络配置，确认了前端设备和服务器设备有相同的授权服务器访问能力，用户需要使用业务应用授权，首先在业务应用里创建WebView（iOS：WKWebView；Android ：android.webkit.Webview）以显示请求内容，使用load方法去请求授权url，这里load的url地址必须来自于下图5中的表。

在完成图4中的流程步骤4后，用户确认授权后，OAuth2.0协议重定向到服务器后，后台服务器可以继续和授权服务器完成授权流程的步骤。

在业务应用中检测到配置网络完成后，用户终端设备使用WebView中的load方法，准备发起对Authorization Server的request访问，其中使用请求中的重定向参数redirect_uri用来接收Authorization Server对Agent request的返回response，在业务应用中对应一个请求目标网络只有一个redirect_uri。

如果多个业务应用的用户请求同一个业务应用的授权服务器，redirect_uri中接收的信息，就是针对与不同用户的，所以需要区分同一个redirect_uri中的信息属于是哪个用户和来自于哪个目标网的。

在本发明中利用OAuth2.0规定的参数state，通过对每个用户和请求的每个平台设定唯一加密state参数，通过这个参数识别出对应业务应用的用户的账号的AccessToken。

如图3，每次去请求目标网的服务器时候，生成业务应用的用户识别码，同时还需要生成对访问不同的目标网标识，把用户识别码和目标网标识打包在state参数中，以统一的格式发出去，然后在同一个redirect_uri地址中接收回来。根据OAuth.2协议，在完成图2中步骤3时候，就可以开始步骤4，用Authorization code去请求token时候，在业务应用侧在接收到一个access token就可以判断是对应业务应用的唯一确定用户。

见图4，在业务应用的用户确认了授权范围后，也就在步骤4后，可以断开步骤2.2.1中用户设备到目标网站的访问能力，也就是可以停止到业务后台服务器的虚拟专用网络或者proxy等，清除各种网络访问能力的配置，授权的后续动作由业务应用的服务器和授权服务器完成，图2中给出的是服务器完成了各种授权，获取后台开用户设备访问设置。

授权流程在redirect_uri中获得的用户获取了access token后，这个token被存于业务应用的服务器上，业务应用的用户可以这个access token发起不同的业务服务要求。

当业务应用的用户在设备上需要开始实际业务，用户先调用业务应用的服务器端口，业务应用服务器获得端口请求，把业务请求分解成对实际目标网站的API调用集，再使用户对应的access token去调取用户想要访问的目标网站，把用户的业务流转发到请求目标网站的API地址。这种方式就可以使用户设备不需要访问目标网站的网域能力，就可以操作和管理这些网站上的内容。

这样优化的OAuth2.0授权流程和使用方法，使没有业务网站访问能力的终端用户，可以利用业务应用提供的能力，做一些合理的内容发布；也可以用于业务应用帮助管理多个用户，且可以管理多个不同的需要授权的网站。

本发明的产品中使用情况可能很多：

在产品中的应用可以使用的硬件方式不同，例如可以使用在手机，平板终端，pc和各种终端类的直播工具。

从后台服务器上，可以使用一台物理服务器上做授权工作，也可以在不同的物理服务器上部署不同的功能完成这这个优化的OAuth2.0流程。

业务应用的服务器端是已经配置，或者不需要配置就可以访问设定的授权服务器。

在访问上，我们使用了预先存表格的形式让业务应用的选择访问的目标网站，表格保存方式可以是在应用的前端软件包，也可以是存于应用的后台服务器上。

各种的预存了目标网站的授权url的表格方案，并且把前端的访问url送到后台服务器上比对，确认前端应用设备和后台服务器的网络访问能力一致的手段有多种形式，都是本发明的衍生方案。

在配置终端设备访问其它网域的访问能力时候，可以使用限制普遍使用的虚拟专用网络和http proxy技术，也可以使用其它的协议方式。不局限于本文档提到的技术方式。

对于本发明，最重要的是对于OAuth2.0的请求参数state使用，是本发明首先创新用于识别业务应用的用户同时识别访问的目标网站，但其实可以在state参数增加部分新内容，也属于本发明的要求范围内。

虽然结合附图描述了本发明的实施方式，但是本领域技术人员可以在不脱离本发

明的精神和范围的情况下做出各种修改和变型，这样的修改和变型均落入由所附权利要求所限定的范围之内。

Claims (10)

1.一种基于OAuth2.0协议的授权登录方法的优化，其特征在于、包含：使用OAuth2.0协议授权业务应用访问第三方目标网站的授权流程可以使用如下方法去扩展：

a）使用用户终端设备（如手机和其它用户访问网站设备、下同）完成需要用户输入和确认的步骤，使用业务应用后台服务器处理不需要用户参与的步骤，用户设备和服务器构成授权登录的硬件系统;

b）业务应用在前端预存授权地址控制表格，后端生产访问授权服务表格，匹配系统的前后端能力，保障授权协议的流程可以在前端设备和后台服务器上配合完成；

c）业务应用请求url地址前，需要先检查网络直接访问授权服务器能力，需要时候可以配置专门访问通道到后台服务器，确保网络可以访问到选定url服务器；

d）检测配置网络后，在用户设备上处理OAuth2.0协议的前面需要用户输入和按键确认的步骤，其它授权流程步骤转入到应用的后台服务器上处理，前面的网络配置部分可以清除；

e）在后台上需要处理多个应用用户请求使用同一个redirect_uri的诉求，使用OAuth2.0协议可选state参数编辑唯一用户识别码，通过协议返回的state参数确认Redirect_uri的返回值是对于哪个应用用户；

f）同时扩大地在OAuth2.0协议中的state参数可以编辑访问的授权目标网识别码，通过它，整个业务用于可以设计请求更多的不同的目标网的授权。

2.根据权利要求1中b）所述的方法，其特征在于，预先由一个存于应用前端或者服务器上的表格作为请求url来源，应用中不提供输入url地方或者不通过自带浏览器输入。

3.根据权利要求1中b）所述的方法，其特征在于，应用的服务器预先生产一个可以访问的授权服务器列表，以供前端访问时候查询匹配，以确认前端设备和后台服务器有同样的访问能力去配合完成全部的授权流程，且以后台服务器的为标准。

4.根据权利要求1中c）所述的方法，其特征在于，业务应用接收到用户的授权请求，业务应用能替代用户去检测网络访问能力，确定用户是否需要配置专用访问通道，来帮助用户在业务应用上完成授权。

5.根据权利要求1中c）所述的方法，其特征在于，配置专用的通道支持业务应用前端访问后台服务器，支持其完成http(https)的请求访问，通道配置方式有多种协议。

6.根据权利要求1中d）所述的方法，其特征在于：终端设备上的业务应用和目标网站的授权服务器的建立的临时访问通道上只承载流程的发起授权请求和用户登录输入与用户确认（需要用户参与确认的流程步骤）部分。

7.根据权利要求1中d）所述的方法，其特征在于，对于OAuth2.0的访问流程，业务应用的后台服务在用户完成授权确认后承接授权服务器的重定向，接受Authorization code交换和完成获得Access Token，用前端的请求授权url表和后端服务器访问授权url服务器能力表来保障分开处理的成功。

8.根据权利要求1中d）所述的方法，其特征在于：完成用户登录和确认的流程后，业务应用主动隔离用户断开终端设备和目标网站授权服务器的访问能力，清除网络配置。

9.根据权利要求1中e）所述的方法，其特征在于：使用了OAuth2.0协议规定的可选参数state绑定业务用的不同用户的唯一标识和访问的不同平台标识，是这种方式的使用，业务应用用于多用户同时访问授权时，在同一个回调地址redirect_uri可以区分不同用户请求获得的数据。

10.根据权利要求1中（f）所述的方法，其特征在于：可选参数state的使用，也可以区分来自于哪个目标网授权服务器的响应，包含了用户标识和平台标识后，再为state参数增加部分新内容，都属于权利要求范围之内的应用情况。