Authorization method, system, device, storage medium and program product for adaptively selecting security policy based on client risk type

Abstract

The application relates to the technical field of network security, and discloses an authorization method and system based on adaptive selection of a security policy according to a client risk type, an electronic device, a computer readable storage medium, and a computer program product, which are used to solve the technical problem that the prior art cannot automatically execute a corresponding security policy according to actual operation risks of an authorization request, thereby causing security vulnerabilities to be prone to occur. The method comprises the following steps: receiving an authorization request from a client, and extracting authorization request parameters of the client in the authorization request; based on the authorization request parameters, querying static information provided when the client is registered in a client information management database; real-time capturing of context information and environmental characteristics of the authorization request to obtain dynamic information; calling a risk assessment engine to comprehensively assess the static information and the dynamic information, determine a risk type corresponding to the authorization request, and select a corresponding security policy to authorize. The method effectively improves the security of an authorization process.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to an authorization method, system, electronic device, computer storage medium, and computer program product that adaptively selects security policies based on client risk type. Background Technology

[0002] OAuth 2.0 is a widely used industry standard protocol for network authorization. It allows third-party applications to access user resources and data on other service providers after authorization, without sharing the user's username or password. In practice, different authorization modes within the OAuth 2.0 framework can be chosen due to varying trust types among different clients. Specifically, client applications typically need to register with the Authorization Server in advance and are categorized as "Confidential Clients" or "Public Clients." "Confidential Clients" have the ability to securely store credentials and are usually applications running on protected backend servers. "Public Clients" cannot securely store credentials (such as mobile apps and single-page applications, SPAs) and are vulnerable to authorization code interception. To mitigate the risks of public clients, the OAuth 2.0 extended specification PKCE (Proof Key for Code Exchange) is generally used for verification. PKCE requires the client to generate a code_verifier and send its hash value, code_challenge, during the authorization request. The original value is verified during the token exchange phase, preventing the authorization code from being maliciously reused.

[0003] In existing technologies, authorization servers primarily determine whether to require PKCE (Primary Confidential Certificate Enforcement) based on the static type registered by the client. However, during runtime, the actual situation and environment may change dynamically. Situations may arise such as a confidential client front-end being exposed to the browser environment, developers misconfiguring the type, or significant risks during the authorization process. In these cases, if security is compromised by solely selecting a security policy based on the registration type, security will be reduced. For example, in some situations, a client registered with a "confidential" type might have request characteristics indicating it's actually running in a public environment. However, the authorization server might still process the request based on the static type registered at the time of registration, without enforcing PKCE verification, resulting in a serious security blind spot.

[0004] Therefore, there is an urgent need for a method that can address the errors, vulnerabilities, unexpected environmental risks, and response delays that are prone to occur in the OAuth 2.0 ecosystem, enabling the verification and authorization method to adaptively determine the client type and adjust and enforce the corresponding security policy based on the client's judgment result. Summary of the Invention

[0005] The main objective of this invention is to solve the technical problem that existing technologies cannot automatically execute corresponding security policies based on the actual operational risks of authorization requests, which makes them prone to security vulnerabilities.

[0006] The first aspect of this invention provides an authorization method for adaptively selecting security policies based on client risk types, comprising: Receive an authorization request from a client, and extract the client's authorization request parameters from the authorization request; Based on the authorization request parameters, query the static information provided by the client during registration in the client information management database; Real-time capture of the context information and environmental characteristics of the authorization request yields dynamic information; The risk assessment engine is invoked to perform a comprehensive assessment based on the static and dynamic information to determine the risk type corresponding to the authorization request. Based on the risk type, select the corresponding security policy to perform the authorization operation.

[0007] Optionally, in a first implementation of the first aspect of the present invention, the authorization request parameters include a client identifier; the dynamic information includes network-level features, HTTP request-level features, OAuth protocol-level features, and historical behavior-level features. The step of querying the static information provided during client registration in the client information management database based on the authorization request parameters includes: Based on the client identifier, query the client information management database for the registered client type, list of redirect URIs, and application metadata provided during client registration; The real-time capture of the authorization request's context information and environmental characteristics to obtain dynamic information includes: The system captures dynamic attributes related to the authorization request in real time as context information, captures background operating conditions related to the authorization request as environmental features, and obtains network-level features, HTTP request-level features, OAuth protocol-level features, and historical behavior-level features.

[0008] Optionally, in a second implementation of the first aspect of the present invention, the risk assessment engine performs a comprehensive assessment based on the static information and the dynamic information to determine the risk type corresponding to the authorization request, including: The risk assessment engine is invoked to identify the risk factors contained in the static and dynamic information, and a comprehensive risk score is calculated based on the risk factors. Based on the comprehensive risk score and the preset risk threshold in the risk assessment engine, the risk type corresponding to the authorization request is obtained.

[0009] Optionally, in a third implementation of the first aspect of the present invention, the risk type includes low risk, medium risk, and high risk; The step of selecting the corresponding security policy and performing the authorization operation based on the risk type includes: For low-risk authorization requests, the standard processing strategy is applied, and no modifications are made to the authorization request; the authorization process corresponding to the authorization request is then initiated. For medium-risk authorization requests, a security enhancement policy is applied to force the client to use PKCE authorization. For high-risk authorization requests, the direct rejection policy is applied, the authorization process is interrupted, and an authorization error message is sent to the client.

[0010] Optionally, in a fourth implementation of the first aspect of the present invention, when the presumed client type and the registered client type do not match, the risk type is medium risk; For medium-risk authorization requests, matching security enhancement policies and forcing the client to use PKCE authorization includes: Check whether the authorization request parameters include the code_challenge parameter, and check whether the code_challenge parameter is in a valid format; If the code_challenge parameter is included and the format of the code_challenge parameter is valid, then the current client is considered to meet the PKCE verification requirements and is allowed to enter the PKCE verification and authorization process. If the code_challenge parameter is not included, the authorization process is interrupted and a verification failure message is returned to the client. The verification failure message includes a notification that the client developer needs to perform PKCE verification in order to continue the authorization.

[0011] Optionally, in a fifth implementation of the first aspect of the present invention, after selecting the corresponding security policy based on the risk type and performing the authorization operation, the method further includes: Record the request process and authorization result of the authorization request information to obtain the authorization log, and determine whether an alarm needs to be triggered based on the content of the authorization log; If an alarm needs to be triggered, an alarm message containing event details will be sent through the alarm channel.

[0012] A second aspect of the present invention provides an authorization system that adaptively selects security policies based on client risk types, comprising: The request receiving module is used to receive authorization requests from clients and extract the authorization request parameters from the clients in the authorization requests; The first information acquisition module is used to query the static information provided by the client during registration in the client information management database based on the authorization request parameters; The second information acquisition module is used to capture the context information and environmental characteristics of the authorization request in real time to obtain dynamic information; The risk assessment module is used to call the risk assessment engine to perform a comprehensive assessment based on the static information and the dynamic information to determine the risk type corresponding to the authorization request; The strategy selection module is used to select the corresponding security policy based on the risk type and execute the authorization operation.

[0013] A third aspect of the present invention provides an authorization device for adaptively selecting a security policy based on client risk type, comprising: a memory and at least one processor, wherein the memory stores instructions; the at least one processor invokes the instructions in the memory to cause the authorization device for adaptively selecting a security policy based on client risk type to perform the steps of the authorization method described above.

[0014] A fourth aspect of the present invention provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the steps of the authorization method for adaptively selecting a security policy based on client risk type described above.

[0015] A fifth aspect of the present invention provides a computer program product comprising a computer program / instructions that, when executed by a processor, implement the steps of the authorization method described above for adaptively selecting a security policy based on client risk type.

[0016] The technical solution provided by this invention includes receiving an authorization request from a client and extracting the client's authorization request parameters from the authorization request; querying the static information provided by the client during registration in the client information management database based on the authorization request parameters; capturing the context information and environmental characteristics of the authorization request in real time to obtain dynamic information; calling a risk assessment engine to perform a comprehensive assessment based on the static and dynamic information to determine the risk type corresponding to the authorization request; and selecting the corresponding security policy to execute the authorization operation based on the risk type. This method can automatically execute the corresponding security policy based on the actual operational risk of the authorization request, reducing the possibility of security vulnerabilities, improving the security of the authorization process, and enhancing the automation effect of the authorization method.

[0017] Furthermore, the system, electronic device, computer-readable storage medium, and computer program product provided by this invention also solve the corresponding technical problems. Attached Figure Description

[0018] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart illustrating the first embodiment of the authorization method for adaptively selecting security policies based on client risk type in this invention. Figure 2 This is a flowchart illustrating the second embodiment of the authorization method for adaptively selecting security policies based on client risk type in this invention. Figure 3 This is a schematic diagram of a module in a third embodiment of the authorization method for adaptively selecting security policies based on client risk type in this invention. Figure 4 This is a flowchart illustrating the third embodiment of the authorization method for adaptively selecting security policies based on client risk type in this invention. Figure 5 This is a schematic diagram of an embodiment of an authorization system that adaptively selects security policies based on client risk types in this invention. Figure 6 This is a schematic diagram of an embodiment of the authorization device that adaptively selects security policies based on client risk types in this invention. Figure 7 This is a schematic diagram illustrating the principle of a computer-readable medium according to an embodiment of the present invention. Detailed Implementation

[0019] Exemplary embodiments of the invention will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limiting the invention to the embodiments set forth herein. Rather, these exemplary embodiments are provided to make the invention more comprehensive and complete, and to facilitate a full communication of the inventive concept to those skilled in the art. The same reference numerals in the drawings denote the same or similar elements, components, or parts, and therefore repeated descriptions of them will be omitted.

[0020] Subject to the technical concept of this invention, the features, structures, characteristics or other details described in a particular embodiment may be combined in one or more other embodiments in a suitable manner.

[0021] In the description of specific embodiments, the features, structures, characteristics, or other details described in this invention are intended to enable those skilled in the art to fully understand the embodiments. However, it is not excluded that those skilled in the art can practice the technical solutions of this invention without one or more of the specific features, structures, characteristics, or other details.

[0022] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0023] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0024] The terms “and / or” or “and / or” include all combinations of any one or more of the listed items.

[0025] Please see Figure 1 The first embodiment of the authorization method for adaptively selecting security policies based on client risk type in this invention includes: S101. Receive the authorization request from the client and extract the authorization request parameters from the client's authorization request; It is understood that the executing entity of this invention can be an authorization device / system that adaptively selects security policies based on client risk types, or it can be a terminal or a server; the specific implementation is not limited here. This embodiment of the invention uses a server as an example for illustration.

[0026] In this embodiment, the client application can initiate an authorization request to the authorization server. The purpose of this authorization request is to obtain the user's consent and obtain the final authorization code or access token through the authorization process, so that authorization can be completed based on this information and the client can securely obtain user information to prevent user information leakage.

[0027] In this embodiment, the authorization request can be an HTTP request, and the authorization request parameters can include information such as response type, client identifier, and redirection URI (Uniform Resource Identifier).

[0028] S102. Based on the authorization request parameters, query the static information provided by the client during registration in the client information management database; After obtaining the authorization request parameters, the static information provided during client registration can be queried in the client information management database. Specifically, one or more of the authorization request parameters can be used as the query key to retrieve information such as the registered client type, redirection URI list, and application metadata provided during client registration, and then saved as static information.

[0029] In one specific implementation, to improve the query effect of static information, the client identifier in the authorization request parameter can be used as the query primary key to query information such as the registered client type, redirection URI list and application metadata provided during client registration in the client information management database, and save it as static information.

[0030] The client types include either Confidential or Public.

[0031] S103. Capture the context information and environmental characteristics of the authorization request in real time to obtain dynamic information; In this step, the context information and environmental features of the current authorized HTTP request are captured and extracted in real time to obtain dynamic information. The context information includes dynamic attributes directly related to the current request information, which are extracted in real time from a single request and change with each request, representing the specific conditions of this interaction; while the environmental features refer to the background operating conditions in which the request occurs, which can be used to reflect the state of the client and can be used to describe the inherent attributes of the client's operating environment.

[0032] Specifically, the dynamic information includes network-level features, HTTP request-level features, OAuth protocol-level features, and historical behavior-level features.

[0033] S104. Call the risk assessment engine to conduct a comprehensive assessment based on static and dynamic information to determine the risk type corresponding to the authorization request; In this step, a comprehensive risk score can be obtained based on a weighted scoring of a series of risk factors. In one specific implementation, risk factors contained in the static information and the dynamic information are identified, each factor is assigned a different weight according to its degree of danger, and a comprehensive risk score is calculated based on the risk factors of each authorization request.

[0034] In one specific implementation, a comprehensive risk score can be calculated based on risk factors obtained from static and dynamic information; the comprehensive risk score can then be mapped to the corresponding risk type according to a risk threshold.

[0035] S105. Select the corresponding security policy based on the risk type and execute the authorization operation.

[0036] Based on the presumed client type and risk assessment results obtained in the previous steps, the system dynamically matches and enforces security measures applicable to the current session request based on the pre-configured security policy library, and performs authorization operations based on the corresponding security measures.

[0037] Specifically, the risk types described in this embodiment include low risk, medium risk, and high risk; For low-risk authorization requests, the standard processing strategy is applied, and no modifications are made to the authorization request; the authorization process corresponding to the authorization request is then initiated. For medium-risk authorization requests, a security enhancement policy is matched, forcing the client to authorize using the extended protocol of OAuth 2.0, namely PKCE (Proof Key for Code Exchange, RFC 7636); For high-risk authorization requests, the direct rejection policy is applied, the authorization process is interrupted, and an authorization error message is sent to the client.

[0038] The method provided in this embodiment of the invention can automatically execute corresponding security policies based on the actual operational risks of the authorization request, reduce the possibility of security vulnerabilities, improve the security of the authorization process, and enhance the automation effect of the authorization method.

[0039] Please refer to Figure 2 The second embodiment of the authorization method for adaptively selecting security policies based on client risk type in this invention includes: S201. Receive the authorization request from the client and extract the authorization request parameters from the client's authorization request; It is understood that the executing entity of this invention can be an authorization device / system that adaptively selects security policies based on client risk types, or it can be a terminal or an authorization server; the specific implementation is not limited here. This embodiment of the invention uses an authorization server as an example for illustration.

[0040] In this embodiment, the client application can initiate an authorization request to the authorization server. The purpose of this authorization request is to obtain the user's consent and obtain the final authorization code or access token through the authorization process, so that authorization can be completed based on this information and the client can securely obtain user information to prevent user information leakage.

[0041] In one specific implementation, before obtaining the authorization request, the authorization server may receive other interactive requests. If it is an interactive request and the interactive request requires obtaining the user's authorization information, it will redirect to the authorization page of the authorization server. Based on the user's interactive information on the authorization page on the client, it will still send an authorization request to the authorization server.

[0042] Specifically, the authorization endpoint (usually / authorize) of the authorization server listens for and receives HTTP requests from client applications. These HTTP requests can be GET or POST requests. In a GET request, the parameters are in the query string, while in a POST request, the parameters are in the request body. In one specific implementation, the HTTP request conforms to the OAuth 2.0 (RFC 6749) specification.

[0043] Upon receiving a GET or POST request, parse the parameters related to OAuth 2.0 authorization from the query string of the GET request or the request body of the POST request. These parameters should include at least the following items: (1) response_type (response type): This parameter indicates the type of authorization process the client originally expected to use; for example, response_type=code indicates that the client expects to use the authorization code process, in which the server returns an authorization code after the user authorizes the authorization, and the client needs to use this authorization code to exchange for an access token; response_type=token indicates that the client expects to use the implicit process for authorization, in which the authorization server directly returns the access token to the client through a URL fragment after the user authorizes the authorization. (2) client_id (client identifier): This parameter represents the unique identifier obtained by the client application when registering with the authorization server. The authorization server uses it to identify which client application is making the request. The server will use this client_id to look up the client's registration information (such as supported authorization types, valid redirect URIs, keys, etc.) to verify the legitimacy of the request. (3) redirect_uri (redirect URI): This parameter represents the target URI (Uniform Resource Identifier) ​​of the user agent (such as a browser) after successful (or failed) authorization. (4) scope (permission range): This parameter indicates the specific scope of permissions that a client application requests to access user resources. In other words, it defines the types of operations that the client will perform on behalf of the user and the range of data that will be accessed. For example, scope=profile email indicates that the application is requesting access to the user's basic information and email address.

[0044] (5) state: This parameter represents a random string provided by the client application to prevent CSRF (Cross-Site Request Forgery).

[0045] In a preferred embodiment of this implementation, in addition to parsing parameters related to OAuth 2.0 authorization from the query string of a GET request or the request body of a POST request, the method also includes parsing and checking whether the query string of a GET request or the request body of a POST request contains parameters related to OAuth 2.0's extended specification PKCE (Proof Key for Code Exchange, RFC 7636) authorization verification, including: (6) code_challenge: This parameter represents the challenge code generated by the client using the code_verifier (original key). The code_verifier is transformed according to the selected code_challenge_method, and the resulting encoding is the code_challenge.

[0046] (7) code_challenge_method (code challenge method): This parameter indicates the hash algorithm (e.g., SHA-256 hash algorithm) used to convert code_verifier to code_challenge.

[0047] In this step, the input information required for subsequent analysis is completed, and the existence of the PKCE parameter is preliminarily checked.

[0048] S202. Based on the authorization request parameters, query the static information provided by the client during registration in the client information management database; Based on the authorization request parameters obtained in the preceding steps, the static information provided during client registration is queried in the client information management database. Specifically, when performing the query, the client_id (client identifier) ​​contained in the authorization request parameters can be used as the query primary key to retrieve the static information provided during client registration from the information management database or configuration storage contained in the authorization server. This static information includes: (1) Registration client type: Clearly record it as either Confidential or Public; (2) List of pre-registered redirect URIs: The list of redirect URIs includes one or more approved redirect_uri; (3) Application metadata; This information includes data such as the application name and the owner's contact information.

[0049] S203. Capture the context information and environmental characteristics of the current authorization request in real time to obtain dynamic information; In this step, the context information and environmental features of the current authorized HTTP request are captured and extracted in real time. The context information includes dynamic attributes directly related to the current request information, which are extracted in real time from a single request and change with each request, representing the specific conditions of this interaction. The environmental features refer to the background operating conditions in which the request occurs, which can be used to reflect the client's state and describe the inherent attributes of the client's operating environment. In general, the dynamic information obtained based on the context information and environmental features includes multiple aspects, such as: network-level features, HTTP request-level features, OAuth protocol-level features, and historical behavior-level features.

[0050] In one specific implementation, the dynamic information for each aspect includes the following specific content and acquisition method: (1) Network-level characteristics: Source IP address: The IP address from which the request originated; IP geolocation: Information such as country and city obtained by resolving an IP address; IP Reputation: Optionally integrate with third-party threat intelligence databases to determine whether the IP is an exit node of a known proxy, an anonymous communication method such as Tor (The Onion Router), or belongs to a malicious network (botnet, etc.). (2) HTTP request layer characteristics: User-Agent string: Used to initially determine the client's operating environment, such as a mobile app's WebView, a desktop browser, or a server-side script (curl, python-requests, etc.).

[0051] Other HTTP header information, such as Accept-Language and Referer, can be used as auxiliary analytical features.

[0052] (3) OAuth protocol layer features: The information obtained by comparing the redirect_uri in the request with the list of pre-registered redirect URIs queried in step S202; Analyze the sensitivity of the permission scope of the current HTTP request to obtain characteristic information; (4) Characteristics at the level of historical behavior: Query historical request records associated with the client_id (client identifier) ​​contained in the HTTP request, and extract behavioral patterns, including: IP stability: Distribution of historical request IP addresses (whether they frequently change geographical location or IP range); User-Agent consistency: Whether the User-Agent of historical requests is stable or changes regularly; Historical risk record: Whether this client has triggered risk policies in the past.

[0053] In this embodiment, after acquiring static and dynamic information, a pre-built risk assessment model is used to analyze and score the data from multiple aspects, thereby comprehensively assessing the risk type of the current session request. The specific risk type determination includes the following three parts: presumed client type analysis, multi-factor risk weighted scoring, and risk type determination.

[0054] S204. Call the risk assessment engine to identify risk factors contained in static and dynamic information, and calculate a comprehensive risk score based on the risk factors; This step involves obtaining a comprehensive risk score based on a weighted scoring of a series of risk factors. In one specific implementation, risk factors contained in the static and dynamic information are identified, each factor is assigned a different weight according to its degree of danger, and a comprehensive risk score is calculated based on the risk factors for each authorization request. For example: Examples of high-risk factors include: the requesting IP is on the blacklist in the threat intelligence database, the request's redirect_uri is not in the pre-registered list, and the frequency of requests is abnormal within a short period of time, etc. Examples of medium-risk factors include: the geographical location of the requesting IP deviates significantly from its historically frequently used location, atypical changes in the User-Agent, and discrepancies between the presumed type and the registered type (such as a "confidential" client exhibiting "public" behavior), etc.

[0055] In one specific implementation, a risk assessment engine can be invoked to compare static and dynamic information to determine whether there are any inconsistencies. If there are inconsistencies, a judgment rule is searched in a preset type analysis rule base based on the inconsistent information entries and specific inconsistent information content, and the current client type is inferred based on the preset judgment rule.

[0056] The pre-defined type analysis rule base includes the following rule: "Determine the dynamic request type based on HTTP request-level characteristics and OAuth protocol-level characteristics; detect inconsistencies between the client's original registration type and the dynamic request type; if inconsistencies exist, determine the actual client type based on the current dynamic request type, network-level characteristics, and historical behavior-level characteristics." For example, if a client's registered client type is "Confidential," but its current request's User-Agent indicates a standard browser, and its source IP address shows high dispersion in recent history (e.g., from multiple countries or numerous different internet service providers), then the inferred type of its current session is determined to be "Public-like Client." In this case, the authorization request contains a medium-risk factor.

[0057] When the solution in this embodiment needs to address new threats or support new standards, it only needs to adjust the risk assessment engine and security policy library to add new rules, without changing the core authorization process, thus possessing extremely high flexibility and scalability.

[0058] S205: Based on the comprehensive risk score and the preset risk threshold in the risk assessment engine, the risk type corresponding to the authorization request is obtained; This step maps the calculated comprehensive risk score to a predefined risk type. After calculating the comprehensive risk score based on the risk factors, the comprehensive risk score is then compared with a preset first risk threshold. and the second risk threshold The comparison is made, wherein the first risk threshold is... Less than the second risk threshold When the overall risk score is less than the first risk threshold If the overall risk score is greater than or equal to the first risk threshold, it is considered a low-risk authorization request; And less than or equal to the second risk threshold If the overall risk score is greater than the second risk threshold, it is considered medium risk; This indicates a high risk.

[0059] S206. Select the corresponding security policy based on the risk type and execute the authorization operation; Based on the presumed client type and risk assessment results obtained in the previous steps, the system dynamically matches and enforces security measures applicable to the current session request based on the pre-configured security policy library, and performs authorization operations based on the corresponding security measures.

[0060] The security policy library predefines and stores security operation information corresponding to combinations of different effective operation types and risk type assessment results. Specific processing strategies include "standard processing strategies," "security enhancement strategies," and "direct rejection strategies." A concrete example is provided below: When the risk type obtained in the aforementioned steps is a low-risk authorization request, the "standard processing strategy" is matched. No modifications are made to the authorization request, and the normal authorization process is initiated based on the static type originally registered by the client, selecting the authorization method corresponding to the original static type. For example, if the client's original registered static type is confidential, the original OAuth 2.0 authorization method is used. The actual authorization process includes verifying the user's identity, obtaining user consent, generating an authorization code, and redirecting the request to the redirect_uri specified by the client via HTTP. When issuing the authorization code, the server internally binds it to code_challenge and code_challenge_method.

[0061] If a client originally registered a confidential static type, but the presumed client type based on client information, request IP, and UA (User Agent) is actually public, and the obtained risk type assessment result is medium risk, then a "security enhancement strategy" is matched, forcing the current client to request authorization using the PKCE method. For example, it checks whether the authorization request parameters include the `code_challenge` parameter and whether the `code_challenge` parameter is in a valid format. If the `code_challenge` parameter is included and its format is valid, then the current client is considered to meet the PKCE verification requirements, and the current client is allowed to enter the PKCE verification authorization process. If the `code_challenge` parameter is not included, the authorization process is interrupted, and a verification failure message is returned to the client. The verification failure message (the response body returned to the client) includes a notification informing the client developer that PKCE verification is required to continue authorization. At this point, the current authorization process is terminated, and the server constructs and sends an HTTP error response.

[0062] Regardless of the original static type registered by the client, if the IP address sending the request belongs to a known malicious network, or the geographical location does not match the client's historical main activity area, or the request frequency spikes abnormally, then the authorization request contains a high-risk factor. Based on the steps of multi-factor risk weighted scoring and risk type determination, it is determined that the current session request belongs to a high-risk session. In this case, regardless of the presumed client type, the authorization process will be interrupted based on the high risk obtained from the evaluation, the session request will be directly rejected, and an authorization error message will be sent to the client.

[0063] S207. Record the request process and authorization result of the authorization request information, obtain the authorization log, and determine whether an alarm needs to be triggered based on the content of the authorization log. If an alarm needs to be triggered, send an alarm message containing event details through the alarm channel.

[0064] In one specific implementation, this embodiment also includes logging and alarm steps. To ensure the auditability, traceability, and operational responsiveness of the system, this embodiment records all activities in parallel and determines whether to trigger an alarm based on the recorded activity information. Specifically, the logging step generates a detailed authorization log for each authorization request, including the timestamp, request ID; all collected static information and dynamic behavioral characteristics (client_id, IP, UA, etc.); the output of the risk assessment engine, including the presumed type, risk score, and final risk type; the name of the dynamically executed policy (e.g., "Enforce_PKCE"); and the final processing result (whether an authorization code was issued or an error was returned).

[0065] Based on the information recorded in the authorization log and the preset alarm triggering rules, it is determined whether an alarm needs to be triggered, such as actively issuing an alarm when a high-risk event is detected; if an alarm needs to be triggered, an alarm message containing event details is sent through the alarm channel.

[0066] In one specific implementation, an alarm trigger condition is met when a request is assessed as "high" in risk type, or when the "forced PKCE" policy is triggered more than N times. When the alarm trigger condition is met, an alarm message containing event details (such as client ID, risk cause, time, etc.) is sent to the security administrator or application owner through a pre-configured alarm channel (such as email, SMS, webhook, etc.) for manual intervention or investigation.

[0067] The method provided in this invention, by dynamically analyzing the actual behavioral characteristics of the client rather than relying solely on static registration, can more accurately and promptly identify potential security risks. It mitigates security vulnerabilities caused by client misconfiguration, developer negligence, or operation in unexpected environments, particularly regarding the protection of authorization codes. This invention achieves proactive identification and forward-looking defense against potential security risks, effectively blocking potential attack paths by dynamically enforcing appropriate security mechanisms before security incidents actually cause harm. Furthermore, the authorization server can dynamically adjust security policies based on real-time context, rather than using a one-size-fits-all approach. This makes security protection more targeted and refined, improving the security of the authorization process and enhancing the automation of the authorization method.

[0068] Even when developers misconfigure client types, behavioral analysis can identify mismatches and take appropriate authorization measures. For example, even clients registered as "confidential" will be automatically identified and subject to stricter security requirements in specific high-risk contexts, enabling personalized risk assessment and differentiated security protection for each authorization request. This solution enhances the ability to respond to unknown threats and evolving attack methods, endowing OAuth 2.0 authorization servers with intelligent awareness and adaptability, contributing to the overall robustness of the OAuth 2.0 ecosystem, and providing a smooth, intelligent, and backward-compatible upgrade path for existing systems.

[0069] Please see Figure 3 and Figure 4 In one specific implementation, the third embodiment of the authorization method for adaptively selecting security policies based on client risk type in this invention includes: Please see Figure 3 The main system for implementing an authorization method that adaptively selects security policies based on client-side risk types includes an OAuth client and an authorization server. The authorization server contains multiple functional modules, including: a client information management module, a behavior feature collection module, a risk assessment module, a dynamic security policy execution module, and a logging and alerting module. These functional modules work together to implement the authorization method that adaptively selects security policies based on client-side risk types.

[0070] Please continue reading. Figure 4 The workflow of the above functional modules in implementing the authorization method that adaptively selects security policies based on client risk types is as follows: S401. The client first sends an authorization request to the authorization server.

[0071] S402. After receiving the authorization request, the authorization endpoint of the authorization server (represented by / authorize in this embodiment) requests the authorization request information to be analyzed by the behavior feature collection module of the authorization server.

[0072] S403. The behavior feature collection module analyzes client information, the client's request IP, and UA (User Agent) information based on the received analysis authorization request information.

[0073] S404. The behavior feature collection module sends a risk assessment request to the risk assessment module and the log and alarm module based on the information obtained in step S403.

[0074] S405 The risk assessment module provides the risk type based on the obtained client information, the client's request IP, and UA (User Agent) information. At the same time, the log and alarm module assesses the risk type based on the client information and request information, and records logs and high-risk request alarm information.

[0075] S406, and based on the risk assessment results, send an assessment result execution request to the dynamic security policy execution module.

[0076] S407 The dynamic security policy execution module matches the corresponding security policy in the security policy library according to different risk types.

[0077] S408. The dynamic security policy execution module returns security policy requirements to the authorization endpoint of the authorization server.

[0078] S409. The authorization endpoint of the authorization server returns authorization information to the client. If the security policy requirements determined in the preceding steps are different from the authorization method indicated in the original authorization request, then the specific authorization is performed by matching the selected security policy requirements.

[0079] In one specific embodiment, if the dynamic security policy execution module determines that a situation is risky, it rejects the authorization request initiated by the current user and returns an error message, while requiring the user client to use PKCE mode for authorization with code_challenge + code_challenge_method.

[0080] S410. Based on the specific authorization method, request the corresponding access token from the token endpoint (represented by / token in this embodiment). If the authorization is performed using the ordinary OAuth 2.0 authorization method, the access token is obtained directly through the authorization code. If the authorization is performed using the PKCE mode, the access token is obtained through the authorization code Code + code_verifier.

[0081] S411, returns the Access Token and an optional Refresh Token.

[0082] After obtaining the Access Token and an optional Refresh Token, the client can access the necessary information contained in the resource server based on these. The short-lived Access Token reduces the risk of leakage, while the Refresh Token, which is used for token updates and does not directly access resources, is bound to the device to update the token. This eliminates the need for users to frequently re-authorize manually, improving the security of the authorization process, optimizing the user experience, and enhancing the overall user experience.

[0083] For details on the specific implementation of each step in this embodiment, please refer to the content of the aforementioned second embodiment, which will not be repeated here.

[0084] The method provided in this embodiment of the invention can automatically execute corresponding security policies based on the actual operational risks of the authorization request, reduce the possibility of security vulnerabilities, improve the security of the authorization process, and enhance the automation effect of the authorization method.

[0085] The authorization method for adaptively selecting security policies based on client risk types in embodiments of the present invention has been described above. The authorization system for adaptively selecting security policies based on client risk types in embodiments of the present invention is described below. Please refer to [link / reference]. Figure 5 An embodiment of the authorization system that adaptively selects security policies based on client risk types in this invention includes: The request receiving module 501 is used to receive an authorization request from a client and extract the authorization request parameters of the client from the authorization request; The first information acquisition module 502 is used to query the static information provided by the client during registration in the client information management database based on the authorization request parameters; The second information acquisition module 503 is used to capture the context information and environmental characteristics of the authorization request in real time to obtain dynamic information; The risk assessment module 504 is used to call the risk assessment engine to perform a comprehensive assessment based on the static information and the dynamic information to determine the risk type corresponding to the authorization request. The strategy selection module 505 is used to select the corresponding security policy based on the risk type and perform the authorization operation.

[0086] The system of this invention can automatically execute corresponding security policies based on the actual operational risks of authorization requests, reduce the possibility of security vulnerabilities, improve the security of the authorization process, and enhance the automation effect of the authorization method.

[0087] In another embodiment of this application, the authorization request parameters include a client identifier; the dynamic information includes network-level features, HTTP request-level features, OAuth protocol-level features, and historical behavior-level features. The first information acquisition module 502 is specifically used to query the registered client type, redirection URI list and application metadata provided during client registration in the client information management database based on the client identifier; The second information acquisition module 503 is specifically used to capture dynamic attributes related to the authorization request in real time as context information, capture background operating conditions related to the authorization request as environmental features, and obtain network layer features, HTTP request layer features, OAuth protocol layer features and historical behavior layer features.

[0088] In another embodiment of this application, the risk assessment module 504 is specifically used to call the risk assessment engine to identify the risk factors contained in the static information and the dynamic information, and to calculate a comprehensive risk score based on the risk factors; Based on the comprehensive risk score and the preset risk threshold in the risk assessment engine, the risk type corresponding to the authorization request is obtained.

[0089] In another embodiment of this application, the risk types include low risk, medium risk, and high risk; The strategy selection module 505 is specifically used to match a standard processing strategy for low-risk authorization requests, without making any modifications to the authorization request, and to enter the authorization process corresponding to the authorization request; For medium-risk authorization requests, a security enhancement policy is applied to force the client to use PKCE authorization. For high-risk authorization requests, the direct rejection policy is applied, the authorization process is interrupted, and an authorization error message is sent to the client.

[0090] In another embodiment of this application, when the presumed client type and the registered client type do not match, the risk type is medium risk; For medium-risk authorization requests, matching security enhancement policies and forcing the client to use PKCE authorization includes: Check whether the authorization request parameters include the code_challenge parameter, and check whether the code_challenge parameter is in a valid format; If the code_challenge parameter is included and the format of the code_challenge parameter is valid, then the current client is considered to meet the PKCE verification requirements and is allowed to enter the PKCE verification and authorization process. If the code_challenge parameter is not included, the authorization process is interrupted and a verification failure message is returned to the client. The verification failure message includes a notification that the client developer needs to perform PKCE verification in order to continue the authorization.

[0091] In another embodiment of this application, the authorization system that adaptively selects security policies based on client risk type further includes a log recording and alarm module. The log recording and alarm module is specifically used to record the request process and authorization result of authorization request information, obtain authorization logs, and determine whether an alarm needs to be triggered based on the content of the authorization logs. If an alarm needs to be triggered, an alarm message containing event details will be sent through the alarm channel.

[0092] The system of this invention can automatically execute corresponding security policies based on the actual operational risks of authorization requests, reduce the possibility of security vulnerabilities, improve the security of the authorization process, and enhance the automation effect of the authorization method.

[0093] Based on the same inventive concept, this specification also provides an authorized electronic device that adaptively selects a security policy based on client risk type. The authorized electronic device based on adaptive selection of a security policy based on client risk type in this embodiment of the invention will be described in detail below from the perspective of hardware processing.

[0094] Figure 6 This is a schematic diagram of an electronic device provided as an embodiment of this specification. Refer to the following... Figure 6 The electronic device 600 according to this embodiment of the present invention will be described. Figure 6 The electronic device 600 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0095] like Figure 6 As shown, the electronic device 600 is presented in the form of a general-purpose computing device. The components of the electronic device 600 may include, but are not limited to: at least one processing unit 610, at least one storage unit 620, a bus 630 connecting different system components (including storage unit 620 and processing unit 610), a display unit 640, etc.

[0096] The storage unit stores program code that can be executed by the processing unit 610, causing the processing unit 610 to perform the steps described in the processing method section of this specification according to various exemplary embodiments of the present invention. For example, the processing unit 610 can perform actions such as... Figure 1 , Figure 2 or Figure 4 The steps are shown.

[0097] The storage unit 620 may include a readable medium in the form of a volatile storage unit, such as a random access memory unit (RAM) 6201 and / or a cache storage unit 6202, and may further include a read-only memory unit (ROM) 6203.

[0098] The storage unit 620 may also include a program / utility 6204 having a set (at least one) program module 6205, such program module 6205 including but not limited to: an operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0099] Bus 630 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0100] Electronic device 600 can also communicate with one or more external devices 100 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 600, and / or with any device that enables electronic device 600 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 650. Furthermore, electronic device 600 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 660. Network adapter 660 can communicate with other modules of electronic device 600 via bus 630. It should be understood that, although... Figure 6 As not shown in the diagram, other hardware and / or software modules may be used in conjunction with the electronic device 600, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0101] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described in this invention can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this invention can be embodied in the form of a software product, which can be stored in a computer-readable storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, or network device, etc.) to execute the method described above according to this invention. When the computer program is executed by a data processing device, it enables the computer-readable medium to implement the method described above, i.e.: as... Figure 1 , Figure 2 or Figure 4 The method shown.

[0102] Figure 7 This is a schematic diagram of a computer-readable medium provided for embodiments of this specification.

[0103] accomplish Figure 1 , Figure 2 or Figure 4 The computer program of the method shown can be stored on one or more computer-readable media. A computer-readable medium can be a readable signal medium or a readable storage medium. A readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

[0104] The computer-readable storage medium may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The readable storage medium may also be any readable medium other than a readable storage medium, capable of transmitting, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0105] In addition, the present invention provides a computer program product, including a computer program / instruction that, when executed by a processor, implements an authorization method for adaptively selecting a security policy based on client risk type as described in any of the above embodiments.

[0106] Program code for performing the operations of this invention can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0107] In summary, the present invention can be implemented in hardware, or as software modules running on one or more processors, or a combination thereof. Those skilled in the art will understand that in practice, general-purpose data processing devices such as microprocessors or digital signal processors (DSPs) can be used to implement some or all of the functions of some or all of the components according to the embodiments of the present invention. The present invention can also be implemented as a device or apparatus program (e.g., a computer program and computer program product) for performing part or all of the methods described herein. Such programs implementing the present invention can be stored on a computer-readable medium or can be in the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.

[0108] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the present invention is not inherently related to any specific computer, virtual device, or electronic device, and various general-purpose devices can also implement the present invention. The above descriptions are merely specific embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

[0109] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0110] If the technical solution of this application involves personal information, the product using this technical solution has clearly informed the user of the personal information processing rules and obtained the user's voluntary consent before processing the personal information. If the technical solution of this application involves sensitive personal information, the product using this technical solution has obtained the user's separate consent before processing the sensitive personal information, and also meets the requirement of "express consent". For example, at personal information collection devices such as cameras, clear and prominent signs are set up to inform users that they have entered the scope of personal information collection and that personal information will be collected. If an individual voluntarily enters the collection scope, it is deemed that they have agreed to the collection of their personal information; or on the personal information processing device, with clear signs / information informing users of the personal information processing rules, authorization is obtained from the individual through pop-up information or by asking the individual to upload their personal information; wherein, the personal information processing rules may include information such as the personal information processor, the purpose of personal information processing, the processing method, and the types of personal information processed.

[0111] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. An authorization method for adaptively selecting security policies based on client risk types, characterized in that, include: Receive an authorization request from a client, and extract the client's authorization request parameters from the authorization request, wherein the authorization request parameters include a client identifier; Based on the client identifier contained in the authorization request parameters, query the static information provided during client registration in the client information management database, wherein the static information includes the registered client type, a list of redirect URIs, and application metadata; The system captures dynamic attributes representing specific conditions of the authorization request in real time as context information, and captures background operating conditions related to the authorization request as environmental features to obtain dynamic information. The dynamic information includes network layer features, HTTP request layer features, OAuth protocol layer features, and historical behavior layer features. The risk assessment engine is invoked to perform a comprehensive assessment based on the static and dynamic information to determine the risk type corresponding to the authorization request, wherein the risk type includes low risk, medium risk, and high risk; For low-risk authorization requests, the standard processing strategy is applied, and no modifications are made to the authorization request; the authorization process corresponding to the authorization request is then initiated. For medium-risk authorization requests, a security enhancement policy is applied to force the client to use PKCE authorization. For high-risk authorization requests, the direct rejection policy is applied, the authorization process is interrupted, and an authorization error message is sent to the client.

2. The authorization method for adaptively selecting security policies based on client risk type according to claim 1, characterized in that, The risk assessment engine performs a comprehensive evaluation based on the static and dynamic information to determine the risk type corresponding to the authorization request, including: The risk assessment engine is invoked to identify the risk factors contained in the static and dynamic information, and a comprehensive risk score is calculated based on the risk factors. Based on the comprehensive risk score and the preset risk threshold in the risk assessment engine, the risk type corresponding to the authorization request is obtained.

3. The authorization method for adaptively selecting security policies based on client risk type according to claim 2, characterized in that, When the presumed client type does not match the registered client type, the risk type is medium risk; For medium-risk authorization requests, matching security enhancement policies and forcing the client to use PKCE authorization includes: Check whether the authorization request parameters include the code_challenge parameter, and check whether the code_challenge parameter is in a valid format; If the code_challenge parameter is included and the format of the code_challenge parameter is valid, then the current client is considered to meet the PKCE verification requirements and is allowed to enter the PKCE verification and authorization process. If the code_challenge parameter is not included, the authorization process is interrupted and a verification failure message is returned to the client. The verification failure message includes a notification that the client developer needs to perform PKCE verification in order to continue the authorization.

4. The authorization method for adaptively selecting security policies based on client risk type according to any one of claims 1-3, characterized in that, Also includes: Record the request process and authorization result of the authorization request information to obtain the authorization log, and determine whether an alarm needs to be triggered based on the content of the authorization log; If an alarm needs to be triggered, an alarm message containing event details will be sent through the alarm channel.

5. An authorization system that adaptively selects security policies based on client risk types, characterized in that, The authorization system that adaptively selects security policies based on client risk types includes: A request receiving module is used to receive an authorization request from a client and extract the client's authorization request parameters from the authorization request, wherein the authorization request parameters include a client identifier; The first information acquisition module is used to query the static information provided by the client during registration in the client information management database based on the client identifier contained in the authorization request parameters, wherein the static information includes the registered client type, a list of redirect URIs, and application metadata; The second information acquisition module is used to capture dynamic attributes representing specific conditions of the authorization request as context information in real time, capture background operating conditions related to the authorization request as environmental features, and obtain dynamic information, wherein the dynamic information includes network layer features, HTTP request layer features, OAuth protocol layer features and historical behavior layer features. The risk assessment module is used to call the risk assessment engine to perform a comprehensive assessment based on the static information and the dynamic information to determine the risk type corresponding to the authorization request, wherein the risk type includes low risk, medium risk and high risk; The strategy selection module is used to match the standard processing strategy for low-risk authorization requests, without making any modifications to the authorization request, and enter the authorization process corresponding to the authorization request; for medium-risk authorization requests, it matches the security enhancement strategy, forcing the client to use the PKCE method for authorization; for high-risk authorization requests, it matches the direct rejection strategy, interrupts the authorization process, and sends an authorization error message to the client.

6. An authorization device that adaptively selects security policies based on client risk types, characterized in that, The authorization device that adaptively selects security policies based on client risk types includes: a memory and at least one processor, wherein the memory stores instructions; The at least one processor invokes the instructions in the memory to cause the authorization device that adaptively selects a security policy based on client risk type to perform the steps of the authorization method based on client risk type as described in any one of claims 1-4.

7. A computer-readable storage medium storing a computer program / instructions thereon, characterized in that, When the program / instruction is executed by the processor, it implements the steps of the authorization method for adaptively selecting security policies based on client risk type as described in any one of claims 1-4.

8. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instruction is executed by the processor, it implements the steps of the authorization method for adaptively selecting a security policy based on the client risk type as described in any one of claims 1-4.

Images