Methods, devices, equipment and storage media for business access

By receiving the client's initial access request, determining the access token and key based on the access channel identifier, generating and verifying the business access request, the problem of poor security in existing technologies is solved, and more secure and efficient business access is achieved.

CN118748597BActive Publication Date: 2026-03-13CHINA CONSTRUCTION BANK +1
View PDF 2 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-06-07
Publication Date
2026-03-13

AI Technical Summary

Technical Problem

In existing technologies, relying solely on access tokens and access keys for business access results in poor security.

Method used

Receive the initial access request sent by the client, determine the access token and access key based on the access channel identifier, return them to the client to generate a business access request, and verify the access level. If the verification is successful, obtain the business access link.

Benefits of technology

It improves the security and efficiency of business access by enhancing the security and accuracy of the access process through customized processing for different access channels and business scenarios.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN118748597B_ABST
    Figure CN118748597B_ABST
Patent Text Reader

Abstract

This application provides a method, apparatus, device, and storage medium for business access. It relates to the field of big data technology. The method includes: receiving an initial access request sent by a client; determining the corresponding access token and access key based on the identifier of the access channel included in the initial access request; returning the access token and access key to the client that sent the initial access request, so that the client generates a business access request based on the received access token and access key, and the access level; receiving the business access request sent by the client, and verifying the business access request according to the access level corresponding to the business access request; if the verification passes, obtaining the business access link corresponding to the business access request, and sending the business access link to the client, so that the client can access the business corresponding to the business access link. The method of this application solves the problem of poor security in the prior art.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of big data technology, and in particular to a method, apparatus, device and storage medium for business access. Background Technology

[0002] With the rapid expansion of business scenarios, during client-side business access, servers typically need to send external link addresses to the requesting client to complete the access. However, directly sending external link addresses raises access security issues, further jeopardizing user information security and application service security.

[0003] In existing technologies, the server generates an access token and an access key based on the access request sent by the user, and sends them to the user so that the user can access services based on the received access token and access key.

[0004] However, relying solely on access tokens and access keys for business access can lead to poor security. Summary of the Invention

[0005] This application provides a method, apparatus, device, and storage medium for business access, in order to solve the problem of poor security in the prior art.

[0006] Firstly, this application provides a method for accessing services, including:

[0007] Receive an initial access request sent by the client; wherein the initial access request includes an identifier of the access channel; the identifier of the access channel indicates the type of access channel;

[0008] Based on the identifier of the access channel included in the initial access request, determine the corresponding access token and access key;

[0009] The access token and access key are returned to the client that sent the initial access request, so that the client can generate a business access request based on the received access token and access key, as well as the access level; wherein, the access level represents the security level of the business scenario accessed by the business access request;

[0010] Receive the service access request sent by the client, and verify the service access request according to the access level corresponding to the service access request;

[0011] If the verification passes, the business access link corresponding to the business access request is obtained and sent to the client so that the client can access the business corresponding to the business access link.

[0012] In one possible design, the access levels include: a first access level, a second access level, and a third access level, wherein the first access level indicates that the business scenario accessed by the business access request is a public information query scenario; the second access level indicates that the business scenario accessed by the business access request is a business information query scenario; and the third access level indicates that the business scenario accessed by the business access request is a business processing scenario.

[0013] In one possible design, if the access level corresponding to the service access request is the first access level, the service access request is verified, including: extracting an access token from the service access request, and performing a first verification on the service access request based on the extracted access token to obtain a verification result of the first verification; if the verification result of the first verification is that the verification passes, then decrypting the service access request based on the access key corresponding to the access token to obtain a decryption result of the service access request; and performing a second verification on the service access request based on the decryption result of the service request.

[0014] In one possible design, the business access request further includes: login status information, a business scenario identifier, and an identifier of the access channel; if the access level corresponding to the business access request is the second access level, the business access request is verified, including: extracting an access token from the business access request, and performing a first verification on the business access request based on the extracted access token to obtain a first verification result; if the first verification result is successful, then decrypting the business access request based on the access key corresponding to the access token to obtain a decryption result; performing a second verification on the business access request based on the decryption result to obtain a second verification result; if the second verification result is successful, then extracting the login status information, the business scenario identifier, and the identifier of the access channel from the decrypted access request, and performing a third verification on the business access request based on the extracted login status information, the business scenario identifier, and the identifier of the access channel.

[0015] In one possible design, the business access request further includes: business process information, a business scenario identifier, and an identifier of the access channel; if the access level corresponding to the business access request is the third access level, the business access request is verified, including: extracting an access token from the business access request, and performing a first verification on the business access request based on the extracted access token to obtain a verification result of the first verification; if the verification result of the first verification is successful, then decrypting the business access request based on the access key corresponding to the access token to obtain a decryption result of the business access request; performing a second verification on the business access request based on the decryption result of the business request to obtain a verification result of the second verification; if the verification result of the second verification is successful, then extracting the business process information, the business scenario identifier, and the identifier of the access channel from the decrypted access request, and performing a third verification on the business access request based on the extracted business process information, the business scenario identifier, and the identifier of the access channel.

[0016] In one possible design, obtaining the business access link corresponding to the business access request includes: obtaining the initial business access link corresponding to the business access request; and encrypting the link according to the determined access key to obtain the business access link.

[0017] In one possible design, determining the corresponding access token and access key based on the identifier of the access channel included in the initial access request includes: determining the corresponding access token and access key acquisition method based on the identifier of the access channel included in the initial access request; and acquiring the corresponding access key based on the corresponding access key acquisition method.

[0018] Secondly, this application provides a service access apparatus, comprising:

[0019] A receiving module is used to receive an initial access request sent by a client; wherein the initial access request includes an identifier of an access channel; the identifier of the access channel indicates the type of access channel;

[0020] The determining module is used to determine the corresponding access token and access key based on the identifier of the access channel included in the initial access request;

[0021] The sending module is used to return the access token and access key to the client that sent the initial access request, so that the client can generate a business access request based on the received access token and access key, as well as the access level; wherein, the access level represents the security level of the business scenario accessed by the business access request;

[0022] The verification module is used to receive the service access request sent by the client and verify the service access request according to the access level corresponding to the service access request.

[0023] The access module is used to obtain the business access link corresponding to the business access request if the verification is successful, and send the business access link to the client so that the client can access the business corresponding to the business access link.

[0024] Thirdly, embodiments of this application provide an electronic device, including: at least one processor and a memory; the memory stores computer-executable instructions; the at least one processor executes the computer-executable instructions stored in the memory, causing the at least one processor to perform the service access method as described in the first aspect and various possible designs of the first aspect.

[0025] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions. When a processor executes the computer-executable instructions, it implements the service access method described in the first aspect and various possible designs of the first aspect.

[0026] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the service access method described in the first aspect and various possible designs of the first aspect.

[0027] The service access method, apparatus, device, and storage medium provided in this application receive an initial access request sent by a client, determine the corresponding access token and access key based on the access channel identifier included in the initial access request, and return the access token and access key to the client that sent the initial access request. This allows the client to generate a service access request based on the received access token and access key, and the access level. The application also receives the service access request sent by the client and verifies the service access request according to the access level corresponding to the service access request. If the verification passes, it obtains the service access link corresponding to the service access request and sends the service access link to the client, enabling the client to access the service corresponding to the service access link. The method of determining the corresponding access token and access key for each access channel and verifying the service access request according to the access level during the service access process improves the security of service access. Attached Figure Description

[0028] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0029] Figure 1 The flow of the service access method provided in the embodiments of this application Figure 1 ;

[0030] Figure 2 The flow of the service access method provided in the embodiments of this application Figure 2 ;

[0031] Figure 3 The flow of the service access method provided in the embodiments of this application Figure 3 ;

[0032] Figure 4 A schematic diagram of the structure of the device for service access provided in the embodiments of this application;

[0033] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0034] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0035] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0036] The collection, storage, use, processing, transmission, provision, and disclosure of financial data or user data involved in the technical solution of this application all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0037] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, they do not mean that the applicant has used or necessarily used the solution.

[0038] In existing technologies, the server generates an access token and an access key based on the access request sent by the client, and sends them to the client so that the client can access services based on the received access token and access key. However, accessing services solely through access tokens and access keys leads to poor security.

[0039] To address the aforementioned technical issues, this application receives an initial access request from a client, determines the corresponding access token and access key based on the access channel identifier included in the initial access request, and returns the access token and access key to the client that sent the initial access request. This allows the client to generate a business access request based on the received access token, access key, and access level. The application then receives the business access request from the client and verifies it according to the access level. If the verification passes, it obtains the business access link corresponding to the business access request and sends the link to the client, enabling the client to access the corresponding business. By determining the corresponding access token and access key for each access channel and verifying the business access request according to the access level during the business access process, the security of business access can be improved.

[0040] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0041] Figure 1 The flow of the service access method provided in the embodiments of this application Figure 1 The execution entity is a server or a device that accesses services. Generally, this can be implemented through software, hardware, or a combination of both.

[0042] like Figure 1 As shown, the methods for accessing this service include:

[0043] Step S101: Receive the initial access request sent by the client.

[0044] Specifically, it can receive initial access requests sent by clients. These initial requests, at the start of the business access phase, request the acquisition of the access token and access key corresponding to the access channel. The initial access request includes an identifier for the access channel, indicating the type of access channel. The access channel refers to the channel through which the user accesses the business, such as an application software (APP) or a mini-program.

[0045] Optionally, the access channel identifier is an identifier determined by the client based on the access channel indicated by the user's access operation.

[0046] Step S102: Determine the corresponding access token and access key based on the identifier of the access channel included in the initial access request.

[0047] Specifically, after receiving the initial access request from the client, the access token and access key corresponding to the access channel identifier included in the initial access request can be determined. The access token is a string generated by the server to serve as a token for the client to make requests. Upon the first login, the server generates a token and returns it to the client, allowing the client to make data requests with this token without needing to provide the username and password again. The access token reduces server load and minimizes frequent database queries. The access token corresponds to the access channel that sent the initial access request. The access key is the key used to encrypt transmitted business data during the business access process. Business data includes, but is not limited to, business access request data and business response data, with the business response data referring to the response data corresponding to the business access request.

[0048] In this application, the process of determining the corresponding access token and access key based on the identifier of the access channel included in the initial access request is not limited. Optionally, the method of obtaining the corresponding access token and access key can be determined first based on the identifier of the access channel included in the initial access request; and then the corresponding access key can be obtained based on the method of obtaining the corresponding access key.

[0049] In particular, determining the corresponding access token and access key based on the access channel identifier included in the initial access request can improve the security and accuracy of business access.

[0050] Step S103: Return the access token and access key to the client that sent the initial access request, so that the client can generate a business access request based on the received access token and access key, as well as the access level.

[0051] Specifically, after determining the access token and access key corresponding to the access channel identifier, the access token and access key can be returned to the client that sent the initial access request. This allows the client to generate a business access request based on the received access token and access key, as well as the access level. The access level represents the security level of the business scenario accessed by the business access request. The business access request is used to request access to a business scenario, which refers to the scenario corresponding to the business. Specifically, different business scenarios correspond to different security levels.

[0052] This application does not limit the classification of security levels for business scenarios. Optionally, the security level of a business scenario can be classified according to the business functions it implements. Specifically, different business scenarios implement different business functions. For example, there are business scenarios for public information query and display, business scenarios for introducing products or services, and business scenarios for business processing. In classifying the security level of a business scenario according to the business functions it implements, lower security levels can be set for business scenarios with lower security requirements, such as public information query and display, while higher security levels can be set for business scenarios with higher security requirements, such as business processing.

[0053] Optionally, the access level is determined by the client based on the business scenario indicated by the user's access operation.

[0054] Optionally, after receiving the access token and access key from the server, the client can cache these resources, such as through session caching, for later use during business operations. Specifically, in computer science, session caching is a technique for storing user session data.

[0055] Step S104: Receive the service access request sent by the client, and verify the service access request according to the access level corresponding to the service access request.

[0056] Specifically, it can receive business access requests sent by clients and verify the business access requests according to the access level corresponding to the business access requests. The description of the business access requests and the access levels corresponding to the business access requests can be found in step S103, and will not be repeated in this step.

[0057] Optionally, the access request includes verification information corresponding to the access level, where the verification information refers to pre-defined information used to verify the business access request. Optionally, different security level verification information can be set for different access levels. For example, for access requests to business scenarios with lower security levels as described in step S103, simpler verification information can be included; for access requests to business scenarios with higher security levels as described in step S103, more complex verification information can be included to improve the security of business access and save system resource consumption.

[0058] In this application, the process of receiving a business access request sent by the client and verifying the business access request according to the access level corresponding to the business access request is not limited. Optionally, the process of obtaining the information to be verified corresponding to the access level of the business access request and then verifying the information to be verified corresponding to the access level can be completed to complete the process of verifying the business access request.

[0059] Among these measures, verifying business access requests based on their corresponding access levels can improve both the security and efficiency of business access.

[0060] Step S105: If the verification passes, obtain the business access link corresponding to the business access request and send the business access link to the client so that the client can access the business corresponding to the business access link.

[0061] Specifically, according to the verification in step S104, if the verification passes, the business access link corresponding to the business access request is obtained, and the business access link is sent to the client so that the client can access the business corresponding to the business access link.

[0062] The business access link indicates a link to the page of the business scenario accessed by the business access request. Optionally, the number of pages corresponding to one business scenario can vary, with one business scenario corresponding to one or more pages. For example, if the business scenario accessed by the business access request is for displaying the homepage, it corresponds to one page; conversely, if the business scenario accessed by the multi-business access request is for business processing, it corresponds to multiple pages.

[0063] Specifically, according to the verification in step S104, if the verification fails, a prompt message indicating that the business access request verification failed is sent to the client. Optionally, the specific content of the prompt message is related to the information to be verified that caused the verification to fail. The description of the information to be verified can be referred to the description in step S104, which will not be repeated in this step.

[0064] This embodiment receives an initial access request from a client, determines the corresponding access token and access key based on the access channel identifier included in the initial access request, and returns the access token and access key to the client that sent the initial access request. The client then generates a service access request based on the received access token and access key, and the access level. The embodiment receives the service access request from the client and verifies it according to the access level. If the verification passes, it obtains the service access link corresponding to the service access request and sends the link to the client, enabling the client to access the service corresponding to the link. Determining the corresponding access token and access key for each access channel and verifying the service access request according to the access level during the service access process improves the security of service access.

[0065] Figure 2 The flow of the service access method provided in the embodiments of this application Figure 2 ,exist Figure 1 Based on the illustrated embodiment, this embodiment elaborates on the process of determining the corresponding access token and access key according to the identifier of the access channel included in the initial access request.

[0066] like Figure 2 As shown, the process of determining the corresponding access token and access key based on the access channel identifier included in the initial access request includes:

[0067] Step S201: Determine the corresponding access token and access key acquisition method based on the access channel identifier included in the initial access request.

[0068] Specifically, based on the access channel identifier included in the initial access request, the corresponding access token and access key acquisition method can be determined. As described in step S101, the access channel identifier indicates the type of access channel. The access channel refers to the channel through which the user accesses services, such as an application software (APP) or a mini-program. Optionally, the access channel identifier is an identifier determined by the client based on the access channel indicated by the user's access operation.

[0069] This application does not limit the process of determining the corresponding access token based on the access channel identifier included in the initial access request. Any process that can determine the corresponding access token based on the access channel identifier included in the initial access request can be used as the process provided by this application for determining the corresponding access token based on the access channel identifier included in the initial access request. Optionally, a randomly assigned access token can be obtained based on the access channel identifier included in the initial access request. Optionally, the obtained access token has a certain time limit, for example, it is valid for 30 minutes after acquisition. Specifically, within 30 minutes after acquiring the access token, if the business access request received by the server includes the acquired access token, there is no need to verify the username and password again; otherwise, the username and password need to be verified. Specifically, outside of 30 minutes after acquiring the access token, if the business access request received by the server includes the acquired access token, but the access token has expired due to the time limit described above, then the username and password need to be verified.

[0070] The access key acquisition method refers to the way the access key is obtained. This method includes, but is not limited to, symmetric key acquisition, negotiated key acquisition, dynamic key acquisition, and static key acquisition. Specifically, to ensure access security, different access channels have different preset access key acquisition methods; that is, different access channel identifiers correspond to different access key acquisition methods.

[0071] This application does not limit the process of determining the corresponding access key acquisition method based on the access channel identifier included in the initial access request. Any process that can determine the corresponding access key acquisition method based on the access channel identifier included in the initial access request can be used as the process provided by this application for determining the corresponding access key acquisition method based on the access channel identifier included in the initial access request. Optionally, the method for obtaining the access key for each access channel can be preset according to the channel characteristics and / or access requirements of each access channel. Specifically, this application does not limit the process of presetting the method for obtaining the access key for each access channel. Any process that can preset the method for obtaining the access key for each access channel can be used as the process provided by this application for presetting the method for obtaining the access key for each access channel. Optionally, the method for obtaining the access key for each access channel can be preset according to the channel characteristics and / or access requirements of each access channel. The preset access channels can obtain access keys in one of the ways described above, or in combination of multiple ways described above, such as a combination of dynamic key acquisition and static key acquisition, or a combination of symmetric key acquisition and negotiated key acquisition.

[0072] Step S202: Obtain the corresponding access key according to the corresponding access key acquisition method.

[0073] After determining the access token and access key acquisition method based on the access channel identifier included in the initial access request, the corresponding access key can be obtained according to the determined access key acquisition method. As described in step S201, the preset method for obtaining access keys for each access channel can be one of the access key acquisition methods described above, or a combination of multiple access key acquisition methods described above. Therefore, if the access key acquisition method corresponding to the access channel identifier is one method, then the access key is obtained according to this method. For example, if the access key acquisition method corresponding to the access channel identifier is a negotiated key acquisition method, then the access key is obtained through the negotiated key acquisition method. If the access key acquisition method corresponding to the access channel identifier is multiple methods, then the access key is obtained according to multiple methods. Optionally, multiple sub-access keys can be obtained according to each of the multiple access key acquisition methods, and then the final access key is determined according to the multiple sub-access keys. For example, if the access key acquisition method corresponding to the access channel identifier is a static key acquisition method and a dynamic key acquisition method, then the static key and the dynamic key are obtained respectively through the static key acquisition method and the dynamic key acquisition method, and then the final access key is determined according to the static key and the dynamic key. Optionally, a first access key can be obtained using one of several methods. Then, a second key can be obtained using the first access key and another method, and so on, until the final access key is obtained using the last of the several methods. For example, if the access channel identifier corresponds to both static and dynamic key acquisition methods, a static key can be obtained first, and then the final access key can be obtained based on both methods. Obtaining the corresponding access key based on the access channel identifier improves the accuracy and relevance of access key generation, further enhancing the accuracy and security of business access based on the obtained access key.

[0074] Optionally, after obtaining the access token and access key corresponding to the access channel identifier, the correspondence between the access channel identifier and the access token and access key can be saved for verification of business access requests sent by the client.

[0075] This embodiment provides a process for determining the corresponding access token and access key based on the access channel identifier included in the initial access request. By determining the acquisition method of the corresponding access token and access key based on the access channel identifier included in the initial access request, and obtaining the corresponding access key based on the corresponding access key acquisition method, the process improves the accuracy and relevance of access key generation and further enhances the accuracy and security of the process of accessing services based on the obtained access key.

[0076] Figure 3 The flow of the service access method provided in the embodiments of this application Figure 3 ,exist Figure 1 and Figure 2 Based on the illustrated embodiment, specifically, the access levels include: a first access level, a second access level, and a third access level. The first access level indicates that the business scenario accessed by the access request is a public information query scenario. The second access level indicates that the business scenario accessed by the access request is a business information query scenario. The third access level indicates that the business scenario accessed by the access request is a business processing scenario. The higher the access level, the higher the security requirements of the business scenario accessed by the access request. This embodiment elaborates on the process of verifying the business access request based on its corresponding access level.

[0077] like Figure 3 As shown, the process of validating a business access request based on its access level includes:

[0078] Step S301: If the access level corresponding to the business access request is the first access level, verify the business access request.

[0079] Specifically, if the access level corresponding to the business access request is the first access level, the process of validating the business access request includes:

[0080] First, extract the access token from the business access request, and perform a first verification on the business access request based on the extracted access token to obtain the verification result of the first verification.

[0081] The description of the access token can be found in step S102, and will not be repeated here. This application does not limit the method of extracting the access token from the business access request; optionally, the header of the HTTP message of the business access request can be extracted, and then the access token carried in the header can be extracted from the header.

[0082] After obtaining the access token extracted from the business access request, the business access request can be first verified based on the extracted access token to obtain the verification result of the first verification. This application does not limit the process of performing the first verification on the business access request based on the extracted access token to obtain the verification result of the first verification. Optionally, an access token pre-stored in the server can be obtained, and then the access token extracted from the business access request can be matched with the access token pre-stored in the server, and the verification result of the first verification can be determined based on the matching result. The access tokens pre-stored in the server are those pre-stored in step S102 during the process of determining the corresponding access token and access key based on the access channel identifier included in the initial access request. If there is an access token among the pre-stored access tokens that is consistent with the access token extracted from the business access request and is not expired, the matching result is a successful match, and the verification result of the first verification is determined to be a successful verification. If there is no access token among the pre-stored access tokens that is consistent with the access token extracted from the business access request, or if there is an access token that is consistent with the access token extracted from the business access request but is expired, the matching result is a failed match, and the verification result of the first verification is determined to be a failed verification.

[0083] Secondly, if the verification result of the first verification is that the verification is successful, the business access request is decrypted according to the access key corresponding to the access token to obtain the decryption result of the business access request.

[0084] Specifically, according to the first verification process described above, if the verification result of the first verification is successful, the business access request is decrypted using the access key corresponding to the access token to obtain the decryption result of the business access request. This application does not limit the process of decrypting the business access request using the access key corresponding to the access token to obtain the decryption result of the business access request. Optionally, the correspondence between access tokens and access keys pre-stored in the server can be obtained first. This pre-stored correspondence is the one pre-stored in step S102 when determining the corresponding access token and access key based on the identifier of the access channel included in the initial access request. Then, based on the correspondence between access tokens and access keys, the access key corresponding to the extracted access token is determined. Finally, the business access request is decrypted using the determined access key to obtain the decryption result of the business access request. The decryption result of the business access request is either successful or failed.

[0085] Optionally, based on the first verification process described above, if the verification result of the first verification is that the verification failed, then it can be determined that the verification result of the business access request failed. Optionally, a verification failure prompt message can be further sent to the client, wherein the verification failure prompt message includes the prompt message of the first verification failing.

[0086] Then, a second verification is performed on the business access request based on the decryption processing result of the business request.

[0087] If the decryption process of the business access request fails, for example, if the decrypted information is garbled, then the second verification result is determined to be a verification failure, and the verification result of the business access request is also determined to be a verification failure. Optionally, a verification failure prompt message can be sent to the client, which includes the second verification failure prompt message. Specifically, the reasons that cause the decryption process of the business access request to fail include, but are not limited to: tampering during the process of returning the access token and access key to the client that sent the initial access request as described in step S103, and / or tampering during the process of the client generating the business access request based on the received access token and access key and the access level, and / or tampering during the process of receiving the business access request sent by the client in step S104.

[0088] If the decryption processing result of the business access request is successful, then the verification result of the second verification is determined to be successful, and the verification result of the business access request is also determined to be successful.

[0089] Step S302: If the access level corresponding to the business access request is the second access level, verify the business access request.

[0090] The business access request also includes: login status information, business scenario identifier, and access channel identifier. Specifically, login status information refers to information representing the login status of a user account; specifically, login status information indicates that the user account is logged in or not. The business scenario identifier refers to the identifier of the business scenario accessed by the business access request. The description of the access channel identifier can be found in step S101, and will not be repeated here.

[0091] Specifically, if the access level corresponding to the business access request is the second access level, the process of verifying the business access request may include:

[0092] First, an access token is extracted from the business access request, and the business access request is first verified based on the extracted access token to obtain the verification result of the first verification. The description of extracting the access token from the business access request and performing the first verification on the business access request based on the extracted access token to obtain the verification result of the first verification can be referred to in step S301, and will not be repeated in this step.

[0093] Secondly, if the verification result of the first verification is that the verification passes, the business access request is decrypted according to the access key corresponding to the access token to obtain the decryption result of the business access request. The description of the process of decrypting the business access request according to the access key corresponding to the access token to obtain the decryption result of the business access request if the verification result of the first verification passes can be found in step S301, and will not be repeated in this step.

[0094] Next, the business access request is subjected to a second verification based on the decryption processing result of the business request, and the verification result of the second verification is obtained. The description of the second verification of the business access request based on the decryption processing result of the business request and the obtained verification result can be referred to the description in step S301, and will not be repeated in this step.

[0095] Then, if the second verification passes, the login status information, business scenario identifier, and access channel identifier are extracted from the decrypted access request, and the business access request is subjected to a third verification process based on the extracted login status information, business scenario identifier, and access channel identifier. This application does not limit the process of performing the third verification process on the business access request based on the extracted login status information, business scenario identifier, and access channel identifier.

[0096] As described above, the second access level indicates that the business scenario accessed by the business access request is a business information query scenario. Optionally, in some business information query scenarios, it is necessary to determine that the user account's login status is "logged in." Therefore, during the third verification process of the business access request based on the extracted login status information, business scenario identifier, and access channel identifier, if it is determined that the business scenario corresponding to the business scenario identifier requires the user's login status to be "logged in," then the third verification process of the business access request can be performed based on the extracted login status information and access channel identifier. Specifically, during the third verification process of the business access request based on the extracted access channel identifier, if the extracted access channel identifier does not match the access channel identifier pre-stored in the server, then the result of the third verification process is determined to be verification failed; otherwise, the result of the third verification process is determined to be verification passed. The pre-stored access channel identifier is the one pre-stored in step S102 during the process of determining the corresponding access token and access key based on the access channel identifier included in the initial access request.

[0097] Optionally, in some business information query scenarios, it is not necessary to determine whether the user account is logged in. Therefore, during the third-party verification process of the business access request based on the extracted login status information, business scenario identifier, and access channel identifier, if it is determined that the business scenario corresponding to the business scenario identifier is a business scenario that does not require the user's login status, then the third-party verification process can be performed based on the extracted access channel identifier. Specifically, during the third-party verification process of the business access request based on the extracted login status information and access channel identifier, if the login status information indicates that the user is not logged in, and / or the extracted access channel identifier does not match the access channel identifier pre-stored in the server, then the result of the third-party verification process is determined to be verification failed; otherwise, the result of the third-party verification process is determined to be verification passed.

[0098] In summary, if the result of the third verification process is determined to be verification passed, then the verification result of the access request is determined to be verification passed; if the result of the third verification process is determined to be verification failed, then the verification result of the access request is determined to be verification failed. Optionally, a verification failure prompt message can be sent to the user, wherein the verification failure prompt message includes the prompt message of the third verification failure, such as: the access channel identifier does not match and / or the login status information is that the user is not logged in.

[0099] Step S303: If the access level corresponding to the business access request is the third access level, verify the business access request.

[0100] The business access request also includes: business process information, business scenario identifier, and access channel identifier; specifically, the business process information represents the verification information for business processing scenarios. The business scenario identifier refers to the identifier of the business scenario accessed by the business access request; the description of the access channel identifier can be found in step S101, and will not be repeated here.

[0101] Specifically, if the access level corresponding to the business access request is the third access level, the process of validating the business access request may include:

[0102] First, an access token is extracted from the business access request, and the business access request is first verified based on the extracted access token to obtain the verification result of the first verification. The description of extracting the access token from the business access request and performing the first verification on the business access request based on the extracted access token to obtain the verification result of the first verification can be referred to in step S301, and will not be repeated in this step.

[0103] Secondly, if the verification result of the first verification is that the verification passes, the business access request is decrypted according to the access key corresponding to the access token to obtain the decryption result of the business access request. The description of the process of decrypting the business access request according to the access key corresponding to the access token to obtain the decryption result of the business access request if the verification result of the first verification passes can be found in step S301, and will not be repeated in this step.

[0104] Next, the business access request is subjected to a second verification based on the decryption processing result of the business request, and the verification result of the second verification is obtained. The description of the second verification of the business access request based on the decryption processing result of the business request and the obtained verification result can be referred to the description in step S301, and will not be repeated in this step.

[0105] Then, if the second verification passes, the business process information, business scenario identifier, and access channel identifier are extracted from the decrypted access request. A third verification process is then performed on the business access request based on the extracted business process information, business scenario identifier, and access channel identifier. This application does not limit the process of performing the third verification on the business access request based on the extracted business process information, business scenario identifier, and access channel identifier. As described above, the third access level indicates that the business scenario accessed by the business access request is a business processing scenario. Specifically, in business processing scenarios, different business scenarios have different requirements for business process information. Optionally, after determining the business scenario based on the business scenario identifier, the requirements for business process information for that business scenario can be determined. If the extracted business process information does not meet the determined requirements for business process information, and / or the extracted access channel identifier does not match the access channel identifier pre-stored in the server, then the result of the third verification process is determined to be verification failure. Otherwise, the result of the third verification process is determined to be verification pass.

[0106] In summary, if the result of the third verification process is determined to be verification passed, then the verification result of the access request is determined to be verification passed; if the result of the third verification process is determined to be verification failed, then the verification result of the access request is determined to be verification failed. Optionally, a verification failure prompt message can be sent to the user terminal, wherein the verification failure prompt message includes the prompt message of the third verification failure, such as: the access channel identifier does not match and / or the extracted business process information does not meet the requirements of the business process information determined according to the business scenario identifier.

[0107] The process of verifying business access requests based on the access level corresponding to the business access request provided in this embodiment improves the accuracy of verification by verifying access requests of different access levels separately, and further enhances the accuracy and security of business access based on the verification results.

[0108] In one possible embodiment, the process of obtaining the business access link corresponding to the business access request may include: First, obtaining the initial business access link corresponding to the business access request. The initial business access link refers to the link to the access page obtained based on a business access request whose verification result is successful. This application does not limit the process of obtaining the initial business access link corresponding to the business access request; optionally, the initial business access link can be extracted from the DMZWEB resource deployment area of ​​the server based on the verified business access request. Here, DMZ (Demilitarized Zone) refers to a network architecture and security policy used to isolate an intermediate area between an internal trusted network and an external untrusted network. It is a network security measure designed to protect the internal network from potential threats and attacks while allowing trusted users and systems to communicate with the external network. DMZs are typically located between firewalls or security devices, acting as a buffer zone for managing and inspecting traffic. DMZs typically include web servers that host publicly accessible internet-facing applications and websites. These servers typically contain publicly accessible information but are isolated from the internal network to reduce the impact of potential threats on the internal system. Second, the business access link is obtained by encrypting the access key. After obtaining the initial business access link corresponding to the business access request, the obtained initial business access link can be encrypted using the access key determined in step S102 to obtain the business access link. Optionally, the initial business access link can be in the form of a list of URLs.

[0109] Optionally, as described above, since the business access link is an encrypted initial business access link, after the client receives the business access link, it can decrypt it according to the access key received in step S103 to obtain the initial business access link. Furthermore, the client can load and render the corresponding business page according to the initial business access link to obtain the business page corresponding to the business access request and present it to the user.

[0110] Figure 4 This is a schematic diagram of the structure of a service access device provided in an embodiment of this application. Figure 4 As shown, the processing device 400 for this service access includes: a receiving module 401, a determining module 402, a sending module 403, a verification module 404, and an access module 405.

[0111] The receiving module 401 is used to receive an initial access request sent by the client; wherein the initial access request includes an identifier of the access channel; the identifier of the access channel indicates the type of access channel;

[0112] The determining module 402 is used to determine the corresponding access token and access key based on the identifier of the access channel included in the initial access request;

[0113] The sending module 403 is used to return the access token and access key to the client that sent the initial access request, so that the client can generate a business access request based on the received access token and access key, as well as the access level; wherein, the access level represents the security level of the business scenario accessed by the business access request.

[0114] The verification module 404 is used to receive business access requests sent by the client and verify the business access requests according to the access level corresponding to the business access requests.

[0115] Access module 405 is used to obtain the business access link corresponding to the business access request if the verification passes, and send the business access link to the client so that the client can access the business corresponding to the business access link.

[0116] In some embodiments, the access levels include: a first access level, a second access level, and a third access level, wherein the first access level indicates that the business scenario accessed by the business access request is a public information query scenario; the second access level indicates that the business scenario accessed by the business access request is a business information query scenario; and the third access level indicates that the business scenario accessed by the business access request is a business processing scenario.

[0117] In some embodiments, if the access level corresponding to the business access request is the first access level, the verification module 404 is specifically used to extract the access token from the business access request, and perform a first verification on the business access request based on the extracted access token to obtain the verification result of the first verification; if the verification result of the first verification is that the verification passes, the business access request is decrypted based on the access key corresponding to the access token to obtain the decryption result of the business access request; and a second verification is performed on the business access request based on the decryption result of the business request.

[0118] In some embodiments, if the access level corresponding to the business access request is the second access level, the verification module 404 is specifically used to extract the access token from the business access request, and perform a first verification on the business access request based on the extracted access token to obtain the verification result of the first verification; if the verification result of the first verification is successful, the business access request is decrypted based on the access key corresponding to the access token to obtain the decryption result of the business access request; the business access request is then subjected to a second verification based on the decryption result of the business request to obtain the verification result of the second verification; if the verification result of the second verification is successful, the login status information, business scenario identifier, and access channel identifier are extracted from the decrypted access request, and a third verification is performed on the business access request based on the extracted login status information, business scenario identifier, and access channel identifier.

[0119] In some embodiments, if the access level corresponding to the business access request is the third access level, the verification module 404 is specifically used to extract an access token from the business access request, and perform a first verification on the business access request based on the extracted access token to obtain a verification result of the first verification; if the verification result of the first verification is successful, the business access request is decrypted based on the access key corresponding to the access token to obtain a decryption result of the business access request; the business access request is then subjected to a second verification based on the decryption result of the business request to obtain a verification result of the second verification; if the verification result of the second verification is successful, business process information, business scenario identifier, and access channel identifier are extracted from the decrypted access request, and a third verification is performed on the business access request based on the extracted business process information, business scenario identifier, and access channel identifier.

[0120] In some embodiments, the access module 405 is specifically used to obtain the initial business access link corresponding to the business access request; and to perform encryption processing according to the determined access key to obtain the business access link.

[0121] In some embodiments, the determining module 402 is specifically used to determine the corresponding access token and access key acquisition method based on the identifier of the access channel included in the initial access request; and to acquire the corresponding access key based on the corresponding access key acquisition method.

[0122] The service access apparatus provided in this application embodiment can be used to execute the technical solution of the service access method in the above embodiment. Its implementation principle and technical effect are similar, and will not be repeated here.

[0123] It should be noted that the division of the various modules in the above device is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, these modules can be implemented entirely in software via processing element calls; they can be fully implemented in hardware; or some modules can be implemented in software via processing element calls, while others are implemented in hardware. For example, the receiving module 401 can be a separate processing element, or it can be integrated into a chip in the above device. Alternatively, it can be stored as program code in the memory of the above device, and its functions can be called and executed by a processing element of the above device. The implementation of other modules is similar. Moreover, these modules can be fully or partially integrated together, or they can be implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. In the implementation process, each step of the above method or each of the above modules can be completed through the integrated logic circuits in the hardware of the processor element or through software instructions.

[0124] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 5 As shown, the electronic device 50 may include: a processor 51, a memory 52, and a communication interface 53.

[0125] Memory 52 is used to store the processor's executable instructions.

[0126] The processor 51 is configured to execute the above method embodiments by executing executable instructions. Figures 1 to 2 The method for accessing any business function.

[0127] Processor 51 executes computer execution instructions stored in memory, causing processor 51 to perform the scheme in the above embodiments. Processor 51 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0128] The memory 52 is connected to the processor 51 via the system bus and completes communication between them. The memory 52 is used to store computer program instructions.

[0129] The system bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The system bus can be divided into address bus, data bus, control bus, etc. For ease of representation, only one thick line is used in the diagram, but this does not indicate that there is only one bus or one type of bus. Transceivers are used to enable communication between database access devices and other computers (e.g., clients, read-write libraries, and read-only libraries). Memory may include random access memory (RAM) and may also include non-volatile memory.

[0130] The electronic device provided in this application embodiment can be the terminal device described in the above embodiments.

[0131] This application also provides a chip for executing instructions, which is used to execute the service access method described in the above embodiments.

[0132] This application also provides a computer-readable storage medium storing computer instructions that, when executed on a computer, cause the computer to perform the service access method described in the above embodiments.

[0133] This application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium, and when the at least one processor executes the computer program, it can implement the technical solution of the business access method in the above embodiments.

[0134] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or modules, and may be electrical, mechanical, or other forms.

[0135] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to implement the solution of this embodiment according to actual needs.

[0136] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The unit composed of the above modules can be implemented in hardware or in the form of hardware plus software functional units.

[0137] The integrated modules described above, implemented as software functional modules, can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.

[0138] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0139] The memory may include high-speed RAM, and may also include non-volatile storage (NVM), such as at least one disk storage device, and may also be a USB flash drive, external hard drive, read-only memory, disk or optical disc, etc.

[0140] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0141] The aforementioned storage medium can be implemented from any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The storage medium can be any available medium accessible to general-purpose or special-purpose computers.

[0142] An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Alternatively, the storage medium can be an integral part of the processor. The processor and storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and storage medium can exist as discrete components in an electronic control unit or main control device.

[0143] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0144] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method of service access, characterized by, Applied to a server, comprising: receiving an initial access request sent by a client; wherein the initial access request includes an identifier of an access channel; the identifier of the access channel indicates the type of the access channel; determining the corresponding access token and access key according to the identifier of the access channel included in the initial access request; returning the access token and access key to the client sending the initial access request, so that the client generates a business access request according to the received access token and access key, and an access level; wherein the access level represents the security level of the business scenario accessed by the business access request; receiving the business access request sent by the client, and verifying the business access request according to the access level corresponding to the business access request; if the verification is passed, obtaining the business access link corresponding to the business access request, and sending the business access link to the client, so that the client accesses the business corresponding to the business access link; wherein the verification of the business access request comprises: extracting the access token from the business access request, and performing a first verification on the business access request according to the extracted access token; if the verification result of the first verification is verification passed, decrypting the business access request according to the access key corresponding to the access token; performing a second verification on the business access request according to the decrypted business access request; if the verification result of the second verification is verification passed, and the access level corresponding to the business access request is the second access level or the third access level, performing a third verification processing on the business access request.

2. The method of claim 1, wherein, The access level includes: a first access level, a second access level and a third access level, wherein the first access level represents that the business scenario accessed by the business access request is a public information query type scenario; the second access level represents that the business scenario accessed by the business access request is a business information query type scenario; and the third access level represents that the business scenario accessed by the business access request is a business handling type scenario.

3. The method of claim 2, wherein, The business access request also includes login state information, business scenario identifier and identifier of the access channel; if the access level corresponding to the business access request is the second access level, the third verification processing includes: extracting the login state information, the business scenario identifier and the identifier of the access channel from the decrypted access request, and performing a third verification processing on the business access request according to the extracted login state information, business scenario identifier and identifier of the access channel.

4. The method of claim 2, wherein, The business access request also includes business process information, business scenario identifier and identifier of the access channel; if the access level corresponding to the business access request is the third access level, the third verification processing includes: extract the business process information, the business scenario identifier and the identifier of the access channel from the access request after decryption processing, and perform third verification processing on the business access request according to the extracted business process information, the business scenario identifier and the identifier of the access channel.

5. The method according to any one of claims 1-4, characterized in that, The business access request corresponds to a business access link, including: An initial business access link corresponding to the business access request is obtained. According to the determined access key, the business access link is obtained by encryption processing.

6. The method of claim 5, wherein, According to the identifier of the access channel included in the initial access request, the corresponding access token and access key are determined, including: According to the identifier of the access channel included in the initial access request, the corresponding access token and access key acquisition mode are determined. According to the corresponding access key acquisition mode, the corresponding access key is obtained.

7. An apparatus for service access, the apparatus comprising: Including: The receiving module is configured to receive an initial access request sent by a client; wherein the initial access request includes an identifier of an access channel; the identifier of the access channel indicates the type of the access channel; The determining module is configured to determine the corresponding access token and access key according to the identifier of the access channel included in the initial access request; The sending module is configured to return the access token and access key to the client sending the initial access request, so that the client generates a business access request according to the received access token and access key, and an access level; wherein the access level represents the security level of the business scenario accessed by the business access request; The verification module is configured to receive a business access request sent by a client, and verify the business access request according to the access level corresponding to the business access request; The access module is configured to obtain a business access link corresponding to the business access request if the verification passes, and send the business access link to the client, so that the client accesses the business corresponding to the business access link; The verification module is specifically configured to extract an access token from the business access request, and perform first verification on the business access request according to the extracted access token; If the verification result of the first verification is verification pass, the business access request is decrypted according to the access token corresponding to the access key; According to the decrypted business access request, the business access request is verified. If the verification result of the second verification is verification pass, and the access level corresponding to the business access request is the second access level or the third access level, the business access request is verified.

8. An electronic device, comprising: Including: A processor, and a memory in communication connection with the processor; The memory stores computer execution instructions; The processor executes the computer execution instructions stored in the memory to realize the method in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer execution instructions, and the computer execution instructions are executed by the processor to realize the method in any one of claims 1-6.

10. A computer program product, characterised in that, A computer program comprising computer program elements which, when executed by a processor, perform the method of any one of claims 1-6. A computer program comprising computer program elements which, when executed by a processor, perform the method of any one of claims 1-6.

Citation Information

Patent Citations

  • Security authentication method and device, electronic equipment and storage medium

    CN114912991A

  • Service authentication method, system and related equipment

    CN116886428A