API (Application Program Interface) authorization and identity verification method, device, equipment and medium

Abstract

The invention relates to the technical field of identity authentication, can be applied to business system platforms of financial science and technology, medical health and the like, and discloses an API authorization and identity authentication method, device, equipment and medium, comprising the following steps: generating API interfaces of different business modules according to preset business requirements to obtain an API interface set, constructing a fine-grained permission model according to the service demand, when an interface access request of a user is received, obtaining identity information of the user, selecting an identity verification standard according to the identity information to perform identity verification on the user to obtain an identity verification result, generating an access token according to the identity verification result, and sending the access token to the user. And generating an access permission list according to the access token by using the fine-grained permission model, applying for interface authorization of API interfaces of different service modules in the API interface set according to the access permission list to obtain an interface authorization result, and accessing the authorized API interface according to the interface authorization result, thereby improving the security of API authorization and identity verification.

Description

Technical Field

[0001] This invention relates to the field of identity authentication technology, and in particular to an API authorization and authentication method, apparatus, device, and medium. Background Technology

[0002] In the healthcare field, the widespread adoption of electronic medical records, telemedicine, and medical IoT devices has led to a surge in demand for data exchange between different systems and applications. However, existing medical information systems' API access controls are mostly based on static, coarse-grained role-based access control models, which are ill-suited to complex clinical scenarios. For example, an emergency room doctor may need to temporarily access a specific patient's entire medical history during a resuscitation effort, exceeding normal permissions. Existing systems often cannot achieve this dynamic, fine-grained escalation of permissions while ensuring compliance. Furthermore, patient privacy data is extremely sensitive, and traditional authentication and authorization processes are at risk of being bypassed or abused, potentially leading to large-scale data breaches and failing to strike a good balance between ensuring data security and achieving diagnostic and treatment efficiency.

[0003] In the fintech field, particularly in scenarios like open banking and cross-border payments, third-party applications need to securely interact with core banking systems via APIs. While the industry widely adopts standard protocols such as OAuth 2.0, its authorization model proves inadequate when faced with complex financial business rules. For example, in a high-value cross-border transfer, authorization verification needs to integrate multiple attributes in real time, including user identity, transaction amount, recipient risk level, and anti-money laundering strategies. Traditional solutions struggle to achieve such granular and dynamic access control. Furthermore, financial businesses have extremely high security requirements for identity verification; static passwords or single-factor authentication are no longer effective against attacks such as credential theft, posing a significant risk of financial fraud. Existing technical architectures struggle to balance security, user experience, and compliance, hindering the pace of financial innovation. Summary of the Invention

[0004] This invention provides an API authorization and authentication method, apparatus, computer device, and medium to solve the problem of low security of existing API authentication and authentication methods on the market.

[0005] Firstly, it provides an API authorization and authentication method, including: Based on pre-defined business requirements, API interfaces for different business modules are generated, resulting in an API interface set. Build a fine-grained permission model based on the aforementioned business requirements; When a user's API access request is received, the user's identity information is obtained; Based on the identity information, an identity verification standard is selected to verify the user's identity, and an identity verification result is obtained. An access token is generated based on the authentication result, and an access permission list is generated based on the access token using the fine-grained permission model. Based on the access permission list, request API authorization for different business modules in the API interface set, and obtain the interface authorization result; Access the authorized API interface based on the interface authorization result.

[0006] Secondly, an API authorization and authentication device is provided, including: The interface generation module is used to generate API interfaces for different business modules based on pre-defined business requirements, thus obtaining a set of API interfaces. The model building module is used to build a fine-grained permission model based on the business requirements. The authentication module, upon receiving a user's interface access request, obtains the user's identity information, selects an authentication standard based on the identity information to authenticate the user, and obtains the authentication result. The list generation module is used to generate an access token based on the authentication result, and to generate an access permission list based on the access token using the fine-grained permission model; The interface authorization module is used to apply for interface authorization of API interfaces of different business modules in the API interface set according to the access permission list, obtain the interface authorization result, and access the authorized API interface according to the interface authorization result.

[0007] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described API authorization and authentication methods.

[0008] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the above-described API authorization and authentication methods.

[0009] In the aforementioned API authorization and authentication methods, devices, computer equipment, and storage media, the API interface set can first be generated based on preset business requirements. In the medical field, with patient safety and privacy protection as the core, the focus is on clinical scenarios such as electronic medical record access and remote diagnosis, defining the minimum data access permissions for roles such as doctors and complying with HIPAA regulations. In the fintech field, focusing on fund security and compliance, the operational permissions of roles such as individual customers and risk control specialists for payment settlement, loan approval, etc., are clarified, and regulatory rules are embedded. When generating APIs, functional modules need to be broken down, target data in the database identified, and permission structures mapped using a business data model, then the interface set is generated in combination with a preset API format. Next, a fine-grained permission model is constructed. By analyzing permission requirements, identifying participating entities, operational behaviors, and protected resources, a permission requirement matrix is ​​built, a core access control model (such as RBAC or ABAC) is selected, and the architecture design is completed. When a user interface access request is received, their identity information is first obtained, and account and password verification is performed (distinguishing between administrators and ordinary users). Then, an access token containing a token payload and signature is generated. The token is verified using the fine-grained model, the declaration is parsed, and attributes are extracted to generate an access permission list. Subsequently, the authorization context is identified based on the list, an authorization request is generated, and the authorization result is obtained by matching the preset authorization policy. Finally, the authorized API interface is accessed based on the result to ensure secure sharing of business data and compliant operation. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a schematic diagram of an application environment for an API authorization and authentication method according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating an API authorization and authentication method in one embodiment of the present invention; Figure 3 This is a schematic diagram of an API authorization and authentication device in one embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 5 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0012] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0013] The API authorization and authentication method provided in this embodiment of the invention can be applied to, for example... Figure 1 In this application environment, the client communicates with the server via a network. The server can first generate an API interface set based on preset business requirements from the client. In the medical field, with patient life safety and privacy protection as the core, it focuses on clinical scenarios such as electronic medical record access and remote diagnosis and treatment, defining the minimum data access permissions for roles such as doctors and complying with HIPAA regulations. In the fintech field, with fund security and compliance as the focus, it clarifies the operational permissions of roles such as individual customers and risk control specialists for payment settlement, loan approval, and other businesses, embedding regulatory rules. When generating APIs, it is necessary to decompose functional modules, identify target data in the database, map the permission structure using the business data model, and then generate an interface set in combination with the preset API format. Next, a fine-grained permission model is built. By analyzing permission requirements, identifying participating entities, operational behaviors, and protected resources, a permission requirement matrix is ​​constructed, a core access control model (such as RBAC or ABAC) is selected, and the architecture design is completed. When a user interface access request is received, the identity information is first obtained, and account and password verification is performed (distinguishing between administrators and ordinary users). Then, an access token containing a token payload and signature is generated. The token is verified, the declaration is parsed, and attributes are extracted using the fine-grained model to generate an access permission list. Subsequently, the authorization context is identified based on the list, an authorization request is generated, and the authorization result is obtained by matching the preset authorization policy. Finally, the authorized API interface is accessed based on the result to ensure secure sharing of business data and compliant operation.

[0014] Please see Figure 2 As shown, Figure 2 A flowchart illustrating the API authorization and authentication method provided in this embodiment of the invention includes the following steps: S1. Generate API interfaces for different business modules based on pre-defined business requirements to obtain an API interface set.

[0015] In the healthcare field, the aforementioned business requirements are centered on patient safety and privacy protection, focusing on clinical scenarios such as access to electronic medical records, remote diagnosis and treatment, and prescription issuance. It is necessary to accurately define the minimum data access permissions for roles such as doctors, nurses, and pharmacists based on the purpose of diagnosis and treatment (such as only being able to view medical history and test results related to the consultation), dynamically link permissions to the context of diagnosis and treatment (such as exceeding normal permissions in emergency situations), and strictly comply with the requirements of HIPAA and other regulations regarding patient informed consent, data anonymization, and access auditing, ultimately promoting the reasonable sharing and collaboration of medical information while protecting patient privacy.

[0016] In the fintech field, the core of these business requirements revolves around the security, compliance, and risk control of fund flows. Specifically, this manifests in the implementation requirements for core business functions such as payment settlement, loan approval, and investment management. This requires strictly defining the access and operation permissions (such as querying, transferring, and approving) of different user roles (e.g., individual customers, account managers, and risk control specialists) for specific accounts, transaction records, and sensitive financial data. It also requires embedding amount thresholds, time ranges, and regulatory compliance rules such as anti-money laundering and Know Your Customer to ensure that every operation is auditable and controllable, ultimately satisfying the user experience while ensuring fund security.

[0017] In this embodiment of the invention, the step of generating API interfaces for different business modules according to pre-defined business requirements to obtain an API interface set includes: Identify the core functional modules in the business requirements and obtain a list of functional module divisions; Based on the functional modules, the target data in the database is identified and a data list is obtained. Using a preset business data model, a permission structure is mapped based on the data list to obtain a data permission mapping table; API interface code is generated based on the data permission mapping table and the preset API data format to obtain an API interface set.

[0018] In detail, identifying the core functional modules in the business requirements and obtaining a functional module breakdown list involves breaking down complex macro-level business requirements into several highly cohesive and loosely coupled core functional modules (e.g., user management module, payment transaction module, loan approval module, etc.). The output, the "functional module breakdown list," is a structured document that clearly defines the components of the system, the responsibilities and boundaries of each module, and the interaction relationships between modules, providing a clear architectural blueprint for subsequent database design and API development.

[0019] In detail, the process of identifying target data in the database based on the functional module division list to obtain the data list involves reverse analysis based on the operations (such as add, delete, modify, and query) required by each functional module to determine which database tables, views, or fields need to be accessed. For example, the "user management module" would correspond to the user information table, user permission table, etc. The output "data list" is a detailed data asset catalog that clearly lists all data entities involved in each business module, their attributes, and the relationships between data entities.

[0020] In detail, the process of mapping the data list to a permission structure using a preset business data model to obtain a data permission mapping table involves associating each data entity and attribute in the data list with the permission rules defined in the business data model, thereby assigning a permission label to each piece of data or each type of operation. The output, the "data permission mapping table," is a crucial configuration matrix that precisely defines the rules of "what kind of user (such as a regular user or an administrator) can perform what operation on what data under what conditions."

[0021] In detail, the step of generating API interface code based on the data permission mapping table and the preset API data format to obtain the API interface set can be accomplished using code generation tools or platforms (such as those based on the Swagger / OpenAPI specification or a custom template engine). The generator reads the data permission mapping table and automatically generates the corresponding API endpoint code framework for each functional module.

[0022] S2. Construct a fine-grained permission model based on the business requirements.

[0023] In this embodiment of the invention, constructing a fine-grained permission model based on the business requirements includes: Perform a business permission requirement analysis on the aforementioned business requirements to obtain the permission analysis results; Identify the participating entities and operational behaviors of each business module based on the aforementioned business requirements; Identify protected resources in the database based on the stated business requirements; Construct a permission requirement matrix based on the protected resources, the permission analysis results, the participating entities, and the operational behaviors; Select the core access control model based on the preset access control policy; Based on the permission requirement matrix, the core access control model is designed with a permission model architecture to obtain a fine-grained permission model.

[0024] In detail, the business permission requirement analysis, which yields the permission analysis results, involves deconstructing the business scenario and focusing on analyzing "which operations need to be controlled" and "where the boundaries of control lie." This includes identifying sensitive operations (such as fund transfers and querying user privacy information), compliance requirements (such as adhering to the financial industry's "Know Your Customer" (KYC) principle and data minimization principle), and potential risk points.

[0025] In detail, identifying the participating entities and operational behaviors of each business module based on the business requirements means identifying all participating entities interacting with the system. This includes not only users but also other systems, third-party applications, automated services, etc., and clearly defining their types and classifications (e.g., ordinary users, risk control administrators, partner merchant APIs). Secondly, for each business module, all possible operational behaviors are enumerated in detail, such as "creating an account," "changing a mobile phone number," "querying transaction history," and "approving loan applications."

[0026] In detail, identifying protected resources in the database based on the business requirements involves filtering out all entities containing sensitive or critical business data and identifying them as protected resources.

[0027] In detail, the construction of the permission requirement matrix based on the protected resources, the permission analysis results, the participating entities, and the operational behaviors involves associating entities, operations, and resources, and defining access rules and conditions at the intersections. For example, the matrix may specify that "the risk control administrator (entity) can query (operate on) all loan contracts (resources)" and "ordinary users (entity) can only modify (operate on) their own basic information (resources)".

[0028] In detail, the selection of the core access control model based on the preset access control policy involves evaluating and selecting the most suitable core access control model based on the control complexity reflected in the matrix. For example, if the rules are relatively static and based on user roles, RBAC (Role-Based Access Control) might be selected; if the rules are extremely dynamic and require judgment based on a large number of conditions such as user attributes, resource attributes, and environment (such as time and location), then ABAC (Attribute-Based Access Control) would be selected.

[0029] In detail, the design of the permission model architecture based on the permission requirement matrix to obtain a fine-grained permission model is a key step in transforming control requirements described in business language into RBAC technology elements and achieving fine-grained control. Its core work involves abstracting stable roles from the matrix as carriers for permission allocation, rather than directly assigning permissions to users. First, the "Subject" column in the matrix is ​​analyzed to categorize users with the same operation and resource access requirements, defining business roles (such as "Loan Reviewer" and "Regular Customer"). Next, the combination of "Operation" and "Protected Resource" in the matrix is ​​defined as specific permissions (e.g., "Permission: Query all loan contracts"). Then, a role-permission allocation relationship is established, and permissions are batch-assigned to the corresponding roles. To achieve fine-grained control at the field and row levels, permission definitions are bound to specific resource attributes or data identifiers (e.g., "Permission: Modify [Current User's] [Basic Information]"), and the decision is ultimately made by dynamically injecting user-specific context (such as user ID) at runtime through the session. Therefore, the output fine-grained permission model is an implementable technical architecture that includes role hierarchy, permission set, role-permission mapping relationship and constraint rules, ensuring the flexibility, maintainability and security of permission management.

[0030] S3. When a user's interface access request is received, obtain the user's identity information.

[0031] In this embodiment of the invention, the identity information may refer to the account and password entered by the user.

[0032] In the healthcare field, the aforementioned interface access request may be an action by a doctor attempting to retrieve patient information during clinical diagnosis and treatment. The data content typically includes metadata such as the doctor's identity token, patient ID, the specific range of medical data requested (such as laboratory test results, imaging reports, or the entire medical record), and the purpose of access. For example, for a request to "GET / api / patients / {id} / medical-history", the system must dynamically determine whether the doctor has the right to access this sensitive health information of the patient in the current diagnosis and treatment context, and ensure that it complies with the "minimum necessary" principle and patient privacy protection regulations.

[0033] In the fintech field, such API access requests may be sensitive attempts to perform financial transactions. Their data content typically includes key fields such as encrypted access tokens, target account numbers, transaction amounts, recipient information, and transaction types. For example, the JSON data carried in the request body of a request to "POST / api / v1 / transfers" requires the system to verify in real time whether the user has the right to transfer the corresponding amount of funds from the specified account to a specific recipient, while simultaneously satisfying anti-money laundering rules and risk control strategies such as single transaction limits.

[0034] S4. Select an identity verification standard based on the identity information to verify the user's identity and obtain the identity verification result.

[0035] In this embodiment of the invention, the step of selecting an authentication standard based on the identity information to authenticate the user and obtain an authentication result includes: Obtain the account information and password information from the identity information; The user is logged in based on the account information and the password information, and a login verification result is obtained. When it is determined that the user has passed the login verification based on the login verification result, it is determined whether the user is an administrator based on the identity information; If the user is an administrator, the authentication result is determined to be administrator login; If the user is not an administrator, the authentication result is determined to be a regular user login.

[0036] S5. Generate an access token based on the authentication result, and generate an access permission list based on the access token using the fine-grained permission model.

[0037] In this embodiment of the invention, generating an access token based on the authentication result includes: Determine the token generation criteria based on the authentication results; Generate the token payload according to the token generation standard; A signature is generated based on the token payload and the preset token header; The token header, the token payload, and the signature are concatenated to obtain the access token.

[0038] In detail, determining the token generation standard based on the authentication result involves establishing a set of clear and secure rules and parameters for token creation. The authorization server needs to dynamically determine the key specifications of the generated token based on this information and security policies. This includes: selecting the token type (e.g., JWT); determining the cryptographic signature algorithm (e.g., Chinese national cryptographic standard SM2, RS256, etc., to ensure the token is tamper-proof); setting the token's validity period (e.g., 3600 seconds); defining the token's audience (Aud, i.e., which API services the token is allowed to access); and defining the token's permission scope.

[0039] In detail, a token payload is generated according to the aforementioned token generation standard, constructing a JSON object (i.e., the payload). This object contains a series of claims, including standard claims such as issuer (iss), subject (sub, i.e., user identifier), expiration time (exp), audience (aud), etc., all directly mapped from the generation standard; and custom claims such as user role, authorization scope, and other necessary business attributes, which come from the authentication results. The output, the "token payload," is a structured data collection containing all identity, authorization, and metadata information.

[0040] In detail, the process involves generating a signature based on the token payload and a preset token header, and encoding the token header and token payload using Base64Url. Then, the two encoded strings are connected with a period (.) to form a message to be signed. Finally, the message is digitally signed using a private key securely stored by the authorization server, according to an algorithm (such as SM2) pre-declared in the token header.

[0041] In this embodiment of the invention, generating an access permission list based on the access token using the fine-grained permission model includes: The access token is signed and verified using a preset public key; When the access token passes the signature verification, the access token is subjected to standard claim verification and payload parsing to obtain the parsed token claim set; Extract the permission query attribute set from the parsed token statement set; The fine-grained permission model is used to perform enumeration permission queries based on the permission query attribute set to obtain the original permission set; Generate an access permission list based on the original permission set.

[0042] In detail, the signature verification of the access token using a preset public key involves verifying the signature portion of the token using a preset cryptographic algorithm. The system recalculates the signature digest of the token header and payload and compares it with the original signature decrypted using the public key. If they match, it proves that the token was indeed issued by a trusted authorization server and has not been modified during transmission.

[0043] In detail, when the access token passes the signature verification, standard claim verification and payload parsing are performed on the access token to obtain a parsed token claim set. This is done by checking whether the standard fields in the token payload meet expectations, such as confirming whether the token is valid, whether the token's audience matches this service, and whether the issuer is trustworthy, thereby rejecting expired or invalid tokens. After successful verification, the payload portion of the token is parsed, converting it from a Base64Url-encoded string into a structured JSON object.

[0044] In detail, extracting the permission query attribute set from the parsed token declaration set involves extracting specific key-value pairs from the declaration set according to predefined rules. These attributes are the "input parameters" for initiating queries to the fine-grained permission model, typically including the user's unique identifier (sub), their list of roles, their group affiliation, department ID, etc. This results in a structured permission query attribute set that encapsulates the user's identity characteristics and serves as the request parameters for initiating a query to the permission engine asking "What permissions does the user possess?"

[0045] In detail, the step of using the fine-grained permission model to enumerate permission queries based on the permission query attribute set to obtain the original permission set involves matching, deducing, and calculating based on the input permission query attribute set, ultimately enumerating all operations that the user is allowed to perform and all resources that they are allowed to access.

[0046] In detail, generating the access permission list based on the original permission set involves standardizing and formatting the permissions (e.g., unifying them into a resource:operation:instance string format or a specific JSON object structure), grouping and categorizing them by business modules, or mapping and converting them according to API interfaces. The output is the final access permission list.

[0047] S6. Apply for API authorization for different business modules in the API interface set according to the access permission list, and obtain the interface authorization result.

[0048] In this embodiment of the invention, the step of requesting API authorization for different business modules in the API interface set according to the access permission list, and obtaining the interface authorization result, includes: Identify the authorization context object based on the access permission list and the interface access request; An authorization request is generated and invoked based on the authorization context object and the access permission list; Based on the authorization request, the authorization context object is matched and calculated with the preset authorization policy to obtain an authorization decision response; The authorization result is determined based on the authorization decision response identification interface.

[0049] In detail, identifying the authorization context object based on the access permission list and the interface access request involves extracting key elements from the interface access request based on the access permission list. These elements include the subject (i.e., who is making the request, obtained from the token as the user identifier), the operation (i.e., what to do, typically mapped from HTTP methods such as GET / POST), and the resource (i.e., what operation is performed, parsed from the request URL and parameters as the specific resource identifier). Environmental context (such as request time and client IP) is also collected. A standardized authorization context object encapsulating all the information needed for authorization decisions is output.

[0050] In detail, the step of generating an authorization request based on the authorization context object and the access permission list is to assemble the input data into a structured authorization request according to a predefined communication protocol (such as the API format of Open Policy Agent).

[0051] In detail, the step of matching the authorization context object with a preset authorization policy based on the authorization request to obtain an authorization decision response involves substituting the context object (subject, operation, resource, environment) in the request as input parameters into the policy rules for calculation, matching, and deduction. This is an automated reasoning process that ultimately produces a clear, either-or binary conclusion. The output is an authorization decision response that contains no ambiguity and clearly indicates whether the request should be approved or rejected.

[0052] S7. Access the authorized API interface based on the interface authorization result.

[0053] In this embodiment of the invention, accessing the authorized API interface according to the interface authorization result means that when the policy execution point receives the "allow" authorization decision from the policy decision point, it releases the interception of the API request and forwards it completely to the backend business processing service. The service then performs the specific business operation corresponding to the request (such as querying account balance, creating transfer order, or retrieving patient medical records) and returns the normal result data generated after the business processing is completed to the client, thereby completing a secure and controlled data access process.

[0054] As can be seen, in the above solution, an API interface set is first generated based on preset business requirements. In the medical field, patient life safety and privacy protection are the core focus, concentrating on clinical scenarios such as electronic medical record access and remote diagnosis and treatment, defining the minimum data access permissions for roles such as doctors and complying with HIPAA regulations. In the fintech field, fund security and compliance are the focus, clarifying the operational permissions of roles such as individual customers and risk control specialists for payment settlement, loan approval and other businesses, and embedding regulatory rules. When generating APIs, functional modules need to be broken down, target data in the database needs to be identified, permission structures need to be mapped using business data models, and then an interface set needs to be generated in combination with preset API formats. Next, a fine-grained permission model is constructed. By analyzing permission requirements, identifying participating entities, operational behaviors and protected resources, a permission requirement matrix is ​​constructed, a core access control model (such as RBAC or ABAC) is selected and the architecture design is completed. When a user interface access request is received, the user's identity information is first obtained, and account and password verification is performed (distinguishing between administrators and ordinary users). Then, an access token containing a token payload and signature is generated. The token is verified, the declaration is parsed, and attributes are extracted in combination with the fine-grained model to generate an access permission list. Subsequently, the authorization context is identified based on the list, an authorization request is generated, and the authorization result is obtained by matching the preset authorization policy. Finally, the authorized API interface is accessed based on the result to ensure secure sharing of business data and compliant operation.

[0055] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0056] In one embodiment, an API authorization and authentication device is provided, which corresponds one-to-one with the API authorization and authentication methods described in the above embodiments. For example... Figure 3 As shown, the API authorization and authentication device includes an interface generation module 101, a model building module 102, an authentication module 103, a list generation module 104, and an interface authorization module 105. Detailed descriptions of each functional module are as follows: The interface generation module 101 is used to generate API interfaces for different business modules according to pre-defined business requirements, thereby obtaining an API interface set. Model building module 102 is used to build a fine-grained permission model based on the business requirements; When the authentication module 103 receives a user's interface access request, it obtains the user's identity information, selects an authentication standard based on the identity information to authenticate the user, and obtains the authentication result. The list generation module 104 is used to generate an access token based on the authentication result, and to generate an access permission list based on the access token using the fine-grained permission model. The interface authorization module 105 is used to apply for interface authorization of API interfaces of different business modules in the API interface set according to the access permission list, obtain the interface authorization result, and access the authorized API interface according to the interface authorization result.

[0057] In one embodiment, when the interface generation module 101 generates API interfaces for different business modules according to pre-defined business requirements to obtain an API interface set, it is specifically used for: Identify the core functional modules in the business requirements and obtain a list of functional module divisions; Based on the functional modules, the target data in the database is identified and a data list is obtained. Using a preset business data model, a permission structure is mapped based on the data list to obtain a data permission mapping table; API interface code is generated based on the data permission mapping table and the preset API data format to obtain an API interface set.

[0058] In one embodiment, the model building module 102, when executing the step of building a fine-grained permission model based on the business requirements, is specifically used for: Perform a business permission requirement analysis on the aforementioned business requirements to obtain the permission analysis results; Identify the participating entities and operational behaviors of each business module based on the aforementioned business requirements; Identify protected resources in the database based on the stated business requirements; Construct a permission requirement matrix based on the protected resources, the permission analysis results, the participating entities, and the operational behaviors; Select the core access control model based on the preset access control policy; Based on the permission requirement matrix, the core access control model is designed with a permission model architecture to obtain a fine-grained permission model.

[0059] In one embodiment, when the authentication module 103 performs the step of selecting an authentication standard based on the identity information to authenticate the user and obtain an authentication result, it is specifically used for: Obtain the account information and password information from the identity information; The user is logged in based on the account information and the password information, and a login verification result is obtained. When it is determined that the user has passed the login verification based on the login verification result, it is determined whether the user is an administrator based on the identity information; If the user is an administrator, the authentication result is determined to be administrator login; If the user is not an administrator, the authentication result is determined to be a regular user login.

[0060] In one embodiment, the list generation module 104, when performing the step of generating an access token based on the authentication result, is specifically used for: Determine the token generation criteria based on the authentication results; Generate the token payload according to the token generation standard; A signature is generated based on the token payload and the preset token header; The token header, the token payload, and the signature are concatenated to obtain the access token.

[0061] In one embodiment, the list generation module 104, when performing the step of generating an access permission list based on the access token using the fine-grained permission model, is specifically used for: The access token is signed and verified using a preset public key; When the access token passes the signature verification, the access token is subjected to standard claim verification and payload parsing to obtain the parsed token claim set; Extract the permission query attribute set from the parsed token statement set; The fine-grained permission model is used to perform enumeration permission queries based on the permission query attribute set to obtain the original permission set; Generate an access permission list based on the original permission set.

[0062] In one embodiment, when the interface authorization module 05 executes the step of requesting interface authorization for API interfaces of different business modules in the API interface set according to the access permission list and obtaining the interface authorization result, it is specifically used for: Identify the authorization context object based on the access permission list and the interface access request; An authorization request is generated and invoked based on the authorization context object and the access permission list; Based on the authorization request, the authorization context object is matched and calculated with the preset authorization policy to obtain an authorization decision response; The authorization result is determined based on the authorization decision response identification interface.

[0063] This invention provides an API authorization and authentication device. First, it generates an API interface set based on preset business requirements. In the medical field, focusing on patient safety and privacy protection, it addresses clinical scenarios such as electronic medical record access and remote diagnosis, defining minimum data access permissions for roles like doctors and complying with HIPAA regulations. In the fintech field, focusing on fund security and compliance, it clarifies the operational permissions of individual customers and risk control specialists for payment settlement, loan approval, and other businesses, embedding regulatory rules. When generating APIs, it is necessary to decompose functional modules, identify target data in the database, map the permission structure using a business data model, and then generate an interface set based on a preset API format. Next, a fine-grained permission model is constructed. By analyzing permission requirements, identifying participating entities, operational behaviors, and protected resources, a permission requirement matrix is ​​built, a core access control model (such as RBAC or ABAC) is selected, and the architecture design is completed. When a user's interface access request is received, their identity information is first obtained, and account and password verification is performed (distinguishing between administrators and ordinary users). Then, an access token containing a token payload and signature is generated. The fine-grained model is used to verify the token, parse the declaration, and extract attributes to generate an access permission list. Subsequently, the authorization context is identified based on the list, an authorization request is generated, and the authorization result is obtained by matching the preset authorization policy. Finally, the authorized API interface is accessed based on the result to ensure secure sharing of business data and compliant operation.

[0064] Specific limitations regarding the API authorization and authentication mechanism can be found in the limitations on API authorization and authentication methods described above, and will not be repeated here. Each module in the aforementioned API authorization and authentication mechanism can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can invoke and execute the operations corresponding to each module.

[0065] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4 As shown. The computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When executed by the processor, the computer program implements server-side functions or steps for an API authorization and authentication method.

[0066] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements client-side functions or steps of an API authorization and authentication method.

[0067] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Based on pre-defined business requirements, API interfaces for different business modules are generated, resulting in an API interface set. Build a fine-grained permission model based on the aforementioned business requirements; When a user's API access request is received, the user's identity information is obtained; Based on the identity information, an identity verification standard is selected to verify the user's identity, and an identity verification result is obtained. An access token is generated based on the authentication result, and an access permission list is generated based on the access token using the fine-grained permission model. Based on the access permission list, request API authorization for different business modules in the API interface set, and obtain the interface authorization result; Access the authorized API interface based on the interface authorization result.

[0068] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: Based on pre-defined business requirements, API interfaces for different business modules are generated, resulting in an API interface set. Build a fine-grained permission model based on the aforementioned business requirements; When a user's API access request is received, the user's identity information is obtained; Based on the identity information, an identity verification standard is selected to verify the user's identity, and an identity verification result is obtained. An access token is generated based on the authentication result, and an access permission list is generated based on the access token using the fine-grained permission model. Based on the access permission list, request API authorization for different business modules in the API interface set, and obtain the interface authorization result; Access the authorized API interface based on the interface authorization result.

[0069] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0070] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0071] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0072] Finally, it should be noted that if any software tools or components not belonging to this company appear in the embodiments of the application, they are merely illustrative examples and do not represent actual use. The embodiments described above are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. An API authorization and authentication method, characterized by, The application comprises the following steps: According to the pre-set business requirements, API interfaces of different business modules are generated to obtain an API interface set; According to the business requirements, a fine-grained permission model is constructed; When receiving an interface access request of a user, the identity information of the user is obtained; According to the identity information, an identity authentication standard is selected to authenticate the user to obtain an identity authentication result; According to the identity authentication result, an access token is generated, and an access permission list is generated according to the access token by using the fine-grained permission model; According to the access permission list, an interface authorization of the API interfaces of different business modules in the API interface set is applied to obtain an interface authorization result; According to the interface authorization result, the authorized API interfaces are accessed.

2. The API authorization and authentication method of claim 1, wherein, The step of generating API interfaces of different business modules according to pre-set business requirements to obtain an API interface set comprises the following steps: The core function modules in the business requirements are identified to obtain a function module division list; According to the function module division list, target data in the database is identified to obtain a data list; According to the data list, a permission structure mapping is performed by using a pre-set business data model to obtain a data permission mapping table; According to the data permission mapping table and a pre-set API data format, API interface codes are generated to obtain an API interface set.

3. The API authorization and authentication method of claim 1, wherein, The step of constructing a fine-grained permission model according to the business requirements comprises the following steps: The business requirements are analyzed to obtain a permission analysis result; According to the business requirements, the participating subjects and operation behaviors of each business module are identified; According to the business requirements, protected resources in the database are identified; According to the protected resources, the permission analysis result, the participating subjects and the operation behaviors, a permission requirement matrix is constructed; According to a pre-set access control strategy, a core access control model is selected; Based on the permission requirement matrix, the core access control model is designed to obtain a fine-grained permission model.

4. The API authorization and authentication method of claim 1, wherein, The step of selecting an identity authentication standard according to the identity information to authenticate the user to obtain an identity authentication result comprises the following steps: The account information and password information in the identity information are obtained; According to the account information and the password information, the user is verified to obtain a login verification result; When it is determined that the user passes the login verification according to the login verification result, it is determined whether the user is an administrator according to the identity information; If the user is an administrator, it is determined that the identity authentication result is an administrator login; If the user is not an administrator, it is determined that the identity authentication result is a normal user login.

5. The API authorization and authentication method of claim 1, wherein, The step of generating an access token according to the identity authentication result comprises the following steps: According to the identity authentication result, a token generation standard is determined; According to the token generation standard, a token payload is generated; According to the token payload and a pre-set token header, a signature is generated; The token header, the token payload and the signature are spliced to obtain an access token.

6. The API authorization and authentication method of claim 1, wherein, The step of generating an access permission list according to the access token by using the fine-grained permission model comprises the following steps: The access token is verified by using a pre-set public key; When the access token passes the signature verification, the access token is subjected to standard claim verification and payload parsing to obtain the parsed token claim set; Extract the permission query attribute set from the parsed token statement set; The fine-grained permission model is used to perform enumeration permission queries based on the permission query attribute set to obtain the original permission set; Generate an access permission list based on the original permission set.

7. The API authorization and authentication method of claim 1, wherein, The step of requesting API authorization for different business modules in the API interface set according to the access permission list, and obtaining the interface authorization result, includes: Identify the authorization context object based on the access permission list and the interface access request; An authorization request is generated and invoked based on the authorization context object and the access permission list; Based on the authorization request, the authorization context object is matched and calculated with the preset authorization policy to obtain an authorization decision response; The authorization result is determined based on the authorization decision response identification interface.

8. An API authorization and authentication apparatus, characterized by, include: The interface generation module is used to generate API interfaces for different business modules based on pre-defined business requirements, thus obtaining a set of API interfaces. The model building module is used to build a fine-grained permission model based on the business requirements. The authentication module, upon receiving a user's interface access request, obtains the user's identity information, selects an authentication standard based on the identity information to authenticate the user, and obtains the authentication result. The list generation module is used to generate an access token based on the authentication result, and to generate an access permission list based on the access token using the fine-grained permission model; The interface authorization module is used to apply for interface authorization of API interfaces of different business modules in the API interface set according to the access permission list, obtain the interface authorization result, and access the authorized API interface according to the interface authorization result.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the API authorization and authentication method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, the computer program comprising instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 9. When the computer program is executed by a processor, it implements the steps of the API authorization and authentication method as described in any one of claims 1 to 7.

Images