Embedded operation and maintenance platform login method, device and equipment based on double-token bridging

Abstract

The application discloses a double-token bridging-based embedded operation and maintenance platform login method, device and equipment, and belongs to the technical field of application security. The method comprises the following steps: receiving a token exchange request sent by an embedded web application, wherein the token exchange request comprises a user identity token issued by a client side; performing identity verification on the user identity token to obtain a standardized user identity certificate; creating a platform token according to the standardized user identity certificate; issuing the platform token to the embedded web application; receiving a business access request sent by the embedded web application and carrying the platform token, and completing identity authentication based on the platform token. The technical scheme of the application only needs to complete cross-system identity trusted conversion through single-interface token exchange, and simultaneously completes closed-loop authentication through the platform token, so that accurate connection between the client identity and the platform permission is realized, the defects of identity context fracture and permission fault are solved, and the embedded H5 operation and maintenance scene is realized to be non-intrusive, safe and trusted in unified login access with low access cost.

Description

Technical Field

[0001] This application relates to the field of application security technology, and in particular to an embedded operation and maintenance platform login method, apparatus and device based on dual-token bridging. Background Technology

[0002] In the context of enterprise digital operations and platform integration, customers generally need to integrate third-party operations platforms into their own apps (mobile applications) as embedded H5 (HTML5 Page) applications to achieve a unified entry point, seamless login, and minimal modification for integration. In this scenario, the customer's app already has a mature user login mechanism, and it is necessary to securely, seamlessly, and lightweightly transfer user identity to the operations platform, and quickly establish an identity authentication and access control system on the platform side to ensure normal business access.

[0003] Existing technologies typically employ three methods for cross-system identity access: key signature authentication, standard SSO (Single Sign-On), and independent account two-factor authentication. Key signature schemes rely on fixed keys and parameters for signature verification to achieve inter-system calls; SSO schemes achieve cross-domain authentication based on authentication protocols; and independent account schemes require users to re-register and log in to the operations and maintenance platform account within the H5 interface. All of these solutions require significant modifications and development by customers or platform integration, and may suffer from issues such as fragmented user experience, missing permission context, inconsistent token lifecycles, and unbalanced security mechanisms. Existing technologies cannot achieve lightweight, short-cycle, secure, stable, and permission-executable H5 embedded login while reusing the customer's existing login state, making it difficult to meet the actual needs of enterprises for rapid integration, seamless access, fine-grained permission control, and secure data transmission. Summary of the Invention

[0004] Existing technologies have limitations in meeting the practical needs of enterprises for rapid integration, seamless access, fine-grained access control, and secure data transmission. To address these issues, this application provides an embedded operations and maintenance platform login method, apparatus, and device based on dual-token bridging.

[0005] To achieve the above objectives, the first technical solution adopted in this application is: an embedded operation and maintenance platform login method based on dual-token bridging, comprising: receiving a token exchange request sent by an embedded web application, wherein the token exchange request includes a user identity token issued by the client side; verifying the user identity token to obtain a standardized user identity credential; creating a platform token based on the standardized user identity credential; issuing the platform token to the embedded web application; receiving a business access request sent by the embedded web application carrying the platform token, and completing identity authentication based on the platform token.

[0006] The second technical solution adopted in this application is: an embedded operation and maintenance platform login device based on dual-token bridging, comprising: a token exchange request receiving module, which receives a token exchange request sent by an embedded web application, wherein the token exchange request includes a user identity token issued by the client side; an identity verification module, which verifies the user identity token to obtain a standardized user identity credential; a platform token creation module, which creates a platform token based on the standardized user identity credential; a platform token distribution module, which distributes the platform token to the embedded web application; and a business access request receiving module, which receives a business access request sent by the embedded web application carrying the platform token and completes identity authentication based on the platform token.

[0007] The third technical solution adopted in this application is: a computer device, including a memory, a processor, and a computer program stored in the memory, characterized in that the processor executes the computer program to implement the embedded operation and maintenance platform login method based on dual-token bridging in Solution 1.

[0008] The beneficial effects of the technical solution presented in this application are as follows: When applied, this technical solution constructs a unified login authentication link for an embedded operations and maintenance platform based on dual-token bridging, forming a lightweight and trusted access system of "customer-side identity credential input—platform unified verification—platform token generation and distribution—embedded H5 business closed-loop access". This solution abandons heavy and redundant mechanisms such as authorization code processes and callback governance, eliminating the need for complex key signature logic on the client side, and completing cross-system identity trusted conversion solely through single-interface token exchange. Simultaneously, through platform token closed-loop authentication, it achieves precise connection between customer identity and platform permissions, solving the defects of identity context breakage and permission gaps in existing lightweight access solutions. Under the premise of low access cost, it achieves seamless, secure, and trusted unified login access in embedded H5 operations and maintenance scenarios. Attached Figure Description

[0009] 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, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This is a flowchart illustrating a specific implementation example of an embedded operation and maintenance platform login method based on dual-token bridging according to this application; Figure 2 This is a structural diagram of a specific embodiment of the verification orchestrator in the embedded operation and maintenance platform login method based on dual-token bridging of this application; Figure 3This is a flowchart of a specific embodiment of the identity mapping in an embedded operation and maintenance platform login method based on dual-token bridging in this application; Figure 4 This is a flowchart of a specific embodiment of token updating in an embedded operation and maintenance platform login method based on dual-token bridging according to this application; Figure 5 This is a flowchart of a specific embodiment of a secure transmission method for an embedded operation and maintenance platform login based on dual-token bridging, as described in this application; Figure 6 This is a logical block diagram of a specific embodiment of an embedded operation and maintenance platform login method based on dual-token bridging according to this application; Figure 7 This is a schematic diagram of a specific implementation of an embedded operation and maintenance platform login device based on dual-token bridging according to this application.

[0011] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0012] The preferred embodiments of this application will now be described in detail with reference to the accompanying drawings, so that the advantages and features of this application can be more easily understood by those skilled in the art, thereby providing a clearer and more definite definition of the scope of protection of this application.

[0013] 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..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0014] The technical solution of this application and how it solves the above-mentioned technical problems will be described in detail below with specific embodiments. The specific embodiments described below can be combined with each other to form new embodiments. The same or similar ideas or processes described in one embodiment may not be repeated in other embodiments.

[0015] like Figure 1 As shown, in a specific embodiment of an embedded operations and maintenance platform login method based on dual-token bridging in this application, the method includes: step S101, receiving a token exchange request sent by an embedded web application. The token exchange request may include a user identity token issued by the client side.

[0016] In one specific embodiment of this application, the embedded web application can be an H5 web application that runs within the customer's own APP and is loaded and used in the APP environment.

[0017] In one specific embodiment of this application, the token exchange request may be a request initiated by an embedded web application to the operation and maintenance platform, carrying an identity token issued by the client side, requesting the conversion of external identity credentials into an access token recognized by the platform.

[0018] In one specific embodiment of this application, the user identity token can be a customer token, that is, a user identity credential issued by the customer's own login system, indicating that the user has completed authentication on the customer side.

[0019] like Figure 1 As shown, in a specific embodiment of an embedded operation and maintenance platform login method based on dual-token bridging in this application, the embedded operation and maintenance platform login method based on dual-token bridging includes: step S102, verifying the user identity token to obtain standardized user identity credentials.

[0020] In one specific embodiment of this application, such as Figure 2 As shown, verifying the user identity token to obtain standardized user identity credentials can include: using a verification orchestrator to perform unified identity verification processing on the received user identity token according to the adaptation configuration corresponding to the configuration template pre-stored in the database, thereby obtaining standardized user identity credentials. The standardized user identity credentials can be identity data that conforms to the platform's processing specifications after unified mapping verification and format standardization, including customer identifier, application identifier, user identifier, and fixed access entry fields, used for subsequent identity mapping and token generation.

[0021] As an example, each customer can have its own independent adaptation configuration. The adaptation configuration can be a validation rule configuration stored in the form of a JSON template. The adaptation configuration can include the URL (UniformResource Locator, network resource access address) of the customer's validation interface, the request method, the request header pass-through rules, and the response field mapping rules.

[0022] As an example, the configuration activation mechanism can adopt a strategy of "real-time activation + local caching + timed refresh": after the configuration is changed, each node is immediately refreshed through message notification, and the latest configuration is pulled from the database every 60 seconds as a backup guarantee.

[0023] As an example, format validation, such as JSON Schema validation, and connectivity pre-checks can be performed before configuration is entered into the database, such as calling the client validation interface to perform health checks, to prevent illegal configurations from causing runtime validation failures.

[0024] As an example, it supports versioned configuration management, allowing each configuration modification to generate a new version while retaining historical versions. When a customer modifies the validation interface rules, the new configuration can be validated first on a canary rollout, for example, with 10% of requests, and then switched to a full rollout after successful validation.

[0025] As an example, the old and new configurations can coexist during the gray-scale release. If the gray-scale traffic verification fails, it can automatically revert to the old version configuration to ensure that online business is not affected.

[0026] As an example, configuration changes for different customers are isolated from each other. For instance, a configuration change for customer A will not affect the verification process for customer B.

[0027] As an example, a verification orchestrator can be a scalable verification process component implemented on the platform side.

[0028] As an example, the verification orchestrator can support unified access from two verification sources: the customer's existing interface mode, such as reusing existing interfaces like "current user information" to complete token verification, and the platform's standard interface mode, such as implementing a dedicated verification interface according to the platform's agreement.

[0029] As an example, the validation orchestrator, through adaptation configurations such as URL, method, request header pass-through rules, and response field mapping rules, abstracts different client interfaces into a unified output object, such as externalUserId, externalUserName, and status. This achieves "heterogeneous client interface input, platform standard identity object output".

[0030] As an example, the validation orchestration module can read the interface type identifier from the configuration center, such as the interfaceType field, which can be either EXISTING or STANDARD, and load the corresponding adapter logic. In EXISTING mode, it loads the "existing interface adapter," calls the customer's existing interface according to the URL, request method, and header pass-through rules configured by the customer, and parses the response.

[0031] As an example, loading the "Standard Interface Adapter" in STANDARD mode allows the client to call the standard validation interface according to the platform's unified request / response format.

[0032] As an example, adapter loading can adopt the strategy pattern. Adding a new verification pattern only requires implementing the corresponding adapter and registering it with the orchestrator, without modifying the core verification process.

[0033] like Figure 1 As shown, in a specific embodiment of an embedded operation and maintenance platform login method based on dual-token bridging in this application, the embedded operation and maintenance platform login method based on dual-token bridging includes: step S103, creating a platform token based on standardized user identity credentials.

[0034] In one specific embodiment of this application, such as Figure 3 As shown, standardized user identity credentials may include customer identifier, customer application identifier, external user identifier, and access point.

[0035] As an example, a customer identifier can be a unique code for a customer on the platform side, such as a customerCode. This code is assigned by the platform when a customer registers and is used to locate their tenant. It is globally unique, stored in the customer's registry, and passed in as a request parameter or header with the token exchange request.

[0036] As an example, the customer application identifier can be the AppKey of the H5 application, generated and distributed by the platform when the application is created. It is used in conjunction with the customer identifier to locate specific tenants and applications. It ensures global uniqueness and is also passed in with requests or carried as a parameter when loaded through the H5 page.

[0037] As an example, the external user identifier can be a unique account number within the customer's system. The access point can be the channel information through which the user enters the operations and maintenance platform H5.

[0038] As an example, a platform token can be a platform token, which is an access credential issued by the operations and maintenance platform and includes platform-side authorization context such as tenants, applications, and users.

[0039] In one specific embodiment of this application, creating a platform token based on standardized user identity credentials may include: locating a tenant identifier based on a customer identifier and a customer application identifier.

[0040] As an example, the customer identifier and the customer application identifier are combined as a unique key for tenant location. For example, customerCode + AppKey locates tenantId + appId, ensuring the accuracy of the mapping.

[0041] In one specific embodiment of this application, creating a platform token based on standardized user identity credentials may include: mapping a platform user identifier to an external user identifier.

[0042] As an example, based on the customer-side user ID, it can be matched and converted into a unique user ID within the platform system.

[0043] In one specific embodiment of this application, creating a platform token based on standardized user identity credentials may include: determining the platform application identifier and available functional domains based on the access entry point.

[0044] As an example, based on access channel information, the corresponding platform application identifier is matched from a pre-defined data table linking channels and applications / functional permissions to define the available functional domains. The pre-defined data table linking channels and applications / functional permissions can be a pre-built mapping data table that records the binding relationship between access entry points, platform application identifiers, and functional permissions.

[0045] As an example, the platform application identifier can be a unique number that distinguishes various access applications within the operation and maintenance platform.

[0046] As an example, the available functional domains can be the set of platform functions that a user can use normally under their current permissions.

[0047] In one specific embodiment of this application, creating a platform token based on standardized user identity credentials may include: generating a permission scope based on available functional domains.

[0048] As an example, based on the set of available functions, the boundaries of a user's corresponding operation permissions can be defined as the scope of permissions.

[0049] In one specific embodiment of this application, creating a platform token based on standardized user identity credentials may include: generating a minimum available authorization context based on tenant identifier, platform user identifier, platform application identifier, and permission scope.

[0050] As an example, the minimum available authorization context can be an authorization object that contains only the minimum permission information necessary for the current user to complete the business operation.

[0051] As an example, tenant identifiers, platform user identifiers, platform application identifiers, and permission scopes can be encapsulated according to a unified platform data structure to form a minimum available authorization context.

[0052] In one specific embodiment of this application, creating a platform token based on standardized user identity credentials may include: creating a platform token based on the minimum available authorization context.

[0053] As an example, information such as tenant identifier, platform user identifier, platform application identifier, and permission scope in the minimum available authorization context can be supplemented with token metadata, and then signed and encrypted using the platform key to generate a platform access token that conforms to the platform specifications.

[0054] In one specific embodiment of this application, generating a permission scope based on available functional domains may include: determining whether a tenant corresponding to a tenant identifier is shared by multiple customers.

[0055] As an example, you can check the tenant binding relationship to determine whether the tenant identifier is associated with multiple customers.

[0056] Therefore, this mechanism ensures that the platform token is not only "authentication-enabled" but also "authorization-enabled," avoiding the gap where login is successful but business interfaces lack permissions. Unlike traditional simplified SSO solutions that only transmit authentication results without establishing an authorization context, this solution completes the identity mapping loop simultaneously during the token exchange process, fundamentally solving the permission gap problem.

[0057] In one specific embodiment of this application, generating a permission scope based on available functional domains may include: determining the set of roles and data access scope corresponding to a customer identifier when it is determined that a tenant is shared by multiple customers.

[0058] As an example, different customers among multiple customers can be assigned independent sets of preset roles and configured with corresponding preset data access ranges. For instance, customer A may only have the "alarm viewing" role, while customer B may have the "alarm viewing + work order processing" role.

[0059] As an example, when multiple customers share the same tenant or application, the mapping rules add role-based restrictions.

[0060] As an example, when multiple customers share a space, the corresponding role permissions can be matched based on the customer identifier to limit the data boundaries that can be accessed.

[0061] In one specific embodiment of this application, generating a permission scope based on available functional domains may include: determining the set of roles corresponding to the tenant when it is determined that the tenant is used by only a single customer, and determining all of the tenant's business data as the data access scope.

[0062] As an example, when a tenant belongs to a single customer, corresponding role permissions can be matched to determine the scope of data access for all of the tenant's business data.

[0063] In one specific embodiment of this application, generating a permission scope based on available functional domains may include: generating a permission scope based on available functional domains, a determined set of roles, and a determined data access scope.

[0064] As an example, functional permissions, role permissions, and data access boundaries are integrated to form the final permission scope.

[0065] Therefore, for multi-customer shared tenant / application scenarios, when multiple customers share the same tenant or application, the mapping rules add role-based restrictions. Each customer is assigned an independent set of roles under the shared tenant, and the scope field in the generated minimum authorization context is strictly limited to the functional permissions corresponding to that customer's role. At the same time, data scope isolation is added at the interface access layer. For example, customer A can only view alarms of its own associated devices and cannot view alarms of other customers, thereby avoiding the risk of permission overreach.

[0066] In one specific embodiment of this application, such as Figure 5 As shown, both the user identity token and the platform token can be transmitted encrypted via HTTPS (HyperText Transfer Protocol Secure), and both the user identity token and the platform token can be transmitted within the HTTP request header. Furthermore, the user identity token can be a single-use, time-limited token.

[0067] In one specific embodiment of this application, such as Figure 5 As shown, multiple layers of security control can be introduced at the transport and storage layers: As an example, end-to-end HTTPS encryption is implemented, meaning that the token exchange interface and all subsequent business requests are subject to HTTPS to prevent eavesdropping at the transport layer.

[0068] As an example, the request header priority delivery strategy means that both user identity tokens and platform tokens can be delivered first through the HTTP request header (Authorization header) rather than URL parameters or the request body, reducing the risk of logs being written to disk and browser history being leaked.

[0069] As an example, the URL parameter short-term token mechanism is used when the client application passes the user identity token to the H5 via URL parameters. The short-term token strategy is valid for 5 minutes and can only be used once. A 10-second buffer period is reserved when the token is generated to ensure that it will not expire prematurely in the case of network latency.

[0070] As an example, the multi-factor risk control and anomaly detection mechanism includes: frequency limiting—rate limiting is triggered when a single IP address makes more than 10 token exchange requests within one minute; device fingerprint verification—exchange requests initiated by the same user's identity token undergo device fingerprint consistency checks, and exchange is rejected and an alarm is triggered if they do not match; IP location verification—after the initial exchange IP location record, changes across provinces / countries trigger secondary confirmation or blocking; and forged token blocking—if verification fails five times consecutively, the user is automatically added to the blacklist for 30 minutes.

[0071] As an example, the minimum field return means that the token exchange interface response only returns necessary fields such as platform token, tenant identifier, application identifier, user identifier, and expiration time, following the principle of minimum disclosure.

[0072] like Figure 1 As shown, in a specific embodiment of an embedded operation and maintenance platform login method based on dual-token bridging in this application, the embedded operation and maintenance platform login method based on dual-token bridging includes: step S104, issuing the platform token to the embedded web application.

[0073] In one specific embodiment of this application, such as Figure 4 As shown, platform tokens can be set with a remaining validity period.

[0074] As an example, the remaining validity period can be the time during which the platform token can be used as a valid token.

[0075] As an example, the remaining validity period can be configured differently based on the customer / application dimension.

[0076] As an example, the default value for the remaining validity period is 60 seconds. The configuration range is from 30 seconds to 300 seconds, and can be adjusted at the client or application level through the platform management interface.

[0077] As an example, for customers with high-frequency operations, such as real-time monitoring scenarios, a threshold of 120 seconds can be set to ensure a sufficient renewal window.

[0078] As an example, for low-frequency scenarios, the default 60 seconds can be used.

[0079] As an example, the H5 client uses a timer to start a countdown after each acquisition of a platform token, and automatically triggers a token exchange request when the remaining validity period is lower than the threshold.

[0080] In one specific embodiment of this application, such as Figure 4 As shown, when the remaining validity period is less than the preset validity threshold, the embedded web application obtains a new platform token in the following way: it sends a new token exchange request to the platform for the first time.

[0081] As an example, when the remaining validity period is less than the preset validity threshold, that is, when it is about to expire, the embedded web application can send a new token exchange request to the platform for the first time.

[0082] In one specific embodiment of this application, such as Figure 4 As shown, when the remaining validity period is less than the preset validity threshold, the embedded web application obtains a new platform token in the following way: if the exchange is successful, it obtains a new platform token and sends a business access request to the platform with the obtained new platform token.

[0083] As an example, after receiving a new platform token from the platform backend, the system sends a business access request to the platform with the acquired new platform token.

[0084] In one specific embodiment of this application, such as Figure 4 As shown, the embedded web application also obtains new platform tokens in the following way: if the exchange fails, it sends a second request to the platform to exchange a new token after a preset interval.

[0085] As an example, when an automatic renewal request fails, such as due to network timeout or temporary unavailability of the customer verification interface, a tiered degradation strategy is executed—Level 1: Retry immediately once, for example, after a 2-second interval, to cover scenarios with momentary network jitter.

[0086] In one specific embodiment of this application, such as Figure 4 As shown, the embedded web application also obtains the new platform token in the following ways: if the second exchange is successful, it obtains the new platform token and sends a business access request to the platform with the obtained new platform token.

[0087] As an example, if the second exchange is successful, the system receives a new platform token from the platform backend and uses the acquired new platform token to initiate a business access request to the platform.

[0088] In one specific embodiment of this application, such as Figure 4 As shown, the embedded web application also obtains a new platform token in the following way: if the exchange fails again, it continues to send a business access request to the platform with the platform token and pops up a token renewal prompt.

[0089] As an example, if the retry still fails, the cached platform token is temporarily used to continue providing services. For instance, before the remaining validity period expires completely, a friendly message "Login status is about to expire, re-acquiring" is displayed at the top of the H5 page.

[0090] In one specific embodiment of this application, such as Figure 4 As shown, the embedded web application also obtains new platform tokens by sending a third new token exchange request to the platform when the remaining validity period is 0.

[0091] As an example, when the remaining validity period is 0, that is, when the platform token has completely expired, a third request to exchange a new token is sent to the platform.

[0092] In one specific embodiment of this application, such as Figure 4As shown, the embedded web application also obtains new platform tokens in the following ways: if the third exchange fails, the locally cached platform token is cleared and the login is deemed invalid, prompting the user to re-enter the login process.

[0093] As an example, if the platform token has completely expired and renewing it still fails, the local token status will be cleared, and a pop-up window will appear saying "Login status has expired, please return to the APP to re-enter".

[0094] Thus, the mechanism establishes a session continuity strategy that is "renewable, rollbackable, and recoverable," avoiding repeated logins and unrecoverable states in abnormal scenarios.

[0095] like Figure 1 As shown, in a specific embodiment of an embedded operation and maintenance platform login method based on dual-token bridging in this application, the embedded operation and maintenance platform login method based on dual-token bridging includes: step S105, receiving a business access request sent by an embedded web application carrying a platform token, and completing identity authentication based on the platform token.

[0096] In one specific embodiment of this application, a business request carrying a platform token from an embedded web application is received, and the token is verified to complete identity verification.

[0097] In one specific embodiment of this application, such as Figure 6 As shown, the embedded operation and maintenance platform login system based on dual-token bridging consists of five types of entities: user terminal, customer APP, customer service terminal, operation and maintenance platform H5, and operation and maintenance platform backend.

[0098] As an example, users can first log in to the customer's app to obtain a customer token. Subsequently, when the app launches the platform's H5 page, it can pass the customer token through URL parameters or a message channel. The H5 page can then use this token to call the platform's token exchange interface. The platform backend can verify, map, and issue the token before returning a platform token. The H5 page can then use this platform token in all subsequent calls.

[0099] In one specific embodiment of this application, the "login state reuse" and "platform authorization establishment" can be separated into a two-stage process that is sequentially connected: the first stage completes login within the customer domain, and the second stage completes token bridging within the platform domain, thereby avoiding the customer directly modifying the platform authentication system. Unlike traditional SSO solutions that require authorization code processes, callback address registration, and multi-party IdP (Identity Provider) integration, this application only requires the customer's APP to pass in an existing token when launching the H5 page, and the platform side completes all identity bridging operations through a single interface, significantly simplifying the access link.

[0100] In one specific embodiment of this application, for multi-terminal adaptation, the token transmission method for different terminals is as follows: As an example, in native app scenarios, the customer's token can be passed via URL parameters or WebView postMessage.

[0101] As an example, in a mini-program scenario, the customer's token can be passed through the wx.request request header or as a parameter on the mini-program page.

[0102] As an example, H5 can be loaded through the WeChat Mini Program's web-view component.

[0103] As an example, in a PC client scenario, the client's token can be temporarily stored locally using encrypted storage, such as localStorage with AES encryption. When the H5 page loads, the token is read from the encrypted storage and sent to the token exchange interface.

[0104] This solution differs from traditional SSO solutions in the following core technologies: Regarding the authorization process, traditional SSO requires an authorization code process involving multiple redirects and callbacks. This solution abandons the authorization code process and completes identity bridging solely through a single interface token exchange.

[0105] Regarding the callback mechanism, traditional SSO requires the registration and management of callback addresses, such as Redirect URIs. In multi-client scenarios, the governance of callback addresses is complex. This solution eliminates the need for callback addresses, allowing H5 to directly call the token exchange interface.

[0106] Regarding IdP integration, traditional SSO requires the client to integrate with IdP to implement standard protocols. This solution does not require IdP and directly reuses the client's existing login interface for token verification.

[0107] In terms of identity mapping, traditional SSO usually only transmits authentication results, such as sub / email, without actively establishing a platform-side authorization context, which can easily lead to permission gaps. This solution simultaneously completes the three-dimensional mapping of tenant / application / user during the token exchange process to generate the minimum authorization context.

[0108] Regarding the access period, the typical access period for traditional SSO is more than 2 weeks, requiring multi-party joint debugging between the front-end, back-end, and authentication center. This solution has an access period of 1-2 days, and the client only needs to provide a verification interface or pass in a token.

[0109] In terms of customer modification, traditional SSO requires modifications to both the front-end and back-end, such as authorization code acquisition, callback processing, and token exchange. This solution reduces the amount of code modification on the customer side by 80%, requiring only the token to be passed in when launching the H5 page.

[0110] The core design concept of this solution is to "achieve a complete identity bridging closed loop with the lightest access cost". By eliminating heavy dependencies such as the SSO authorization code process and callback mechanism, and retaining only the three core logic steps of "verification - mapping - issuance", the access complexity is reduced by an order of magnitude without sacrificing security and authorization integrity.

[0111] The beneficial effects of the technical solution presented in this application are as follows: When applied, this technical solution constructs a unified login authentication link for an embedded operations and maintenance platform based on dual-token bridging, forming a lightweight and trusted access system of "customer-side identity credential input—platform unified verification—platform token generation and distribution—embedded H5 business closed-loop access". This solution abandons heavy and redundant mechanisms such as authorization code processes and callback governance, eliminating the need for complex key signature logic on the client side, and completing cross-system identity trusted conversion solely through single-interface token exchange. Simultaneously, through platform token closed-loop authentication, it achieves precise connection between customer identity and platform permissions, solving the defects of identity context breakage and permission gaps in existing lightweight access solutions. Under the premise of low access cost, it achieves seamless, secure, and trusted unified login access in embedded H5 operations and maintenance scenarios.

[0112] Figure 7 This is a schematic diagram of a specific implementation of an embedded operation and maintenance platform login device based on dual-token bridging according to this application.

[0113] exist Figure 7 In the specific implementation shown, the embedded operation and maintenance platform login device based on dual-token bridging may include: a token exchange request receiving module 701, which receives a token exchange request sent by an embedded web application, wherein the token exchange request includes a user identity token issued by the client side; an identity verification module 702, which verifies the user identity token to obtain a standardized user identity credential; a platform token creation module 703, which creates a platform token based on the standardized user identity credential; a platform token distribution module 704, which distributes the platform token to the embedded web application; and a business access request receiving module 705, which receives a business access request sent by the embedded web application carrying the platform token and completes identity authentication based on the platform token.

[0114] The embedded operation and maintenance platform login device based on dual-token bridging provided in this application can be used to execute the embedded operation and maintenance platform login method based on dual-token bridging described in any of the above embodiments. Its implementation principle and technical effect are similar, and will not be repeated here.

[0115] In another specific embodiment of this application, a computer device includes a memory, a processor, and a computer program stored in the memory. The processor executes the computer program to implement the embedded operation and maintenance platform login method based on dual-token bridging described in any of the above embodiments.

[0116] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0117] 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 units can be selected to achieve the purpose of this embodiment according to actual needs.

[0118] The above description is merely an embodiment of this application and does not limit the patent scope of this application. Any equivalent structural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A login method for an embedded operation and maintenance platform based on dual-token bridging, characterized in that, include: Receive a token exchange request sent by an embedded web application, wherein the token exchange request includes a user identity token issued by the client. The user identity token is verified to obtain a standardized user identity credential; Create a platform token based on the standardized user identity credentials; The platform token is sent to the embedded web application; Receive the business access request sent by the embedded web application carrying the platform token, and complete identity authentication based on the platform token.

2. The method according to claim 1, characterized in that, The step of verifying the user identity token to obtain standardized user identity credentials includes: The verification orchestrator performs unified identity verification on the received user identity tokens based on the adaptation configuration corresponding to the configuration template pre-stored in the database, thereby obtaining standardized user identity credentials. Each customer corresponds to an independent adaptation configuration.

3. The method according to claim 1, characterized in that, The standardized user identity credentials include customer identifier, customer application identifier, external user identifier, and access point; as well as The step of creating a platform token based on the standardized user identity credentials includes: Based on the customer identifier and the customer application identifier, locate the tenant identifier; The platform user identifier is mapped based on the external user identifier; Based on the access point, determine the platform application identifier and available functional domains; Generate the permission scope based on the available functional domains; Based on the tenant identifier, the platform user identifier, the platform application identifier, and the permission scope, a minimum available authorization context is generated; The platform token is created based on the minimum available authorization context.

4. The method according to claim 3, characterized in that, The step of generating a permission scope based on the available functional domains includes: Determine whether the tenant corresponding to the tenant identifier is shared by multiple customers; When it is determined that the tenant is shared by multiple customers, the set of roles and the data access scope corresponding to the customer identifier are determined, wherein different customers among the multiple customers are assigned mutually independent preset set of roles and configured with corresponding preset data access scopes; If it is determined that the tenant is used by only a single customer, the set of roles corresponding to the tenant is determined, and all business data of the tenant is determined as the data access scope; Based on the available functional domains, the determined set of roles, and the determined data access scope, a permission scope is generated.

5. The method according to claim 1, characterized in that, Both the user identity token and the platform token are transmitted via HTTPS encryption, and both are carried in the HTTP request header. The user identity token is a single-use, time-limited token.

6. The method according to claim 1, characterized in that, The platform token has a remaining validity period; and If the remaining validity period is less than a preset validity threshold, the embedded web application obtains a new platform token in the following way: The first time a new token exchange request is sent to the platform; If the exchange is successful, obtain a new platform token and use the obtained new platform token to initiate a business access request to the platform.

7. The method according to claim 6, characterized in that, The embedded web application also obtains the new platform token through the following methods: If the exchange fails, a second request for the new token exchange will be sent to the platform after a preset interval. If the second exchange is successful, a new platform token is obtained, and the obtained new platform token is used to initiate a business access request to the platform.

8. The method according to claim 7, characterized in that, The embedded web application also obtains the new platform token through the following methods: If the redemption fails again, continue to send a business access request to the platform with the platform token and pop up a token renewal prompt; If the remaining validity period is 0, a third request for exchanging the new token is sent to the platform. If the third redemption fails, the platform token cached locally is cleared and the login is deemed invalid, prompting the user to re-enter the login process.

9. An embedded operation and maintenance platform login device based on dual-token bridging, comprising: The token exchange request receiving module receives token exchange requests sent by the embedded web application, wherein the token exchange request includes a user identity token issued by the client. The identity verification module verifies the user identity token to obtain a standardized user identity credential. The platform token creation module creates a platform token based on the standardized user identity credentials. The platform token issuing module issues the platform token to the embedded web application. The business access request receiving module receives the business access request sent by the embedded web application carrying the platform token, and completes identity authentication based on the platform token.

10. A computer device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the embedded operation and maintenance platform login method based on dual-token bridging as described in any one of claims 1-8.

Images