A dynamic authentication method, device, storage medium, and electronic device

Abstract

This application discloses a dynamic authentication method, apparatus, storage medium, and electronic device, relating to the field of cloud computing technology. First, in response to a call request for a target network service, it acquires multi-dimensional authentication factors related to the call request. Then, based on the multi-dimensional authentication factors, it generates a dynamic authentication policy corresponding to the current call scenario. Next, according to the dynamic authentication policy, it performs authentication on the call request. After the call request passes authentication, a temporary access credential is generated, which is used to access the target network service. Compared with existing technologies, this application dynamically acquires multi-dimensional authentication factors during service calls, generates an authentication policy adapted to the current scenario, and performs authentication and issues temporary access credentials based on this policy. This enhances the system's ability to perceive and defend against abnormal behavior and potential attacks, while also meeting the dynamic, scenario-based, and heterogeneous authentication requirements under a 6G service-oriented architecture.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, specifically to a dynamic authentication method, apparatus, storage medium, and electronic device. Background Technology

[0002] As sixth-generation mobile communications systems (6G) evolve towards a fully service-oriented, intelligent, and distributed architecture, network functions are abstracted into flexibly invoked services, such as computing power services, connectivity services, and artificial intelligence (AI) services. Third-party applications (such as industrial internet platforms and metaverse applications) and diverse terminals (such as augmented reality devices (AR devices) and autonomous vehicles) need to dynamically access multi-domain heterogeneous networks (including terrestrial cellular networks, satellite links, and edge nodes) through open interfaces to achieve on-demand invocation and collaboration.

[0003] Currently, the primary authentication mechanism is a static authentication mechanism based on Authentication and Key Agreement (AKA), which relies on pre-defined user identities and fixed permission policies. During service invocation, authentication is typically completed as a separate step during the access phase, and subsequent service interactions do not involve dynamic verification.

[0004] However, static authentication strategies cannot adapt to the dynamic business needs such as cross-domain service combinations and edge intelligence in 6G service-oriented scenarios. In particular, in the face of heterogeneous terminal devices such as edge nodes and satellite terminals, static authentication strategies are prone to resource waste or security vulnerabilities. Summary of the Invention

[0005] In view of this, this application provides a dynamic authentication method, device, storage medium and electronic device, the main purpose of which is to improve the technical problem that static authentication strategies cannot adapt to the dynamic business needs such as cross-domain service combination and edge intelligence in 6G service-oriented scenarios, which can easily lead to resource waste or security vulnerabilities.

[0006] Firstly, this application provides a dynamic authentication method, including: In response to a request to invoke a target network service, obtain multi-dimensional authentication factors related to the request; Based on the aforementioned multi-dimensional authentication factors, a dynamic authentication strategy corresponding to the current calling scenario is generated. Based on the dynamic authentication strategy, the authentication operation is performed on the call request; After the call request is authenticated, a temporary access credential is generated, which is used to access the target network service.

[0007] Secondly, this application provides a dynamic authentication device, comprising: The acquisition module is configured to acquire multi-dimensional authentication factors related to the call request in response to a call request to the target network service; The first generation module is configured to generate a dynamic authentication strategy corresponding to the current calling scenario based on the multi-dimensional authentication factors. The execution module is configured to perform authentication operations on the call request according to the dynamic authentication strategy; The second generation module is configured to generate a temporary access credential after the call request is authenticated, the temporary access credential being used to access the target network service.

[0008] Thirdly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in the first aspect.

[0009] Fourthly, this application provides an electronic device including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor executes the computer program to implement the method described in the first aspect.

[0010] Fifthly, this application provides a computer program product having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the method of the first aspect.

[0011] By employing the above technical solutions, this application provides a dynamic authentication method, apparatus, storage medium, and electronic device. First, in response to a call request for a target network service, it acquires multi-dimensional authentication factors related to the call request. Then, based on these multi-dimensional authentication factors, it generates a dynamic authentication policy corresponding to the current call scenario. Next, according to the dynamic authentication policy, it performs authentication on the call request. After the call request passes authentication, a temporary access credential is generated, which is used to access the target network service. Compared with existing technologies, this application dynamically acquires multi-dimensional authentication factors during service calls, generates an authentication policy adapted to the current scenario, and performs authentication and issues temporary access credentials based on this policy. This enhances the system's ability to perceive and defend against abnormal behavior and potential attacks, while simultaneously meeting the dynamic, scenario-based, and heterogeneous authentication requirements under the 6G service-oriented architecture.

[0012] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are given below. Attached Figure Description

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

[0014] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0015] Figure 1 A flowchart illustrating a dynamic authentication method provided in an embodiment of this application is shown; Figure 2 A flowchart illustrating another dynamic authentication method provided in an embodiment of this application is shown; Figure 3 A schematic diagram illustrating an example provided in an embodiment of this application is shown; Figure 4 A schematic diagram illustrating an example provided in an embodiment of this application is shown; Figure 5 A schematic diagram of the structure of a dynamic authentication device provided in an embodiment of this application is shown. Detailed Implementation

[0016] The embodiments of this application will now be described in more detail with reference to the accompanying drawings. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0017] Since the introduction of service-oriented architecture into the 5G control plane, it has undergone three release iterations and has been implemented in the core network control plane and billing system. The advantages brought by service-oriented architecture are gradually becoming apparent. 5G networks have opened the door for the evolution of telecommunications networks towards service-oriented architecture. However, as the first generation of systems to introduce service-oriented architecture, 5G service-oriented design still suffers from incomplete decoupling of atomic services, and some emerging service-oriented technologies have not yet been introduced into 5G networks. Therefore, a fully service-oriented architecture needs to further eliminate the coupling between atomic services, incorporate more service-oriented technologies, and enhance aspects such as service framework, service interfaces, and atomic services to fully leverage the advantages of service-oriented technologies.

[0018] In the future 6G service-oriented architecture, network functions will be abstracted into services that can be flexibly invoked (such as computing power services, connectivity services, AI services, etc.). Third-party applications (such as industrial internet platforms and metaverse applications) need to invoke network services through open APIs, and terminal devices (such as AR glasses and autonomous vehicles) need to dynamically access multi-domain networks (ground, satellite, edge nodes).

[0019] To address the technical issue that static authentication strategies are incompatible with dynamic service requirements such as cross-domain service composition and edge intelligence in 6G service-oriented scenarios, which can easily lead to resource waste or security vulnerabilities, this embodiment provides a dynamic authentication method, such as... Figure 1 As shown, the method includes: Step 101: In response to the call request for the target network service, obtain the multi-dimensional authentication factors related to the call request.

[0020] In some examples, a scenario-based authentication factor library is used to collect and store multi-dimensional authentication factors to support dynamic, fine-grained security decisions.

[0021] For example, multi-dimensional authentication factors can cover identity factors, including terminal device ID, application digital certificate and other information used to identify the requesting subject; service factors, involving the type of service requested and its sensitivity level, such as "medical data transmission" being marked as a highly sensitive service, thus triggering stricter verification requirements; environmental factors, including contextual information such as network location and access method, such as access via "satellite link" being considered a high-risk environment, and correspondingly increasing the strength of security policies; and behavioral factors, recording dynamic usage patterns such as historical call frequency and data interaction volume, such as high-frequency call behavior during non-working hours being identified as suspicious activity.

[0022] Step 102: Generate a dynamic authentication strategy corresponding to the current calling scenario based on multi-dimensional authentication factors.

[0023] For example, the intelligent policy engine can dynamically generate authentication policies adapted to the current calling scenario by integrating rule-driven and data-driven mechanisms. The rule base provides basic policy logic predefined by security policies, such as mandating biometric verification for highly sensitive services (e.g., services involving personal health or financial data) to ensure that minimum security baselines are met.

[0024] Step 103: Perform authentication operations on the call request according to the dynamic authentication strategy.

[0025] In some examples, a personalized security policy can be generated based on the current call scenario and integrates multiple factors (such as identity, service sensitivity, network environment, and historical behavior) to verify the legitimacy of the requester's identity, scope of permissions, and risk status in real time.

[0026] For example, the authentication process may include verifying digital certificates, comparing device identifiers, confirming edge node endorsements, verifying biometrics or multi-factor authentication, and combining the service type and context to determine whether the access conditions are met, thereby deciding whether to authorize the service call.

[0027] Step 104: After the call request passes authentication, generate a temporary access credential.

[0028] Temporary access credentials are used to access the target network service.

[0029] For example, after a call request is authenticated, the system generates a temporary access credential. This credential has an expiration date, context binding, and scope of use restrictions, and is used to authorize the requester to access the requested target network service within a limited time. This temporary access credential serves as the legitimate credential for subsequent service calls, ensuring that only requesters who have undergone dynamic authentication and verification can obtain controlled access to the target service, thereby achieving fine-grained and revocable secure access control in an open service-oriented architecture.

[0030] Compared with existing technologies, the technical solution of this embodiment first responds to a call request for a target network service by acquiring multi-dimensional authentication factors related to the call request; then, based on the multi-dimensional authentication factors, a dynamic authentication policy corresponding to the current call scenario is generated; next, authentication is performed on the call request according to the dynamic authentication policy; and after the call request passes authentication, a temporary access credential is generated, which is used to access the target network service. Compared with existing technologies, this application dynamically acquires multi-dimensional authentication factors and generates an authentication policy adapted to the current scenario during the service call process, and performs authentication and issues temporary access credentials based on the policy, enhancing the system's ability to perceive and defend against abnormal behavior and potential attacks, while meeting the dynamic, scenario-based, and heterogeneous authentication requirements under the 6G service-oriented architecture.

[0031] To further illustrate the specific implementation process of the method in this embodiment, this embodiment provides a method such as... Figure 2 The method shown includes: Step 201: In response to the call request for the target network service, obtain the multi-dimensional authentication factors related to the call request.

[0032] Among them, the multi-dimensional authentication factors include at least one of the following: identity factor, service factor, environmental factor, and behavioral factor.

[0033] For example, one authentication system architecture in this embodiment is as follows: Figure 3As shown: At the terminal layer, diverse access entities, including industrial AR devices, autonomous vehicles, and smart home terminals, access the network through various methods. The access layer provides base station access, satellite access, and other access methods, supporting terminal connections in heterogeneous network environments. The service-oriented functional layer is the core of the system, encapsulating authentication capabilities into standardized APIs (such as "authentication request," "credential generation," and "permission revocation"), and deploying them together with network services such as computing power scheduling, AI inference, data transmission, and slice management to achieve modularization, invoking, and collaborative operation of authentication capabilities. This layer consists of multiple core functional modules: the authentication service module includes an authentication request interface, an intelligent policy engine, a scenario-based authentication factor library, an adaptive optimization module, a global policy controller, and a distributed authentication proxy, forming a closed-loop mechanism of "scenario perception—multi-factor decision-making—dynamic execution—self-optimization"; simultaneously, the digital twin, resource orchestration engine, and global policy controller in the management and coordination layer are responsible for unified management of cross-domain policies, resource scheduling, and global coordination. The underlying resource layer aggregates cloud computing resources, edge computing resources, and storage resource pools to provide elastic support for upper-layer services.

[0034] Step 202: Determine the preset basic strategy corresponding to the current calling scenario based on the risk coefficient and preset weight of each authentication factor.

[0035] In some examples, the scenario-based authentication factor library supports dynamic configuration of the weights of various authentication factors. Each factor is associated with a configurable "risk coefficient threshold" to quantify its security impact in the current scenario. For example, "satellite link," as a high-risk access method, has a default environmental factor risk coefficient of 0.8, while "industrial Ethernet," being in a controlled environment, has a lower default risk coefficient of 0.3. This automatically reflects the security level differences of different network environments when generating policies. Furthermore, the factor library supports a real-time update mechanism. Edge nodes or the core network can proactively push new factor information through the standardized FactorUpdate API. This API includes parameters such as FactorType (factor type), FactorValue (factor value), RiskCoeff (corresponding risk coefficient), and UpdateTime (update timestamp), enabling the system to respond promptly to changes in network status, terminal behavior, or service attributes, ensuring that authentication decisions are always based on the latest and most accurate contextual data.

[0036] For example, the intelligent policy engine can dynamically generate authentication policies adapted to the current calling scenario by integrating rule-driven and data-driven mechanisms. The rule base provides basic policy logic predefined by security policies, such as mandating biometric verification for highly sensitive services (e.g., services involving personal health or financial data) to ensure that minimum security baselines are met.

[0037] Optionally, the method in this embodiment may further include: determining whether the current call scenario belongs to a local decision-making scenario based on the matching relationship between the service coverage involved in the call request and the current access location of the requester, as well as the sensitivity level of the target network service.

[0038] For example, in the authentication process, the distributed authentication proxy performs the judgment of the local decision scenario: After receiving the AuthRequest, the proxy parses the ServiceID and queries the corresponding service coverage from the locally cached ServiceScopeMap (for example, the coverage of "Edge AI Quality Inspection Service" is defined as "Factory A Edge Area"); at the same time, it obtains the current access location of the requester by calling the LocationAPI (with RequesterID as a parameter), and the returned result can be latitude and longitude coordinates or standardized area codes. Subsequently, the proxy performs a dual condition judgment: if the access location of the requester falls within the coverage of the service and the sensitivity level of the target service is "medium" or lower, it is determined to be a "local decision" scenario, and the process enters the subsequent local factor acquisition and policy generation stage; otherwise, if the access location is outside the service coverage, or the service sensitivity level is marked as "high" (meeting either condition), it is determined to be a "global decision" scenario, and the proxy will initiate a cross-domain policy request to the global policy controller to obtain the authentication policy applicable to this high-risk or cross-domain scenario.

[0039] Optionally, step 202 may specifically include: if the current call scenario belongs to the local decision-making scenario, then call the locally cached factor library and preset rule library to generate a local authentication policy; if the current call scenario does not belong to the local decision-making scenario, then based on the cross-domain information query, generate a cross-domain authentication policy containing multi-domain joint verification requirements, the multi-domain joint verification requirements including node signature verification or certificate cross-authentication of at least two geographical domains.

[0040] In some examples, distributed authentication agents are deployed in multi-layered distributed network units such as edge nodes, regional cores, and group centers to achieve low-latency and high-efficiency localized authentication processing. This is especially suitable for scenarios where industrial equipment calls computing services at the edge and is sensitive to response speed. At the same time, it maintains real-time synchronization of policies and states with the intelligent policy engine to support the key technical capability of "distributed intelligent decision-making".

[0041] For example, the distributed authentication proxy adopts a "layered deployment + hierarchical decision-making" architecture: At the deployment level, the edge-level proxy is located at the edge nodes of the factory or campus, and a single instance can support concurrent authentication requests from no more than 1,000 terminals, with end-to-end processing latency controlled within 10 milliseconds; the regional-level proxy is deployed at the provincial core network nodes, supporting a scale of up to 100,000 concurrent terminals, with a latency of no more than 30 milliseconds; the global-level proxy is located in the core network, focusing on handling complex authentication needs across geographical domains, with a latency limit of 100 milliseconds. In terms of decision-making logic, the system dynamically selects the decision level based on service coverage and security sensitivity—when the requested service geographical scope is limited to the coverage area of ​​a single edge node and the service sensitivity level is "medium" or lower, the proxy directly generates an authentication policy based on the locally cached authentication factor library (cache update cycle no more than 1 minute), achieving rapid local closed-loop processing.

[0042] In some examples, when a service request involves cross-domain movement (e.g., an autonomous vehicle switching from the edge of city A to the edge of city B) and the service sensitivity level is "high", a global decision-making process is triggered. The agent initiates a policy query to the global policy controller through the GlobalPolicyRequest API. This API carries parameters such as the requester ID, cross-domain information (CrossDomainInfo), and service sensitivity level (ServiceSensitivity). The controller must return the cross-domain authentication policy within a configurable response time limit (default 500 milliseconds). If the timeout occurs, a pre-set local backup policy is automatically enabled to balance security and service continuity.

[0043] For example, the global policy controller, acting as the "global coordination center" in the distributed authentication system, undertakes the core functions of cross-domain collaboration and resource optimization. Its primary function is to achieve unified management of cross-domain policies. By centrally storing inter-domain authentication rules across different regions, it ensures the consistency and executability of security policies in multi-domain service call scenarios. For instance, for cross-domain service requests between "City A and City B," the system can simultaneously verify digital signatures from edge nodes in both locations according to preset rules, thereby achieving joint trust anchoring between geographical domains. Furthermore, the global policy controller also possesses resource scheduling and coordination capabilities. It can monitor the load status of each edge authentication proxy in real time. When it detects that the resource utilization rate (such as CPU or concurrent sessions) of a certain proxy reaches or exceeds the threshold of 80%, it automatically triggers a load balancing mechanism, dynamically migrating some authentication requests to nearby proxy nodes with lower loads. The end-to-end latency of the entire scheduling process is controlled within 1 second, ensuring service availability in high-concurrency scenarios while avoiding authentication delays or failures due to local overload. This improves the overall resilience and response efficiency of the system while maintaining the uniformity of global security policies.

[0044] For example, after determining it to be a global decision-making scenario, the distributed authentication proxy initiates a cross-domain policy request to the global policy controller to obtain a security policy applicable to the current call context. This process is implemented by the proxy actively calling the GlobalPolicyRequest API, whose input parameters include the authentication session identifier (AuthSessionID), the requester identifier (RequesterID), cross-domain information (CrossDomainInfo, used to describe the geographical or administrative domains traversed by the service call, such as "City A—City B"), and the sensitivity level of the target service (ServiceSensitivity). Upon receiving the request, the global policy controller performs a matching query based on its built-in "inter-domain rule base," which predefines security collaboration requirements under different domain combinations. Based on the query results, the controller dynamically generates a specific cross-domain authentication policy, such as "verifying the device's digital certificate + joint signature of edge nodes in Beijing and Tianjin + a one-time dynamic password based on time." The generated policy is returned to the requesting distributed authentication proxy via a GlobalPolicyResponse message. The response latency of the entire interaction process is strictly controlled within 500 milliseconds to ensure service availability and user experience under high security requirements.

[0045] For example, after completing the decision-level judgment, the distributed authentication agent executes the corresponding policy generation and authentication operations based on the judgment result. In local decision-making scenarios, the agent directly obtains the required multi-dimensional authentication factors from the locally cached factor library. This cached content is updated periodically, with an update cycle of no more than 1 minute, thereby ensuring the timeliness of factor data and avoiding additional latency and bandwidth overhead introduced by cross-node or cross-domain communication, meeting the needs of low-latency sensitive services such as industrial control and edge intelligence. In global decision-making scenarios, the agent further integrates locally available contextual information, such as the current access network type, terminal location, and link security status, based on the cross-domain authentication policy returned by the global policy controller. It combines the globally issued security constraints with the local real-time context to generate the final execution policy. This "global policy + local factors" fusion mechanism not only ensures the unified security baseline and multi-domain collaborative verification capabilities required for cross-domain highly sensitive services, but also fully utilizes the local awareness advantages of the edge side, effectively balancing security and response efficiency, and achieving a dynamic balance between security control and service quality under the 6G distributed network architecture.

[0046] Step 203: Based on the analysis of historical authentication data, adjust the preset basic strategy to generate a dynamic authentication strategy.

[0047] Optionally, step 203 may specifically include: using a federated learning model to jointly train historical authentication data in distributed nodes to identify potential abnormal behavior patterns; when the current call behavior is detected to match the identified abnormal behavior pattern, an enhanced authentication strategy is triggered, which includes increasing the number of authentication factors required for the current call scenario and / or shortening the validity period of temporary access credentials.

[0048] For example, artificial intelligence (AI) models (such as models based on federated learning architectures) can be used to continuously analyze historical authentication data accumulated in distributed nodes to identify potential attack behavior patterns or abnormal access trends, such as high-frequency failed requests from the same terminal in a short period of time or large-scale data calls during atypical periods. Based on this, authentication strategies can be adjusted in real time, such as automatically triggering multi-factor authentication, shortening the validity period of credentials, or introducing additional verification steps when suspicious behavior is detected.

[0049] Step 204: Perform authentication operations on the call request according to the dynamic authentication strategy.

[0050] In some examples, authentication capabilities can be encapsulated as standardized network services and embedded into the service-oriented functional layer in the form of three core APIs: "authentication request," "credential generation," and "authorization revocation," thereby achieving seamless integration with various service call processes in 6G networks.

[0051] For example, before a third-party application calls the "computing power service," the system can automatically trigger the authentication process without manual intervention or additional adaptation. Specifically, the Authentication Request API (AuthRequest) receives the requester ID, target service ID, and access type as input parameters and returns a unique authentication session ID (AuthSessionID); the Credential Generation API (CredentialGenerate) generates a temporary access credential containing a digital signature based on the session ID and the specified credential validity period (ValidityPeriod, in seconds); and the Permission Revocation API (PermissionRevoke) supports proactively revoking granted permissions at runtime based on the temporary credential and the revocation reason (such as "data overload" or "device offline"), and returns the operation result (success or failure). To ensure communication security, all APIs are required to use HTTPS and encrypted transmission to prevent credential leakage, replay attacks, or man-in-the-middle tampering.

[0052] Optionally, the method in this embodiment may further include: obtaining the authentication result corresponding to the current authentication operation; if the authentication success rate of the current calling scenario is not lower than the first threshold and no security event occurs within the first preset time period, then reducing the number of authentication factors required for the current calling scenario and / or extending the validity period of the temporary access credential; if the number of authentication failures of the same requester exceeds the second threshold within the second preset time period, then increasing the number of authentication factors required for the current calling scenario and / or adding biometric verification.

[0053] In some examples, after the authentication process is completed, the system initiates a self-evolutionary optimization closed loop. First, the distributed authentication proxy reports detailed authentication data to the adaptive optimization module, covering three dimensions: basic data includes authentication session identifier (AuthSessionID), requester type (terminal or application), target service identifier (ServiceID), authentication result (success / failure), and processing latency (AuthLatency); security data records attack types (such as "certificate forgery" and "permission violation") and the number of attack interceptions (InterceptCount); for IoT terminals, additional resource consumption indicators such as power consumption change and battery life change are also collected. After receiving the above data, the adaptive optimization module conducts multi-dimensional analysis: it calculates the average authentication success rate (target no less than 99.5%) and average latency (target no more than 15ms) for a specific scenario (such as "industrial AR equipment + AI quality inspection service") over 72 hours through statistical analysis; it identifies potential problems using an anomaly detection mechanism, such as an IoT sensor that successfully authenticates 10 times consecutively but its power consumption increases abnormally by 20%, which is judged as "over-authentication"; at the same time, it evaluates the effectiveness, marking scenarios with an attack interception rate of less than 95% as "requiring enhanced strategies", while IoT scenarios with a power consumption increase of more than 15% are marked as "requiring simplified strategies".

[0054] For example, based on the analysis results, the module generates structured optimization suggestions: for high-risk combinations (such as "satellite link + medical data service"), it is recommended to upgrade from two-factor authentication to three-factor authentication; for low-power environment monitoring services, it is recommended to adjust the authentication frequency from each call to once every 5 minutes in batches, and extend the validity period of temporary credentials from 10 minutes to 30 minutes to reduce interaction overhead; all suggestions adopt a standardized format.<SceneID, OptimizeType,ParamName, OldValue, NewValue, Reason> "The code is encapsulated to ensure parsing and traceability. Then, the intelligent policy engine completes the adjustment of the rule base or AI model (such as the weight of the reinforcement learning reward function) within 10 seconds, and pushes the changes to each distributed authentication agent in an incremental update manner through the PolicyUpdate API, transmitting only the changed rule or factor parameters."

[0055] For example, once the agent receives an update, the new policy takes effect immediately. At the same time, the policy version number is recorded, and a rollback mechanism is built in. If the new policy causes the authentication failure rate to rise to 5% or higher during operation, the system will automatically roll back to the previous stable version, thereby ensuring the reliability and stability of the service while continuously optimizing the security policy.

[0056] Step 205: After the call request passes authentication, generate a temporary access credential.

[0057] Temporary access credentials are used to access the target network service.

[0058] Optionally, the method in this embodiment may further include: during the process of the requester accessing the target network service through a temporary access credential, real-time monitoring of the data interaction behavior corresponding to the call request; if any of the following situations are detected, such as the data transmission volume exceeding a preset threshold, the access frequency deviating from a preset baseline, or the access behavior exceeding the authorized scope, then the temporary access credential is revoked to terminate the access permission to the target network service.

[0059] In some examples, an adaptive optimization mechanism with end-to-end data analysis and strategy tuning capabilities can be built to achieve continuous evolution and dynamic optimization of authentication strategies, corresponding to the key technical point of "self-evolving security strategy". The system performs feedback optimization of the strategy based on authentication results (such as false positive rate and attack interception rate): for low-risk scenarios where legitimate requests are frequently rejected, the authentication strength is proactively reduced to improve service efficiency; while for services facing high attack risks, security protection is enhanced, such as increasing the dimensionality of the authentication factors used or introducing more stringent verification steps.

[0060] For example, the aforementioned adaptive optimization mechanism mainly consists of four collaborative sub-modules: the data acquisition sub-module collects multi-dimensional data once per session after each authentication session, including authentication results (success / failure and reasons for failure), service performance indicators (such as authentication latency and terminal power consumption changes), and security event records (such as attack interception logs and permission overreach behaviors); based on this, the data analysis sub-module combines statistical analysis and anomaly detection algorithms for comprehensive judgment, for example, marking scenarios where "the authentication success rate is not less than 99.5% and there are no security events within 72 consecutive hours" as "low risk". The system identifies "suspicious terminals" by identifying scenarios where "a single terminal fails authentication 5 times or more within 1 hour." The optimization suggestion generation submodule outputs structured quantitative optimization suggestions based on the analysis results. For example, it suggests "reducing the number of authentication factors by 2" for low-risk scenarios or "adding biometric verification" for suspicious terminals. Each suggestion clearly includes the adjustment dimensions (such as the number of factors, weights, or verification steps), adjustment values, and expected technical effects (such as "reducing latency by 8ms" or "reducing terminal power consumption by 12%). Finally, the feedback loop submodule pushes the optimization suggestions to the intelligent policy engine through the PolicyOptimize API. The engine completes the rule base update or model parameter adjustment within 10 seconds and returns confirmation information through the PolicyAck API. At the same time, this module continuously records the comparison of key indicators before and after the policy update (such as authentication latency decreasing from 20ms to 12ms), forming a traceable and verifiable policy evolution loop.

[0061] In some examples, such as Figure 4 As shown, a third-party application or terminal device first initiates a service call request to the service-based authentication capability interface. This interface, acting as the entry point, forwards the request to the corresponding distributed authentication proxy. Upon receiving the request, the proxy retrieves multi-dimensional authentication factors related to the current call from a scenario-based authentication factor library, including information on identity, service, environment, and behavior. These factors are then submitted to the intelligent policy engine to generate a dynamic authentication policy adapted to the current scenario. The policy engine analyzes the data based on a preset rule base and AI model, returning the generated authentication policy to the proxy. The proxy then performs authentication operations on the requester according to this policy: if authentication is successful, the request is allowed to proceed to the target network service, which processes the business and returns the result to the requester. Simultaneously, the proxy reports the success information to the adaptive optimization module; if authentication fails, a failure response is returned to the requester, and failure details are reported synchronously. Throughout the process, the adaptive optimization module continuously collects authentication result data, combines statistical analysis and anomaly detection algorithms to evaluate the security and efficiency performance of each scenario, and provides optimization suggestions to the intelligent policy engine, driving the dynamic evolution of the authentication policy and thus achieving closed-loop iteration and self-evolution of security capabilities.

[0062] In some embodiments, taking "industrial AR device calling edge AI quality inspection service" as an example, this dynamic authentication process fully embodies the closed-loop mechanism of scene perception, policy generation, execution control, and adaptive optimization. The industrial AR device first initiates a call request to the "edge AI quality inspection service" through an open API, carrying its own device ID and service parameters (such as "real-time image recognition"). The distributed authentication agent deployed at the factory edge node then initiates factor collection: on the one hand, it automatically acquires local environmental factors (such as the access method being "industrial Ethernet") and behavioral factors (such as the call frequency being at a normal baseline within the past hour); on the other hand, it queries the corresponding service factors from the scenario-based authentication factor library to confirm that the "AI quality inspection" service is marked as "medium" sensitive due to its association with production data. Based on these multi-dimensional factors, the intelligent policy engine combines a preset rule base (which stipulates that medium-sensitive services require "device certificate + local edge node endorsement") and AI model analysis results to generate a specific authentication policy: "verify device digital certificate + edge node signature". The proxy performs authentication, verifying the validity of the device certificate and confirming that the edge node has authorized the device to access. It then generates a temporary access credential valid for 10 minutes, which is bound to the computing resources of the current edge node. The AR device uses this credential to call the AI ​​quality inspection service. Simultaneously, the authentication proxy continuously monitors its data interaction behavior. If it detects abnormal transmission volume exceeding the expected threshold, it immediately triggers permission revocation. In long-term operation, if the adaptive optimization module observes no security events and a stable authentication success rate for 30 consecutive days, it will suggest simplifying the strategy, downgrading the authentication requirement for subsequent calls to "verify device certificate only," thereby reducing interaction steps, lowering end-to-end latency, and improving service efficiency while ensuring security.

[0063] Compared to existing technologies, this embodiment constructs an integrated dynamic authentication system. It relies on a scenario-based authentication factor library to collect multi-dimensional contextual information in real time. An intelligent policy engine integrates rules and AI models to generate fine-grained policies, which are then flexibly executed at the edge or core via a distributed authentication proxy. This ensures that authentication decisions are both closely aligned with the business context and comply with global security constraints. Simultaneously, the service-oriented authentication capability interface seamlessly embeds security capabilities into the service call process, enabling third-party applications to automatically trigger appropriate authentication actions when calling computing power, connectivity, or AI services, without requiring additional integration. The adaptive optimization module continuously analyzes authentication effectiveness and resource consumption, driving policy autonomous evolution. For example, it simplifies verification steps to reduce latency in long-term stable, low-risk industrial AR scenarios, or overlays multiple factors to enhance protection for high-risk cross-domain medical data transmission. While ensuring inherent security, it significantly improves the flexibility, efficiency, and scalability of authentication, better meeting the core requirements of 6G service-oriented architecture for dynamic, intelligent, and autonomous security mechanisms.

[0064] Furthermore, as Figure 1 and Figure 2 The specific implementation of the method shown in this embodiment provides a dynamic authentication device, such as... Figure 5 As shown, the device includes: an acquisition module 31, a first generation module 32, an execution module 33, and a second generation module 34.

[0065] The acquisition module 31 is configured to acquire a multi-dimensional authentication factor related to the call request in response to a call request to the target network service. The first generation module 32 is configured to generate a dynamic authentication strategy corresponding to the current calling scenario based on the multi-dimensional authentication factors. Execution module 33 is configured to perform authentication operations on the call request according to the dynamic authentication strategy; The second generation module 34 is configured to generate a temporary access credential after the call request passes authentication, the temporary access credential being used to access the target network service.

[0066] In some examples of this embodiment, the multi-dimensional authentication factors include at least one of identity factors, service factors, environmental factors, and behavioral factors; correspondingly, the first generation module 32 is further configured to determine the preset basic strategy corresponding to the current calling scenario based on the risk coefficient and preset weight of each authentication factor; and to adjust the preset basic strategy based on the analysis of historical authentication data to generate a dynamic authentication strategy.

[0067] In some examples of this embodiment, the first generation module 32 is further configured to determine whether the current call scenario belongs to a local decision-making scenario based on the matching relationship between the service coverage involved in the call request and the current access location of the requester, as well as the sensitivity level of the target network service.

[0068] In some examples of this embodiment, the first generation module 32 is further configured to, if the current call scenario belongs to a local decision-making scenario, call the locally cached factor library and preset rule library to generate a local authentication strategy; if the current call scenario does not belong to a local decision-making scenario, generate a cross-domain authentication strategy containing multi-domain joint verification requirements based on cross-domain information query corresponding inter-domain authentication rules, wherein the multi-domain joint verification requirements include node signature verification or certificate cross-authentication of at least two geographical domains.

[0069] In some examples of this embodiment, the first generation module 32 is further configured to use a federated learning model to jointly train historical authentication data in distributed nodes to identify potential abnormal behavior patterns; when the current call behavior is detected to match the identified abnormal behavior pattern, an enhanced authentication strategy is triggered, which includes increasing the number of authentication factors required for the current call scenario and / or shortening the validity period of temporary access credentials.

[0070] In some examples of this embodiment, the execution module 33 is further configured to obtain the authentication result corresponding to the current authentication operation; if the authentication success rate of the current calling scenario is not lower than the first threshold and no security event occurs within the first preset time period, the number of authentication factors required for the current calling scenario is reduced and / or the validity period of the temporary access credential is extended; if the number of authentication failures of the same requester exceeds the second threshold within the second preset time period, the number of authentication factors required for the current calling scenario is increased and / or biometric verification is added.

[0071] In some examples of this embodiment, the second generation module 34 is further configured to monitor the data interaction behavior corresponding to the call request in real time during the process of the requester accessing the target network service through the temporary access credential; if any of the following situations are detected, such as the data transmission volume exceeding a preset threshold, the access frequency deviating from a preset baseline, or the access behavior exceeding the authorized scope, then the temporary access credential is revoked to terminate the access permission to the target network service.

[0072] It should be noted that for other corresponding descriptions of the functional units involved in the dynamic authentication device provided in this embodiment, please refer to... Figure 1 and Figure 2 The corresponding descriptions in [the document] will not be repeated here.

[0073] Based on the above, Figure 1 and Figure 2 Accordingly, this embodiment also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method. Figure 1 and Figure 2 The method shown.

[0074] Based on this understanding, the technical solution of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as CD-ROM, USB flash drive, mobile hard drive, etc.) and includes several instructions to cause a computer device (such as personal computer, server, or network device, etc.) to execute the methods of various implementation scenarios of this application.

[0075] Based on the above, Figure 1 and Figure 2 The method shown, and Figure 5 To achieve the above objectives, the present application also provides an electronic device, such as a personal computer, server, laptop computer, intelligent robot, or other intelligent terminal, as illustrated in the virtual device embodiment. This device includes a storage medium and a processor; the storage medium stores a computer program; the processor executes the computer program to implement the above-described virtual device. Figure 1and Figure 2 The method shown.

[0076] Optionally, the aforementioned physical devices may also include a user interface, a network interface, a camera, radio frequency (RF) circuitry, sensors, audio circuitry, a Wi-Fi module, etc. The user interface may include a display screen, input units such as a keyboard, etc., and optional user interfaces may also include USB interfaces, card reader interfaces, etc. The network interface may optionally include standard wired interfaces, wireless interfaces (such as Wi-Fi interfaces), etc.

[0077] Those skilled in the art will understand that the physical device structure provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or combine certain components, or have different component arrangements.

[0078] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the aforementioned physical device, supporting the operation of information processing programs and other software and / or programs. The network communication module is used to enable communication between the various components within the storage medium, as well as communication with other hardware and software in the information processing physical device.

[0079] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented using software plus necessary general-purpose hardware platforms, or it can be implemented through hardware. By applying the solution of this embodiment, compared with the existing technology, this embodiment significantly improves the security protection capability, system flexibility, and operating efficiency in a 6G service environment. In terms of security, it abandons the traditional authentication model that relies solely on static identity identifiers, and instead integrates multi-dimensional factors such as identity, service, environment, and behavior. Combined with dynamically generated strategies, it responds to risk changes in real time, effectively curbing new types of attacks such as privilege abuse, terminal forgery, and unauthorized access, which aligns with the core design concept of 6G's "intrinsic security." In terms of flexibility, it embeds authentication capabilities into a service-oriented architecture in a standardized service form, supporting cross-domain, heterogeneous, and dynamically combined service call scenarios. This allows third-party applications to securely access network services without adapting to underlying security mechanisms, significantly reducing integration complexity. In terms of efficiency, it completes local decision-making at the edge through a distributed authentication proxy, achieving millisecond-level low-latency response in critical scenarios such as industrial control. At the same time, it relies on an adaptive optimization mechanism to continuously identify low-risk scenarios and streamline the authentication process, avoiding unnecessary computation and energy consumption for resource-constrained terminals such as low-power IoT devices. This achieves the optimal balance between performance and resources while ensuring security.

[0080] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0081] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A dynamic authentication method, characterized in that, include: In response to a request to invoke a target network service, obtain multi-dimensional authentication factors related to the request; Based on the aforementioned multi-dimensional authentication factors, a dynamic authentication strategy corresponding to the current calling scenario is generated. Based on the dynamic authentication strategy, the authentication operation is performed on the call request; After the call request is authenticated, a temporary access credential is generated, which is used to access the target network service.

2. The method according to claim 1, characterized in that, The multi-dimensional authentication factors include at least one of identity factors, service factors, environmental factors, and behavioral factors; Based on the aforementioned multi-dimensional authentication factors, a dynamic authentication strategy corresponding to the current invocation scenario is generated, including: Based on the risk coefficient and preset weight of each authentication factor, determine the preset basic strategy corresponding to the current calling scenario; Based on the analysis of historical authentication data, the preset basic strategy is adjusted to generate a dynamic authentication strategy.

3. The method according to claim 2, characterized in that, Before determining the preset basic strategy corresponding to the current calling scenario based on the risk coefficient and preset weight of each authentication factor, the method further includes: Based on the matching relationship between the service coverage involved in the call request and the current access location of the requester, as well as the sensitivity level of the target network service, it is determined whether the current call scenario belongs to a local decision-making scenario.

4. The method according to claim 3, characterized in that, Based on the risk coefficients and preset weights corresponding to each authentication factor, the preset basic strategy corresponding to the current invocation scenario is determined, including: If the current call scenario belongs to the local decision-making scenario, the local cached factor library and preset rule library are called to generate a local authentication strategy; If the current call scenario does not belong to the local decision-making scenario, then based on the cross-domain information query corresponding to the inter-domain authentication rules, a cross-domain authentication strategy containing multi-domain joint verification requirements is generated. The multi-domain joint verification requirements include node signature verification or certificate cross-authentication of at least two geographical domains.

5. The method according to claim 2, characterized in that, Based on the analysis of historical authentication data, the preset basic strategy is adjusted to generate a dynamic authentication strategy, including: A federated learning model is used to jointly train historical authentication data in distributed nodes to identify potential abnormal behavior patterns. When the current call behavior is detected to match an identified abnormal behavior pattern, an enhanced authentication strategy is triggered. The enhanced authentication strategy includes increasing the number of authentication factors required for the current call scenario and / or shortening the validity period of temporary access credentials.

6. The method according to claim 1, characterized in that, After performing authentication on the call request according to the dynamic authentication strategy, the method further includes: Obtain the authentication result corresponding to this authentication operation; If the authentication success rate of the current calling scenario is not lower than the first threshold and no security event occurs within the first preset time period, then the number of authentication factors required for the current calling scenario shall be reduced and / or the validity period of the temporary access credential shall be extended. If the number of authentication failures for the same requester exceeds the second threshold within the second preset time period, the number of authentication factors required for the current call scenario will be increased and / or biometric verification will be added.

7. The method according to claim 1, characterized in that, The method further includes: During the process of the requester accessing the target network service through the temporary access credential, the data interaction behavior corresponding to the call request is monitored in real time. If any of the following situations are detected: data transmission volume exceeds a preset threshold, access frequency deviates from a preset baseline, or access behavior exceeds the authorized scope, the temporary access credential will be revoked to terminate access to the target network service.

8. A dynamic authentication device, characterized in that, include: The acquisition module is configured to acquire multi-dimensional authentication factors related to the call request in response to a call request to the target network service; The first generation module is configured to generate a dynamic authentication strategy corresponding to the current calling scenario based on the multi-dimensional authentication factors. The execution module is configured to perform authentication operations on the call request according to the dynamic authentication strategy; The second generation module is configured to generate a temporary access credential after the call request passes authentication, the temporary access credential being used to access the target network service.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

10. An electronic device comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 7.

11. A computer program product having a computer program stored thereon, characterized in that, When the computer program product is executed by a processor, it implements the method of any one of claims 1 to 7.

Images