Authentication method and device for cross-service access, storage medium, equipment and product

Abstract

Embodiments of the present application disclose a cross-service access authentication method and device, a storage medium, equipment and products. The method comprises: in response to an access request for a target service sent by a user terminal, comparing the security level of a session source service of the access request with the security level of the target service; in the case that the security level of the target service is higher than the security level of the session source service, extracting an upgrade credential from the access request, the upgrade credential being previously issued by an authorized end of the target service; verifying the upgrade credential; in response to the upgrade credential passing the verification, authorizing the user terminal to access the target service, and authorizing the authorization to be invalid after the access request is processed. The present application can complete cross-service access without interrupting the normal service process, while ensuring session security.

Description

Technical Field

[0001] This application relates to the field of network security technology, and in particular to an authentication method, apparatus, storage medium, device, and product for cross-service access. Background Technology

[0002] In large internet platforms, the same account system often needs to support multiple service scenarios with different security requirements simultaneously. To prevent high-security services from being directly accessed by low-security domain credentials, controlled management of access between services with different security levels is necessary.

[0003] In related technologies, when the current request's security level is detected to be insufficient, the user is required to complete full authentication again and be issued a new, high-security, persistent session credential. However, this method requires the user to log in again, causing the normal service process to be interrupted and the original session context to be lost. Furthermore, once a high-security, persistent session credential is issued, it remains valid for a long time, leading to persistent privilege escalation and increasing the risk of credential leakage and abuse. Summary of the Invention

[0004] In view of this, this application provides an authentication method, apparatus, storage medium, device, and product for cross-service access, so as to complete cross-service access without interrupting normal service processes, while ensuring session security.

[0005] This application provides the following solution: According to the first aspect, a token-based authentication method is provided, the method comprising: In response to an access request for a target service sent by a user, the security levels of the session origin service of the access request and the target service are compared. If the security level of the target service is higher than the security level of the session origin service, an upgrade credential is extracted from the access request. The upgrade credential is pre-issued by the authorization end of the target service. Verify the upgrade certificate; Upon successful verification of the upgrade credential, the client is authorized to access the target service, and the authorization expires after the access request is processed.

[0006] Optionally, verifying the upgrade certificate includes: Parse the actual use case information of the access request; The upgrade certificate is decrypted to obtain usage scenario description information; Perform a consistency check between the actual usage scenario information and the usage scenario description information; Based on the consistency verification result, the upgrade credential verification result is determined.

[0007] Optionally, the usage scenario description information includes user identity information, source service information, and target service information; or, the usage scenario description information includes user identity information, source service information, target service information, and device characteristic information.

[0008] Optionally, the upgrade certificate is decrypted to obtain constraint information of the upgrade certificate, the constraint information including at least one of the maximum number of times the upgrade certificate can be used and the aging time; The step of determining the upgrade credential verification result based on the consistency verification result includes: Determine whether the upgrade certificate meets the constraint conditions. In response to the consistency verification result being successful and the upgrade certificate satisfying the constraint conditions, it is determined that the upgrade certificate has passed the verification.

[0009] Optionally, before verifying the upgrade certificate, the method further includes: Verify whether the upgrade path from the session source service to the target service is a preset valid upgrade path. If it is, continue to verify the upgrade credentials; otherwise, deny the user's access to the target service.

[0010] Optionally, the authorization to allow the user to access the target service, and the expiration of the authorization after the access request is processed, includes: An authorization tag corresponding to the target service is written into the processing context of the access request; wherein the processing context is cleared after the access request is processed to invalidate the authorization tag.

[0011] Optionally, the processing context is the thread-level context corresponding to the access request; Optionally, the upgrade credential exists independently of the persistent session credential in the access request.

[0012] According to the second aspect, an authentication device for cross-service access, the device comprising: The security level comparison unit is configured to compare the security level of the session origin service of the access request with that of the target service in response to an access request sent by the client for a target service. The credential extraction unit is configured to extract an upgrade credential from the access request when the security level of the target service is higher than the security level of the session origin service, wherein the upgrade credential is pre-issued by the authorization end of the target service; The credential verification unit is configured to verify the upgrade credential; The service authorization unit is configured to authorize the user to access the target service in response to the successful verification of the upgrade credential, and the authorization expires after the access request is processed.

[0013] According to a third aspect, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in any one of the first aspects.

[0014] According to the fourth aspect, an electronic device is provided, comprising: One or more processors; and A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method described in any one of the first aspects above.

[0015] According to a fifth aspect, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the steps of the method described in any of the first aspects above.

[0016] According to the specific embodiments provided in this application, the following technical effects are disclosed: This application compares the security levels of the source and target services of a session. If the target service has a higher security level, it extracts a pre-issued upgrade credential for verification. Access is only granted after successful verification. This ensures that only users with valid upgrade credentials can obtain cross-security access authorization, preventing security issues such as low-security session services directly accessing high-security services. Furthermore, since the upgrade credential is pre-issued, users do not need to log in again when cross-security access is triggered, thus not interrupting normal service processes or causing the loss of the original session context. In addition, this authorization is only valid within a single access request processing cycle and expires after the access request is processed, preventing persistent privilege escalation, reducing the risk of abuse after credential leakage, and improving session security.

[0017] Of course, any product implementing this application does not necessarily need to achieve all of the advantages described above at the same time. Attached Figure Description

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

[0019] Figure 1This is a system architecture diagram applicable to the embodiments of this application.

[0020] Figure 2 A flowchart illustrating the authentication method for cross-service access provided in this application embodiment.

[0021] Figure 3 This is a schematic diagram illustrating the security level comparison process provided in an embodiment of this application.

[0022] Figure 4 This is a schematic diagram illustrating the interaction process at each level within the server side, as provided in the embodiments of this application.

[0023] Figure 5 The interaction sequence diagram is shown for the cross-service access authentication method provided in the embodiments of this application.

[0024] Figure 6 A schematic block diagram of an authentication device for cross-service access provided in an embodiment of this application.

[0025] Figure 7 A schematic block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0026] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0027] The terminology used in the embodiments of this invention is for the purpose of describing particular embodiments only and is not intended to limit the invention. The singular forms “a,” “the,” and “the” as used in the embodiments of this invention and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0028] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0029] Depending on the context, the word "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection." Similarly, depending on the context, the phrase "if determination" or "if detection (of the stated condition or event)" can be interpreted as "when determination," "in response to determination," "when detection (of the stated condition or event)," or "in response to detection (of the stated condition or event)."

[0030] In the field of identity authentication and authorization, a single account system often needs to support multiple services with different security requirements simultaneously. To prevent high-security services from being directly accessed by low-security domain credentials, controlled management is required for access between services with different security levels.

[0031] In related technologies, when an insufficient security level is detected in the current request, the user is typically required to complete full authentication again, and a new, high-security persistent session credential is issued. This approach matches the target service's security requirements by replacing the user's existing persistent session credential. However, this method forces the user to complete the login process again, which interrupts the user's ongoing service flow and results in the loss of the original session's context state. Furthermore, once the newly issued persistent session credential takes effect, it persists in the session storage until it expires or is actively deleted, creating a long-term privilege escalation state. If this credential is compromised, it can be abused by attackers over a prolonged period.

[0032] For example, an advertising agency may have already logged into an ad delivery service, and the user holds a persistent session credential. This credential records that the source service is the ad delivery service, which has a low security level. When the advertising agency switches from the low-security ad delivery service to the high-security e-commerce management service, it needs to re-enter its password to obtain a session credential for the e-commerce management service. This operation disrupts the advertising agency's ongoing ad configuration workflow, and the original session's page state, input drafts, and other contextual data are lost. Furthermore, the newly obtained e-commerce management service credential can persistently access e-commerce interfaces. If this credential is inadvertently leaked, attackers could use it to gain long-term access to highly sensitive service interfaces.

[0033] In view of this, this application provides a new approach. To facilitate understanding of this application, the system architecture on which this application is based will first be described. Figure 1 An exemplary system architecture that can be applied to embodiments of this application is shown, such as Figure 1 As shown, the system architecture may include: a user terminal and an authentication device set up on the server side. The server side is connected to the user terminal via a network.

[0034] The server side and the client side are the two main components of an application service. The server side uses a server as its primary hardware infrastructure and may include one or more software service modules. In this embodiment, it is mainly responsible for establishing sessions with the client and providing services to the client, forming a collaborative front-end and back-end.

[0035] The user terminal can be, but is not limited to, devices such as smart mobile terminals, wearable devices, and PCs (Personal Computers). Smart mobile devices can include devices such as mobile phones, tablets, PDAs (Personal Digital Assistants), and connected car terminals. Wearable devices can include devices such as smartwatches, smart glasses, smart bracelets, VR (Virtual Reality) devices, AR (Augmented Reality) devices, and mixed reality devices (devices that support both virtual and augmented reality), etc.

[0036] The user end can be a client, app, or web application running on a terminal. The authentication device can be an application located on the server side, or it can be a plugin or software development kit (SDK) functional unit set in the application.

[0037] The server can be a standalone server, a server cluster, or a cloud server. A cloud server, also known as a cloud computing server or cloud host, is a hosting product within the cloud computing service system, designed to address the shortcomings of traditional physical hosts and Virtual Private Servers (VPS) services, such as high management difficulty and weak service scalability.

[0038] In one scenario, the client can send an access request for a target service to the server, which carries credential information. The server's authentication device receives and processes the request, performs authentication using the cross-service access authentication method provided in this application, and finally returns the authentication result or service response data to the client. For details, please refer to the relevant descriptions in the following embodiments.

[0039] It should be understood that Figure 1 The authentication devices and user terminals shown are merely illustrative. Depending on implementation needs, any number of authentication devices and user terminals can be included.

[0040] Figure 2 This is a flowchart of a cross-service access authentication method provided in an embodiment of this application. This method can be... Figure 1 The authentication device in the system shown is executed. For example... Figure 2 As shown, the method may include the following steps: Step 201: In response to the access request sent by the client for the target service, compare the security levels of the session origin service and the target service of the access request.

[0041] Step 203: If the security level of the target service is higher than that of the service from which the session originated, extract the upgrade credential from the access request. The upgrade credential is pre-issued by the authorized end of the target service.

[0042] Step 205: Verify the upgrade certificate.

[0043] Step 207: In response to the successful verification of the upgrade credentials, the client is authorized to access the target service. The authorization expires after the access request is processed.

[0044] As can be seen from the above process, this application compares the security levels of the source service and the target service. If the target service has a higher security level, it extracts the pre-issued upgrade credential for verification. Access is only granted after the verification is successful. This ensures that only users with valid upgrade credentials can obtain cross-level access authorization, avoiding the security problem of low-security-level session services directly accessing high-security-level services. At the same time, since the upgrade credential is pre-issued, users do not need to log in again when cross-level access is triggered, which does not interrupt the normal service process or cause the loss of the original session context. In addition, this authorization is only valid within the processing cycle of a single access request and expires after the access request is processed. This does not cause persistent privilege escalation, reduces the risk of abuse after credential leakage, and improves session security.

[0045] The following describes in detail each step of the above process and the effects that can be further produced, with reference to the embodiments.

[0046] First, the above step 201, namely "in response to an access request for the target service sent by the user terminal, the security levels of the session source service of the access request and the target service are compared", will be described in detail with reference to the embodiments.

[0047] The target service can refer to the specific service that the user requests in this request. Examples include advertising agency services, e-commerce store management services, and fund settlement services. The session origin service can refer to the service that issues persistent session credentials to the user, whose identifier is written into the persistent session credential when the user logs in. A persistent session credential is an identity credential issued and persistently stored by the system after successful user login (e.g., stored in a small text file in the browser or in server-side storage). It carries information such as the session origin service identifier and can maintain the user's login state across multiple requests; for example, it could be a session token.

[0048] Security level refers to the required security strength of a service and can be represented by a non-negative integer, with smaller values ​​indicating higher security requirements. For example, a high security level has a value of 0, and a low security level has a value of 1; the smaller the value, the higher the security requirement. Security levels can be dynamically managed through a configuration center, and adding or adjusting the level of a service takes effect immediately without modifying the code.

[0049] The following is combined with Figure 3 The process of comparing security levels is explained in detail.

[0050] An authentication interceptor is deployed on the server side. Upon receiving an access request from the client, the interceptor first parses the persistent session token carried in the request, extracts the source service identifier (sourceServiceid) from it, and obtains the target service identifier (targetServiceid) from the parameters of the access request. Then, based on the source service identifier and the target service identifier, it queries the security levels of the source service and the target service, respectively.

[0051] If the security level corresponding to the source service or target service of the session is missing (i.e., the security level does not exist), the authentication interceptor can record a "Service Level Configuration Missing" alert and reject the access request to avoid security risks caused by configuration deficiencies. If the security levels corresponding to both the source service and the target service exist, the two are compared to determine whether the current session is sufficient to directly access the target service.

[0052] In some specific examples, the comparison logic can be expressed as follows: if the security level of the target service is not higher than the security level of the session originating service, it means that the security level of the session originating service meets or exceeds the security level requirements of the target service, and access to the target service can be directly granted, proceeding to subsequent service processing; if the security level of the target service is higher than the security level of the session originating service, it means that the security level of the session originating service is insufficient to directly access the target service, and an upgrade process needs to be triggered. Taking the commercial account authentication scenario of a certain internet platform as an example, after a user logs into the advertising agency service and obtains a persistent session credential, when they request access to the e-commerce store management service, the authentication interceptor parses and finds that the security level of the e-commerce store management service is higher than the security level of the advertising agency service, that is, the security level of the session originating service is insufficient to directly access the target service.

[0053] Then, step 203, namely "extracting upgrade credentials from the access request when the security level of the target service is higher than that of the service from which the session originated", will be described in detail with reference to the embodiments.

[0054] In cases where the security level of the session source service is insufficient to directly access the target service, in order to avoid requiring users to log in again and interrupting the service process, and to prevent the security risks caused by the long-term validity of credentials after privilege escalation, this application completes authentication by issuing a pre-issued, single-use upgrade credential.

[0055] Upgrade credentials can refer to credentials pre-issued by the authorized end of the target service to complete the security level transition. The authorized end of the target service can refer to the authorized endpoint corresponding to the target high-security-level service, which, as a trusted authorizing party, is responsible for generating and issuing upgrade credentials. It should be noted that "pre-issued" in this application can broadly mean that the generation time of the upgrade credentials is earlier than the arrival time of this access request. The timing of issuance can be either that the user client actively requests the upgrade credentials from the authorized end of the target service before initiating this access request, or that the authorized end of the target service generates and distributes the upgrade credentials to the user client in batches or on demand based on service rules.

[0056] Specifically, when it is detected that a user has completed the authentication of the target service's security level, the authorization end of the target service generates an upgrade credential and returns it to the user's storage. When a subsequent access to the target service from a lower-security-level session origin service is triggered, the user can directly send the pre-stored upgrade credential along with the access request to the server for upgrade verification.

[0057] In one implementation, upgrade credentials can also be formed by updating or extending persistent session credentials. For example, after a user completes security level authentication for the target service, the authorizing end of the target service can write or associate the target service identifier with the original persistent session credentials, enabling the updated persistent session credentials to act as upgrade credentials when subsequently accessing the target service across different security levels. After the access request ends, the target service identifier in the persistent session credentials is deleted, thus invalidating the authorization.

[0058] In another implementation, the upgrade credential and the persistent session credential in the access request exist independently. The upgrade credential can be generated separately by the authorization end of the target service after the user completes authentication for the corresponding security level of the target service, and carried as an independent field in the access request. This can be transmitted through a specified field in the request parameters, request header, or request body. Since the upgrade credential does not write to, replace, or modify the persistent session credential, the two are independent in structure and lifecycle.

[0059] By setting the upgrade credential as an additional credential independent of the persistent session credential, the two can be decoupled in terms of functionality and lifecycle. The persistent session credential is used to maintain the user's basic login state throughout the entire login cycle, while the upgrade credential is only used to complete the upgrade verification of the target service in specific cross-level access scenarios. Therefore, even if the upgrade credential verification fails, expires, or is not carried, it will not cause the persistent session credential on the user's end to become invalid, thereby avoiding the impact of abnormal upgrade verification mechanism on the stability of the user's basic login state.

[0060] The following describes step 205, namely "verifying the upgrade certificate", in detail with reference to the embodiments.

[0061] like Figure 3 As shown, after determining that the security level of the target service is higher than that of the service originating the session, the upgrade credential can be extracted from the request parameters of the access request (e.g., request headers or request body). If the access request does not carry an upgrade credential, a "missing upgrade credential" marker can be recorded, and an authentication failure response of "insufficient security level" can be returned to the user. If the access request carries an upgrade credential, the upgrade credential verification process can proceed.

[0062] Specifically, the upgrade certificate can be subjected to consistency verification, and at least one of the following can be performed: integrity verification, timeliness verification, and usage count verification.

[0063] In some embodiments, when performing consistency verification on the upgrade credential, the actual usage scenario information of the access request can be parsed; the upgrade credential can be decrypted to obtain usage scenario description information; the actual usage scenario information and the usage scenario description information can be verified for consistency; and the upgrade credential verification result can be determined based on the consistency verification result.

[0064] Real-world usage scenario information is extracted from access requests and reflects the actual environment at the time the request was initiated. For example, it may include the user's identity, the source service identifier, the target service identifier, and the device identifier that sent the request. Extracting real-world usage scenario information from access requests in real time provides an unforgeable benchmark for subsequent consistency verification.

[0065] The upgrade certificate undergoes decryption, meaning the encrypted text of the upgrade certificate is decrypted to reveal the usage scenario description information bound to the certificate at the time of issuance. The decryption process can employ either symmetric or asymmetric decryption. The upgrade certificate exists in encrypted form and can only be decrypted and restored during verification, preventing tampering or snooping during transmission and storage.

[0066] The decrypted use case description information is the scenario parameter locked when the credential was issued. In one implementation, the use case description information includes user identity information, source service information, and target service information. User identity information is the user's unique identifier, such as a user ID or user account ID. Source service information can be the source service identifier recorded in the persistent session credential. Target service information can be the target service identifier for this upgrade. The use case description information binds the three dimensions of user identity, source service, and target service to ensure that the upgrade credential is applied in a specific use case. Alternatively, the use case description information includes user identity information, source service information, target service information, and device characteristic information. Device characteristic information can be the unique identifier, MAC address, or device fingerprint information of the device initiating the access request. Adding device characteristic information to the three dimensions of user identity, source service, and target service further locks the upgrade credential to a specific device. Even if the credential is stolen, it cannot be used on other devices, effectively defending against abnormal device replay attacks after credential theft and providing stronger security protection.

[0067] By binding the use cases of upgrade credentials to at least three dimensions—user, source service, and target service—or further adding the device dimension, the precise association between credentials and specific subjects, specific service paths, and specific devices is achieved. Even if the credentials are leaked, attackers will not be able to pass the verification if they lack the correct information in any of these dimensions, thereby significantly reducing the abuse of credentials and improving overall security.

[0068] Consistency verification involves comparing the actual usage scenario information with the usage scenario description information item by item. For example, it compares the user identity in the actual usage scenario information with the user identity information recorded in the usage scenario description information; it compares the source service identifier of the access request with the source service identifier recorded in the usage scenario description information; it compares the target service identifier of the actual request with the target service identifier recorded in the usage scenario description information, and so on. By comparing each item, it ensures that every binding element of the upgrade credential is consistent with the actual environment of the current access request. Any mismatch in a single element can be identified, making it impossible for attackers to reuse the upgrade credential across different users, devices, or services even if it is intercepted, effectively preventing credential theft and cross-scenario replay attacks.

[0069] When determining the verification result of an upgrade certificate based on the consistency check results, the following strategy can be adopted: if the consistency check results show that all items match successfully, the upgrade certificate is deemed to have passed verification; if any item does not match, the upgrade certificate is deemed to have failed verification. Adopting a strategy of only allowing verification to pass if all items match ensures that the certificate's usage scenario is fully locked, avoiding potential security risks arising from partial matching.

[0070] By pre-encrypting the usage scenario description information in the upgrade credential and parsing the actual usage scenario information of the access request, the verification result of the upgrade credential is determined based on the consistency comparison result between the actual usage scenario information and the usage scenario description information. This associates the verification result of the upgrade credential with the scenario consistency comparison result, ensuring that the upgrade credential can only pass verification in specific scenarios. This prevents attackers from reusing the upgrade credential in other scenarios after it is intercepted during transmission or storage, thus improving the security of cross-service access.

[0071] like Figure 3 As shown, when the upgrade credential verification fails, a "upgrade failed" marker and the reason for the failure can be recorded, and an authentication failure response can be returned to the user. When the upgrade credential verification passes, it can be confirmed that the upgrade credential can support this cross-level access, authorize access to the target service, and record a "upgrade successful" marker, and proceed to subsequent service processing.

[0072] It should be noted that the authorization expires after the access request is processed. This means that the scope of the authorization is limited to the processing cycle of the current access request. Once the current access request is processed, the authorization will automatically disappear. This mechanism ensures that each cross-level operation requires an independent upgrade certificate, avoiding the risk of a privilege escalation that becomes permanent after a single upgrade.

[0073] Furthermore, during the decryption of the upgrade certificate, in addition to obtaining the usage scenario description information, the constraint information of the upgrade certificate is also obtained. The constraint information is encrypted and stored together with the usage scenario information in the upgrade certificate, and is restored during decryption to ensure that the constraints cannot be tampered with externally and to guarantee the reliability of the constraints. The constraint information includes at least one of the following: the maximum number of times the upgrade certificate can be used and the aging time.

[0074] The maximum number of uses in the constraint information limits the total number of times an upgrade credential can be used before it expires. For example, the maximum number of uses can be set to 1, enabling a one-time use upgrade credential. By limiting the maximum number of uses of the upgrade credential, it automatically expires after reaching the limit, effectively preventing replay attacks after the credential is intercepted.

[0075] The aging time in the constraint information can be the validity period of the voucher; after this time, the voucher automatically expires. By setting the aging time, it is ensured that upgrade vouchers are no longer usable after their validity period expires, even if the voucher has not reached its maximum usage count. This prevents long-unused vouchers from being maliciously exploited, and fills the potential protection gaps in usage count limits from a time perspective.

[0076] When the constraint information includes both maximum usage count and aging time, the upgrade certificate must meet both conditions to be valid. The dual constraints of maximum usage count and aging time are complementary: the usage count limit prevents high-frequency replay, and the aging time limit prevents long-term retention and use.

[0077] Determining whether an upgrade credential meets the constraints can include: atomically checking and incrementing the upgrade credential's usage count; if the maximum usage count has been reached, the credential is deemed unsatisfactory; and checking if the current time has exceeded the aging time; if so, the credential is deemed unsatisfactory. Atomic checking and incrementing the upgrade credential's usage count can be performed using atomic operation commands provided by the database or caching system, such as using the INCR command in Redis (Remote Dictionary Server) or using row-level locks in conjunction with field auto-incrementing in the database. Using atomic operations to check and increment the usage count avoids race conditions caused by multiple requests simultaneously using the usage count verification in concurrent scenarios, ensuring the accuracy and reliability of the usage count limit in high-concurrency environments.

[0078] When constraint information verification is introduced, the implementation method for determining the upgrade certificate verification result based on the consistency verification result can be as follows: determine whether the upgrade certificate meets the constraint information; in response to the consistency verification result being that the verification passed and the upgrade certificate meets the constraint information, determine that the upgrade certificate verification passed. If the upgrade certificate does not meet the constraint information, or the consistency verification result is that the verification failed, then the upgrade certificate verification failed.

[0079] By embedding constraints such as maximum usage count and aging time into the upgrade certificate, and judging these constraints during the upgrade certificate verification process, the number of times and usage time of the upgrade certificate are limited, effectively avoiding certificate replay attacks and delay abuse. At the same time, authorization is only granted when the consistency verification passes and the upgrade certificate meets the constraint information. This, combined with the consistency verification, forms a two-layer verification gating system. Authorization is only granted when both pass, forming a multi-dimensional joint protection.

[0080] Furthermore, the validity of the upgrade path can be verified before verifying the upgrade credentials. Specifically, before verifying the upgrade credentials, it can be verified whether the upgrade path from the session's source service to the target service is a preset valid upgrade path. An upgrade path is a service pair mapping relationship from the session's source service to the target service. A set of service pair mapping relationships can be pre-defined, storing multiple allowed upgrade service pair mapping relationships, i.e., multiple valid upgrade paths. The upgrade path from the session's source service to the target service is compared with each path in the service pair mapping relationship set. If a path matching the upgrade path exists in the set, the upgrade path is determined to be a valid upgrade path. If no matching path exists in the set, the upgrade path is determined to be invalid.

[0081] If the upgrade path is legitimate, the verification of the upgrade credentials continues. If the upgrade path is illegitimate, the client's access to the target service is denied. Upon denying access, an error response indicating an illegitimate upgrade path can be returned to the client. When upgrade path verification fails, request processing is immediately terminated and a clear rejection result is returned, eliminating the need for subsequent credential decryption and verification steps, ensuring that requests using illegitimate upgrade paths are blocked immediately.

[0082] By predefining legitimate upgrade paths and performing legitimacy checks on the upgrade path from the source service to the target service before verifying upgrade credentials, it is possible to clearly define which source services are allowed to initiate security level jumps to which target services. Access requests that do not belong to the predefined legitimate upgrade paths can be directly rejected before credential decryption and verification, thus avoiding unnecessary processing of upgrade credentials carried by illegal paths and reducing ineffective computational overhead. Simultaneously, it also prevents arbitrary low-security-level service sessions from impersonating legitimate requests to initiate upgrades to unauthorized high-security-level services, forming an independent security defense line outside of credential verification and enhancing the protection capabilities for service access.

[0083] The verification mechanism for upgrade credentials has been explained above. The implementation mechanism for authorization invalidation will be described below. Specifically, when an authorized client accesses the target service, the authorization becomes invalid after the access request is processed. This includes: writing an authorization tag corresponding to the target service into the processing context of the access request; wherein, the processing context is cleared after the access request is processed to invalidate the authorization tag.

[0084] The process of authorizing a client to access a target service, and having that authorization expire after the access request is processed, can be achieved by writing an authorization flag corresponding to the target service into the access request's processing context. The processing context refers to a temporary data storage space existing within a single access request processing cycle, used to transmit information between the core authentication layer and the service logic layer. The authorization flag can be the target service identifier, or a permission code, flag, etc., set for the target service. When processing an access request, this authorization flag can be read from the processing context, meaning the access request is processed with the permissions of the target service.

[0085] The processing context is cleared after the access request is processed, thus invalidating the authorization token. In other words, the lifecycle of the processing context is synchronized with the processing cycle of the access request; once the request is processed, the processing context is cleared, and the authorization token written within it becomes invalid. The clearing of the processing context is synchronized with the completion of request processing. The invalidation of the authorization token does not rely on additional timers or recycling mechanisms but is driven by the natural end of the request's lifecycle. This mechanism ensures that authorization is not leaked to subsequent requests, and the session credentials for the next request will still be the original session source service identifier, with permissions automatically reverting.

[0086] It's important to note that the authorization token is written to the processing context and does not write to or modify the persistent session credentials on the client side. These persistent session credentials are persistently stored session tokens. The authorization token exists only in the request-level processing context, not in the persistent session credentials, ensuring that cross-level access does not change the client's session state. Subsequent requests from the client after the initial request are completed still use the original session's origin service for authentication, thus preventing persistent privilege escalation.

[0087] By visualizing the authorization action as writing a marker in the processing context that is automatically cleared when the request ends, rather than writing any permission changes to persistent storage, the effect of authorization escalation is limited to the current access request. Once the request is processed, the authorization disappears immediately, eliminating the possibility of permission leakage. This achieves the principle of least privilege and request-level isolation, avoiding the persistent privilege escalation problem caused by permissions being permanently retained in the user session after an upgrade.

[0088] Furthermore, the processing context is the thread-level context corresponding to the access request. Thread-level contexts can be implemented using Thread Local Storage (TLS). TLS ensures that each thread has its own independent copy of the context. When multiple threads concurrently process multiple access requests, the authorization tags corresponding to different access requests do not interfere with each other, avoiding the risk of unauthorized access caused by authorization tag crosstalk in concurrent scenarios. After a thread finishes execution, its local storage space is automatically cleared along with the release of the thread context, requiring no additional cleanup logic.

[0089] By using thread-level context to carry authorization tags, and leveraging the inherent data isolation characteristics of threads, it ensures that the authorization information for each request is unique and not interfered with by other concurrent requests. This eliminates the need to introduce additional distributed storage or complex isolation mechanisms, thus guaranteeing the isolation effect of request-level authorization in a simple and high-performance manner.

[0090] Besides writing the authorization flag corresponding to the target service into the processing context of the access request as described above, other implementation methods can also be used. For example, the authorization flag can be written into the scope cache of the access request. This scope cache is only valid during the processing of the access request and is automatically destroyed after the access request is completed. Another example is carrying a temporary authorization flag in the request header of the access request for the target service, and so on.

[0091] The following is combined with Figure 4 This section explains the interaction process at each level within the server during the authentication process.

[0092] This server-side hierarchical interaction structure is used to handle cross-level access requests initiated by the client within a unified account authentication system. The server-side mainly includes a request entry layer, a core authentication layer, an upgrade credential generation layer, a data support layer, and a service logic layer.

[0093] The request entry layer is used to receive access requests (such as Hypertext Transfer Protocol requests) sent by the client. The request entry layer can extract the persistent session credential from the access request and pass it to the core authentication layer for parsing to obtain information such as the session origin service identifier.

[0094] The core authentication layer includes a session credential parsing module, a security level comparison and routing module, an upgrade credential verification module, and a context-based authorization processing module. The session credential parsing module parses persistent session credentials to obtain user identity information, session origin service information, and other content. The security level comparison and routing module queries the security levels of the source and target services based on the session origin service identifier and compares whether the security level of the target service is higher than that of the source service.

[0095] If the security level of the target service is not higher than that of the session origin service, the core authentication layer can directly allow the access request to enter the service logic layer. If the security level of the target service is higher than that of the session origin service, the core authentication layer triggers an upgrade verification process, extracts upgrade credentials from the access request, and the upgrade credential verification module verifies the upgrade credential.

[0096] The upgrade credential generation layer can be set up on the authorization side of the target service, including an upgrade credential generation module. This module generates upgrade credentials and returns them to the user after the user completes authentication for the security level corresponding to the target service. The upgrade credential can carry user identity information, session source service information, target service information, device characteristic information, maximum number of uses, validity period, and other constraint information.

[0097] The data support layer provides the necessary data support to the core authentication layer. It provides services such as service security level registration, upgrade path mapping configuration, and upgrade credential usage counting. Specifically, service security level registration maintains the correspondence between services and security levels; upgrade path mapping configuration maintains legitimate upgrade paths that allow cross-level access; and upgrade credential usage counting records the number of times upgrade credentials have been used to support verification of one-time or limited-use applications.

[0098] When verifying upgrade credentials, the upgrade credential verification module first queries the upgrade path configuration based on the session source service identifier and the target service identifier to determine if the current upgrade path is valid. If the upgrade path is valid, it further verifies the consistency between the use case of the upgrade credential and the actual use case corresponding to the access request. If the verification passes, it is determined that the current access request has the authorization conditions for temporary access to the target service.

[0099] The processing context authorization module writes the authorization token corresponding to the target service into the processing context of the current access request after the upgrade credential verification is successful. The target service interface in the service logic layer can read the authorization token from this processing context and process the current access request based on the authorization token.

[0100] After an access request is processed, the processing context is cleared when the request's lifecycle ends, and the authorization tokens written in it become invalid. Therefore, the server can implement single or limited-number cross-level temporary authorizations for a target service without modifying the client's persistent session credentials, avoiding the risk of permanent privilege escalation caused by a single upgrade taking effect for an extended period.

[0101] The following is combined with Figure 5 The interaction sequence of the authentication method for cross-service access in this application is described in detail.

[0102] This interaction process involves authentication interceptors, upgrade path configuration, upgrade credential verifiers, usage counters, processing contexts, and service interfaces.

[0103] The authentication interceptor first checks if the security level of the service originating the session is lower than that of the target service. If it is lower, the security level of the service originating the session is deemed insufficient to directly access the target service, and an upgrade is required. In the case of an upgrade, the authentication interceptor queries the upgrade path configuration based on the session origin service identifier and the target service identifier to determine if the current upgrade path is a preset, valid upgrade path.

[0104] If the upgrade path is invalid, the request is rejected and an "invalid upgrade path" marker is recorded; if the upgrade path is valid, the upgrade credential is extracted from the access request and submitted to the upgrade credential verifier along with the current processing context information.

[0105] The upgrade credential verifier performs verification on the upgrade credential, including: whether the user identity information in the credential matches the user identity information of the current request; whether the session source service identifier in the credential matches the current session source service; whether the target service identifier in the credential matches the current target service; whether the device identifier in the credential matches the current requesting device; and whether the current time has not exceeded the credential's aging time. Compared to verifying only user identity or service information, multi-dimensional verification allows for precise targeting of upgrade credential use cases. Even if an attacker obtains any single element, the credential cannot be misused.

[0106] If the verification fails, the reason for the failure is recorded and the request is rejected; if the verification passes, the usage count verification proceeds. A usage counter records the number of times the upgrade credential has been successfully used, and a judgment is made based on the maximum usage count carried in the upgrade credential. Specifically, the usage counter atomically checks whether the current usage count of the upgrade credential has reached the maximum usage count, and returns the count verification result; if the usage count has reached the limit, a verification failure result is returned, and the authentication interceptor rejects this request; if the usage count has not reached the limit, the usage count of the upgrade credential is incremented in the same atomic operation, and a count verification pass result is returned.

[0107] Subsequently, after the authentication interceptor detects successful verification, it writes an authorization token into the processing context of the access request and forwards the access request to the target service interface. The service interface reads the authorization token from the processing context and executes the service processing of the target service based on the authorization token. After the service processing is completed, it returns the service processing result. Finally, the request ends and a "upgrade successful" marker is recorded. The processing context is destroyed, and the authorization token corresponding to the target service identifier disappears. The user's persistent session credentials still retain the original session source service identifier, and the permissions are automatically reverted. Since the service code directly reads the authorization token from the context, it does not need to distinguish whether an upgrade has been performed, so it is unaware of this at the service logic layer.

[0108] This application achieves differentiated security policy management for multiple services within a unified authentication framework, eliminating the need to deploy separate authentication systems for services with different security levels. This reduces infrastructure costs and avoids inconsistencies between systems. Furthermore, by upgrading credentials, users with lower security level sessions can securely complete cross-security level access without interrupting their current workflow and re-login, as their persistent session credentials remain unchanged. This effectively improves the completion rate of cross-security level operations and enhances user experience. Simultaneously, the upgraded credentials are verified across multiple dimensions, including user identity, source service, target service, device identifier, and usage count. Even if credentials are intercepted during transmission or storage, attackers cannot reuse them across different users, devices, or services, effectively preventing credential theft and replay attacks. Moreover, this application employs a request context-level write authorization mechanism, writing the authorization flag to the thread-local context rather than the persistent session. The authorization effect is automatically destroyed at the end of the request's lifecycle, avoiding the security risks of persistent privilege escalation at the mechanism level. Adhering to the principle of least privilege, this ensures precise, temporary, and controllable privilege escalation while guaranteeing access control for high-security level services.

[0109] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0110] Figure 6 A schematic block diagram of an authentication device for cross-service access provided in embodiments of this application, such as... Figure 6 As shown, the authentication device 600 includes: a level comparison unit 601, a credential retrieval unit 602, a credential verification unit 603, and a service authorization unit 604. The main functions of each component include: The security level comparison unit 601 is configured to compare the security levels of the session source service and the target service in response to an access request sent by the client for the target service. The credential extraction unit 602 is configured to extract an upgrade credential from the access request when the security level of the target service is higher than that of the session origin service. The upgrade credential is pre-issued by the authorized end of the target service. The voucher verification unit 603 is configured to verify the upgrade voucher; Service authorization unit 604 is configured to authorize the client to access the target service in response to successful upgrade credential verification, and the authorization expires after the access request is processed.

[0111] As one possible implementation method, the credential verification unit 603 can be configured to: parse the actual usage scenario information of the access request; decrypt the upgrade credential to obtain the usage scenario description information; perform consistency verification between the actual usage scenario information and the usage scenario description information; and determine the upgrade credential verification result based on the consistency verification result.

[0112] One possible approach is to include user identity information, source service information, and target service information in the usage scenario description information; or, the usage scenario description information may include user identity information, source service information, target service information, and device characteristic information.

[0113] As one possible approach, the upgrade certificate is decrypted to obtain constraint information of the upgrade certificate, which includes at least one of the maximum number of times the upgrade certificate can be used and the aging time. The voucher verification unit 603 can be configured to: determine whether the upgrade voucher meets the constraint information; and, in response to the consistency verification result being that the verification is passed and the upgrade voucher meets the constraint information, the upgrade voucher verification is passed.

[0114] Furthermore, the device also includes a path verification unit, configured to verify whether the upgrade path from the session source service to the target service is a preset valid upgrade path before verifying the upgrade credentials; if so, the verification of the upgrade credentials continues; otherwise, the user's access to the target service is denied.

[0115] As one possible implementation, the service authorization unit 604 can be configured to: write an authorization tag corresponding to the target service into the processing context of the access request; wherein the processing context is cleared after the access request is processed to invalidate the authorization tag.

[0116] As one possible approach, the processing context is the thread-level context corresponding to the access request; As one possible approach, upgrade credentials and persistent session credentials in access requests exist independently of each other.

[0117] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for system or device embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. The system and device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0118] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0119] In addition, embodiments of this application also provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of any of the methods in the foregoing method embodiments.

[0120] And an electronic device, comprising: One or more processors; and A memory associated with one or more processors, the memory being used to store program instructions that, when read and executed by one or more processors, perform the steps of any of the methods in the foregoing method embodiments.

[0121] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the methods in the foregoing method embodiments.

[0122] in, Figure 7 An exemplary architecture of an electronic device is shown, which may include a processor 710, a video display adapter 711, a disk drive 712, an input / output interface 713, a network interface 714, and a memory 720. The processor 710, video display adapter 711, disk drive 712, input / output interface 713, network interface 714, and memory 720 can communicate with each other via a communication bus 730.

[0123] The processor 710 can be implemented using a general-purpose CPU, microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits to execute relevant programs and implement the technical solution provided in this application.

[0124] The memory 720 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 720 can store the operating system 721 for controlling the operation of the electronic device 700, and the basic input / output system (BIOS) 722 for controlling the low-level operations of the electronic device 700. Additionally, it can store a web browser 723, a data storage management system 724, and an authentication device 600, etc. The aforementioned authentication device 600 can be the application program that specifically implements the aforementioned steps in this embodiment. In summary, when the technical solution provided in this application is implemented through software or firmware, the relevant program code is stored in the memory 720 and is called and executed by the processor 710.

[0125] Input / output interface 713 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components in the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touch screens, microphones, various sensors, etc., and output devices may include displays, speakers, vibrators, indicator lights, etc.

[0126] Network interface 714 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0127] Bus 730 includes a pathway for transmitting information between various components of the device, such as processor 710, video display adapter 711, disk drive 712, input / output interface 713, network interface 714, and memory 720.

[0128] It should be noted that although the above-described device only shows the processor 710, video display adapter 711, disk drive 712, input / output interface 713, network interface 714, memory 720, bus 730, etc., in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the solution of this application, and does not necessarily include all the components shown in the figures.

[0129] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer program product. This computer program product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of various embodiments or some parts of the embodiments of this application.

[0130] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for authentication across services, characterized in that, The method includes: In response to an access request for a target service sent by a user, the security levels of the session origin service of the access request and the target service are compared. If the security level of the target service is higher than the security level of the session origin service, an upgrade credential is extracted from the access request. The upgrade credential is pre-issued by the authorization end of the target service. Verify the upgrade certificate; Upon successful verification of the upgrade credential, the client is authorized to access the target service, and the authorization expires after the access request is processed.

2. The method according to claim 1, characterized in that, The verification of the upgrade certificate includes: Parse the actual use case information of the access request; The upgrade certificate is decrypted to obtain usage scenario description information; Perform a consistency check between the actual usage scenario information and the usage scenario description information; Based on the consistency verification result, the upgrade credential verification result is determined.

3. The method according to claim 2, characterized in that, The usage scenario description information includes user identity information, source service information, and target service information; or, The usage scenario description information includes user identity information, source service information, target service information, and device characteristic information.

4. The method according to claim 2, characterized in that, The upgrade certificate is decrypted to obtain constraint information of the upgrade certificate, which includes at least one of the maximum number of times the upgrade certificate can be used and the aging time. The step of determining the upgrade credential verification result based on the consistency verification result includes: Determine whether the upgrade certificate meets the constraint conditions. In response to the consistency verification result being successful and the upgrade certificate satisfying the constraint conditions, it is determined that the upgrade certificate has passed the verification.

5. The method according to claim 1, characterized in that, Before verifying the upgrade certificate, the method further includes: Verify whether the upgrade path from the session source service to the target service is a preset valid upgrade path. If it is, continue to verify the upgrade credentials; otherwise, deny the user's access to the target service.

6. The method according to any one of claims 1 to 5, characterized in that, The authorization granted to the user client to access the target service, and the authorization becoming invalid after the access request is processed, includes: An authorization tag corresponding to the target service is written into the processing context of the access request; wherein the processing context is cleared after the access request is processed to invalidate the authorization tag.

7. The method according to claim 6, characterized in that, The processing context is the thread-level context corresponding to the access request.

8. The method according to any one of claims 1 to 5, characterized in that, The upgrade credential exists independently of the persistent session credential in the access request.

9. An authentication device for cross-service access, characterized in that, The device includes: The security level comparison unit is configured to compare the security level of the session origin service of the access request with that of the target service in response to an access request sent by the client for a target service. The credential extraction unit is configured to extract an upgrade credential from the access request when the security level of the target service is higher than the security level of the session origin service, wherein the upgrade credential is pre-issued by the authorization end of the target service; The credential verification unit is configured to verify the upgrade credential; The service authorization unit is configured to authorize the user to access the target service in response to the successful verification of the upgrade credential, and the authorization expires after the access request is processed.

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

11. An electronic device, characterized in that, include: One or more processors; as well as A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method according to any one of claims 1 to 8.

12. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the steps of the method according to any one of claims 1 to 8.

Images