CN118114213A - 认证方法、装置、业务平台及存储介质 - Google Patents

认证方法、装置、业务平台及存储介质 Download PDF

Info

Publication number
CN118114213A
CN118114213A CN202211528407.2A CN202211528407A CN118114213A CN 118114213 A CN118114213 A CN 118114213A CN 202211528407 A CN202211528407 A CN 202211528407A CN 118114213 A CN118114213 A CN 118114213A
Authority
CN
China
Prior art keywords
user
information
service
authentication
login
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
Application number
CN202211528407.2A
Other languages
English (en)
Inventor
付丽琴
张勇
刘先
李骏霖
李�浩
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Mobile Communications Group Co Ltd
China Mobile Chengdu ICT Co Ltd
Original Assignee
China Mobile Communications Group Co Ltd
China Mobile Chengdu ICT Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by China Mobile Communications Group Co Ltd, China Mobile Chengdu ICT Co Ltd filed Critical China Mobile Communications Group Co Ltd
Priority to CN202211528407.2A priority Critical patent/CN118114213A/zh
Priority to PCT/CN2023/134739 priority patent/WO2024114636A1/zh
Publication of CN118114213A publication Critical patent/CN118114213A/zh
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Databases & Information Systems (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Data Mining & Analysis (AREA)

Abstract

本申请公开了一种认证方法、装置、业务平台及存储介质。其中，方法包括：业务平台接收第一客户端发送的第一请求，所述第一请求用于请求对用户进行授权；响应于所述第一请求，确定第一信息，所述第一信息包含所述第一客户端的用户认证相关信息；基于所述第一信息，从所述业务平台的至少两个第一服务中确定目标第一服务；不同第一服务对应的用户类型不同；利用所述目标第一服务对所述用户进行身份认证；在身份认证通过的情况下，生成授权信息并将所述授权信息发送到所述第一客户端；所述授权信息用于所述第一客户端从所述业务平台获取资源。本申请公开的方案，能够实现业务平台对不同类型用户进行有效认证和授权。

Description

认证方法、装置、业务平台及存储介质
技术领域
本申请涉及通信领域，尤其涉及一种认证方法、装置、业务平台及存储介质。
背景技术
在开放授权(OAuth，Open Authorization)授权场景下，用户要获取OAuth资源服务器(Resource Server)的资源，需要先通过客户端从OAuth认证/授权服务器(Authorization Server)获取访问令牌(access token)，再利用获取的access token从Resource Server获取资源。而OAuth Authorization Server在向用户发放access token之前，将会对登录的用户进行身份认证。
然而，相关技术中的认证方案，不能有效实现多种类型用户的认证与授权。
发明内容
为解决相关技术问题，本申请实施例提供一种认证方法、装置、业务平台及存储介质。
本申请实施例的技术方案是这样实现的：
本申请实施例提供一种认证方法，应用于业务平台，包括：
接收第一客户端发送的第一请求，所述第一请求用于请求对用户进行授权；
响应于所述第一请求，确定第一信息，所述第一信息包含所述第一客户端的用户认证相关信息；
基于所述第一信息，从所述业务平台的至少两个第一服务中确定目标第一服务；所述第一服务用于对用户进行身份认证，不同第一服务对应的用户类型不同；
利用所述目标第一服务对所述用户进行身份认证；
在身份认证通过的情况下，生成授权信息并将所述授权信息发送到所述第一客户端。
上述方案中，所述利用所述目标第一服务对所述用户进行身份认证，包括：
所述业务平台的第二服务利用所述目标第一服务对所述用户进行身份认证；所述第二服务至少用于对所述用户的登录进行管理；
和/或，
所述业务平台的第三服务利用所述目标第一服务对所述用户进行身份认证；所述第三服务至少用于对所述用户的授权进行管理。
上述方案中，所述方法还包括：
确定第二信息，所述第二信息指示是否对所述用户的登录进行管理；
基于所述第二信息，利用所述目标第一服务对所述用户进行身份认证。
上述方案中，所述基于所述第二信息，利用所述目标第一服务对所述用户进行身份认证，包括以下之一：
在所述第二信息指示对所述用户的登录进行管理的情况下，所述业务平台中的第二服务对所述用户的登录进行管理，并在登录管理过程中，利用所述目标第一服务对所述用户进行身份认证；在身份认证通过的情况下，所述业务平台中的第三服务为所述用户生成所述授权信息；
在所述第二信息指示对所述用户的登录进行管理，所述业务平台中的第二服务对所述用户的登录进行管理，并在登录管理过程中，利用所述目标第一服务对所述用户进行登录身份认证；在登录身份认证通过的情况下，所述业务平台中的第三服务为所述用户进行授权身份认证；在授权身份认证通过的情况下，所述第三服务为所述用户生成所述授权信息；
在所述第二信息指示不对所述用户的登录进行管理的情况下，所述业务平台中的第三服务利用所述目标第一服务对所述用户进行身份认证；在身份认证通过的情况下，所述第三服务为所述用户生成所述授权信息。
上述方案中，所述确定第二信息，包括：
确定第三信息，所述第三信息表征所述第一客户端的授权模式；
基于所述第三信息，确定第二信息。
上述方案中，
在所述第三信息表征所述第一客户端的授权模式包括授权码授权模式或者隐式授权模式的情况下，所述第二信息指示对所述用户的登录进行管理；
或者，
在所述第三信息表征所述第一客户端的授权模式包括密码授权模式或者客户凭证授权模式的情况下，所述第二信息指示不对所述用户的登录进行管理。
上述方案中，所述方法还包括：
在所述第二信息指示对所述用户的登录进行管理，基于所述第一信息，从业务平台的至少两个第二服务中确定目标第二服务；不同第二服务对应的用户类型不同；
利用所述目标第二服务与所述第一客户端进行至少用于用户登录的通信。
上述方案中，所述第一信息包含以下信息至少之一：
第一服务标识；
用户类型；
用户认证接口信息。
上述方案中，所述用户认证接口信息，包括以下之一：
远程调用相关信息；
内部调用相关信息；
用户认证登录相关信息。
上述方案中，所述确定第一信息，包括：
从本地存储的客户端的用户认证相关信息中确定第一信息；
或者，
从所述第一请求中获取第一信息。
上述方案中，所述方法还包括：
配置所述第一客户端的用户认证相关信息并存储。
本申请实施例还提供一种认证装置，包括：
接收单元，用于接收第一客户端发送的第一请求，所述第一请求用于请求对用户进行授权；
确定单元，用于响应于所述第一请求，确定第一信息，所述第一信息包含所述第一客户端的用户认证相关信息；基于所述第一信息，从所述业务平台的至少两个第一服务中确定目标第一服务；所述第一服务用于对用户进行身份认证，不同第一服务对应的用户类型不同；
认证单元，用于利用所述目标第一服务对所述用户进行身份认证；
授权单元，用于在身份认证通过的情况下，生成授权信息并将所述授权信息发送到所述第一客户端；所述授权信息用于所述第一客户端从所述业务平台获取资源。
本申请实施例还提供一种业务平台，包括：通信接口及处理器；其中，
所述通信接口，用于接收第一客户端发送的第一请求，所述第一请求用于请求对用户进行授权；
所述处理器，用于响应于所述第一请求，确定第一信息，所述第一信息包含所述第一客户端的用户认证相关信息；基于所述第一信息，从所述业务平台的至少两个第一服务中确定目标第一服务；所述第一服务用于对用户进行身份认证，不同第一服务对应的用户类型不同；利用所述目标第一服务对所述用户进行身份认证；在身份认证通过的情况下，生成授权信息并将所述授权信息发送到所述第一客户端；所述授权信息用于所述第一客户端从所述业务平台获取资源。
本申请实施例还提供一种业务平台，包括：处理器和用于存储能够在处理器上运行的计算机程序的存储器；
其中，所述处理器用于运行所述计算机程序时，执行上述任一方法的步骤。
本申请实施例还提供一种存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任一方法的步骤。
本申请实施例提供的认证方法、装置、业务平台及存储介质，业务平台接收第一客户端发送的第一请求，所述第一请求用于请求对用户进行授权；响应于所述第一请求，确定第一信息，所述第一信息包含所述第一客户端的用户认证相关信息；基于所述第一信息，从所述业务平台的至少两个第一服务中确定目标第一服务；所述第一服务用于对用户进行身份认证，不同第一服务对应的而用户类型不同；利用所述目标第一服务对所述用户进行身份认证；在身份认证通过的情况下，生成授权信息并向所述第一客户端发送所述授权信息；所述授权信息用于所述第一客户端从所述业务平台获取资源。本申请实施例提供的方案，业务平台能够根据用户的认证相关信息确定用户对应的认证端，从而利用对应的认证端对用户进行身份认证，进而能够在一个业务平台内利用不同认证端对不同类型用户进行身份认证，实现对不同类型用户进行有效认证和授权，从而为不同类型用户提供不同服务跳转或认证。
附图说明
图1为本申请实施例通信的方法流程示意图；
图2为本申请实施例认证方法中登录管理模块架构示意图；
图3为本申请实施例认证方法中未登录管理的流程示意图；
图4为本申请实施例授权获取方法中授权模块的授权信息颁发流程示意图；
图5为本申请应用示例医疗业务平台架构示意图；
图6为本申请应用示例医疗业务平台中用户认证端信息结构示意图；
图7为本申请应用示例用户认证端信息中认证信息结构示意图；
图8为本申请应用示例access token获取方法中用户认证端信息具体实现示意图；
图9为本申请应用示例access token获取方法中第一登录管理功能获取的用户认证端信息示意图；
图10为本申请实施例认证装置结构示意图；
图11为本申请实施例业务平台架构示意图。
具体实施方式
下面结合附图及实施例对本申请再作进一步详细的描述。
业务平台作为综合性的应用平台，可以接收不同类型用户的访问，业务平台通过不同的服务模块为对应类型的用户提供服务。相关技术中，在向用户提供资源之前，业务平台可以基于OAuth协议实现对用户的认证和授权。比如，在医院信息***(HIS，HospitalInformation System)应用场景下，A医院的医生用户可以通过单点登录(SSO，Single SignOn)跳转到B医院业务平台，在此过程中，A医院的业务平台基于OAuth协议对医生用户进行认证和授权。
相关技术中，基于OAuth协议仅能够实现单一的用户认证和授权，即只支持一种OAuth认证路径，不能针对不同的OAuth客户端用户进行有效的认证和授权。比如，在HIS应用场景下，A医院业务平台能够为Web端账户体系和C端账户体系的用户提供服务，其中，Web端账户体系包含医生用户，C端账户体系包含患者用户，具体可以实现为小程序端、应用程序(APP)端、第5代超文本标记语言(H5)端、公众号等，根据OAuth协议定义的认证授权流程，A医院业务平台对Web端账户体系的用户进行认证和授权，或者对C端账户体系的用户进行认证和授权。
然而，业务平台作为综合性的应用平台，需要同时支持不同类型的用户访问。
比如，在医疗应用场景下：
医生端可以通过A医院业务平台(Web端)单点登录(SSO，Single Sign On)跳转到B医院业务平台，或者采用B医院业务平台的账号授权登录到A医院业务平台，在此SSO过程中，A医院业务平台需要利用针对Web端账户体系的认证服务对医生进行认证和授权；
同时，患者端(C端，比如移动端)也可以在采用患者账号登录A医院业务平台提供的患者服务后，通过SSO跳转到B医院业务平台提供的其他患者服务(比如，患者登录A医院业务平台提供的患者服务后，除了可以享受A医院业务平台提供的挂号等业务外，还可以通过SSO跳转到B医院业务平台提供的患者业务享受图文问诊服务)，在此SSO过程中，A医院业务平台还需要利用针对C端账户体系的认证服务对患者进行认证和授权。
因此，业务平台需要支持多种不同类型的用户认证和授权。
基于此，在本申请的各种实施例中，业务平台能够根据用户认证相关信息确定用户对应的认证端，从而利用对应的认证端对用户进行身份认证，进而能够在一个业务平台内利用不同认证端对不同类型用户进行身份认证，实现对不同类型用户进行有效认证和授权，从而为不同类型用户提供不同服务跳转或认证。
本申请实施例提供的认证***中，包括业务平台和第一客户端。下面对业务平台和第一客户端的具体处理过程进行详细说明。
本申请实施例提供了一种认证方法，应用于业务平台，比如，医疗业务平台等；如图1所示，该方法包括：
步骤101：接收第一客户端发送的第一请求，所述第一请求用于请求对用户进行授权；
步骤102：响应于所述第一请求，确定第一信息，所述第一信息包含所述第一客户端的用户认证相关信息；
步骤103：基于所述第一信息，从所述业务平台的至少两个第一服务中确定目标第一服务；所述第一服务用于对用户进行身份认证，不同第一服务对应的用户类型不同；
步骤104：利用所述目标第一服务对所述用户进行身份认证；
步骤105：在身份认证通过的情况下，生成授权信息并将所述授权信息发送到所述第一客户端；所述授权信息用于供所述第一客户端从所述业务平台获取资源。
其中，实际应用时，所述授权信息也可以称为access token，本申请实施例对此不作限定，只要能实现其功能即可。
实际应用时，所述第一客户端可理解为需要进行授权或SSO的平台，包括平台的前端应用和后端平台服务；实际应用时，所述第一客户端也可以称为授权客户端，还可以称为OAuth客户端，本申请实施例对此不作限定，只要能实现其功能即可；其中，所述第一客户端的前端应用运行在终端上，所述接收第一客户端发送的第一请求，可理解为，接收终端上第一客户端的前端应用发送的第一请求；所述终端具体可以是手机、计算机、平板电脑等终端设备。
实际应用时，在步骤102中，所述第一信息也可以称为用户认证端信息，本申请实施例对此不作限定，只要能实现其功能即可。所述第一信息可以理解为所述业务平台为所述第一客户端配置的用户认证信息，具体地，所述第一信息可以包含所述第一服务认证相关的信息，从而使所述业务平台能够确定用于对所述第一客户端进行认证的第一服务。
实际应用时，在得到所述第一信息之前，所述业务平台需要先为所述第一客户端配置所述第一信息。
基于此，在一实施例中，所述方法还可以包括：
配置所述第一客户端的用户认证相关信息并存储。
实际应用时，所述业务平台根据所述第一客户端对应的用户类型，也就是根据所述第一客户端服务的对象，为所述第一客户端配置对应用户认证相关信息；具体地，所述业务平台根据第一客户端的标识(比如，客户端标识(client_id))确定第一客户端服务的用户类型，生成对应的用户认证相关信息，其中，用户认证相关信息用于确定对所述第一客户端进行认证的第一服务。示例性地，在HIS应用场景下，当业务平台根据第一客户端的client_id确定第一客户端对Web端账户体系的用户(医生用户)提供服务时，业务平台将为第一客户端生成Web端账户体系对应的用户认证信息，从而在业务平台接收到第一客户端发送的请求时，根据用户认证信息，跳转到Web端账户体系关联的第一服务进行用户身份认证；当业务平台根据第一客户端的client_id确定第一客户端服务于C端账户体系的用户(患者用户)时，业务平台将为第一客户端生成C端账户体系对应的用户认证信息，从而在业务平台接收到第一客户端发送的请求时，根据用户认证信息，跳转到C端账户体系关联的第一服务进行用户身份认证。实际应用时，所述用户类型也可以称为用户认证端类型，还可以称为用户账户体系，本申请实施例对此不作限定，只要能实现其功能即可。
实际应用时，所述用户类型可以由所述业务平台根据服务具体应用需求进行分类，比如，在HIS应用场景下，可以配置为Web端账户体系包含医生用户，C端账户体系包含患者用户，也可以配置为Web端账户体系包含医生用户和患者用户，C端账户体系包含护工用户；具体如何分类，由所述业务平台根据实际使用需求确定，本申请实施例对此不作限定。
实际应用时，所述业务平台在配置并存储所述第一客户端的用户认证信息后，当接收到所述第一客户端发送的请求时，可以根据所述第一客户端的标识(比如，client_id)，从本地数据库存储的用户认证信息中获取所述第一信息；基于此，在一实施例中，所述确定第一信息，可以包括：从本地存储的客户端的用户认证相关信息中确定第一信息。当然，所述业务平台也可以将配置的用户认证相关信息发送到所述第一客户端，当所述第一客户端发送所述第一请求中，可以在所述第一请求中携带对应用户认证相关信息，从而使所述业务平台所述第一请求中获取所述第一信息；基于此，在一实施例中，所述确定第一信息，可以包括：从所述第一请求中获取第一信息。
实际应用时，所述第一信息可以由一种或多种能够表示第一服务的信息组成，从而使所述业务平台能够根据所述第一信息确定用于认证所述用户的第一服务。
基于此，在一实施例中，所述第一信息包含以下信息至少之一：
第一服务标识；
用户类型；
用户认证接口信息。
实际应用时，所述第一服务标识，用于供所述业务平台识别所述用户对应的第一服务；所述第一服务标识可以由业务平台生成，比如，通用唯一识别码(UUID，UniversallyUnique Identifier)或者全局唯一标识符(GUID，Globally Unique Identifier)，也可以是数据库身份标识号(ID，Identity document)，即在存储注册信息的数据库中所述第一信息的ID。所述第一服务标识也可以称为用户认证端唯一识别符，本申请实施例对此不作限定，只要能实现其功能即可。
实际应用时，所述用户类型，与所述第一服务相关联，所述业务平台可以根据用户类型和第一服务的关联关系，确定所述用户对应的第一服务；实际应用时，所述用户类型可以通过不同形式体现；比如，所述用户类型可以包括超级管理员(admin)或用户(user)，其中，admin代表医生端，对应的第一服务是Web账户体系对应的第一服务，user代表患者端，对应的第一服务是C端账户体系对应的第一服务；再比如，所述用户类型也可以包括1或2，其中，1代表医生端，对应的第一服务是Web账户体系对应的第一服务，2代表患者端，对应的第一服务是C端账户体系对应的第一服务；所述用户类型具体采用哪种体现形式，可以根据实际应用需求来确定，本申请实施例对此不作限定。
实际应用时，所述用户认证接口信息可以包含所述业务平台对所述用户进行认证的接口相关信息，用于供业务平台对用户认证情况进行校验，比如，校验用户是否存在、用户是否被锁定、用户名及密码是否正确等。
在一实施例中，所述用户认证接口信息，可以包括以下之一：
远程调用相关信息；
内部调用相关信息；
用户认证登录相关信息。
具体地，所述业务平台可以采用接口调用或方法调用的方法调用认证接口，即采用接口调用方法或方法调用方法从数据库中调用对应的信息对用户进行认证校验，也可以根据预先配置的用户认证登录路径相关信息确定校验的路径，从而跳转到对应的服务；所述远程调用相关信息，表示当采用远程调用方法调用第一服务时，远程调用接口的相关信息，比如，应用程序接口(API)信息等，其中，API接口信息可以包括restful接口或feign接口等远程过程调用(RPC，Remote Procedure Call)接口的信息)接口的相关信息；所述内部调用相关信息，表示当采用内部调用方式调用第一服务时，内部调用接口的相关信息，比如，服务调用、微服务调用或模块的方法调用的接口信息，其中，方法调用信息可以包含类名、方法名等信息；所述用户认证登录相关信息，表示用户认证逻辑的相关信息，比如，用户认证登录路径信息，其中，用户认证登录路径相关信息可以包含跳转的统一资源定位符(URL，Uniform Resource Locator)等；实际应用时，所述用户认证登录路径相关信息可以由所述业务平台进行主动配置或内置，也可以通过请求传入，本申请实施例对此不作限定。
实际应用时，为了便于实现所述业务平台对所述用户进行身份认证，所述业务平台在配置用户认证接口信息的过程中，对于同一种访问方式(即远程调用方法、内部调用方法或根据配置的用户认证登录相关信息访问)，访问时所采用的接口定义也相同，比如，输出的参数和输入的参数的定义。
实际应用时，所述第一信息还可以包含用户登录交互相关的信息，比如，用户登录交互界面的URL等，本申请实施例对此不作限定。
实际应用时，所述第一服务用于对用户进行认证，具体地，所述业务平台将用用户进行分类后，确定不同的用户类型和对应的第一服务，所述第一服务能够实现对应用户类型用户的认证服务，比如，确定用户是否存在，用户身份是否有效等；所述第一服务也可以称为用户认证端，还可以称为认证端，本申请实施例对此不作限定。
实际应用时，所有的第一服务可以实现在一起，即通过一个功能模块实现，也可以分别实现，即通过两个不同的功能模块实现，本申请实施例对此不作限定；所述第一服务的数量可以根据所述业务平台需要支持的网络架构数量确定，本申请实施例对此不作限定。
相关技术中，OAuth协议定义了客户端类型、client_id、客户端密码(client_secret)等字段；本申请实施例通过在OAuth协议定义的原有字段的基础上，增加所述第一信息，实现为不同需求场景的客户端(即第一客户端)分配对应的第一服务，从而使业务平台能够在接收到第一客户端的请求后，根据第一客户端的第一信息，跳转到不同的第一服务，进而对不同用户进行认证和授权；其中，需要说明的是，OAuth协议中定义的客户端类型是指机密客户端或公开客户端，与所述第一信息不同，与所述用户类型也不相同。实际应用时，针对每个用户，所述第一信息可以与OAuth协议中定义的对应字段信息作为一个整体进行存储，也可以与对应字段信息分开存储并进行关联，本申请实施例对此不作限定。
实际应用时，根据应用场景的不同，所述业务平台对所述用户的身份认证可以包括登录身份认证和授权身份认证，也可以只包括登录身份认证，还可以只包括授权身份认证。
基于此，在一实施例中，所述利用所述目标第一服务对所述用户进行身份认证，可以包括：
所述业务平台的第二服务利用所述目标第一服务对所述用户进行身份认证；所述第二服务至少用于对所述用户的登录进行管理；
和/或，
所述业务平台的第三服务利用所述目标第一服务对所述用户进行身份认证；所述第三服务至少用于对所述用户的授权进行管理。
具体地，所述登录身份认证在所述OAuth客户端的登录阶段进行，可以通过在所述业务平台中的登录管理模块和对应第一服务实现，所述授权身份认证在所述OAuth客户端的授权阶段进行，可以通过所述业务平台中的授权模块和对应第一服务实现；所述登录管理模块用于对所述用户的登录进行管理，所述登录身份认证即所述登录管理模块对所述用户的信息进行认证，所述授权模块用于对所述用户的授权进行管理，所述授权身份认证即所述授权模块对所述用户的信息进行认证；其中，对所述用户的信息进行认证，可以包括对所述用户的的身份信息和登录信息进行认证，比如，确定所述用户是否存在，登录状态是否正确、用户账号密码是否正确等；所述第一服务用于在被所述登录管理模块或所述授权模块的调用时，进行对应的认证操作。
实际应用时，所述登录管理模块和所述授权模块部署在所述业务平台的认证中心，所述第一服务和所述认证中心可以为独立的微服务架构，在小型***或者统一用户中心中，也可以在同一个服务中实现，本申请实施例对此不作限定。
实际应用时，在认证过程中，为了确定需要将所述第一请求发送到所述登录管理模块还是所述授权模块，即确定认证流程的执行逻辑，需要先确定是否需要对所述用户进行登录管理。
基于此，在一实施例中，所述方法还可以包括：
确定第二信息，所述第二信息指示是否对所述用户的登录进行管理；
基于所述第二信息，利用所述目标第一服务对所述用户进行身份认证。
在一实施例中，所述基于所述第二信息，利用所述目标第一服务对所述用户进行身份认证，包括以下之一：
在所述第二信息指示对所述用户的登录进行管理的情况下，所述业务平台中的第二服务对所述用户的登录进行管理，并在管理过程中，利用所述目标第一服务对所述用户进行身份认证；在身份认证通过的情况下，所述业务平台中的第三服务为所述用户生成所述授权信息；
在所述第二信息指示对所述用户的登录进行管理的情况下，所述业务平台中的第二服务对所述用户的登录进行管理，并在登录管理过程中，利用所述目标第一服务对所述用户进行登录身份认证；在登录身份认证通过的情况下，所述业务平台中的第三服务为所述用户进行授权身份认证；在授权身份认证通过的情况下，所述第三服务为所述用户生成所述授权信息；
在所述第二信息指示不对所述用户的登录进行管理的情况下，所述业务平台中的第三服务利用所述目标第一服务对所述用户进行身份认证；在身份认证通过的情况下，所述第三服务为所述用户生成所述授权信息。
实际应用时，是否需要对所述用户的登录进行管理，可以由所述第一客户端的授权模式确定。
基于此，在一实施例中，所述确定第二信息，包括：
确定第三信息，所述第三信息表征所述第一客户端的授权模式；
基于所述第三信息，确定第二信息。
在一实施例中，在所述第三信息表征所述第一客户端的授权模式包括授权码授权模式或者隐式授权模式的情况下，所述第二信息指示对所述用户的登录进行管理；
或者，
在所述第三信息表征所述第一客户端的授权模式包括密码授权模式或者客户端授权模式的情况下，所述第二信息指示不对所述用户的登录进行管理。
实际应用时，针对不同用户类型，所述业务平台对所述用户的登录进行管理的逻辑也不相同。因此，为了在不同场景下实现确定登录认证逻辑，针对每种用户类型，所述登录管理模块可以通过建立对应的第二服务来实现管理对应类型用户的登录认证。
基于此，在一实施例中，所述方法还可以包括：
在所述第二信息指示对所述用户的登录进行管理，基于所述第一信息，从业务平台的至少两个第二服务中确定目标第二服务；不同第二服务对应的用户类型不同；
利用所述目标第二服务与所述第一客户端进行至少用于登录的通信。
具体地，在一实施例中，所述利用所述目标第一服务对所述用户进行身份认证，包括：
所述目标第二服务调用所述目标第一服务对所述用户进行身份认证。
实际应用时，所述第二服务也可以称为登录管理功能，本申请实施例对此不作限定，只要能实现其功能即可。
实际应用时，所述至少两个第二服务可以分开实现，即通过两个不同的功能模块实现，也可以实现在一起，即通过同一个功能模块实现，并通过不同的信息进行识别和处理，本申请实施例对此不作限定。
示例性地，在HIS应用场景下，所述至少两个第二服务实现在一起，即通过同一个功能模块实现不同的第二服务，当第二服务需要实现针对医生端的登录管理功能时，将OAuth协议中的客户端类型(client_type)参数定义为医生(doctor)，当第二服务需要实现针对患者端的登录管理功能时，将OAuth协议中的client_type参数定义为患者(patient)
实际应用时，所述登录管理主要包含登录状态校验和未登录处理两种操作；具体地，所述登录管理模块先判断所述用户的登录状态，在所述用户未登录所述业务平台的情况下，对所述用户进行未登录处理，以引导用户进行对应的登录操作；所述未登录处理包括登录用户交互、登录校验和登录认证；其中，所述用户交互包括第一客户端呈现的登录页面，即人机交互界面，比如，针对医生端呈现的医生登录页面，针对患者呈现的患者登录页面；所述登录校验包括对登录用户的安全性校验，比如，图形验证码校验、短信随机码校验等；所述登录身份认证包括对用户登录信息的校验，比如，校验用户是否存在，是否为登录状态、用户名及密码是否正确等；当登录身份认证通过的情况下，授权模块直接生成授权信息，或者由所述授权模块对所述用户进行授权身份认证。相应地，当所述用户已登录所述业务平台的情况下，则无需再进行未登录身份处理，直接由所述授权模块直接进行授权身份认证。
基于此，在一实施例中，所述第二服务对所述用户的登录进行管理，可以包括：
所述第二服务确认所述用户的登录状态，并在所述用户未登录的情况下，对所述用户进行未登录处理；所述未登录处理包括登录用户交互、登录校验和登录认证。
实际应用时，所述登录校验和所述登录认证可以分开实现，也可以实现在一起，本申请实施例对此不作限定。
其中，对于需要进行未登录处理的用户，不同用户类型对应的服务模块和认证逻辑不同，即不同第二服务的管理方式不同；具体地，不同第二服务定义的未登录处理逻辑不同，比如，登录方式逻辑、登录校验逻辑、登录认证逻辑等，从而在进行未登录处理时，针对不同类型的用户，能够按照对应的处理逻辑进行处理。
示例性地，如图2所示，所述登录管理模块包括两个第二服务，分别用于对Web端账户体系和C端账户体系的用户的登录进行管理；其中，一个第二服务的未登录处理流程包括第一登录用户交互、第一登录校验和第一登录认证，另一个第二服务的未登录处理流程包括第二登录用户交互、第二登录校验和第二登录认证；当所述业务平台接收到所述第一客户端发送的第一请求后，对于需要进行未登录处理的用户，根据所述第一信息，确定进行登录管理需要使用的第二服务，即目标第二服务。
如图3所示，所述未登录处理的过程包括：
步骤301：目标第二服务根据第一信息，从业务平台的客户端管理模块中获取登录交互相关信息；
具体地，根据第一信息中的第一服务标识、用户类型或用户认证接口信息，从OAuth客户端管理模块中获取登录用户交互；这里，所述登录交互相关信息包括所述目标第二服务与所述第一客户端进行交互过程中的参数信息，比如，用户选择的登录方式、登录页面的相关参数等；
步骤302：基于所述登录交互相关信息，执行对应的用户交互，即执行第一登录用户交互或第二登录用户交互；
步骤303：基于所述登录交互相关信息，执行对应的登录校验，即执行第一登录校验或第二登录校验；
步骤304：基于所述登录交互相关信息，调用对应认证端(即第一服务)的用户认证接口信息，对用户的登录信息进行校验；具体地，校验用户是否存在，是否为登录状态、用户名及密码是否正确等。
实际应用时，当所述用户通过登录身份认证，或者所述用户不需要进行登录管理，或者所述用户为已登录状态时，由所述授权模块对所述用户进行身份认证。其中，当所述用户需要进行登录管理时，即所述第一客户端的授权模式为授权码授权模式或隐式授权模式，所述授权模块可以从已登录的用户信息中获取所述用户的用户信息，生成授权信息并发送到所述第一客户端；当所述用户不需要进行登录管理时，即所述第一客户端的授权模式为密码授权模式或客户端授权模块，所述授权模块可以直接调用对应第一服务对所述用户的用户密码信息进行认证，并在认证通过时向所述第一客户端发送授权信息。其中，所述用户密码信息可以携带在所述第一请求中。
示例性地，如图4所示，所述授权模块的授权信息颁发过程包括：
步骤401：基于所述用户认证接口信息，确定所述第一客户端的授权模式，即确定所述第三信息；
步骤402：确定是否需要进行身份认证，即基于所述第三信息，确定第二信息；当需要进行身份认证时，执行步骤403，当不需要进行身份认证时，执行步骤405；
步骤403：根据第一客户端(即OAuth客户端)位移识别符获取用户认证端信息；
步骤404：根据所述用户认证端信息，执行对应的身份认证，并在身份认证通过的情况下，执行步骤405；
具体地，调用对应的第一服务对所述第一客户端进行身份认证；比如，当所述第一客户端的授权模式为密码授权模式的情况下，验证用户名及密码是否正确，用户是否存在，用户密码是否有效等；
步骤405：为所述第一客户端颁发access token；
具体地，为已登录的用户或认证通过的用户颁发access token。
本申请实施例提供的认证方法，业务平台接收第一客户端发送的第一请求，所述第一请求用于请求对用户进行授权；响应于所述第一请求，确定第一信息，所述第一信息包含所述第一客户端的用户认证相关信息；基于所述第一信息，从所述业务平台的至少两个第一服务中确定目标第一服务；所述第一服务用于对用户进行身份认证，不同第一服务对应的用户类型不同；利用所述目标第一服务对所述用户进行身份认证；在身份认证通过的情况下，生成授权信息并将所述授权信息发送到所述第一客户端；所述授权信息用于所述第一客户端从所述业务平台获取资源。本申请实施例提供的方案，业务平台根据用户认证相关信息区分不同类型的用户，并通过不同的认证服务实现对对应类型的用户进行身份认证，从而实现业务平台对多种类型用户的认证和授权。
下面结合应用示例对本申请再作进一步详细的描述。
图5为本申请应用示例医疗业务平台结构示意图，如图5所示，所述医疗业务平台主要包括：Authorization Server、Resource Server、第一认证端501和第二认证端502；其中，Authorization Server和Resource Server组成医疗业务平台的统一认证/授权中心。
下面对OAuth客户端、Authorization Server、Resource Server、第一认证端501和第二认证端502的功能分别进行详细说明。
OAuth客户端，用于请求从所述业务平台获取access token；具体实现可以是B端或C端。
第一认证端501，用于对医生端进行登录认证和身份认证。
第二认证端502，用于对患者端进行登录认证和身份认证。
Authorization Server，用于对所述OAuth客户端进行认证和为所述OAuth客户端颁发access token；所述Authorization Server包括登录管理模块503、code管理模块504、授权模块505和OAuth客户端管理模块506。
登录管理模块503，用于对所述OAuth客户端进行登录管理，比如，验证所述OAuth客户端的登录状态，调用所述第一认证端或所述第二认证端对所述OAuth客户端进行登录认证；其中，所述登录管理模块504包括第一登录管理功能和第二登录管理功能，即第二服务，所述第一登录管理功能用于对医生端进行登录管理，所述第二登录管理功能用于对患者端进行登录管理。
code管理模块504，用于对code进行管理。
授权模块505，用于对所述OAuth客户端进行身份认证，以及为所述OAuth客户端颁发access token。
OAuth客户端管理模块506，用于对用户认证端信息进行管理。其中，如图6所示，所述用户认证端信息包括用户信息和认证信息，其中，用户信息包含client_id和client_secret，认证信息包含用户认证端唯一识别符、用户认证端类型和用户认证接口信息，如图7所示；将所述用户认证端信息进行存储时，可以将所述用户信息和所述认证信息进行组合后存储在一起，也可以将所述用户信息和所述认证信息分别存储，并进行关联，从而使所述业务平台可以根据所述用户信息获取对应的用户认证端信息。
下面基于上述架构图，结合不同的应用场景，对本申请应用示例进行进一步说明。
应用示例一
本申请应用示例中，从OAuth客户端管理模块中获取用户认证端信息，所述用户认证端信息包含用户认证接口信息和登录相关的信息，具体实现如图8所示；其中，用户认证API接口采用内部restful接口或微服务架构的Feign接口。
本申请应用示例access token获取方法，包括：
步骤1：医生端(Web端)通过SSO服务跳转到某三方Web服务时，OAuth客户端管理模块识别该医生端的客户端标识为web_client1，为该三方服务生成一个对应的OAuth客户端标识web_client2，用于指示该三方服务的认证端类型为Web用户认证端，从而形成web端用户的SSO闭环；其中，web_client1与web_client2的配置相同；
步骤2：Authorization Server从接口信息中获取医生端的授权模式为授权码授权模；
步骤3：第一登录管理功能确定用户未登录，从医生端的请求参数中确定client_id为web_client1；
步骤4：第一登录管理功能从OAuth客户端管理模块中获取用户认证端信息，用户认证端信息包括登录信息和api接口信息，如图9所示；
步骤5：第一登录管理功能基于获取的信息，进行用户登录交互和用户校验；
步骤6：第一登录管理功能基于用户认证端信息，调用第一认证端对医生端进行登录认证，并在登录认证通过的情况下，执行步骤7；所述登录认证具体包括确定用户是否存在、是否登录、用户名密码是否正确等；
步骤7：授权模块基于用户认证端信息，调用第一认证端对医生端进行身份认证，并在身份认证通过的情况下，为医生端颁发access token；所述身份认证具体包括确定用户是否存在、是否登录、用户名密码是否正确等；。
应用示例二
本申请应用示例中，从OAuth客户端管理模块中获取用户认证端信息，所述用户认证端信息包含用户认证接口信息和登录相关的信息，具体实现如图8所示；其中，用户认证API接口采用内部restful接口或微服务架构的Feign接口。
本申请应用示例access token获取方法，包括：
步骤1：患者端(H5端)通过SSO服务跳转到某三方H5服务时，OAuth客户端管理模块为该三方服务生成一个对应的OAuth客户端标识h5_client1，用于指示该三方H5服务的认证端类型为C端用户认证端，从而形成C端用户的SSO闭环；其中，h5_client1的配置与C端用户认证体系的配置相同；
步骤2：Authorization Server从接口信息中获取患者端的授权模式为授权码授权模；
步骤3：第二登录管理功能确定用户未登录，从患者端的请求参数中确定client_id为H5_client1；
步骤4：第二登录管理功能从OAuth客户端管理模块中获取用户认证端信息，用户认证端信息包括登录信息和api接口信息，如图9所示；
步骤5：第二登录管理功能基于获取的信息，进行用户登录交互和用户校验；
步骤6：第二登录管理功能基于用户认证端信息，调用第二认证端对患者端进行登录认证，并在登录认证通过的情况下，执行步骤7；所述登录认证具体包括确定用户是否存在、是否登录、用户名密码是否正确等；
步骤7：授权模块基于用户认证端信息，调用第二认证端对患者端进行身份认证，并在身份认证通过的情况下，为患者端颁发access token；所述身份认证具体包括确定用户是否存在、是否登录、用户名密码是否正确等。
应用示例3
本申请应用示例中，医疗业务平台从OAuth客户端发送的请求中获取用户认证端信息。
本申请应用示例access token获取方法，包括：
步骤1：医生端(Web端)向Authorization Server发送access token获取请求，请求中携带用户认证端信息，用户认证端信息包含client_Type；其中，client_Type为1，代表用户认证端是B端用户；
步骤2：Authorization Server获取请求参数中的client_id为Web_client1，client_Type为1，确定OAuth客户端为医生端，并判断用户未登录，将请求转至第一登录管理功能进行处理；
步骤3：第一登录管理功能对患者端进行登录交互和登录校验。
步骤4：第一登录管理功能基于用户认证端信息，调用第一认证端对医生端进行用户登录认证，并在登录认证通过的情况下，执行步骤5；所述登录认证具体包括确定用户是否存在、是否登录、用户名密码是否正确等；
步骤5：授权模块基于用户认证端信息，调用第一认证端对医生端进行身份认证，并在身份认证通过的情况下，为医生端颁发access token；所述身份认证具体包括确定用户是否存在、是否登录、用户名密码是否正确等；。
应用示例四
本申请应用示例中，医疗业务平台从OAuth客户端发送的请求中获取用户认证端信息。
本申请应用示例access token获取方法，包括：
步骤1：患者端(H5端)向Authorization Server发送access token获取请求，请求中携带用户认证端信息，用户认证端信息包含client_Type；其中，client_Type为2，代表用户认证端是C端用户；
步骤2：Authorization Server获取请求参数中的client_id为h5_client1，client_Type为2，确定OAuth客户端为患者端，并判断用户未登录，将请求转至第二登录管理功能进行处理；
步骤3：第二登录管理功能对患者端进行登录交互和登录校验。
步骤4：基于用户认证端信息，对患者端进行用户登录认证，并在登录认证通过的情况下，执行步骤5；所述登录认证具体包括确定用户是否存在、是否登录、用户名密码是否正确等；
步骤5：授权模块基于用户认证端信息，调用第二认证端对患者端进行身份认证，并在身份认证通过的情况下，为患者端颁发access token；所述身份认证具体包括确定用户是否存在、是否登录、用户名密码是否正确等；。
本申请应用示例通过第一登录管理功能和第二登录管理功能，对不同账户体系(医生端和患者端)的登录管理流程进行识别和管理，通过第一认证端和第二认证端对不同账户体系的OAuth客户端进行认证，从而实现同一个业务平台同时支持多种账户体系的认证和授权，同时，无需额外自定义开发业务平台，也无需部署多个认证/授权中心，且能够兼容针对多种账户体系的OAuth客户端的认证；进一步地，本申请应用示例在OAuth协议定义的字段的基础上，增加了用户认证端信息的定提升OAuth授权过程的安全性。
为了实现本申请的方法，本申请实施例还提供了一种认证装置，设置在业务平台上，如图10所示，该装置包括：
接收单元1001，用于接收第一客户端发送的第一请求，所述第一请求用于请求对用户进行授权；
确定单元1002，用于响应于所述第一请求，确定第一信息，所述第一信息包含所述第一客户端的用户认证相关信息；基于所述第一信息，从所述业务平台的至少两个第一服务中确定目标第一服务；所述第一服务用于对用户进行身份认证，不同第一服务对应的用户类型不同；
认证单元1003，用于利用所述目标第一服务对所述用户进行身份认证；
授权单元1004，用于在身份认证通过的情况下，生成授权信息并将所述授权信息发送到第一客户端；所述授权信息用于供所述第一客户端从所述业务平台获取资源。
在一实施例中，所述认证单元1003，具体用于：
所述业务平台的第二服务利用所述目标第一服务对所述用户进行身份认证；所述第二服务至少用于对所述用户的登录进行管理；
和/或，
所述业务平台的第三服务利用所述目标第一服务对所述用户进行身份认证；所述第三服务至少用于对所述用户的授权进行管理。
在一实施例中，所述确定单元1002，还可以用于：
确定第二信息，所述第二信息指示是否对所述用户的登录进行管理；
基于所述第二信息，利用所述目标第一服务对所述用户进行身份认证。
在一实施例中，所述确定单元1002，具体用于以下之一：
在所述第二信息指示对所述用户的登录进行管理，所述业务平台中的第二服务对所述用户的登录进行管理，并在登录管理过程中，利用所述目标第一服务对所述用户进行身份认证；在身份认证通过的情况下，所述业务平台中的第三服务为所述用户生成所述授权信息；
在所述第二信息指示对所述用户的登录进行管理的情况下，所述业务平台中的第二服务对所述用户的登录进行管理，并在登录管理过程中，利用所述目标第一服务对所述用户进行登录身份认证；在登录身份认证通过的情况下，所述业务平台中的第三服务为所述用户进行授权身份认证；在授权身份认证通过的情况下，所述第三服务为所述用户生成所述授权信息；
在所述第二信息指示不对所述用户的登录进行管理的情况下，所述业务平台中的第三服务利用所述目标第一服务对所述用户进行身份认证；在身份认证通过的情况下，所述第三服务为所述用户生成所述授权信息。
在一实施例中，所述确定单元1002，具体用于：
确定第三信息，所述第三信息表征所述第一客户端的授权模式；
基于所述第三信息，确定第二信息。
在一实施例中，在所述第三信息表征所述第一客户端的授权模式包括授权码授权模式或者隐式授权模式的情况下，所述第二信息指示对所述用户的登录进行管理；
或者，
在所述第三信息表征所述第一客户端的授权模式包括密码授权模式或者客户凭证授权模式的情况下，所述第二信息指示不对所述用户的登录进行管理。
在一实施例中，所述确定单元1002，还用于：
在所述第二信息指示对所述用户的登录进行管理的情况下，基于所述第一信息，从业务平台的至少两个第二服务中确定目标第二服务；不同第二服务对应的用户类型不同；
利用所述目标第二服务与所述第一客户端进行至少用于用户登录的通信。
在一实施例中，所述第一信息包含以下信息至少之一：
第一服务标识；
用户类型；
用户认证接口信息。
在一实施例中，所述用户认证接口信息，包括以下之一：
远程调用相关信息；
内部调用相关信息；
用户认证登录相关信息。
在一实施例中，所述确定单元1002，具体用于：
从本地存储的客户端的用户认证相关信息中确定第一信息；
或者，
从所述第一请求中获取第一信息。
在一实施例中，所述装置还包括：
配置单元，用于配置所述第一客户端的用户认证相关信息并存储。
实际应用时，接收单元1001可由认证装置中的处理器结合通信接口实现，确定单元1002、认证单元1003、授权单元1004和配置单元可由认证装置中的处理器实现。
需要说明的是：上述实施例提供的认证装置在获取授权信息时，仅以上述各程序模块的划分进行举例说明，实际应用中，可以根据需要而将上述处理分配由不同的程序模块完成，即将装置的内部结构划分成不同的程序模块，以完成以上描述的全部或者部分处理。另外，上述实施例提供的认证装置与认证方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。
基于上述程序模块的硬件实现，且为了实现本申请实施例业务平台侧的方法，本申请实施例还提供了一种业务平台，如图11所示，该业务平台1100包括：
通信接口1101，能够与第一客户端进行信息交互；比如，接收第一客户端发送的第一请求，向第一客户端发送授权信息；
处理器1102，与所述通信接口1101连接，以实现与第一客户端进行信息交互，用于运行计算机程序时，执行上述业务平台侧一个或多个技术方案提供的方法；
存储器1103，所述计算机程序存储在所述存储器1103上。
具体地，所述通信接口1101，用于接收第一客户端发送的第一请求，所述第一请求用于请求为用户进行授权；
所述处理器1102，用于响应于所述第一请求，确定第一信息，所述第一信息包含所述第一客户端的用户认证相关信息；基于所述第一信息，从所述业务平台的至少两个第一服务中确定目标第一服务；所述第一服务用于对用户进行身份认证，不同第一服务对应的用户类型不同；利用所述目标第一服务对所述用户进行身份认证；在身份认证通过的情况下，生成授权信息并利用所述通信接口1101将所述授权信息发送到所述第一客户端；所述授权信息用于所述第一客户端从所述业务平台获取资源。
在一实施例中，所述处理器1102，具体用于：
所述业务平台的第二服务利用所述目标第一服务对所述用户进行身份认证；所述第二服务至少用于对所述用户的登录进行管理；
和/或，
所述业务平台的第三服务利用所述目标第一服务对所述用户进行身份认证；所述第三服务至少用于对所述用户的授权进行管理
在一实施例中，所述处理器1102，还用于：
确定第二信息，所述第二信息指示是否对所述用户的登录进行管理；
基于所述第二信息，利用所述目标第一服务对所述用户进行身份认证。
所述处理器1102，具体用于以下之一：
在所述第二信息指示对所述用户的登录进行管理的情况下，所述业务平台中的第二服务对所述用户的登录进行管理，并在登录管理过程中，利用所述目标第一服务对所述用户进行身份认证；在身份认证通过的情况下，所述业务平台中的第三服务为所述用户生成所述授权信息；
在所述第二信息指示对所述用户的登录进行管理的情况下，所述业务平台中的第二服务对所述用户的登录进行管理，并在登录管理过程中，利用所述目标第一服务对所述用户进行登录身份认证；在登录身份认证通过的情况下，所述业务平台中的第三服务为所述用户进行授权身份认证；在授权身份认证通过的情况下，所述第三服务为所述用户生成所述授权信息；
在所述第二信息指示不对所述用户的登录进行管理的情况下，所述业务平台中的第三服务利用所述目标第一服务对所述用户进行身份认证；在身份认证通过的情况下，所述第三服务为所述用户生成所述授权信息。
在一实施例中，所述处理器1102，具体用于：
确定第三信息，所述第三信息表征所述第一客户端的授权模式；
基于所述第三信息，确定第二信息。
在一实施例中，所在所述第三信息表征所述第一客户端的授权模式包括授权码授权模式或者隐式授权模式的情况下，所述第二信息指示对所述用户的登录进行管理；
或者，
在所述第三信息表征所述第一客户端的授权模式包括密码授权模式或者客户凭证授权模式的情况下，所述第二信息指示不对所述用户的登录进行管理。
在一实施例中，所述处理器1102，还用于：
在所述第二信息指示对所述用户的登录进行管理的情况下，基于所述第一信息，从业务平台的至少两个第二服务中确定目标第二服务；不同第二服务对应的用户类型不同；
利用所述目标第二服务与所述第一客户端进行至少用于用户登录的通信。
在一实施例中，所述处理器1102，具体用于：
所述目标第二服务调用所述目标第一服务对第一客户端进行登录认证。
在一实施例中，所述第一信息包含以下信息至少之一：
第一服务标识；
用户类型；
用户认证接口信息。
在一实施例中，所述用户认证接口信息，包括以下之一：
远程调用相关信息；
内部调用相关信息；
用户认证登录相关信息。
在一实施例中，所述处理器1102，具体用于：
从本地存储的客户端的用户认证相关信息中确定第一信息；或者，从所述第一请求中获取第一信息。
在一实施例中，所述处理器1102，还可以用于：
配置所述第一客户端的用户认证相关信息并存储。
需要说明的是：处理器1102和通信接口1101的具体处理过程可参照上述方法理解。
当然，实际应用时，业务平台1100中的各个组件通过总线***1104耦合在一起。可理解，总线***1104用于实现这些组件之间的连接通信。总线***1104除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图11中将各种总线都标为总线***1104。
本申请实施例中的存储器1103用于存储各种类型的数据以支持业务平台1100的操作。这些数据的示例包括：用于在业务平台1100上操作的任何计算机程序。
上述本申请实施例揭示的方法可以应用于所述处理器1102中，或者由所述处理器1102实现。所述处理器1102可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过所述处理器1102中的硬件的集成逻辑电路或者软件形式的指令完成。上述的所述处理器1102可以是通用处理器、数字信号处理器(DSP，DigitalSignal 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)、或者其他电子元件实现，用于执行前述方法。
可以理解，本申请实施例的存储器(存储器1103)可以是易失性存储器或者非易失性存储器，也可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(ROM，Read Only Memory)、可编程只读存储器(PROM，Programmable Read-OnlyMemory)、可擦除可编程只读存储器(EPROM，Erasable Programmable Read-Only Memory)、电可擦除可编程只读存储器(EEPROM，Electrically Erasable Programmable Read-OnlyMemory)、磁性随机存取存储器(FRAM，ferromagnetic random access memory)、快闪存储器(Flash Memory)、磁表面存储器、光盘、或只读光盘(CD-ROM，Compact Disc Read-OnlyMemory)；磁表面存储器可以是磁盘存储器或磁带存储器。易失性存储器可以是随机存取存储器(RAM，Random Access Memory)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(SRAM，Static Random Access Memory)、同步静态随机存取存储器(SSRAM，Synchronous Static Random Access Memory)、动态随机存取存储器(DRAM，Dynamic Random Access Memory)、同步动态随机存取存储器(SDRAM，Synchronous Dynamic Random Access Memory)、双倍数据速率同步动态随机存取存储器(DDRSDRAM，Double Data Rate Synchronous Dynamic Random Access Memory)、增强型同步动态随机存取存储器(ESDRAM，Enhanced Synchronous Dynamic Random AccessMemory)、同步连接动态随机存取存储器(SLDRAM，SyncLink Dynamic Random AccessMemory)、直接内存总线随机存取存储器(DRRAM，Direct Rambus Random Access Memory)。本申请实施例描述的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
在示例性实施例中，本申请实施例还提供了一种存储介质，即计算机存储介质，具体为计算机可读存储介质，例如包括存储计算机程序的存储器1103，上述计算机程序可由业务平台1100的处理器1102执行，以完成前述业务平台侧方法所述步骤。计算机可读存储介质可以是FRAM、ROM、PROM、EPROM、EEPROM、Flash Memory、磁表面存储器、光盘、或CD-ROM等存储器。
需要说明的是：“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。
另外，本申请实施例所记载的技术方案之间，在不冲突的情况下，可以任意组合。
以上所述，仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围。

Claims (14)

1.一种认证方法，其特征在于，应用于业务平台，包括：
接收第一客户端发送的第一请求，所述第一请求用于请求对用户进行授权；
响应于所述第一请求，确定第一信息，所述第一信息包含所述第一客户端的用户认证相关信息；
基于所述第一信息，从所述业务平台的至少两个第一服务中确定目标第一服务；所述第一服务用于对用户进行身份认证，不同第一服务对应的用户类型不同；
利用所述目标第一服务对所述用户进行身份认证；
在身份认证通过的情况下，生成授权信息并将所述授权信息发送到所述第一客户端。
2.根据权利要求1所述的方法，其特征在于，所述利用所述目标第一服务对所述用户进行身份认证，包括：
所述业务平台的第二服务利用所述目标第一服务对所述用户进行身份认证；所述第二服务至少用于对所述用户的登录进行管理；
和/或，
所述业务平台的第三服务利用所述目标第一服务对所述用户进行身份认证；所述第三服务至少用于对所述用户的授权进行管理。
3.根据权利要求1所述的方法，其特征在于，所述方法还包括：
确定第二信息，所述第二信息指示是否对所述用户的登录进行管理；
基于所述第二信息，利用所述目标第一服务对所述用户进行身份认证。
4.根据权利要求3所述的方法，其特征在于，所述基于所述第二信息，利用所述目标第一服务对所述用户进行身份认证，包括以下之一：
在所述第二信息指示对所述用户的登录进行管理的情况下，所述业务平台中的第二服务对所述用户的登录进行管理，并在登录管理过程中，利用所述目标第一服务对所述用户进行身份认证；在身份认证通过的情况下，所述业务平台中的第三服务为所述用户生成所述授权信息；
在所述第二信息指示对所述用户的登录进行管理的情况下，所述业务平台中的第二服务对所述用户的登录进行管理，并在登录管理过程中，利用所述目标第一服务对所述用户进行登录身份认证；在登录身份认证通过的情况下，所述业务平台中的第三服务为所述用户进行授权身份认证；在授权身份认证通过的情况下，所述第三服务为所述用户生成所述授权信息；
在所述第二信息指示不对所述用户的登录进行管理的情况下，所述业务平台中的第三服务利用所述目标第一服务对所述用户进行身份认证；在身份认证通过的情况下，所述第三服务为所述用户生成所述授权信息。
5.根据权利要求3所述的方法，其特征在于，所述确定第二信息，包括：
确定第三信息，所述第三信息表征所述第一客户端的授权模式；
基于所述第三信息，确定第二信息。
6.根据权利要求5所述的方法，其特征在于，
在所述第三信息表征所述第一客户端的授权模式包括授权码授权模式或者隐式授权模式的情况下，所述第二信息指示对所述用户的登录进行管理；
或者，
在所述第三信息表征所述第一客户端的授权模式包括密码授权模式或者客户凭证授权模式的情况下，所述第二信息指示不对所述用户的登录进行管理。
7.根据权利要求3所述的方法，其特征在于，所述方法还包括：
在所述第二信息指示对所述用户的登录进行管理的情况下，基于所述第一信息，从业务平台的至少两个第二服务中确定目标第二服务；不同第二服务对应的用户类型不同；
利用所述目标第二服务与所述第一客户端进行至少用于用户登录的通信。
8.根据权利要求1所述的方法，其特征在于，所述第一信息包含以下信息至少之一：
第一服务标识；
用户类型；
用户认证接口信息。
9.根据权利要求8所述的方法，其特征在于，所述用户认证接口信息，包括以下之一：
远程调用相关信息；
内部调用相关信息；
用户认证登录相关信息。
10.根据权利要求1至9任一项所述的方法，其特征在于，所述确定第一信息，包括：
从本地存储的客户端的用户认证相关信息中确定第一信息；
或者，
从所述第一请求中获取第一信息。
11.根据权利要求10所述的方法，其特征在于，所述方法还包括：
配置所述第一客户端的用户认证相关信息并存储。
12.一种认证装置，其特征在于，包括：
接收单元，用于接收第一客户端发送的第一请求，所述第一请求用于请求对用户进行授权；
确定单元，用于响应于所述第一请求，确定第一信息，所述第一信息包含所述第一客户端的用户认证相关信息；基于所述第一信息，从所述业务平台的至少两个第一服务中确定目标第一服务；所述第一服务用于对用户进行身份认证，不同第一服务对应的用户类型不同；
认证单元，用于利用所述目标第一服务对所述用户进行身份认证；
授权单元，用于在身份认证通过的情况下，生成授权信息并将所述授权信息发送到所述第一客户端；所述授权信息用于所述第一客户端从所述业务平台获取资源。
13.一种业务平台，其特征在于，包括：处理器和用于存储能够在处理器上运行的计算机程序的存储器；
其中，所述处理器用于运行所述计算机程序时，执行权利要求1至11任一项所述方法的步骤。
14.一种存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至11任一项所述方法的步骤。
CN202211528407.2A 2022-11-30 2022-11-30 认证方法、装置、业务平台及存储介质 Pending CN118114213A (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202211528407.2A CN118114213A (zh) 2022-11-30 2022-11-30 认证方法、装置、业务平台及存储介质
PCT/CN2023/134739 WO2024114636A1 (zh) 2022-11-30 2023-11-28 认证方法、装置、业务平台及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211528407.2A CN118114213A (zh) 2022-11-30 2022-11-30 认证方法、装置、业务平台及存储介质

Publications (1)

Publication Number Publication Date
CN118114213A true CN118114213A (zh) 2024-05-31

Family

ID=91207487

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211528407.2A Pending CN118114213A (zh) 2022-11-30 2022-11-30 认证方法、装置、业务平台及存储介质

Country Status (2)

Country Link
CN (1) CN118114213A (zh)
WO (1) WO2024114636A1 (zh)

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10846390B2 (en) * 2016-09-14 2020-11-24 Oracle International Corporation Single sign-on functionality for a multi-tenant identity and data security management cloud service
CN110826043B (zh) * 2018-08-08 2022-11-25 腾讯科技（深圳）有限公司 一种数字身份申请***及方法、身份认证***及方法
CN111541656B (zh) * 2020-04-09 2022-09-16 中央电视台 基于融合媒体云平台的身份认证方法及***
CN115225299B (zh) * 2021-04-19 2023-06-27 中国科学院计算机网络信息中心 用户认证方法、服务器和***
CN114095266B (zh) * 2021-11-19 2023-09-19 深圳市雷鸟网络传媒有限公司 登录认证方法、装置、电子设备及可读存储介质
CN114745178A (zh) * 2022-04-11 2022-07-12 中国南方电网有限责任公司 身份认证方法、装置、计算机设备、存储介质和程序产品

Also Published As

Publication number Publication date
WO2024114636A1 (zh) 2024-06-06

Similar Documents

Publication Publication Date Title
US10764286B2 (en) System and method for proxying federated authentication protocols
CN109309683B (zh) 基于token的客户端身份验证的方法及***
CN106487774B (zh) 一种云主机服务权限控制方法、装置和***
US8522333B2 (en) Client/server system for communicating according to the standard protocol OPC UA and having single sign-on mechanisms for authenticating, and method for performing single sign-on in such a system
CN112468481B (zh) 一种基于CAS的单页和多页web应用身份集成认证方法
CN105144111A (zh) 用于不同web服务架构的中继服务
KR20040049272A (ko) 네트워크 위치의 하위 위치에 대한 사용자의 인증을 위한방법 및 시스템
Shah et al. Multi-factor Authentication as a Service
KR20130109322A (ko) 통신 시스템에서 사용자 인증을 대행하는 장치 및 방법
CN112491776B (zh) 安全认证方法及相关设备
CN113746633A (zh) 物联网设备绑定方法、装置、***、云服务器和存储介质
CN104717648A (zh) 一种基于sim卡的统一认证方法和设备
CN114745431B (zh) 基于边车技术的无侵入式权限认证方法、***、介质和设备
CN112543169A (zh) 一种认证方法、装置、终端及计算机可读存储介质
CN112187465B (zh) 无感登录方法、装置、计算机设备和存储介质
CN109962892A (zh) 一种登录应用的认证方法及客户端、服务器
CN113765655A (zh) 访问控制方法、装置、设备及存储介质
CN116192483A (zh) 认证鉴权方法、装置、设备及介质
CN112953892B (zh) 第三方***的访问认证方法和装置
CN118114213A (zh) 认证方法、装置、业务平台及存储介质
CN117134927A (zh) 一种基于Kong网关的登录校验方法及相关设备
CN113452677A (zh) 一种请求处理方法、***、设备以及介质
KR20210037722A (ko) 인증 방법, 보조 인증 컴포넌트, 관리 서버 및 컴퓨터 판독 가능 매체
CN114579951A (zh) 业务访问方法、电子设备及存储介质
CN117834158A (zh) 授权信息获取方法、装置、相关设备及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination