CN117834158A - 授权信息获取方法、装置、相关设备及存储介质 - Google Patents
授权信息获取方法、装置、相关设备及存储介质 Download PDFInfo
- Publication number
- CN117834158A CN117834158A CN202211190334.0A CN202211190334A CN117834158A CN 117834158 A CN117834158 A CN 117834158A CN 202211190334 A CN202211190334 A CN 202211190334A CN 117834158 A CN117834158 A CN 117834158A
- Authority
- CN
- China
- Prior art keywords
- application
- service
- request
- authorization information
- user
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000013475 authorization Methods 0.000 title claims abstract description 217
- 238000000034 method Methods 0.000 title claims abstract description 117
- 230000015654 memory Effects 0.000 claims description 46
- 230000006854 communication Effects 0.000 claims description 39
- 238000004891 communication Methods 0.000 claims description 38
- 238000012795 verification Methods 0.000 claims description 22
- 238000004590 computer program Methods 0.000 claims description 19
- 230000004044 response Effects 0.000 claims description 19
- 230000007246 mechanism Effects 0.000 claims description 14
- 235000014510 cooky Nutrition 0.000 description 15
- 230000008569 process Effects 0.000 description 15
- 101100055496 Arabidopsis thaliana APP2 gene Proteins 0.000 description 11
- 101100016250 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) GYL1 gene Proteins 0.000 description 11
- 238000010586 diagram Methods 0.000 description 10
- 101150053844 APP1 gene Proteins 0.000 description 9
- 101100189105 Homo sapiens PABPC4 gene Proteins 0.000 description 9
- 102100039424 Polyadenylate-binding protein 4 Human genes 0.000 description 9
- 230000001360 synchronised effect Effects 0.000 description 9
- 230000006870 function Effects 0.000 description 8
- 238000012545 processing Methods 0.000 description 7
- 230000003993 interaction Effects 0.000 description 5
- 238000012546 transfer Methods 0.000 description 5
- 210000004899 c-terminal region Anatomy 0.000 description 4
- 235000019800 disodium phosphate Nutrition 0.000 description 4
- 230000005291 magnetic effect Effects 0.000 description 4
- 230000003068 static effect Effects 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 2
- 230000009191 jumping Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 101100264195 Caenorhabditis elegans app-1 gene Proteins 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000005294 ferromagnetic effect Effects 0.000 description 1
- 230000004807 localization Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Telephonic Communication Services (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
本申请公开了一种授权信息获取方法、装置、第一设备、第一业务平台及存储介质。其中，方法包括：第一设备上被使用的第一应用向第一业务平台发送第一请求，所述第一请求用于请求获取授权信息，所述授权信息用于所述第一设备上的第二应用被使用时验证用户的身份，所述第二应用为所述第一应用关联的应用；所述第一应用接收所述第一业务平台发送的授权信息；所述第一应用将接收的授权信息发送给所述第二应用。本申请提供的方案，能够实现不同应用场景下的授权登录服务。
Description
技术领域
本申请涉及通信领域，尤其涉及一种授权信息获取方法、装置、相关设备及存储介质。
背景技术
在应用浏览器/服务器(B/S，Browser/Server)架构的场景下，用户通过浏览器登录主应用后，可以通过主应用提供的接口访问第三方应用，而在用户访问第三方应用的过程中，第三方应用可以根据浏览器中用户的会话(session)获取一个用于用户登录第三方应用的授权码，从而实现用户在第三方应用上的自动登录。比如，在单点登录(SSO，SingleSign On)服务场景下，用户通过浏览器登录A应用后，浏览器和SSO服务共享A应用登录后的session；当用户通过A应用提供的入口访问B应用时，B应用携带session访问SSO服务，并从SSO服务获取授权码，利用获取到的授权码实现用户自动登录B应用。
然而，在应用客户机/服务器(C/S，Client/Server)架构的场景下，第三方应用如何获取授权码，是目前亟待解决的问题。
发明内容
为解决相关技术问题，本发明实施例提供一种授权信息获取方法、装置、相关设备及存储介质。
本发明实施例的技术方案是这样实现的：
本申请实施例提供一种授权信息获取方法，应用于第一设备，包括：
所述第一设备上被使用的第一应用向第一业务平台发送第一请求，所述第一请求用于请求获取授权信息，所述授权信息用于所述第一设备上的第二应用被使用时验证用户的身份，所述第二应用为所述第一应用关联的应用；
所述第一应用接收所述第一业务平台发送的授权信息；
所述第一应用将接收的授权信息发送给所述第二应用。
上述方案中，所述方法还包括：
所述第一应用获取用户登录所述第一应用的上下文信息；所述第一请求包含所述上下文信息，所述上下文信息用于所述第一业务平台对用户的登录相关信息进行校验。
上述方案中，所述第一应用获取用户登录所述第一应用的上下文信息，包括：
响应于针对所述第一应用的登录操作，所述第一应用向所述第一业务平台发送第二请求，所述第二请求用于请求获取所述上下文信息，所述第二请求包含登录所述第一应用的用户的身份信息；
所述第一应用接收所述第一业务平台针对所述第二请求发送的上下文信息。
本申请实施例还提供一种授权信息获取方法，应用于第一业务平台，包括：
所述第一业务平台的第一服务接收第一设备上被使用的第一应用发送的第一请求，所述第一请求用于请求获取授权信息，所述授权信息用于所述第一设备上的第二应用被使用时验证用户的身份，所述第二应用为所述第一应用关联的应用；
响应于所述第一请求，所述第一服务从所述第一业务平台的第二服务获取所述授权信息，并向所述第一应用发送所述授权信息。
上述方案中，所述第一请求包含用户登录所述第一应用的上下文信息，所述方法还包括：
基于所述上下文信息，所述第一服务对用户的登录相关信息进行校验，并在校验通过的情况下，响应于所述第一请求，从所述第二服务获取所述授权信息。
上述方案中，所述方法还包括：
所述第一服务接收所述第一应用发送的第二请求，所述第二请求用于请求获取所述上下文信息，所述第二请求包含登录所述第一应用的用户身份信息；
响应于所述第二请求，所述第一服务向所述第一应用发送所述上下文信息。
上述方案中，所述响应于所述第一请求，从所述第二服务获取所述授权信息，包括：
所述第一服务向所述第二服务发送第三请求，所述第三请求用于请求获取所述授权信息，所述第三请求包含所述第二应用的身份相关信息；
基于所述身份相关信息，所述第二服务对所述第二应用的身份进行校验，并在校验通过的情况下，向所述第一服务发送所述授权信息。
上述方案中，所述第一服务和所述第二服务基于安全机制进行通信。
本申请实施例还提供一种授权信息获取装置，包括：
第一发送单元，用于所述第一设备上被使用的第一应用向第一业务平台发送第一请求，所述第一请求用于请求获取授权信息，所述授权信息用于所述第一设备上的第二应用被使用时验证用户的身份，所述第二应用为所述第一应用关联的应用；以及，所述第一应用将接收的授权信息发送给所述第二应用；
第一接收单元，用于所述第一应用接收所述第一业务平台发送的授权信息。
本申请实施例还提供一种授权信息获取装置，包括：
第二接收单元，用于所述第一业务平台的第一服务接收第一设备上被使用的第一应用发送的第一请求，所述第一请求用于请求获取授权信息，所述授权信息用于所述第一设备上的第二应用被使用时验证用户的身份，所述第二应用为所述第一应用关联的应用；
第二发送单元，用于响应于所述第一请求，所述第一服务从所述第一业务平台的第二服务获取所述授权信息，并向所述第一应用发送所述授权信息。
本申请实施例还提供一种第一设备，包括：第一通信接口及第一处理器；其中，
所述第一处理器，用于利用所述第一通信接口使所述第一设备上被使用的第一应用向第一业务平台发送第一请求，所述第一请求用于请求获取授权信息，所述授权信息用于所述第一设备上的第二应用被使用时验证用户的身份，所述第二应用为所述第一应用关联的应用；以及，
利用所述第一通信接口使所述第一应用接收所述第一业务平台发送的授权信息。
本申请实施例还提供一种第一业务平台，包括：第二通信接口及第二处理器；其中，
所述第二通信接口，用于所述第一业务形态的第一服务接收第一设备上被使用的第一应用发送的第一请求，所述第一请求用于请求获取授权信息，所述授权信息用于所述第一设备上的第二应用被使用时验证用户的身份，所述第二应用为所述第一应用关联的应用；
所述第二处理器，用于响应于所述第一请求，所述第一服务从所述第一业务平台的第二服务获取所述授权信息，并利用所述第二通信接口向所述第一应用发送所述授权信息。
本申请实施例还提供一种第一设备，包括：第一处理器和用于存储能够在第一处理器上运行的计算机程序的第一存储器；
其中，所述第一处理器用于运行所述计算机程序时，执行上述设备侧任一方法的步骤。
本申请实施例还提供一种第一业务平台，包括：第二处理器和用于存储能够在第二处理器上运行的计算机程序的第二存储器；
其中，所述第二处理器用于运行所述计算机程序时，执行上述平台侧任一方法的步骤。
本申请实施例还提供一种存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现上述设备侧任一方法的步骤，或者实现上述平台侧任一方法的步骤。
本申请实施例提供的授权信息获取方法、装置、相关设备及存储介质，第一设备上被使用的第一应用向第一业务平台发送第一请求，所述第一请求用于请求获取授权信息，所述授权信息用于所述第一设备上的第二应用被使用时验证用户的身份，所述第二应用为所述第一应用关联的应用；所述第一应用接收所述第一业务平台发送的授权信息；所述第一应用将接收的授权信息发送给所述第二应用。本申请实施例提供的方案，主应用(即第一应用)从主应用的业务平台(即第一业务平台)获取授权信息，并将获取的授权信息传递给第三方应用(即第二应用)，从而实现了C/S架构下，第三方应用对授权信息的获取，进而实现C/S架构下用户在第三方应用的自动登录；同时，由于不需要基于session获取授权信息，因此能够应用于不支持session的场景中，从而能够适用于包括B/S、C/S在内的不同应用场景。
附图说明
图1为相关技术中实现SSO服务的授权协议示意图；
图2为相关技术中基于B/S架构的SSO服务系统架构示意图；
图3为基于B/S架构的SSO服务系统登录的方法流程示意图；
图4为本申请实施例第一种授权信息获取的方法流程示意图；
图5为本申请实施例第二种授权信息获取的方法流程示意图；
图6为本申请实施例第三种授权信息获取的方法流程示意图；
图7为本申请应用示例SSO服务系统架构示意图；
图8为本申请应用示例SSO服务方法流程意图；
图9为本申请实施例一种授权信息获取装置结构示意图；
图10为本申请实施例另一种授权信息获取装置结构示意图；
图11为本申请实施例第一设备结构示意图；
图12为本申请实施例第一业务平台结构示意图；
图13为本申请授权信息获取系统结构示意图。
具体实施方式
下面结合附图及实施例对本申请再作进一步详细的描述。
在SSO服务的应用场景下，当用户登录了主应用后，利用从SSO服务获取的授权码，即可安全地访问第三方应用，由于无需用户再次登录，因此能够避免用户重复登录造成的体验较差的问题，其中，主应用可以是与主应用同属一个业务平台的应用，也可以是主应用的业务平台之外的应用。在此过程中，为了解决SSO服务场景下的通信安全问题，相关技术中，可以利用图1所示的中央认证服务(CAS，Central Authentication Service)、OAuth2.0、OIDC(英文可以表达为Open ID Connect)、安全断言标记语言(SAML，SecurityAssertion Markup Language)等多种授权协议实现SSO服务；从图1可以看出，其中，OAuth2.0是安全性最高、应用最为广泛的授权协议之一。
相关技术中，SSO服务通常基于session实现，因此主要适用于如图2所示的具有session服务的B/S架构；具体地，如图3所示，在应用B/S架构的场景下，基于OAuth2.0协议实现SSO服务的过程包括：
步骤1：用户采用SSO服务提供的方法登录主万维网(Web)服务(也就是主应用)；也就是说，用户登录主Web后，SSO服务将记录用户访问主Web服务的session；
这里，当用户成功登录主Web服务后，SSO服务通过储存在用户本地终端上的数据(即Cookie)记录用户访问主Web服务的session和session登录状态等信息，主Web服务的前端和SSO服务之间通过cookie实现了session共享，在此之后，主Web服务对SSO服务发起的访问请求均会携带共享的session。
步骤2：用户在主Web服务界面点击三方Web服务(也就是第三方应用)入口，浏览器跳转到三方web服务的统一资源定位系统(URL，Uniform Resource Locator)，发起对三方Web服务的访问请求；
其中，浏览器对三方Web服务发起访问请求中不携带任何与OAuth2.0相关的信息，包含授权码。
步骤3：三方Web服务通过浏览器访问SSO服务的OAuth授权服务器(Auth Server)，从Auth Server获取授权码；
其中，三方Web服务访问SSO服务时，向SSO发送的访问请求中携带了共享的session；由于浏览器cookie中记录了session和session登录状态等信息，因此，当SSO服务接收到三方Web服务发送的访问请求时，能够根据cookie判断出访问请求中携带的session已存在且已登录，因此，SSO服务不再引导用户进行登录，而是直接为三方Web服务颁发授权码，也就是向三方Web服务发送基于OAuth2.0协议定义的授权码。
步骤4：三方Web服务将授权码传递到三方业务平台(比如，提供三方Web服务的服务器)；
步骤5：三方业务平台利用授权码从Auth Server获取基于OAuth2.0协议的访问令牌(Access Token)；
步骤6：三方业务平台采用AccessToken从SSO服务的OAuth资源服务器(ResourceServer)获取已登录主Web服务应用的用户信息；
这里，步骤4至步骤6是按照OAuth2.0协议定义的流程进行的，也就是说，SSO服务利用OAuth2.0协议定义了利用授权码获取用户信息的流程，当三方Web服务获取到授权码后，将按照OAuth2.0协议定义的流程执行后续流程。
步骤7：三方业务平台利用获取的用户信息，为用户进行局部登录；
也就是说，三方业务平台根据获取的用户信息实现用户在三方业务平台的自动登录，也就是进入三方业务内部的登录管理，建立三方Web服务和三方业务平台之间的会话；相关技术中，用户与SSO服务之间的会话称为全局会话，而用户与三方业务平台之间建立的会话则可以称为局部会话，当局部会话建立之后，用户通过三方Web服务与三方业务平台进行的所有交互，将通过局部会话进行管理。
然而，随着互联网技术飞速发展，应用SSO服务的实际业务场景中，除了B/S架构场景，还存在大量C/S架构场景。具体地，C/S架构场景主要包括：
第一，通过移动终端、计算机等设备上的应用(包括本地应用和传统应用)跳转到三方web服务，比如，通过微信小程序跳转到个人计算机的web服务或移动设备的web服务；
第二，通过移动终端、计算机等设备上的应用(包括本地应用和传统应用)跳转到相同设备上的另一应用。
而在具有综合型服务需求的应用场景下，同一个服务平台中可能会同时包含B/S架构和C/S架构这两种架构体系的服务。比如，在医疗服务应用场景下，可以基于软件即服务(SaaS，Software-as-a-Service)模式构建医疗服务平台，而医疗服务平台中需要引入和融合多种不同的第三方服务，包括B端服务和C端服务；其中，B端服务表示面向企业级提供的服务产品，是间接服务于用户的，比如，企业的管理系统，而C端服务则表示面向用户提供的服务产品，是直接服务于用户的，比如，移动终端上的客户端；而为了向用户提供种类更多、安全性更强、体验更好的一体化业务服务，B端服务和C端服务均需要具备支持外部服务安全引入的能力，即能够通过SSO服务实现用户的自动登录。
然而，C端服务(比如，微信小程序、H5(英文可以表达为HTML5)和本地化应用等)中的用户登录服务虽然可以采用不同的登录方式实现，但由于不是基于浏览器技术实现，因此不会有session相关信息被存储，也就无法基于session实现SSO服务。
比如，针对微信小程序跳转第三方web服务的C/S架构场景，即便通过SSO服务跳转到第三方web服务，但由于SSO服务的封闭式生态环境，微信小程序和第三方web服务无法共享SSO服务的cookie存储，从而无法实现用户在第三方web服务的自动登录；
针对本地应用跳转第三方web服务的C/S架构场景，若本地应用强行采用OAuth2.0协议的模式进行SSO服务跳转，当本地应用跳转到第三方web服务时，由于本地应用无法与第三方web服务共享session会话，因此时常需要用户重新进行登录，比如，在用户首次登录第三方web服务时、浏览器的cookie或session超期时，用户都需要重新登录，因此也不能达到用户自动登录第三方web服务的目的，降低用户体验。
基于此，在本申请的各种实施例中，主应用从主应用的业务平台获取授权信息，并将获取的授权信息传递给第三方应用，从而实现了C/S架构下，第三方应用对授权信息的获取，进而实现C/S架构下用户在第三方应用的自动登录；同时，由于不需要基于session获取授权信息，因此能够应用于不支持session的场景中，从而能够适用于包括B/S、C/S在内的不同应用场景。
本申请实施例提供了一种授权信息获取方法，应用于第一设备，如图4所示，该方法包括：
步骤401：所述第一设备上被使用的第一应用向第一业务平台发送第一请求，所述第一请求用于请求获取授权信息，所述授权信息用于所述第一设备上的第二应用被使用时验证用户的身份，所述第二应用为所述第一应用关联的应用；
步骤402：所述第一应用接收所述第一业务平台发送的授权信息；
步骤403：所述第一应用将接收的授权信息发送给所述第二应用。
实际应用时，所述第一应用可以称为主应用，也可以称为主应用的前端，本申请实施例对此不作限定，只要能实现其功能即可；所述第一业务平台可以称为主业务平台，也可以称为主应用的后端，本申请实施例对此不作限定，只要能实现其功能即可；所述授权信息包括授权码，所述授权码也可以称为Code，本申请实施例对此不作限定，只要能实现其功能即可；其中，所述授权信息可以包含所述第一业务平台按照OAuth2.0协议的模式为所述第二应用分配的具有一定有效时间的身份凭证，比如，针对所述第二应用生成的身份标识。
其中，所述第一业务平台，可理解为所述第一应用的业务平台，用于为所述第一应用提供业务服务及授权认证服务。而作为面向用户的前端部分，所述第一应用运行在所述第一设备上，为用户提供访问所述第一业务平台资源的入口，而作为为所述第一应用提供业务服务的后端部分，所述第一业务平台可以提供所述第一业务平台自身的业务服务(也就是第一应用)，还可以提供所述第一业务平台引入的外部服务(也就是第二应用)。
这里，实际应用时，所述第一业务平台不仅提供所述第一应用的业务服务，还提供了授权服务，由于所述第一应用从所述第一业务平台获取授权信息的过程中，授权信息的颁发和调用都在所述第一业务平台内完成，因此保证了授权信息获取过程的安全性。
实际应用时，所述第一设备可以是移动终端、计算机、平板电脑等设备，所述第一应用可以包括所述第一设备上的本地应用或web应用；其中，所述本地应用可理解为所述第一设备上提供C端服务的应用，可以包括传统的应用程序，比如，移动终端上的应用程序(APP，Application)，也可以包括不支持cookie和session的应用，比如，微信小程序；而所述Web应用可理解为所述第一设备上提供B端服务的应用。
实际应用时，所述第二应用可以称为第三方应用，也可以称为第三方应用的前端，本申请实施例对此不作限定，只要能实现其功能即可；所述第二应用为所述第一应用关联的应用，可理解为所述第二应用的供应商与所述第一应用的供应商建立合作关系后，所述第一应用为所述第二应用提供访问入口；比如，所述第一应用的界面上呈现第二应用的跳转链接，当用户点击该跳转链接时，通过第一应用跳转到第二应用。
实际应用时，所述第二应用，可以是所述第一业务平台引入的外部服务，也可以是第一业务平台内除第一应用之外的其他服务，用户通过所述第二应用的访问入口可以登录所述第二应用并访问所述第二应用的资源；其中，所述第一业务平台可以引入至少一个所述第二应用；为了实现所述第一应用到所述第二应用的跳转，在OAuth2.0应用场景下，所述第二应用可以作为OAuth客户端注册到所述第一业务平台，从而建立所述第一应用和所述第二应用的信任关系。其中，所述第二应用在所述第一业务平台成功注册后，所述第一业务平台将为所述第二应用生成一个身份标识，所述授权信息中可以包含所述身份标识，从而用于在所述第二应用被使用时，所述第一业务平台对所述第二应用的身份进行校验。
其中，实际应用时，所述第二应用的服务可以通过前端应用和后端服务实现，也就是所述第二应用和运行所述第二应用的第二业务平台，即第三方应用和第三方业务平台；其中，所述第二应用为用户提供用户界面和服务，所述第二业务平台则为所述第二应用提供相应的后台运行业务和逻辑。
实际应用时，所述第二应用可以包括用户设备(比如，移动终端、计算机)上的本地应用或web应用。其中，当所述第二应用包括web应用时，所述第二应用和所述第二业务平台，可以采用前后端分离的架构模式，也就是所述第二应用和所述第二业务平台分设，也可以采用单体服务模式，也就是所述第二应用和所述第二业务平台合设在一起，本申请实施例对此不作限定。
实际应用时，在所述第一应用向所述第一业务平台发送第一请求之前，用户需要先登录所述第一应用。
基于此，在一实施例中，所述方法还可以包括：
响应于针对所述第一应用的登录操作，所述第一应用向所述第一业务平台发送第二请求，所述第二请求用于请求获取上下文信息，所述第二请求包含登录所述第一应用的用户的身份信息；
所述第一应用接收所述第一业务平台针对所述第二请求发送的上下文信息。
其中，实际应用时，所述第一应用为用户提供登录入口，也就是说，用户可以在所述第一设备的第一应用界面上进行登录；其中，用户可以通过多种登录方式登录所述第一应用，比如，用户可以在所述第一应用提供的界面，通过输入第一业务平台预先注册的用户名密码信息进行登录，或者，按照OAuth2.0密码模式进行登录，即用户在第一业务平台注册生成用户名密码后，第一设备利用获取的用户名密码从第一业务平台中获取一个基于OAuth2.0协议生成的访问令牌，当用户登录第一应用时，第一设备利用获取的访问令牌访问所述第一业务平台的资源，或者，通过微信小程序授权或其他平台授权的模式登录；具体采用的登录方式根据实际应用场景确定，本申请实施例对此不作限定。
这里，实际应用时，所述第二请求可理解为用户登录所述第一应用的请求，所述第二请求中携带所述用户的身份信息，当所述第一业务平台接收到所述第二请求后，对所述用户的身份信息进行校验，并在校验通过时，向所述第一应用发送所述上下文信息。
其中，实际应用时，所述上下文信息可以称为第一应用登录上下文，也可以称为主业务登录上下文，本申请实施例对此不作限定，只要能实现其功能即可。所述上下文信息与用户信息和用户在所述第一应用的登录状态相关，可以通过令牌(Token)、jwt(英文可以表达为JSON Web Token)等形式实现。
实际应用时，在所述第一应用不支持cookie和session的应用场景下，比如，所述第一应用为所述第一设备上的APP或微信小程序，所述第一业务平台可以通过显式返回的方式向所述第一应用发送所述上下文信息，也就是所述第一应用向所述第一业务平台发送请求，所述第一业务平台响应于所述第一应用的请求并向所述第一应用发送所述上下文信息；而在所述第一应用支持cookie和session的应用场景下，所述第一业务平台可以通过cookie的方式向所述第一应用发送所述上下文信息的基础上，当然，也可以采用显示返回的方式向所述第一应用返回所述上下文信息。
实际应用时，当所述第一业务平台接收到所述第一请求后，为了保证授权信息的安全发放，所述第一业务平台向所述第一应用发送所述授权之前，可以对用户的登录相关信息进行安全校验，因此，当所述第一应用获取所述上下文信息后，可以利用所述上下文信息从所述第一业务平台获取所述授权信息。
基于此，在一实施例中，所述方法还可以包括：
所述第一应用获取用户登录所述第一应用的上下文信息；所述第一请求包含所述上下文信息，所述上下文信息用于所述第一业务平台对用户的登录相关信息进行校验。
实际应用时，为了确保所述第一应用将要跳转的第二应用的安全性，确定所述第一业务平台还可以在发送所述授权信息之前，对所述第二应用的身份进行安全校验。
基于此，在一实施例中，所述第一请求还可以包含所述第二应用的身份相关信息。
这里，实际应用时，所述第一业务平台可以只对信任的第三方应用发放授权信息，也就是说，第三方应用需要先在所述第一业务平台进行注册，且成功注册后的第三方应用的信息会被记录在所述第一业务平台中；当所述第一应用向所述第一业务平台发送所述第一请求时，所述第一业务平台根据所述第一请求中携带的所述第二应用的身份相关信息，确定所述第二应用是否为可信的第三方应用，即已注册到所述第一业务平台的第三方应用，并在确定所述第二应用为可信的第三方应用的情况下，向所述第一应用发送所述授权信息。其中，所述第二应用的身份信息可以称为所述第二应用的身份标识，也可以称为OAuth客户端校验信息，可以通过client_id、redirect_uri等形式实现。
实际应用时，所述授权信息在用户登录所述第二应用之前获取即可，比如，当用户在第一应用的界面上针对第二应用进行点击操作时，所述第一设备发送所述第一请求，或者，当用户登录所述第一应用但未对第一应用界面上的第二应用进行点击操作时，所述第一设备发送所述第一请求，本申请实施例对此不作限定。
相应地，本申请实施例还提供了一种授权信息获取方法，应用于第一业务平台，如图5所示，该方法包括：
步骤501：所述第一业务平台的第一服务接收第一设备上被使用的第一应用发送的第一请求，所述第一请求用于请求获取授权信息，所述授权信息用于所述第一设备上的第二应用被使用时验证用户的身份，所述第二应用为所述第一应用关联的应用；
步骤502：响应于所述第一请求，所述第一服务从所述第一业务平台的第二服务获取所述授权信息，并向所述第一应用发送所述授权信息。
这里，实际应用时，所述第一服务可以称为主业务服务，也可以称为第一应用的业务服务，本申请实施例对此不作限定，只要能实现其功能即可；所述第一服务作为所述第一业务平台中面向所述第一应用的服务，与所述第一应用进行通信，并用于提供所述第一应用对应的业务服务；所述第二服务可以称为授权服务，也可以称为OAuth服务，本申请对此不作限定，只要能实现其功能即可；所述第二服务用于为所述第一应用提供基于OAuth2.0协议的SSO服务。由于所述第一服务和所述第二服务是同一个平台下的服务，所述第一服务和所述第二服务之间相互信任，因此，本申请实施例通过所述第一服务从所述第二服务服务调用授权信息，实现了对可信域内部服务开放OAuth颁发授权能力，从而保证授权信息调用过程的安全性。
实际应用时，所述第二服务可以包括Auth Server和Resource Server；其中，AuthServer用于为所述第一服务提供授权信息，Resource Server则用于提供SSO服务所需要的资源，比如，在所述第二业务平台利用授权信息进行用户登录的过程中，Resource Server向所述第二业务平台提供用户信息。
实际应用时，为了保证授权信息的安全发放，所述第一服务向所述第一应用发送所述授权信息之前，可以对用户的登录相关信息进行安全校验。
基于此，在一实施例中，所述第一请求包含用户登录所述第一应用的上下文信息，所述方法还包括：
基于所述上下文信息，所述第一服务对用户的登录相关信息进行校验，并在校验通过的情况下，响应于所述第一请求，从所述第二服务获取所述授权信息。
其中，实际应用时，所述上下文信息可以包括所述用户的状态(比如，用户是否被禁用)和用户的登录状态(比如，登录信息是否过期)的登录相关信息，所述对用户的登录相关信息进行校验，即验证用户的状态、用的登录状态等信息的合法性。比如，第一应用携带jwt向第一服务发送第二请求，第一服务检验jwt是否已过期，并检验对应的用户是否被禁用。
这里，所述第一服务校验用户登录相关信息的过程，可理解为按照OAuth2.0协议进行用户认证的过程，只有在用户认证通过的情况下，所述第一服务才会基于可信域的信任关系从所述第二服务调用授权信息，从而确保外部设备对所述第一业务平台的访问为合法访问，保障所述第一业务平台的通信安全。
实际应用时，所述第一应用向所述第一服务发送第一请求之前，用户需要先登录所述第一应用，成功登录后，所述第一业务平台返回所述上下文信息给所述第一应用。
基于此，在一实施例中，所述方法还可以包括：
所述第一服务接收所述第一应用发送的第二请求，所述第二请求用于请求获取上下文信息，所述第二请求包含登录所述第一应用的用户身份信息；
响应于所述第二请求，所述第一服务向所述第一应用发送所述上下文信息。
实际应用时，为了确保所述第一应用将要跳转的第二应用的安全性，所述第二服务还可以在发送所述授权信息之前，对所述第二应用的身份进行安全校验。
基于此，在一实施例中，所述响应于所述第一请求，从所述第二服务获取所述授权信息，包括：
所述第一服务向所述第二服务发送第三请求，所述第三请求用于请求获取所述授权信息，所述第三请求包含所述第二应用的身份相关信息；
基于所述身份相关信息，所述第二服务对所述第二应用的身份进行校验，并在校验通过的情况下，向所述第一服务发送所述授权信息。
实际应用时，所述第一服务和所述第二服务，可以通过所述第一业务平台内的同一个服务实现，也可以通过所述第一业务平台的两个不同的微服务实现，当然，也可以通过同一个局域网内的两个模块实现；所述第一服务可以通过不同的方式从所述第二服务获取所述授权信息。
具体地，所述第一服务可以通过以下方式之一从所述第二服务调用所述授权信息：
远程过程调用(RPC)；
基于自定义的方法进行调用；
基于通信协议进行调用。
其中，RPC是一种微服务的内部调用方式，能够应用于微服务应用场景下，比如，当所述第一服务和所述第二服务为同一平台下两个不同的微服务时，所述第一服务可以通过RPC(具体可以是Feign)从所述第二服务中调用所述授权信息；所述基于自定义的方法进行调用，可以包括方法调用或模块接口，比如，当所述第一服务调用所述授权信息时，通过预先定义的方法向所述第二服务请求接口，以获取所述授权信息；所述基于通信协议进行调用时，可理解为基于通信协议的规定向所述第二服务请求接口，以获取所述授权信息，比如，基于超文本传输协议(HTTP，Hyper Text Transfer Protocol)、超文本传输安全协议(HTTPS，Hypertext Transfer Protocol Secure)等协议的规定进行调用。
这里，实际应用时，所述第一服务从所述第二服务调用授权信息的方式可以根据具体的应用场景确定，本申请实施例对此不作限定。
实际应用时，为了加强所述第一服务和所述第二服务之间的通信安全，可以在调用过程增加安全机制。
基于此，在一实施例中，所述第一服务和所述第二服务基于安全机制进行通信。
实际应用时，所述安全机制可以包括以下至少之一：
所述第一服务和所述第二服务基于网际互联协议(IP，Internet Protocol)白名单建立进行通信；
所述第一服务和所述第二服务基于信息加密机制进行通信；
所述第一服务通过客户端凭证(client credentials)模式从所述第二服务获取所述授权信息。
其中，实际应用时，所述第一服务和所述第二服务基于IP白名单建立进行通信，也就是所述第二服务中将所述第一服务的出口IP记录在白名单中；当所述第二服务接收到所述第一服务发送的请求时，确定访问相关接口的所述第一服务的出口IP是否在白名单内，若在，则认为所述第一服务发送的请求为安全的请求，并为所述第一服务颁发所述授权码，若不在，则认为所述第一服务发送的请求不是安全的请求，并拒绝向所述第一服务颁发所述授权码，以此避免所述第二服务接收到不安全的访问请求，从而提升所述第一业务平台的安全性。
实际应用时，所述第一服务和所述第二服务基于信息加密机制进行通信，也就是所述第一服务和所述第二服务根据加密算法对传输的数据进行加密，并在接收到加密的数据后，按照加密算法解密，从而避免在通信过程数据被拦截而造成的数据泄露；比如，在所述第一服务向所述发送调用所述授权信息的请求时，所述第一服务先将请求的参数加密后再进行传输，当所述第二服务接收到加密后的请求后，则先用加密算法解密；其中，所述加密算法可以是所述第一服务和所述第二服务预先协商好的算法，也可以是由所述第一服务或所述第二服务定义后通知另一服务的，具体确定方式可以根据实际应用场景来确定，本申请实施例对此不作限定。
实际应用时，所述第一服务通过client credentials模式从所述第二服务获取所述授权信息，也就是所述第一服务按照OAuth2.0协议的client credentials模式定义的流程从所述第二服务调用所述授权信息，从而提升调用过程的安全性。比如，所述第一服务使用自己的身份信息从所述第二服务获取一个客户端证书，从而成为所述第二服务信任的OAuth客户端；调用所述授权信息时，OAuth客户端(即所述第一服务)用客户端的凭证(即客户端证书)从授权服务器(即所述第二服务中的Auth Server)换取token，再用获取的token从资源库(即所述第二服务中的Resource Server)获取受保护的资源(即所述授权信息)。其中，由于所述第一服务和所述第二服务支持的通信方式及安全方式可能存在不同，因此，所述第一服务和所述第二服务可以共同协商或自定的方式对Client Credentials进行自定义。
本申请实施例还提供了一种授权信息获取方法，如图6所示，该方法包括：
步骤601：第一设备上被使用的第一应用向第一业务平台发送第一请求，所述第一请求用于请求获取授权信息，所述授权信息用于所述第一设备上的第二应用被使用时验证用户的身份，所述第二应用为所述第一应用关联的应用；
步骤602：所述第一业务平台的第一服务接收所述第一设备上被使用的第一应用发送的第一请求；
步骤603：响应于所述第一请求，所述第一服务从所述第一业务平台的第二服务获取所述授权信息，并向所述第一应用发送所述授权信息；
步骤604：所述第一应用接收所述第一业务平台发送的授权信息；
步骤605：所述第一应用将接收的授权信息发送给所述第二应用。
这里，需要说明的是：第一设备和第一业务平台的具体处理过程已在上文详述，这里不再赘述。
本申请实施例提供的授权信息获取方法，第一设备上被使用的第一应用向第一业务平台发送第一请求，所述第一请求用于请求获取授权信息，所述授权信息用于所述第一设备上的第二应用被使用时验证用户的身份，所述第二应用为所述第一应用关联的应用；而所述第一业务平台的第一服务接收第一设备上被使用的第一应用发送的第一请求，所述第一请求用于请求获取授权信息，所述授权信息用于所述第一设备上的第二应用被使用时验证用户的身份，所述第二应用为所述第一应用关联的应用；响应于所述第一请求，所述第一服务从所述第一业务平台的第二服务获取所述授权信息，并向所述第一应用发送所述授权信息。本申请实施例提供的方案，主应用从主应用的业务平台获取授权信息，并将获取的授权信息传递给第三方应用，从而实现了C/S架构下，第三方应用对授权信息的获取，进而实现C/S架构下用户在第三方应用的自动登录；同时，由于不需要基于session获取授权信息，因此能够应用于不支持session的场景中，从而能够适用于包括B/S、C/S在内的不同应用场景。
下面结合应用示例对本申请再作进一步详细的描述。
为了描述方便，在以下的描述中，将授权信息称为Code。
图7为本申请应用示例提供的一种SSO服务系统架构示意图，如图7所示，所述SSO服务系统包括主应用701、主业务平台702和第三方服务703。下面对所述主应用701、主业务平台702和第三方服务703的功能分别进行说明。
所述主应用701，也就是第一应用，是用户设备(也就是第一设备)上的某个应用，比如，移动终端、个人计算机、平板等设备上的应用；所述主应用701为用户提供了所述主业务平台702对应的服务的总入口，包括所述主业务平台702自身的业务和所述主业务平台702引入的第三方服务703，也就是第一应用和第二应用。其中，所述主应用701可以是本地应用，也就是用户设备上的传统应用程序，比如移动终端上的app，也可以是小程序等不支持cookie和session的应用，还可以是web应用。
所述主业务平台702，包括主业务服务7021和OAuth服务7022；其中，所述主业务服务7021用于提供主应用701对应的业务服务，所述OAuth服务7022，用于基于OAuth协议为所述主应用701提供SSO服务，以便所述第一业务平台可以安全、平滑、专业地引入各种各样的第三方服务703。其中，所述OAuth服务7022可以包括Auth Server和Resource Server，AuthServer负责SSO服务的授权认证，比如，为所述主业务服务7021发送Code，而ResourceServer则提供SSO服务中需要获取的资源，比如，登录所述主应用701的用户信息。
所述第三方服务703，为所述主业务平台702引入的其他业务服务，通常拥有自己的业务；在OAuth领域，特别是Code领域，所述第三方服务703通常由其前端应用和后端服务组成，即三方业务应用7031和三方业务平台7032；其中，所述三方业务应用7031，也就是第二应用，用于向用户提供用户界面和服务，而所述三方业务平台7032，则用于为所述三方业务能够7031提供后台运行的业务和逻辑。所述三方业务应用7031可以是用户设备上的本地应用，也就是用户设备上传统的应用程序，比如，移动终端上的app，也可以是小程序等不支持cookie和session的应用，还可以是web应用。当所述第三业务应用7031是web应用时，所述三方业务应用7031和所述三方业务平台7032可以是前后端分离，也可以是单体服务。
基于上述架构，本申请应用示例还提供了一种SSO服务方法，如图8所示，该方法包括：
步骤801：用户登录主应用，获得主业务登录上下文，然后执行步骤802；
这里，用户登录主应用的方式不限，具体地，可以通过用户名密码登录，也可以通过微信小程序授权或其他平台授权登录，还可以通过主业务平台提供的OAuth密码进行登录。无论采用哪种方式登录，当登录成功后，主应用将从主业服务获得一个与用户信息和登录状态相关的主业务登录上下文，比如token、jwt等。当用户登录主应用后，主应用与主业务服务进行请求响应时，通过主业务登录上下文校验用户信息和登录状态。
当主应用为不支持cookie和session的传统应用或小程序时，主业务登录上下文显式返回，也就是主应用通过请求响应的方式从主业务服务获取主业务登录上下文；当主应用为web应用时，主业务登录上下文可以通过cookie返回，也可以通过显示返回。
步骤802：主应用携带主业务登录上下文信息，以及目标三方服务的client_id、redirect_uri等OAuth客户端校验信息，请求从主业务服务获取Code，然后执行步骤803；
这里，主应用可以在用户触发三方服务前或触发三方服务时向主业务服务获取Code。
步骤803：主业务服务校验主业务登录上下文，具体地，校验用户在主应用上的登录状态、用户状态和其他校验信息，也就是进行OAuth协议定义的用户认证，然后执行步骤804；
当确认主应用发起的访问请求为合法访问后，主业务服务向OAuth服务中的AuthServer请求对该Client_id颁发CodeCode，然后执行步骤804；
在此过程中，主业务服务向Auth Server发送的请求中携带目标三方服务OAuth客户端校验信息，也就是client_id、redirect_uri等信息。
步骤804：OAuth服务中的Auth Server基于可信域的信任关系，接收内部服务(也就是主业务服务)为目标第三方服务颁发Code的请求，并按照OAuth2.0协议，为目标三方服务颁发Code，并记录当前登录用户信息，然后执行步骤805；
这里，主业务服务可以通过以下方式一直从Auth server调用Code：
微服务的内部feign调用或其他rpc调用；
方法调用或模块接口调用；
http/https等其他协议接口调用。
同时，为了进一步提升Code调用过程的安全性，主业务服务对Code的调用过程该可以增加安全校验机制，具体地，增加安全校验机制可以通过以下方式至少之一实现：
IP白名单机制；也就是Auth Server中定义出口IP的白名单，只有白名单的出口IP可以发起对Auth Server的访问；
请求加密机制；也就是主业务服务在发送调用Code的请求之前，先将请求进行加密，再将加密后的请求发送到Auth Server；
基于Auth2.0协议调用Code；也就是主业务平台作为Auth Server的一个OAuth客户端，可以采用Auth2.0协议的Client Credentials模式获取Code，其中，ClientCredentials可以基于安全方面考虑进行自定义增强。
步骤805：主应用将获得的Code传递给三方业务服务，并进入三方业务服务，也就是单点登录三方服务，然后执行步骤806；
这里，在用户触发第三方服务的时候，也就是用户在主应用提供的界面上，点击三方业务应用的跳转入口时，主应用将获取的Code传递给第三方服务中的三方业务应用，然后执行步骤806。
步骤806：三方业务应用按照OAuth2.0协议的规定，将Code传递给三方业务平台，也就是code登录，然后执行步骤807。
步骤807：三方业务平台携带Code从主业务平台的Auth Server获取AccessToken，也就是Code换Access Token，然后执行步骤808。
步骤808：三方业务平台携带Access Token从主业务平台的Auth Server获取用户登录三方业务应用所需要的信息，比如用户信息，也就是利用Access Token获取用户信息，然后执行步骤809。
步骤809：三方业务平台校验用户信息在三方业务平台是否存在，并在用户信息不存在时，按照获取的用户信息创建新的用户，然后执行步骤810；
这里，步骤807至809是第三方服务利用Code从主业务平台获取所需信息的过程，也就是第三方服务按照OAuth2.0协议定义的流程获取所需资源的额过程。
步骤810：三方业务平台生成用户访问第三方服务的三方业务登录上下文，并将三方业务登录上下文返回到三方业务应用；其中，三方业务登录上下文为第三方服务中局部会话管理的上下文，比如，token、jwt等。
下面结合不同的应用场景，对本申请应用示例进行进一步说明。
应用示例一
本应用示例中，针对于微信小程序通过SSO跳转到三方web服务的应用场景。本应用示例SSO服务的方法，包括以下步骤：
步骤1：微信小程序采用授权方式登录，用户登录微信小程序时，主业务服务返回登录上下文jwt给微信小程序；微信小程序请求主业务平台业务时，携带jwt；
其中，微信小程序的用户界面已配置第三方服务的入口。
步骤2：用户在微信小程序的用户界面点击第三方服务入口时，微信小程序携带jwt向主业务服务请求Code；
其中，微信小程序向主业务服务发送的请求中携带第三方服务的redirect_uri；这里，redirect_uri与微信小程序上配置的第三方业务入口信息可以相同，也可以不同，但需要与第三方服务在主业务服务注册的信息相同，以使主业务服务利用redirect_uri对第三方服务进行校验。
步骤3：主业务服务校验jwt的合法性，以及对应用户的合法性；
具体地，主业务服务可以校验jwt是否已超期，以及对应的用户是否已被禁用等。
步骤4：OAuth服务中的Auth Server为可信域内的主业务服务提供“为三方平台颁发Code”的能力接口，比如feign接口。
步骤5：主业务服务获取Code，并将Code发送到微信小程序。
步骤6：微信小程序获取到Code后，启动网页视图(web view)请求第三方服务，将获取的Code传递到三方web服务。
步骤7：三方web服务利用Code，按照OAuth2.0协议的规定，从主业务平台获取用户信息；
这里，三方web服务在对接主业务平台之前已经使用session进行登录管理。
步骤8：三方web服务利用获取的用户信息进行用户的自动登录，生成三方登录上下文，即session，并在Cooike中记录session的相关信息；之后，三方web服务进入内部的局部会话管理。
应用示例二
本应用示例中，针对于本地APP1通过SSO服务跳转本地APP2的应用场景。本申请实施例SSO服务的方法，包括以下步骤：
步骤1：用户采用OAuth的密码模式登录本地APP1，登录后，主业务服务返回登录上下文jwt给APP1；APP1请求主业务平台业务时，携带jwt；
其中，本地APP1的用户界面已配置第三方服务APP2的入口，APP2的入口可以基于APP2的包名或基于Scheme协议实现。
步骤2：用户在APP1的用户界面点击APP2入口时，APP1携带jwt向主业务服务请求Code；
其中，APP1向主业务服务发送的请求中携带APP2的redirect_uri。
步骤3：主业务服务校验jwt的合法性，以及对应用户的合法性。
步骤4：OAuth服务中的Auth Server为可信域内的主业务服务提供“为三方平台颁发Code”的能力接口。
步骤5：主业务服务获取Code，并将Code发送到APP1。
步骤6：APP1获得Code后，采用运行系统提供的方法启动APP2，并携带Code。
步骤7：APP2利用Code，按照OAuth2.0协议的规定，从主业务平台获取用户信息；
这里，APP2在对接主业务平台之前已经使用了自定义token机制进行登录管理。
步骤8：APP2利用获取的用户信息进行用户在APP2上的自动登录，生成三方登录上下文，即自定义的token，并将三方登录上下文返回给APP2的前端应用；之后，APP2进入前端应用与后端服务的局部会话管理。
应用示例三
本应用示例中，针对于主web服务通过SSO服务跳转三方web服务的应用场景。本申请实施例SSO服务的方法，包括以下步骤：
步骤1：主Web服务采用手机号短信验证码方式登录，登录后主业务服务返回自定义登录上下文token给三方web服务；主Web服务请求主业务平台业务时，携带token；
其中，主web服务的用户界面已配置三方web服务的入口。
步骤2：用户在主web服务的用户界面点击三方服务入口时，主Web服务携带token向主业务服务请求Code；
步骤3：主业务服务校验jwt的合法性，以及对应用户的合法性。
步骤4：OAuth服务中的Auth Server为可信域内的主业务服务提供“为三方平台颁发Code”的能力接口。
步骤5：主业务服务获取Code，并将Code发送到主web服务。
步骤6：主web服务获得Code后，采用运行系统提供的方法启动三方web服务，并携带Code参数。
步骤7：三方web服务利用Code，按照OAuth2.0协议的规定，从主业务平台获取用户信息；
这里，三方web服务在对接主业务平台之前已经使用了session进行登录管理。
步骤8：三方web服务利用获取的用户信息进行用户在三方web服务的自动登录，生成三方登录上下文，即session，并在cookie中记录session的相关信息；之后，三方web服务进入内部的局部会话管理。
本申请应用示例提供的方案，主要具有以下几个优点：
(1)通过主应用获取Code的方式，实现了不基于session的SSO服务，不仅能够实现C/S架构模式下的SSO服务的应用，且能够适用于B/S架构在内的众多应用场景；
(2)通过使用OAuth Code的方式，提高了SSO服务系统的安全性；
(3)由于Code是通过在主业务平台可信域内的调用获取的，因此，对于已支持OAuth的平台，仅需在已有平台内增加一个接口和对应的调用逻辑，即可实现Code的调用，从而使本申请应用示例提供的方案能够适用于多种场景；
为了实现本申请实施例设备侧的方法，本申请实施例还提供了一种授权信息获取装置，设置在第一设备，如图9所述，该装置包括：
第一发送单元901，用于所述第一设备上被使用的第一应用向第一业务平台发送第一请求，所述第一请求用于请求获取授权信息，所述授权信息用于所述第一设备上的第二应用被使用时验证用户的身份，所述第二应用为所述第一应用关联的应用；以及，所述第一应用将接收的授权信息发送给所述第二应用；
第一接收单元902，用于所述第一应用接收所述第一业务平台发送的授权信息。
在一实施例中，所述第一接收单元902，还可以用于所述第一应用获取用户登录所述第一应用的上下文信息；所述第一请求包含所述上下文信息，所述上下文信息用于所述第一业务平台对用户的登录相关信息进行校验。
在一实施例中，所述第一接收单元902，具体用于：
响应于针对所述第一应用的登录操作，所述第一应用向所述第一业务平台发送第二请求，所述第二请求用于请求获取所述上下文信息，所述第二请求包含登录所述第一应用的用户的身份信息；
所述第一应用接收所述第一业务平台针对所述第二请求发送的上下文信息。
实际应用时，所述第一发送单元901和所述第一接收单元902可由授权信息获取装置中的处理器结合通信接口实现
为了实现本申请实施例平台侧的方法，本申请实施例还提供了一种授权信息获取装置，设置在第一业务平台，如图10所述，该装置包括：
第二接收单元1001，用于所述第一业务平台的第一服务接收第一设备上被使用的第一应用发送的第一请求，所述第一请求用于请求获取授权信息，所述授权信息用于所述第一设备上的第二应用被使用时验证用户的身份，所述第二应用为所述第一应用关联的应用；
第二发送单元1002，用于响应于所述第一请求，所述第一服务从所述第一业务平台的第二服务获取所述授权信息，并向所述第一应用发送所述授权信息。
在一实施例中，所述第一请求包含用户登录所述第一应用的上下文信息，所述第二发送单元1002，还用于：
基于所述上下文信息，所述第一服务对用户的登录相关信息进行校验，并在校验通过的情况下，响应于所述第一请求，从所述第二服务获取所述授权信息。
在一实施例中，所述第二接收单元1001，还用于所述第一服务接收所述第一应用发送的第二请求，所述第二请求用于请求获取所述上下文信息，所述第二请求包含登录所述第一应用的用户身份信息；
所述第二发送单元1002，还用于响应于所述第二请求，向所述第一应用发送所述上下文信息。
在一实施例中，所述装置还包括校验单元；所述校验单元，用于：
所述第一服务向所述第二服务发送第三请求，所述第三请求用于请求获取所述授权信息，所述第三请求包含所述第二应用的身份相关信息；
基于所述身份相关信息，所述第二服务对所述第二应用的身份进行校验，并在校验通过的情况下，向所述第一服务发送所述授权信息。
在一实施例中，所述第一服务和所述第二服务基于安全机制进行通信。
实际应用时，所述第二接收单元1001和所述第二发送单元1002可由授权信息获取装置中的处理器结合通信接口实现，所述校验单元可由授权信息获取装置中的处理器实现。
需要说明的是：上述实施例提供的授权信息获取装置在获取授权信息时，仅以上述各程序模块的划分进行举例说明，实际应用中，可以根据需要而将上述处理分配由不同的程序模块完成，即将装置的内部结构划分成不同的程序模块，以完成以上描述的全部或者部分处理。另外，上述实施例提供的授权信息获取装置与授权信息获取方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。
基于上述程序模块的硬件实现，且为了实现本申请实施例设备侧的方法，本申请实施例还提供了一种第一设备，如图11所示，该第一设备1100包括：
第一通信接口1101，能够与第一业务平台进行信息交互，比如，向第一业务平台发送第一请求，以及接收所述第一业务平台发送的授权信息；
第一处理器1102，与所述第一通信接口1101连接，以实现与第一业务平台进行信息交互，用于运行计算机程序时，执行上述设备侧一个或多个技术方案提供的方法；
第一存储器1103，所述计算机程序存储在所述第一存储器1103上。
具体地，所述第一处理器1102，用于：
利用所述第一通信接口1101使所述第一设备上被使用的第一应用向第一业务平台发送第一请求，所述第一请求用于请求获取授权信息，所述授权信息用于所述第一设备上的第二应用被使用时验证用户的身份，所述第二应用为所述第一应用关联的应用；以及，
利用所述第一通信接口1101使所述第一应用接收所述第一业务平台发送的授权信息。
在一实施例中，所述第以处理器1102，还可以用于所述第一应用利用所述第一通信接口1101获取用户登录所述第一应用的上下文信息；所述第一请求包含所述上下文信息，所述上下文信息用于所述第一业务平台对用户的登录相关信息进行校验。
在一实施例中，所述第一处理器1102，具体用于：
响应于针对所述第一应用的登录操作，所述第一应用利用所述第一通信接口1101向所述第一业务平台发送第二请求，所述第二请求用于请求获取所述上下文信息，所述第二请求包含登录所述第一应用的用户的身份信息；
利用所述第一通信接口1101所述第一应用接收所述第一业务平台针对所述第二请求发送的上下文信息。
需要说明的是：第一处理器1102和第一通信接口1101的具体处理过程可参照上述方法理解。
当然，实际应用时，第一设备1100中的各个组件通过总线系统1104耦合在一起。可理解，总线系统1104用于实现这些组件之间的连接通信。总线系统1104除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图11中将各种总线都标为总线系统1104。
本申请实施例中的第一存储器1103用于存储各种类型的数据以支持第一设备1100的操作。这些数据的示例包括：用于在第一设备1100上操作的任何计算机程序。
上述本申请实施例揭示的方法可以应用于所述第一处理器1102中，或者由所述第一处理器1102实现。所述第一处理器1102可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过所述第一处理器1102中的硬件的集成逻辑电路或者软件形式的指令完成。上述的所述第一处理器1102可以是通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。所述第一处理器1102可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤，可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于存储介质中，该存储介质位于第一存储器1103，所述第一处理器1102读取第一存储器1103中的信息，结合其硬件完成前述方法的步骤。
在示例性实施例中，第一设备1100可以被一个或多个应用专用集成电路(ASIC，Application Specific Integrated Circuit)、DSP、可编程逻辑器件(PLD，ProgrammableLogic Device)、复杂可编程逻辑器件(CPLD，Complex Programmable Logic Device)、现场可编程门阵列(FPGA，Field-Programmable Gate Array)、通用处理器、控制器、微控制器(MCU，Micro Controller Unit)、微处理器(Microprocessor)、或者其他电子元件实现，用于执行前述方法。
基于上述程序模块的硬件实现，且为了实现本申请实施例平台侧的方法，本申请实施例还提供了一种第一业务平台，如图12所示，该第一业务平台1200包括：
第二通信接口1201，能够与第一设备进行信息交互，比如，接收第一设备发送的第一请求，以及向第一设备发送授权信息；
第二处理器1202，与所述第二通信接口1201连接，以实现与第一设备进行信息交互，用于运行计算机程序时，执行上述平台侧一个或多个技术方案提供的方法；
第二存储器1203，所述计算机程序存储在所述第二存储器1203上。
具体地，所述第二处理器1202，用于：
所述第一业务平台的第一服务利用所述第二通信接口1201接收第一设备上被使用的第一应用发送的第一请求，所述第一请求用于请求获取授权信息，所述授权信息用于所述第一设备上的第二应用被使用时验证用户的身份，所述第二应用为所述第一应用关联的应用；
响应于所述第一请求，所述第一服务从所述第一业务平台的第二服务获取所述授权信息，并利用所述第二通信接口1201向所述第一应用发送所述授权信息。
在一实施例中，所述第一请求包含用户登录所述第一应用的上下文信息，所述第二处理器1202，还用于：
基于所述上下文信息，所述第一服务对用户的登录相关信息进行校验，并在校验通过的情况下，响应于所述第一请求，从所述第二服务获取所述授权信息。
在一实施例中，所述第二处理器1202，还用于：
所述第一服务利用所述第二通信接口1201接收所述第一应用发送的第二请求，所述第二请求用于请求获取所述上下文信息，所述第二请求包含登录所述第一应用的用户身份信息；
响应于所述第二请求，所述第一服务利用所述第二通信接口1201向所述第一应用发送所述上下文信息。
在一实施例中，所述第二处理器1202，具体用于：
所述第一服务向所述第二服务发送第三请求，所述第三请求用于请求获取所述授权信息，所述第三请求包含所述第二应用的身份相关信息；
基于所述身份相关信息，所述第二服务对所述第二应用的身份进行校验，并在校验通过的情况下，向所述第一服务发送所述授权信息。
在一实施例中，所述第一服务和所述第二服务基于安全机制进行通信。
当然，实际应用时，第一业务平台1200中的各个组件通过总线系统1204耦合在一起。可理解，总线系统1204用于实现这些组件之间的连接通信。总线系统1204除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图12中将各种总线都标为总线系统1204。
本申请实施例中的第二存储器1203用于存储各种类型的数据以支持第一业务平台1200操作。这些数据的示例包括：用于在第一业务平台1200上操作的任何计算机程序。
上述本申请实施例揭示的方法可以应用于所述第二处理器1202中，或者由所述第二处理器1202实现。所述第二处理器1202可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过所述第二处理器1202中的硬件的集成逻辑电路或者软件形式的指令完成。上述的所述第二处理器1202可以是通用处理器、DSP，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。所述第二处理器1202可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤，可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于存储介质中，该存储介质位于第二存储器1203，所述第二处理器1202读取第二存储器1203中的信息，结合其硬件完成前述方法的步骤。
在示例性实施例中，第一业务平台1200可以被一个或多个ASIC、DSP、PLD、CPLD、FPGA、通用处理器、控制器、MCU、Microprocessor、或其他电子元件实现，用于执行前述方法。
可以理解，本申请实施例的存储器(第一存储器1103、第二存储器1203)可以是易失性存储器或者非易失性存储器，也可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(ROM，Read Only Memory)、可编程只读存储器(PROM，Programmable Read-Only Memory)、可擦除可编程只读存储器(EPROM，ErasableProgrammable Read-Only Memory)、电可擦除可编程只读存储器(EEPROM，ElectricallyErasable Programmable Read-Only Memory)、磁性随机存取存储器(FRAM，ferromagneticrandom access memory)、快闪存储器(Flash Memory)、磁表面存储器、光盘、或只读光盘(CD-ROM，Compact Disc Read-Only Memory)；磁表面存储器可以是磁盘存储器或磁带存储器。易失性存储器可以是随机存取存储器(RAM，Random Access Memory)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(SRAM，Static Random Access Memory)、同步静态随机存取存储器(SSRAM，SynchronousStatic Random Access Memory)、动态随机存取存储器(DRAM，Dynamic Random AccessMemory)、同步动态随机存取存储器(SDRAM，Synchronous Dynamic Random AccessMemory)、双倍数据速率同步动态随机存取存储器(DDRSDRAM，Double Data RateSynchronous Dynamic Random Access Memory)、增强型同步动态随机存取存储器(ESDRAM，Enhanced Synchronous Dynamic Random Access Memory)、同步连接动态随机存取存储器(SLDRAM，SyncLink Dynamic Random Access Memory)、直接内存总线随机存取存储器(DRRAM，Direct Rambus Random Access Memory)。本申请实施例描述的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
为实现本申请实施例的方法，本申请实施例还提供了一种授权信息获取系统，如图13所示，该系统包括：第一设备1301和第一业务平台1302。
这里，需要说明的是：所述网络设备901和终端902的具体处理过程已在上文详述，这里不再赘述。
在示例性实施例中，本申请实施例还提供了一种存储介质，即计算机存储介质，具体为计算机可读存储介质，例如包括存储计算机程序的第一存储器1103，上述计算机程序可由第一设备1100的第一处理器1102执行，以完成前述设备侧方法所述步骤。再比如包括存储计算机程序的第二存储器1203，上述计算机程序可由第一业务平台1200的第二处理器1202执行，以完成前述网络设备侧方法所述步骤。计算机可读存储介质可以是FRAM、ROM、PROM、EPROM、EEPROM、Flash Memory、磁表面存储器、光盘、或CD-ROM等存储器。
需要说明的是：“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。
另外，本申请实施例所记载的技术方案之间，在不冲突的情况下，可以任意组合。
以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。
Claims (15)
1.一种授权信息获取方法，其特征在于，应用于第一设备，包括：
所述第一设备上被使用的第一应用向第一业务平台发送第一请求，所述第一请求用于请求获取授权信息，所述授权信息用于所述第一设备上的第二应用被使用时验证用户的身份，所述第二应用为所述第一应用关联的应用；
所述第一应用接收所述第一业务平台发送的授权信息；
所述第一应用将接收的授权信息发送给所述第二应用。
2.根据权利要求1所述的方法，其特征在于，所述方法还包括：
所述第一应用获取用户登录所述第一应用的上下文信息；所述第一请求包含所述上下文信息，所述上下文信息用于所述第一业务平台对用户的登录相关信息进行校验。
3.根据权利要求2所述的方法，其特征在于，所述第一应用获取用户登录所述第一应用的上下文信息，包括：
响应于针对所述第一应用的登录操作，所述第一应用向所述第一业务平台发送第二请求，所述第二请求用于请求获取所述上下文信息，所述第二请求包含登录所述第一应用的用户的身份信息；
所述第一应用接收所述第一业务平台针对所述第二请求发送的上下文信息。
4.一种授权信息获取方法，其特征在于，应用于第一业务平台，包括：
所述第一业务平台的第一服务接收第一设备上被使用的第一应用发送的第一请求，所述第一请求用于请求获取授权信息，所述授权信息用于所述第一设备上的第二应用被使用时验证用户的身份，所述第二应用为所述第一应用关联的应用；
响应于所述第一请求，所述第一服务从所述第一业务平台的第二服务获取所述授权信息，并向所述第一应用发送所述授权信息。
5.根据权利要求4所述的方法，其特征在于，所述第一请求包含用户登录所述第一应用的上下文信息，所述方法还包括：
基于所述上下文信息，所述第一服务对用户的登录相关信息进行校验，并在校验通过的情况下，响应于所述第一请求，从所述第二服务获取所述授权信息。
6.根据权利要求5所述的方法，其特征在于，所述方法还包括：
所述第一服务接收所述第一应用发送的第二请求，所述第二请求用于请求获取所述上下文信息，所述第二请求包含登录所述第一应用的用户身份信息；
响应于所述第二请求，所述第一服务向所述第一应用发送所述上下文信息。
7.根据权利4所述的方法，其特征在于，所述响应于所述第一请求，从所述第二服务获取所述授权信息，包括：
所述第一服务向所述第二服务发送第三请求，所述第三请求用于请求获取所述授权信息，所述第三请求包含所述第二应用的身份相关信息；
基于所述身份相关信息，所述第二服务对所述第二应用的身份进行校验，并在校验通过的情况下，向所述第一服务发送所述授权信息。
8.根据权利要求4至7任一项所述的方法，其特征在于，所述第一服务和所述第二服务基于安全机制进行通信。
9.一种授权信息获取装置，其特征在于，包括：
第一发送单元，用于所述第一设备上被使用的第一应用向第一业务平台发送第一请求，所述第一请求用于请求获取授权信息，所述授权信息用于所述第一设备上的第二应用被使用时验证用户的身份，所述第二应用为所述第一应用关联的应用；以及，所述第一应用将接收的授权信息发送给所述第二应用；
第一接收单元，用于所述第一应用接收所述第一业务平台发送的授权信息。
10.一种授权信息获取装置，其特征在于，包括：
第二接收单元，用于所述第一业务平台的第一服务接收第一设备上被使用的第一应用发送的第一请求，所述第一请求用于请求获取授权信息，所述授权信息用于所述第一设备上的第二应用被使用时验证用户的身份，所述第二应用为所述第一应用关联的应用；
第二发送单元，用于响应于所述第一请求，所述第一服务从所述第一业务平台的第二服务获取所述授权信息，并向所述第一应用发送所述授权信息。
11.一种第一设备，其特征在于，包括：第一通信接口及第一处理器；其中，
所述第一处理器，用于利用所述第一通信接口使所述第一设备上被使用的第一应用向第一业务平台发送第一请求，所述第一请求用于请求获取授权信息，所述授权信息用于所述第一设备上的第二应用被使用时验证用户的身份，所述第二应用为所述第一应用关联的应用；以及，
利用所述第一通信接口使所述第一应用接收所述第一业务平台发送的授权信息。
12.一种第一业务平台，其特征在于，包括：第二通信接口及第二处理器；其中，
所述第二通信接口，用于所述第一业务形态的第一服务接收第一设备上被使用的第一应用发送的第一请求，所述第一请求用于请求获取授权信息，所述授权信息用于所述第一设备上的第二应用被使用时验证用户的身份，所述第二应用为所述第一应用关联的应用；
所述第二处理器，用于响应于所述第一请求，所述第一服务从所述第一业务平台的第二服务获取所述授权信息，并利用所述第二通信接口向所述第一应用发送所述授权信息。
13.一种第一设备，其特征在于，包括：第一处理器和用于存储能够在第一处理器上运行的计算机程序的第一存储器；
其中，所述第一处理器用于运行所述计算机程序时，执行权利要求1至3任一项所述方法的步骤。
14.一种第一业务平台，其特征在于，包括：第二处理器和用于存储能够在第二处理器上运行的计算机程序的第二存储器；
其中，所述第二处理器用于运行所述计算机程序时，执行权利要求4至8任一项所述方法的步骤。
15.一种存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至3任一项所述方法的步骤，或者实现权利要求4至8任一项所述方法的步骤。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211190334.0A CN117834158A (zh) | 2022-09-28 | 2022-09-28 | 授权信息获取方法、装置、相关设备及存储介质 |
| PCT/CN2023/120849 WO2024067419A1 (zh) | 2022-09-28 | 2023-09-22 | 授权信息获取方法、装置、相关设备及存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211190334.0A CN117834158A (zh) | 2022-09-28 | 2022-09-28 | 授权信息获取方法、装置、相关设备及存储介质 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117834158A true CN117834158A (zh) | 2024-04-05 |
Family
ID=90476126
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211190334.0A Pending CN117834158A (zh) | 2022-09-28 | 2022-09-28 | 授权信息获取方法、装置、相关设备及存储介质 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN117834158A (zh) |
| WO (1) | WO2024067419A1 (zh) |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8839395B2 (en) * | 2011-05-13 | 2014-09-16 | Cch Incorporated | Single sign-on between applications |
| CN110324276B (zh) * | 2018-03-28 | 2022-01-07 | 腾讯科技（深圳）有限公司 | 一种登录应用的方法、系统、终端和电子设备 |
| CN111538965B (zh) * | 2020-04-15 | 2021-10-12 | 支付宝(杭州)信息技术有限公司 | 一种应用程序的授权登录方法、装置及系统 |
| CN111880953A (zh) * | 2020-07-31 | 2020-11-03 | 北京致远互联软件股份有限公司 | 一种应用程序通信方法、装置、电子设备及存储介质 |
| CN113010874A (zh) * | 2021-02-19 | 2021-06-22 | 建信金融科技有限责任公司 | 登录认证方法、装置、电子设备及计算机可读存储介质 |
-
2022
- 2022-09-28 CN CN202211190334.0A patent/CN117834158A/zh active Pending
-
2023
- 2023-09-22 WO PCT/CN2023/120849 patent/WO2024067419A1/zh unknown
Also Published As
| Publication number | Publication date |
|---|---|
| WO2024067419A1 (zh) | 2024-04-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10397239B2 (en) | Secure access to cloud-based services | |
| US11190501B2 (en) | Hybrid single sign-on for software applications and services using classic and modern identity providers | |
| CN104735066B (zh) | 一种面向网页应用的单点登录方法、装置和系统 | |
| US9038138B2 (en) | Device token protocol for authorization and persistent authentication shared across applications | |
| US9473480B2 (en) | Controlled access | |
| US8650622B2 (en) | Methods and arrangements for authorizing and authentication interworking | |
| JP2020126602A5 (zh) | ||
| CN115021991A (zh) | 未经管理的移动设备的单点登录 | |
| CN108712372B (zh) | 一种客户端接入web第三方登录的方法及系统 | |
| CN102821085A (zh) | 第三方授权登录方法、开放平台及系统 | |
| KR20150036371A (ko) | 클라우드 서버를 위한 바우처 인가 | |
| CN106161475B (zh) | 用户鉴权的实现方法和装置 | |
| US11595215B1 (en) | Transparently using macaroons with caveats to delegate authorization for access | |
| US11606210B1 (en) | Secure activation, service mode access and usage control of IOT devices using bearer tokens | |
| CN111865882A (zh) | 一种微服务认证方法和系统 | |
| US11595389B1 (en) | Secure deployment confirmation of IOT devices via bearer tokens with caveats | |
| US20230020656A1 (en) | Computing session multi-factor authentication | |
| CN113271289A (zh) | 用于资源授权和访问的方法、系统和计算机存储介质 | |
| CN113765655A (zh) | 访问控制方法、装置、设备及存储介质 | |
| CN113472735B (zh) | 一种大数据服务单点登录方法、装置及存储介质 | |
| CN115190483B (zh) | 一种访问网络的方法及装置 | |
| JP2024530949A (ja) | セキュアチャネルの確立方法およびその装置、関連機器、並びに記憶媒体 | |
| CN113765876B (zh) | 报表处理软件的访问方法和装置 | |
| CN117834158A (zh) | 授权信息获取方法、装置、相关设备及存储介质 | |
| CN114090996A (zh) | 多方系统互信认证方法及装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |