A hybrid authentication method based on gateway request

Abstract

This invention provides a hybrid authentication method based on gateway requests, relating to the field of computer science and technology. It includes: S1 receiving a client request and identifying the protocol type; S2 parsing the request and extracting common access elements to generate a unified four-tuple; S3 querying and loading the corresponding hybrid authentication strategy; S4 dynamically injecting real-time risk control data; S5 performing authentication determination through a combination engine of RBAC / ABAC / ReBAC; and S6 allowing or rejecting the request based on the result. This invention integrates three permission models, solving the problems of fragmented heterogeneous protocol strategies, disconnect between authentication and real-time risk control, performance bottlenecks in centralized architectures, and complex scenario-based permission collaborative decision-making, thereby improving authentication flexibility, security, and concurrent processing capabilities.

Description

Technical Field

[0001] This invention relates to the field of computer science and technology, and in particular to a hybrid authentication method based on gateway requests. Background Technology

[0002] With the rapid development of internet technology, microservice architecture, SaaS multi-tenant applications, and zero-trust security architecture are widely used in enterprise systems, placing higher demands on access control and permission management. Current mainstream authentication methods mainly rely on a single permission model, which is insufficient to meet the diverse needs of complex scenarios and has many limitations.

[0003] Currently, the Role-Based Access Control (RBAC) model faces the problem of role explosion, making it difficult to clearly represent resource inheritance, delegation, and organizational hierarchy relationships. It also suffers from poor cross-system permission consistency and cannot flexibly adapt to complex organizational structures and permission allocation needs within enterprises. The Attribute-Based Access Control (ABAC) model suffers from complex attribute combinations, leading to high implementation difficulty and significant shortcomings in reverse reasoning and auditing, hindering permission traceability and management. The Relational Access Control (ReBAC) model relies excessively on relationship graph management, resulting in complex access path calculations that struggle to meet high-performance requirements in high-concurrency scenarios, while also presenting significant auditing challenges.

[0004] In terms of interface protocol support, most existing authentication systems are designed only for REST APIs and cannot adapt to emerging protocols such as GraphQL, which limits the system's compatibility and scalability, making it difficult to cope with business scenarios where multiple protocols coexist.

[0005] Furthermore, the existing technology has the following problems: 1. Fragmentation of permission policies caused by semantic differences of heterogeneous protocols: Existing solutions usually maintain two sets of authentication logic for REST and GraphQL respectively, resulting in scattered permission policies that are difficult to manage in a unified manner, increasing development and operation costs.

[0006] 2. The problem of disconnect between authentication decision-making and real-time security posture: Most existing solutions are static authentication, which cannot dynamically integrate real-time risk data (such as abnormal login scores) from the risk control system during the authentication decision-making process, resulting in insufficient system response capabilities to risks such as advanced persistent threats (APT) and account theft.

[0007] 3. Performance bottlenecks in centralized authentication architecture: Centralized authentication at the gateway layer, which requires multiple remote database queries or service calls for each request, leads to high latency and low throughput, making it difficult to meet the needs of high-concurrency business scenarios.

[0008] 4. The problem of multi-dimensional permissions not being able to make collaborative decisions in complex business scenarios: Existing solutions are difficult to integrate role, attribute and relationship models in a single request for comprehensive judgment, and cannot meet the complex business logic that requires role matching, context compliance and relationship validity. Summary of the Invention

[0009] The purpose of this invention is to address the shortcomings of existing technologies by proposing a hybrid authentication method based on gateway requests. By integrating three permission models, it solves the problems of fragmented heterogeneous protocol policies, disconnect between authentication and real-time risk control, performance bottlenecks in centralized architectures, and collaborative decision-making challenges in complex scenarios, thereby improving authentication flexibility, security, and concurrent processing capabilities.

[0010] To achieve the above objectives, the present invention adopts the following technical solution: A hybrid authentication method based on gateway requests includes the following steps: S1: Accept client requests and identify the protocol type used in the request; Protocol types include: GraphQL protocol and REST API protocol; S2: Structured parsing and extraction of common access elements; Parse and extract common access elements from REST API and GraphQL requests, and normalize requests from different protocols into a standard format; common access elements include Subject, Action, Resource, and Context; S3: Query and load the authentication policy; Based on the parsed Resource path or operation name, query the pre-configured route-policy mapping table to obtain the authentication policy bound to the resource; S4: Dynamic data injection and real-time risk control linkage; Obtain the models participating in the authentication strategy, determine whether the ABAC model exists, if not, continue to execute S5; if it exists, decide whether to inject external real-time data according to the authentication strategy, if yes, inject external real-time data and then execute S5, otherwise execute S5 directly. S5: Executes a hybrid authentication engine: RBAC / ABAC / ReBAC combined judgment; Based on the loaded authentication strategy, obtain the models participating in authentication, and start the corresponding authentication module for parallel or serial evaluation. S6: Request denial or clearance; When the final decision is "allow", the request is forwarded to the downstream microservice; when it is "deny", the gateway directly returns a 403 Forbidden response.

[0011] Furthermore, step S1 includes: S11: In response to a client request, the gateway accepts the complete request data packet sent by the client; the request data packet includes a request line, request headers, and a request body. S12: Trigger protocol category identification and determination; S121: GraphQL protocol determination; If the Content-Type in the request header is application / json and the request body contains a query or mutation field, then it is determined to be a GraphQL request. S122: REST API protocol determination; If the received request data packet conforms to the standard REST style, it is determined to be a REST API request; S123: Exception handling; If a request does not meet the GraphQL protocol's judgment conditions or the REST API standard style, it is judged as an illegal request, and the gateway directly returns a 400 Bad Request response.

[0012] Furthermore, step S2 includes: S21: Protocol parsing; S211: REST API request parsing and extraction; 1) Extract Resources; Extract the request path and query parameters. For the path, break it down and combine it into a Resource. Use segment matching to parse the request path in the request line, split it into a list of path segments by / , filter the prefix segments, retain the resource type segment and resource ID segment, and combine them into a new path to form a Resource. 2) Extract the Action; Read the HTTP method from the request line and extract the HTTP method; HTTP methods include GET, POST, PUT, and DELETE; S212: GraphQL request parsing and extraction; GraphQL requests use a GraphQL parser to parse the query or mutation in the request body into an AST syntax tree, extracting the Action and Resource; First, construct the AST syntax tree; Read the query or mutation field values ​​from the request body, convert them into an AST syntax tree using the parse method of the GraphQL parser, and verify the validity of the AST; the AST syntax tree structure contains OperationDefinition, Field, and Argument nodes; Then, extract the Action; Iterate through the OperationDefinition nodes and extract the operation attribute value; the operation attribute value includes query or mutation, where query directly maps to the Action corresponding to read. Finally, extract the Resource; Traverse the Field nodes in the AST syntax tree and combine all requested top-level objects and their operations into a resource; S22: Extraction of common elements Subject and Context; Extract the Subject from the request header and construct the Context from the request context; the Subject is the user ID or service account; the request context includes the client IP, timestamp, and device information; S23: Generate a unified quadruple; The extracted elements are assembled into quadruples according to a fixed format: Subject, Action, Resource, Context.

[0013] Furthermore, step S3 includes: S31: Configured route-policy mapping table; The route-policy mapping table includes route ID, resource matching key, and authentication policy ID; The route ID is a unique identifier for the route; the resource matching key includes the resource path or operation name; the authentication policy ID is the index number of the policy and is a unique identifier for the authentication policy. Standardized definition of authentication strategy; The authentication strategy defines: The models involved in authentication include RBAC, ABAC, and ReBAC; Combinatorial logic between models, including AND, OR, and PRIORITY; The specific rules for each model include the role list of RBAC, the attribute condition expression of ABAC, and the relational path template of ReBAC; S32: Read the Resource field from the quadruple; if it is a REST API request, get the path; if it is a GraphQL request, get the operation name. S33: Based on the obtained path or operation name, query the route-policy mapping table to obtain the authentication policy ID; the authentication policy ID is associated with the authentication policy, and the content of the complete authentication policy is obtained.

[0014] Furthermore, the authentication policy is stored in a distributed configuration center or database.

[0015] Furthermore, step S4 specifically includes: S41: Obtain the attribute condition expression of ABAC in the authentication strategy, check whether risk data is required. If yes, trigger the injection request; otherwise, do nothing and continue to execute S5. S42: In response to the injection request, the gateway initiates an asynchronous or synchronous call to the risk control center via gRPC or message queue, sending a request to the risk control center containing Subject, client IP, and timestamp. The risk control center returns a real-time risk score and risk label. S43: After obtaining the real-time risk score and risk label, the gateway injects the real-time risk score and risk label into the generated quadruple Context.

[0016] Furthermore, step S5 includes: S51: Authentication module execution; (a) RBAC module execution: Query the set of roles for user Subject, then query which Action permissions these roles have been granted to the target resource, store the role-permission mapping relationship in Redis cache, and return whether permission is allowed; (b) ABAC module execution: Substitute the attributes in Subject, Resource, Action, and Context into the predefined ABAC policy rules: ABAC attribute condition expressions, use a lightweight rule engine for efficient evaluation, and return whether it is allowed; (c) ReBAC module execution: Treats users (Subject) and resources (Resource) as graph nodes, searches the permission relationship graph for an access path that meets the conditions, and returns whether it is allowed; S52: Summarize the judgment results based on the combination logic between the models defined by the authentication strategy; AND mode: All enabled models return "allow" and are judged as "allowed"; otherwise, they are judged as "rejected". OR mode: If any model returns "allow", it is judged as "allow"; otherwise, it is judged as "reject". PRIORITY mode: Short-circuit execution according to preset priority. Once a model returns a clear result, subsequent checks will stop. The output will be "allow" or "reject" based on the returned result.

[0017] Furthermore, in step S212, if a nested object is queried, starting from the Field node of the AST, all nested fields are traversed, the hierarchical relationship between the top-level field and the associated sub-field is recorded, and each field is combined with the corresponding Action into an independent authentication unit in the format [Action]:[Resource Type].

[0018] Compared with existing technologies, the beneficial effects of this invention are as follows: By introducing a unified authentication decision mechanism on the API gateway side and integrating three mainstream access control models—RBAC, ABAC, and ReBAC—this invention brings the following positive effects and significant advantages in practical applications: 1. This invention normalizes the semantics of different protocols at the data processing level by introducing AST parsing and a unified four-tuple model at the gateway layer. This allows the same hybrid authentication strategy to be seamlessly applied to two protocols, fundamentally solving the fragmentation problem of permission governance in multi-protocol environments, reducing system complexity, and resolving the problem of permission strategy fragmentation caused by heterogeneous protocols.

[0019] 2. This invention adds a "dynamic data injection" step to the data processing flow, proactively acquiring real-time risk data from the risk control system and using it as input for ABAC decision-making. This makes authentication no longer based on a fixed role-based "yes / no" judgment, but rather dynamically adjusted according to real-time context such as user login behavior and device fingerprints. This achieves dynamic access control under the "zero trust" principle, significantly improving the defense capability against advanced threats such as account theft, and ensuring that static authentication can address real-time risks.

[0020] 3. This invention utilizes a hybrid data processing architecture of "local caching (Redis), distributed indexing (Neo4j), and rule pre-compilation" to localize over 90% of queries. RBAC permissions are obtained from memory, ReBAC paths are quickly traversed using a graph index, and ABAC rules are efficiently evaluated in memory. This architecture design allows the system to maintain authentication flexibility while keeping the average latency below 20ms, supporting high concurrency, and resolving the contradiction between performance and flexibility that traditional solutions struggle to balance, thus avoiding performance bottlenecks caused by centralized authentication.

[0021] 4. This invention designs a configurable combinatorial decision engine, allowing the definition of AND / OR / PRIORITY logic at the strategy level. This data processing approach enables the system to integrate role, attribute, and relationship dimensions for comprehensive judgment within a single request. For example, it can require that "the user is a project administrator (RBAC) AND the operation time is during working hours (ABAC) AND the project belongs to the department managed by the user (ReBAC)" are satisfied simultaneously. This ability to express complex business rules is something that a single model or simple service call cannot achieve, thus avoiding the inability of a single model to express complex business logic. Attached Figure Description

[0022] Figure 1 This is a flowchart illustrating the steps of the hybrid authentication method based on gateway requests of the present invention. Detailed Implementation

[0023] To provide a further understanding of the purpose, structure, features, and functions of the present invention, detailed descriptions are provided below with reference to specific embodiments.

[0024] A hybrid authentication method based on gateway requests includes the following steps: S1: Accept client requests and identify the protocol type used in the request; The API gateway receives HTTP / HTTPS requests from clients. It analyzes the HTTP Content-Type header field or request body characteristics to identify the protocol type used in the request; Protocol types include: GraphQL protocol and REST API protocol; Specifically, S11: In response to a client request, the gateway accepts the complete request data packet sent by the client; the request data packet includes a request line, request headers, and a request body. S12: Trigger protocol category identification and determination; S121: GraphQL protocol determination; If the Content-Type in the request header is application / json and the request body contains a query or mutation field, then it is determined to be a GraphQL request. S122: REST API protocol determination; If the obtained request data packet conforms to the standard REST style (such as the path format / api / v1 / users / {id}), it is determined to be a REST API request.

[0025] S123: Exception handling; If a request does not meet the GraphQL protocol's judgment conditions or the REST API standard style, it is judged as an illegal request. The gateway directly returns a 400 Bad Request response and records the client IP, request time, and request content of the abnormal request to the gateway log system.

[0026] By using HTTP Content-Type headers, request body characteristics, and path formats, the system accurately distinguishes between the GraphQL protocol and the REST API protocol, avoiding subsequent authentication logic errors caused by protocol confusion. Requests that do not conform to the protocol's specifications are returned with a 400 error and logged, reducing the consumption of gateway resources by invalid requests at the source and intercepting illegal requests.

[0027] S2: Structured parsing and extraction of common access elements; Parse and extract common access elements from REST API and GraphQL requests, and normalize requests from different protocols into a standard format; Common access elements include Subject, Action, Resource, and Context; S21: Protocol parsing; S211: REST API request parsing and extraction; 1) Extract Resource; Extract the request path and query parameters; for the path, decompose and combine the path into a resource; use segment matching to parse the request path in the request line, split it into a list of path segments by / , filter the prefix segment, including api and v1, and retain the resource type segment (including orgs, projects, tasks, etc.) and resource ID segment, such as 123 / 456, etc.; combine them into a new path to form a resource.

[0028] For example, in the GET / api / v1 / orgs / 123 / projects / 456 / tasks?status=open command, the Resource is / orgs / 123 / projects / 456 / tasks.

[0029] 2) Extract Action; Read the HTTP method in the request line and extract the HTTP method (Method), such as GET, POST, PUT, DELETE.

[0030] S212: GraphQL request parsing and extraction; GraphQL requests use a GraphQL parser (such as graphql-js) to parse the query or mutation in the request body into an abstract syntax tree (AST) to extract the Action and Resource. First, construct the AST syntax tree; Read the query or mutation field values ​​from the request body, convert them into an abstract syntax tree (AST) using the parse method of the GraphQL parser. The AST structure contains nodes such as OperationDefinition, Field, and Argument, and the validity of the AST is verified. Then, extract the Action (operation); Traverse the OperationDefinition nodes of the Abstract Syntax Tree (AST) and extract the operation attribute value (query or mutation); where query directly maps to the Action corresponding to read.

[0031] Finally, extract the Resource. Traverse the fields in the Abstract Syntax Tree (AST), combining all requested top-level objects and their operations into a resource identifier: for example, in `mutation { createProject(orgId: "123", name: "New") { id}}`, the operation is `mutation`, and the resource is `createProject`. If querying nested objects, start from the Field node in the AST, traverse all nested fields, record the hierarchical relationship between the top-level field and its associated sub-fields, and combine each field with its corresponding Action into an independent authentication unit in the format `[Action]:[Resource Type]`; for example, `query { org(id: "123"){ projects { tasks { title}}}}`, decompose it into multiple authentication units: `read:org`, `read:projects`, `read:tasks`, and perform authentication checks on each.

[0032] S22: Extraction of common elements Subject and Context; Extract the Subject (user ID or service account) from the request header (such as the Authorization field), and extract the request context (client IP, timestamp, device information, etc.) to construct the Context.

[0033] Context is an environment attribute of the request, extracted from the request header and local gateway data; S23: Generate a unified quadruple; The extracted elements are assembled into a (Subject, Action, Resource, Context) quadruple according to a fixed format.

[0034] By extracting key elements and normalizing protocol semantics, the protocol barriers between GraphQL and REST API are broken down. For REST API, the path (Resource) and HTTP method (Action) are extracted. For GraphQL, the query / mutation is parsed and split into operation (Action) and nested field (Resource) through AST syntax tree parsing. Finally, the requests of the two protocols are uniformly transformed into a (Subject, Action, Resource, Context) quadruple.

[0035] S3: Query and load the authentication policy; Based on the resolved path (REST) ​​or operation name (GraphQL) of the resource, query the pre-configured route-policy mapping table to obtain the authentication policy bound to the resource.

[0036] S31: Configured route-policy mapping table; The route-policy mapping table includes fields such as route ID, resource matching key, and authentication policy ID; the route ID is a unique identifier for the route; the resource matching key includes the Resource path (REST) ​​or operation name (GraphQL); the authentication policy ID is the index number of the policy and is a unique identifier for the authentication policy.

[0037] The authentication strategy is defined using a standardized JSON format; the authentication strategy defines: The models involved in authentication include RBAC, ABAC, and ReBAC; one or more can be selected. Combinatorial logic between models, including AND, OR, and PRIORITY; The specific rules for each model include the role list for RBAC, the attribute condition expressions for ABAC, and the relational path template for ReBAC.

[0038] Authentication policies can be stored in a distributed configuration center (such as Nacos or Consul) or a database, supporting hot updates. This ensures that when authentication policies are added, modified, or deleted, the latest policies can be loaded, and the update process does not affect the authentication requests currently being processed, thus guaranteeing business continuity.

[0039] S32: Read the Resource field from the quadruple; if it is a REST API request, obtain the path, such as / orgs / 123 / projects / 456 / tasks; if it is a GraphQL request, obtain the operation name.

[0040] S33: Based on the obtained path or operation name, query the route-policy mapping table to obtain the authentication policy ID; the authentication policy ID is associated with the authentication policy, and the content of the complete authentication policy is obtained.

[0041] S4: Dynamic data injection and real-time risk control linkage; Obtain the authentication model participating in the authentication strategy, determine whether the ABAC model exists, if not, continue to execute S5; if it exists, decide whether to inject external real-time data according to the authentication strategy, if yes, inject external real-time data and then execute S5, otherwise execute S5 directly.

[0042] Specifically, it includes: S41: Obtain the attribute condition expression of ABAC in the authentication strategy, and check whether risk data is required. For example, if the expression modelRules.ABAC.riskDataRequired=true exists, trigger the injection request; otherwise, do nothing and continue to execute S5. S42: In response to the injection request, the gateway initiates an asynchronous or synchronous call to the enterprise risk control center via gRPC or a message queue (such as Kafka), sending a request containing key information such as the Subject (user ID), client IP, and request timestamp. Upon receiving the request, the risk control center calculates a real-time risk score (risk_score) and risk label (such as is_suspicious_login) based on its internal risk assessment model and returns them to the gateway. This gRPC / message queue (Kafka) enables the gateway and risk control system to work together, ensuring real-time and reliable transmission of risk data without blocking the main authentication process, thus balancing security and performance.

[0043] S43: After obtaining the real-time risk score and risk label, the gateway injects these scores and labels into the generated four-tuple's Context, making them part of the ABAC rule evaluation. For example, an ABAC rule can be defined as: if context.risk_score < 70 then allow. This step achieves dynamic linkage between authentication decisions and the enterprise's security posture. Through dynamic risk control data injection, the authentication system gains the ability to quickly adapt to sudden security events. This upgrades authentication from static identity verification to a dual-dimensional judgment of identity and real-time risk, solving the problem of the disconnect between authentication decisions and real-time security posture.

[0044] S5: Executes a hybrid authentication engine: RBAC / ABAC / ReBAC combined judgment; Based on the loaded authentication strategy, the models participating in the authentication are obtained, and the corresponding authentication modules are started for parallel or serial evaluation.

[0045] include: S51: Authentication module execution; (a) RBAC module execution: Query the set of roles for the user (Subject), and then query which operation (Action) permissions these roles are granted to the target resource (Resource). Use a cache such as Redis to store the role-permission mapping relationship, implement O(1) query, and return whether permission is allowed. For example, determine whether user u789 has the project_admin role and whether the role allows the write:project operation.

[0046] (b) ABAC Module Execution: The module substitutes attributes from Subject, Resource, Action, and Context (e.g., user.department=finance, resource.owner=u101, context.time=14:30, context.ip=192.168.1.100) into predefined ABAC policy rules (e.g., if user.role == 'manager' and resource.org_id == user.org_id and context.time in business_hours thenallow). A lightweight rule engine (e.g., Casbin's ABAC model) performs efficient evaluation and returns whether permission is granted.

[0047] (c) ReBAC Module Execution: Treating users (Subject) and resources (Resource) as graph nodes, the module searches the permission relationship graph for the existence of an access path that meets certain conditions and returns whether permission is granted. For example, it verifies whether the path "User A → Department Manager → Department X → Owner of Project P" exists. It uses a graph database (such as Neo4j) to store relationships and creates indexes to accelerate path lookups. Wildcards and recursive queries (such as "parent's parent") are supported.

[0048] S52: Summarize the judgment results based on the combination logic between the models defined by the authentication strategy; AND mode: All enabled models return "allow" if approved, otherwise "reject". Suitable for high-security scenarios such as financial approval.

[0049] OR mode: If any model returns "allow", it is considered "allowed"; otherwise, it is considered "rejected". Suitable for high-availability scenarios such as knowledge sharing.

[0050] PRIORITY mode: Executes in a short-circuit manner according to a preset priority (e.g., RBAC > ReBAC > ABAC). Subsequent checks stop once a model returns a definite result. A definite result includes allow or deny, and the system outputs an "allow" or "deny" decision based on the returned result. Suitable for low-latency scenarios.

[0051] S6: Request denial or clearance; When the final decision is "allow," the request is forwarded to the downstream microservice; when it is "deny," the gateway directly returns a 403 Forbidden response. This blocks unauthorized access and protects backend resource security. It transforms the initial protocol identification, element extraction, policy loading, and multi-model judgment into a clear access control result, forming a complete closed loop of permission control from request to response.

[0052] The present invention has been described in the above-described embodiments; however, these embodiments are merely examples for implementing the present invention. It must be noted that the disclosed embodiments do not limit the scope of the present invention. Conversely, any modifications and refinements made without departing from the spirit and scope of the present invention are within the scope of patent protection of the present invention.

Claims

1. A hybrid authentication method based on gateway request, characterized in that: Including the following step: S1: Accept client requests and identify the protocol type used in the request; Protocol types include: GraphQL protocol and REST API protocol; S2: Structured parsing and extraction of common access elements; Parse and extract common access elements from REST API and GraphQL requests, and normalize requests from different protocols into a standard format; common access elements include Subject, Action, Resource, and Context; S21: Protocol parsing; S211: REST API request parsing and extraction; 1) Extract Resources; Extract the request path and query parameters. For the path, break it down and combine it into a Resource. Use segment matching to parse the request path in the request line, split it into a list of path segments by / , filter the prefix segments, retain the resource type segment and resource ID segment, and combine them into a new path to form a Resource. 2) Extract the Action; Read the HTTP method in the request line and extract the HTTP method; HTTP methods include GET, POST, PUT, and DELETE; S212: GraphQL request parsing and extraction; GraphQL requests use a GraphQL parser to parse the query or mutation in the request body into an AST syntax tree, extracting the Action and Resource; First, construct the AST syntax tree; Read the query or mutation field values ​​from the request body, convert them into an AST syntax tree using the parse method of the GraphQL parser, and verify the validity of the AST; the AST syntax tree structure contains OperationDefinition, Field, and Argument nodes; Then, extract the Action; Iterate through the OperationDefinition nodes and extract the operation attribute value; the operation attribute value includes query or mutation, where query directly maps to the Action corresponding to read. Finally, extract the Resource; Traverse the Field nodes in the AST syntax tree, and combine all requested top-level objects and their operations into resources; if querying nested objects, start from the Field node of the AST, traverse all nested fields, record the hierarchical relationship between the top-level field and the associated sub-fields, and combine each field with the corresponding Action into an independent authentication unit in the format [Action]:[resource type]. S22: Extraction of common elements Subject and Context; Extract the Subject from the request header and construct the Context from the request context; the Subject is the user ID or service account; the request context includes the client IP, timestamp, and device information; S23: Generate a unified quadruple; The extracted elements are assembled into quadruplets according to a fixed format: Subject, Action, Resource, Context. S3: Query and load the authentication policy; Based on the parsed Resource path or operation name, query the pre-configured route-policy mapping table to obtain the authentication policy bound to the resource; S4: Dynamic data injection and real-time risk control linkage; Obtain the models participating in the authentication strategy, determine whether the ABAC model exists, if not, execute S5; if it exists, decide whether to inject external real-time data according to the authentication strategy, if yes, inject external real-time data and then execute S5, otherwise execute S5 directly. S5: Executes a hybrid authentication engine: RBAC / ABAC / ReBAC combined judgment; Based on the loaded authentication strategy, obtain the models participating in authentication, and start the corresponding authentication module for parallel or serial evaluation. S51: Authentication module execution; (a) RBAC module execution: Query the set of roles for user Subject, then query which Action permissions these roles have been granted to the target resource, store the role-permission mapping relationship in Redis cache, and return whether permission is allowed; (b) ABAC module execution: Substitute the attributes in Subject, Resource, Action, and Context into the predefined ABAC policy rules: ABAC attribute condition expressions, use a lightweight rule engine to perform efficient evaluation, and return whether it is allowed; (c) ReBAC module execution: Treats users (Subject) and resources (Resource) as graph nodes, searches the permission relationship graph for an access path that meets the conditions, and returns whether permission is granted; stores the relationships using a graph database and creates indexes, including Neo4j; S52: Summarize the judgment results based on the combination logic between the models defined by the authentication strategy; AND mode: All enabled models return "allow" and are judged as "allowed"; otherwise, they are judged as "rejected". OR mode: If any model returns "allow", it is judged as "allow"; otherwise, it is judged as "reject". PRIORITY mode: Short-circuit execution according to preset priority. Once a model returns a clear result, subsequent checks will stop. The output will be "allow" or "reject" based on the returned result. S6: Request denial or clearance; When the final decision is "allow", the request is forwarded to the downstream microservice; when it is "deny", the gateway directly returns a 403 Forbidden response.

2. The hybrid authentication method based on gateway requests as described in claim 1, characterized in that: Step S1 includes: S11: In response to a client request, the gateway accepts the complete request data packet sent by the client; the request data packet includes a request line, request headers, and a request body. S12: Trigger protocol category identification and determination; S121: GraphQL protocol determination; If the Content-Type in the request header is application / json and the request body contains a query or mutation field, then it is determined to be a GraphQL request. S122: REST API protocol determination; If the received request data packet conforms to the standard REST style, it is determined to be a REST API request; S123: Exception handling; If the request does not meet the GraphQL protocol's judgment conditions or the REST API standard style, it is judged as an illegal request, and the gateway directly returns a 400 Bad Request response.

3. The hybrid authentication method based on gateway requests as described in claim 2, characterized in that: Step S3 includes: S31: Configured route-policy mapping table; The route-policy mapping table includes route ID, resource matching key, and authentication policy ID; The route ID is a unique identifier for the route; the resource matching key includes the resource path or operation name; the authentication policy ID is the index number of the policy and is a unique identifier for the authentication policy. Standardized definition of authentication strategy; The authentication strategy defines: The models involved in authentication include RBAC, ABAC, and ReBAC; Combinatorial logic between models, including AND, OR, and PRIORITY; The specific rules for each model include the role list for RBAC, the attribute condition expressions for ABAC, and the relational path template for ReBAC; S32: Read the Resource field from the quadruple; if it is a REST API request, get the path; if it is a GraphQL request, get the operation name. S33: Based on the obtained path or operation name, query the route-policy mapping table to obtain the authentication policy ID; the authentication policy ID is associated with the authentication policy, and the content of the complete authentication policy is obtained.

4. The hybrid authentication method based on gateway requests as described in claim 3, characterized in that: The authentication policy is stored in a distributed configuration center or database.

5. The hybrid authentication method based on gateway requests as described in claim 3, characterized in that: Step S4 specifically includes: S41: Obtain the attribute condition expression of ABAC in the authentication strategy, check whether risk data is required. If yes, trigger the injection request; otherwise, do nothing and continue to execute S5. S42: In response to the injection request, the gateway initiates an asynchronous or synchronous call to the risk control center via gRPC or message queue, sending a request to the risk control center containing Subject, client IP, and timestamp. The risk control center returns a real-time risk score and risk label. S43: After obtaining the real-time risk score and risk label, the gateway injects the real-time risk score and risk label into the generated quadruple Context.

Images