Authentication method of map service and related device

Abstract

The application provides a map service authentication method, device and equipment and a readable storage medium. The application can verify a map service request initiated by a user by using a public key and a private key corresponding to user information, so as to verify the map service of the user. Compared with the existing simple application programming interface key authentication mode, the security of map service management is effectively improved, the authentication process of the map service can be simplified, the vulnerability of the developer in the map authentication implementation process can be effectively reduced, the access permission of the user is controlled by using the private key and the public key, the map service access request of the user can be more flexibly managed, the key management and permission verification strategy can be more flexibly adjusted, the dynamically changing service demand can be adapted, the application programming interface access of the user to the map service can be effectively controlled, and the security of data transmission can be improved by signing the authentication request initiated by the user by using the private key of the user.

Description

Technical Field

[0001] This application relates to the field of map service authentication technology, and in particular to a map service authentication method and related equipment. Background Technology

[0002] In today's era of rapid internet development, map services have become an indispensable and crucial component of numerous applications, widely used in navigation, logistics, social networking, and many other fields. To integrate and utilize map services across various applications, they are typically invoked through Application Programming Interfaces (APIs). However, the resulting security issues surrounding APIs have become a core concern for both users and service providers.

[0003] Currently, the most widely used authentication methods in the industry include Application Programming Interface (API) keys and OAuth 2.0. API keys, however, have significant security vulnerabilities because they are easily exposed in client applications, making them susceptible to theft and misuse by malicious actors, posing a significant security risk to users and service providers. While OAuth 2.0 offers excellent security, its implementation process is extremely complex. For small and medium-sized enterprises (SMEs) and developers, it is not only difficult to develop but also costly to maintain, and prone to misconfiguration in practice, thus affecting the normal operation and security of the system. Existing authentication technologies lack sufficient flexibility in user authentication and permission verification, making it difficult to adapt to complex and dynamic scenarios, resulting in verification effects that fall short of expectations and fail to meet the diverse needs of practical applications. There is an urgent need for an authentication mechanism that can improve security and simplify the process to better meet market demands and ensure the secure and reliable operation of map services. Summary of the Invention

[0004] This application aims to at least address one of the aforementioned technical deficiencies. In view of this, this application provides a map service authentication method and related equipment to address the technical deficiency of insecure map service authentication in the prior art.

[0005] An authentication method for a map service includes: determining whether a user is requesting to use the map service for the first time; if the user is requesting to use the map service for the first time, generating a public key and a private key corresponding to the user's information, and uploading the public key to the user's information to an authentication server; after determining the private key corresponding to the user's information, generating a first target authentication request for the user's map service request based on the user's map service usage request, and signing the first target authentication request with the private key corresponding to the user's information to obtain a second target authentication request, wherein the second target authentication request includes user identity information, the application programming interface corresponding to the map service requested by the user, and request timestamp information; sending the second target authentication request to an authentication gateway for verification; and after the authentication gateway verifies the second target authentication request, receiving the map service data required by the user obtained from the map service server forwarded by the authentication gateway.

[0006] Preferably, before generating a first target authentication request for the user to use the map service based on the user's map service usage request after determining the private key corresponding to the user information, the method further includes: if the user is not requesting to use the map service for the first time, then determining the private key corresponding to the user information.

[0007] Preferably, the authentication gateway's verification process for the second target authentication request includes: after receiving the second target authentication request, the authentication gateway reads the stored public key corresponding to the user information to verify the signature of the second target authentication request; based on the public key corresponding to the user information, it confirms whether the signature in the second target authentication request includes a private key matching the public key corresponding to the user information; if it is determined that the signature in the second target authentication request includes a private key matching the public key corresponding to the user information, then the second target authentication request is confirmed to be legitimate, and the user's identity information is verified, and it is checked whether the user has access rights to the application programming interface corresponding to the requested map service; if it is determined that the user's identity information is verified and the user has access rights to the application programming interface corresponding to the requested map service, then the second target authentication request is confirmed to be verified; if it is determined that the signature in the second target authentication request does not include a private key matching the public key corresponding to the user information, then the second target authentication request is confirmed to be illegitimate, and the second target authentication request cannot be verified.

[0008] Preferably, the method further includes: if it is determined that the second target authentication request is legitimate, but the user's identity information has not been verified, then it is determined that the second target authentication request cannot be verified; or, if it is determined that the second target authentication request is legitimate and the user's identity information has been verified, but the user does not have access to the application programming interface corresponding to the requested map service, then it is determined that the second target authentication request cannot be verified.

[0009] Preferably, the authentication gateway obtains the map service data required by the user from the map service server, including: if the authentication gateway determines that the second target authentication request has passed verification, it forwards the second target authentication request to the map service server to obtain the map service data required by the user from the map service server; after the map service server receives the second target authentication request and analyzes the second target authentication request to determine the map service data required by the user, it forwards the map service data required by the user to the authentication gateway.

[0010] Preferably, the user identity information includes the user's unique identifier, password, or other authentication information; the authentication gateway's verification result for the second target authentication request also includes authentication failure and the return of the corresponding failure reason when authentication fails.

[0011] An authentication system for a map service, applied to any of the aforementioned map service authentication methods, includes a user terminal, an authentication gateway, an authentication server, and a map service server. When the user terminal determines that a user has a request to access the map service, the user terminal determines whether this is the user's first request to use the map service. If it is determined that this is the user's first request, a public key and a private key corresponding to the user's information are generated, and the public key is uploaded to the authentication server. If it is determined that this is not the user's first request, the private key corresponding to the user's information is determined. After determining the private key corresponding to the user's information, the user terminal uses the map service based on the user's... The system generates a first target authentication request for a user request to use a map service. It then signs the first target authentication request with the private key corresponding to the user's information to obtain a second target authentication request. This second target authentication request is sent to the authentication gateway for verification. The second target authentication request includes user identity information, the application programming interface (API) corresponding to the map service requested by the user, and request timestamp information. The authentication server receives and stores the public key corresponding to the user information uploaded by the user, and periodically updates the public key according to preset update rules. Upon receiving the second target authentication request, the authentication gateway reads the stored public key from the authentication server. The system stores the public key corresponding to the user information and verifies the signature of the second target authentication request based on this public key. It then checks whether the signature in the second target authentication request includes a private key that matches the public key corresponding to the user information. If the signature in the second target authentication request includes a private key that matches the public key, the second target authentication request is deemed legitimate. Simultaneously, the system analyzes the second target authentication request to verify the user's identity information and checks whether the user has access rights to the application programming interface (API) corresponding to the requested map service. If the user's identity information is verified and the user has access rights to the API corresponding to the requested map service, the system verifies the user's identity information. If the system checks permissions, the second target authentication request is deemed to have passed verification. If the signature in the second target authentication request does not include a private key that matches the public key corresponding to the user information, the second target authentication request is deemed illegitimate and fails verification. If the second target authentication request is deemed legitimate, but the user's identity information has not been verified, the second target authentication request fails verification. Alternatively, if the second target authentication request is deemed legitimate, and the user's identity information has been verified, but the user does not have access to the application programming interface corresponding to the requested map service, the second target authentication request fails verification.If the authentication gateway determines that the second target authentication request passes verification, it returns authentication success information to the user terminal and forwards the second target authentication request to the map service server to obtain the map service data required by the user. If the authentication gateway determines that the second target authentication request fails verification, it returns authentication failure information to the user terminal and records the relevant logs of the authentication failure event. The map service server receives and analyzes the second target authentication request forwarded by the authentication gateway, determines the map service data required by the user, and forwards the determined map service data to the authentication gateway. After receiving the map service data required by the user forwarded by the map service server, the authentication gateway forwards it to the user terminal.

[0012] An authentication device for a map service includes: a judging unit for judging whether a user is requesting to use the map service for the first time; a key generation unit for generating a public key and a private key corresponding to the user's information when the user is requesting to use the map service for the first time, and uploading the public key corresponding to the user's information to an authentication server; a request generation unit for generating a first target authentication request for the user's map service request based on the user's map service request, and signing the first target authentication request with the private key corresponding to the user's information to obtain a second target authentication request, wherein the second target authentication request includes user identity information, the application programming interface corresponding to the map service requested by the user, and request timestamp information; a verification unit for sending the second target authentication request to an authentication gateway for verification; and a data receiving unit for receiving map service data required by the user obtained from the map service server and forwarded by the authentication gateway after the authentication gateway has verified the second target authentication request.

[0013] An authentication device for a map service includes: one or more processors and a memory; the memory stores computer-readable instructions, which, when executed by the one or more processors, implement the steps of the map service authentication method described above.

[0014] A readable storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to implement the steps of the authentication method for the map service as described in any of the foregoing descriptions.

[0015] As can be seen from the technical solutions described above, when a user requests to use a map service, the method provided in this application embodiment can determine whether the user is requesting to use the map service for the first time. If the user is requesting to use the map service for the first time, a public key and a private key corresponding to the user's information can be generated for the user, and the public key corresponding to the user's information can be uploaded to the authentication server. This allows the generated public key and private key to verify whether the user's access request is legitimate. After determining the private key corresponding to the user's information, a first target authentication request for the user's map service request can be generated based on the user's map service request. The first target authentication request is then signed with the private key corresponding to the user's information to obtain a second target authentication request. The second target authentication request includes the user's identity information, the application programming interface corresponding to the map service requested by the user, and the request timestamp information. The second target authentication request allows us to understand the accessing user information and the specific request information. To confirm whether the second target authentication request initiated by the user is legitimate, the second target authentication request can be sent to the authentication gateway for verification. Once the authentication gateway verifies the second target authentication request, it indicates that the user's second target authentication request is legitimate and has the relevant access permissions. The user can then receive the map service data required by the user, which is forwarded by the authentication gateway from the map service server.

[0016] As described above, the method provided in this application can verify the map service request initiated by the user using the public and private keys corresponding to the user information, thereby verifying the user's map service. Compared with the existing simple application programming interface key authentication method, this application effectively improves the security of map service management, simplifies the map service authentication process, effectively reduces vulnerabilities in the map authentication implementation process, and uses private and public keys to control user access permissions, allowing for more flexible management of user map service access requests. It also allows for more flexible adjustment of key management and permission verification strategies to adapt to dynamically changing service needs, effectively controlling user access to the application programming interface of the map service. Furthermore, signing the authentication request initiated by the user with the private key of the user information also improves the security of data transmission. Attached Figure Description

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

[0018] Figure 1A flowchart illustrating the authentication method for implementing map services provided in this application embodiment;

[0019] Figure 2 This is a schematic diagram of a system architecture for implementing map service authentication provided in an embodiment of this application;

[0020] Figure 3 A schematic diagram of the authentication device structure for a map service, as exemplified in an embodiment of this application;

[0021] Figure 4 This is a hardware structure block diagram of the authentication device for the map service disclosed in an embodiment of this application. Detailed Implementation

[0022] 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. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] In practical applications, API keys are easily stolen and misused, especially in client applications. After registering for a map service, a user receives an API key. Each time the user requests the map service, they must include this key in the request. After receiving the request, the map service server checks whether the API key is valid and whether it matches the requested API. This method is simple and easy to implement, but it has low security because the API key can be intercepted or misused.

[0024] Although OAuth 2.0 offers strong security, its implementation process is complex. Users log in through a third-party authentication service, the map service obtains an access token through the OAuth protocol, the map service server verifies the validity of the access token, and provides services according to the permissions in the token. The map service only allows requests from specific IP addresses or rejects requests from blacklisted IPs. This approach is highly secure, but it requires interaction between the user and the third-party service, and its implementation is complex, making it difficult to develop and maintain, especially for small and medium-sized enterprises and developers, and prone to misconfiguration. Existing technologies lack flexibility in user authentication and permission verification, resulting in unsatisfactory verification performance in dynamic scenarios. Given that most current map service authentication schemes are ill-suited to complex and ever-changing business needs, this applicant has researched a map service authentication scheme. This method verifies user-initiated map service requests using the public and private keys corresponding to user information, thereby verifying the user's map service access. Compared to existing simple application programming interface (API) key authentication methods, the method provided in this application effectively improves the security of map service management, simplifies the map service authentication process, and uses private and public keys to control user access permissions, allowing for more flexible management of user map service access requests. It effectively controls user access to the map service's API and improves data transmission security by signing user-initiated authentication requests with the user's private key.

[0025] The method provided in this application can be used in numerous general-purpose or special-purpose computing device environments or configurations. For example, personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor devices, distributed computing environments including any of the above devices, etc. This application also provides a map service authentication method, which can be applied to various map service management systems, as well as to various computer terminals or smart terminals. The executing entity can be the processor or server of the computer terminal or smart terminal.

[0026] The following is combined Figure 1 This document describes the process of the map service authentication method provided in the embodiments of this application, such as... Figure 1 As shown, the process may include the following steps:

[0027] Step S101: Determine whether this is the user's first request to use the map service.

[0028] Specifically, in practical applications, when a user uses a map service for the first time, the system needs to clearly inform the user of the various permissions required by the map service, such as location information and storage permissions, and obtain the user's authorization. This not only complies with relevant laws and regulations but also allows users to clearly understand how their information will be used, enhancing their trust in the service. Furthermore, if a user is using the map service for the first time, the system may need to configure or verify the user's information to ensure the security of the map service data.

[0029] Furthermore, first-time map users may be unfamiliar with map functions and operations. Determining whether a user is a first-time user allows for targeted onboarding guides and tutorials, helping them quickly understand basic map functions such as zooming, panning, and searching for locations. This improves the initial user experience and lowers the barrier to entry. During first-time use, basic user preference information, such as frequently visited locations and travel methods, can be collected to provide more accurate personalized recommendations, such as nearby popular attractions and restaurants. Default settings, such as map display mode and navigation voice, can be adjusted based on user preferences, allowing users to enjoy services tailored to their needs without complicated setup. Understanding whether a user is a first-time user also helps analyze user acquisition channels. If a large number of first-time users come from a specific promotional channel, it indicates that the channel's promotional effect is significant, and investment in that channel can be increased; conversely, channels with poor promotional effects need adjustment and optimization. The map operation behaviors and usage habits of first-time users are of significant research value. By analyzing the behavior path and frequency of function use of first-time users, potential problems in product design can be identified, such as which functions are not easily discovered or are inconvenient to use, thus providing a basis for product optimization and iteration.

[0030] Furthermore, first-time users of map services may face some potential safety risks, such as unfamiliarity with map safety prompts, which could lead to dangerous situations due to improper operation while using navigation. By identifying first-time users, more detailed safety tips and risk notifications can be provided, such as reminding users to pay attention to safety while driving and avoid excessive phone use.

[0031] If a user is requesting the map service for the first time, the server may need to allocate more resources to load basic map data and initialize related configurations. For users who are not first-time users, the server can provide more accurate incremental updates based on their usage habits and historical data, thereby optimizing server resource allocation and improving the overall service response speed and stability.

[0032] For first-time users, since the relevant map data is not in the local cache, it needs to be fully retrieved from the server and stored in the local cache. For repeat users, the map service can adopt a more flexible caching strategy based on the user's usage history and cache status, such as partially updating the cache or preloading potentially needed data, to reduce data transfer volume and speed up map loading.

[0033] Therefore, in practical applications, for the sake of map service data security and to provide users with a better service experience, when a user initiates a map service request, it can be determined whether the user is requesting the map service for the first time. If the user is requesting the map service for the first time, then step S102 is executed. If the user is not requesting the map service for the first time, then step S103 is executed.

[0034] Step S102: Generate a public key and a private key corresponding to the user's information, and upload the public key corresponding to the user's information to the authentication server.

[0035] Specifically, in practical applications, public and private keys are an asymmetric encryption technology, possessing uniqueness and immutability. When it is determined that a user is using the map service for the first time, a public and private key corresponding to the user's information can be generated, and the public key is uploaded to the authentication server. By generating a corresponding public and private key for users using the map service for the first time, during subsequent interactions between the user and the map service and related systems, the user's identity information can be encrypted and signed using the private key, and the authentication server uses the corresponding public key for verification, thereby ensuring the authenticity of the user's identity, preventing unauthorized users from impersonating others to access the map service, and enhancing system security. In today's scenario where map services are used on multiple devices and platforms, users may use the same map service on different devices such as mobile phones, computers, and tablets. After generating a public and private key corresponding to the user's information and uploading the public key to the authentication server, the user can use the private key for authentication on different devices, achieving single sign-on. This allows users to seamlessly switch between multiple platforms to use the map service while ensuring the consistency and security of the user's identity.

[0036] In practical applications, map services typically involve a large amount of sensitive user information, such as location data, search history, and travel preferences. Generating public and private keys corresponding to user information allows for the encryption of this data, ensuring that only users with the corresponding private key can decrypt and view it. Even if the data is intercepted during transmission or stored on the server, third parties cannot access its content, effectively protecting user privacy and data security. When users interact with map services, such as uploading personal settings or downloading map data, the data is encrypted using the public key before transmission, ensuring data integrity and confidentiality during transmission. Furthermore, when storing user data on the server, encrypted ciphertext can also be used to further enhance data storage security.

[0037] Furthermore, by binding public keys to user identities, map service providers can more accurately track and analyze user behavior, such as the types of locations users frequently search for and their travel time distribution. This data is then encrypted before being transmitted to an authentication server, ensuring user privacy while providing more precise data support for personalized map service recommendations, route planning, and other functions, thus improving the user experience.

[0038] In practical applications, based on the user identity information corresponding to the public key, map services can also provide customized services and access control for different users. For example, for paid users or premium members, their identities can be identified based on their public key, providing more advanced map functions, more accurate navigation services, or more personalized recommendations. At the same time, the scope of their access to and use of map resources can be finely managed according to user permissions.

[0039] Public-key and private-key encryption mechanisms effectively defend against various external malicious attacks, such as man-in-the-middle attacks and data tampering attacks. Attackers, without the correct private key, cannot decrypt or tamper with the encrypted data, thus ensuring the integrity and reliability of data exchanged between the map service and users, and maintaining the normal operation of the map service. In scenarios such as map data updates and user feedback, public and private keys are used to sign and verify data, ensuring that the data has not been tampered with during transmission and storage. Once the data is tampered with, verification will fail, thereby promptly detecting and preventing malicious behavior and ensuring the quality and credibility of map service data.

[0040] Step S103: Determine the private key corresponding to the user information.

[0041] Specifically, if a user is not using the map service for the first time, it means that a private key corresponding to the user's information may already be stored. Therefore, based on considerations such as security, user experience, and service optimization, when it is confirmed that a user is not using the map service for the first time, it is necessary to verify the private key corresponding to the user's information. Every time the user uses the map service again, the legitimacy and authenticity of their identity must be confirmed. As one of the key identifiers of a user's identity, verifying the private key corresponding to the user's information ensures that the user currently using the map service is the same user who previously registered and legitimately used the service, preventing others from impersonating the user to perform illegal operations, such as stealing the user's location information or viewing their history.

[0042] In a network environment, there is a risk that attackers may intercept users' previous communication data and launch replay attacks. By requiring users to provide the private key corresponding to the information for verification, the system can determine whether the request is a legitimate real-time request, rather than replayed old data, based on information such as the unique signature generated by the private key. This effectively defends against such attacks and ensures service security.

[0043] For users who are not first-time users, once the private key corresponding to their user information is determined, the system can quickly identify the user and automatically load their previous personalized settings, such as map display preferences, frequently used locations, and navigation voice commands. This eliminates the need for users to manually configure these settings again, achieving seamless service integration and enhancing the consistency and convenience of the user experience. In scenarios where map services are used on multiple devices or platforms, users may switch between different devices. After determining the private key corresponding to their user information, users can easily achieve single sign-on on different devices using this private key, eliminating the need to repeatedly enter usernames and passwords and other cumbersome operations. This allows users to access map services anytime, anywhere, increasing user engagement with the service.

[0044] Map services store a large amount of sensitive user-related data, such as historical trip records and search history. Only users with the correct private key can decrypt and access this data, ensuring that access to user data is strictly controlled by the user, preventing unauthorized third parties from obtaining and abusing user data, and effectively protecting user privacy.

[0045] When users interact with map service servers, such as checking real-time traffic conditions or updating personal information, they use a private key to encrypt and sign the interactive data. This ensures the confidentiality and integrity of the data during transmission. Even if the data is intercepted during transmission, attackers cannot decrypt and obtain the content without the private key, thus protecting user data security.

[0046] By identifying users through their private keys, map services can provide more accurate and personalized recommendations based on users' historical usage behavior and preferences. For example, they can recommend nearby restaurants that match the user's tastes or plan the best routes based on the user's travel habits. The private key, as a precise identifier of the user's identity, helps the system better understand user needs and enhances the personalization of the service.

[0047] Once the private key corresponding to the user's information is determined, the system can identify the user based on the private key, collect and analyze the user's ongoing usage behavior data, and further understand the user's satisfaction with the map service and changes in their needs. This data can be used to optimize the functionality and performance of the map service, such as improving route planning algorithms and optimizing map loading speed, thereby continuously improving service quality and meeting user needs.

[0048] Therefore, if it is determined that the user is not using the map service for the first time, the private key corresponding to the user information can be determined so that the user's information can be identified using the private key.

[0049] Step S104: After determining the private key corresponding to the user information, a first target authentication request for the user to use the map service is generated based on the user's map service usage request, and the first target authentication request is signed with the private key corresponding to the user information to obtain a second target authentication request.

[0050] Specifically, in practical applications, to ensure the security of user information, when a user initiates a map service access request, a first target authentication request can be generated based on the user's map service usage request. This first target authentication request is then signed with the private key corresponding to the user's information, thereby obtaining a second target authentication request. The second target authentication request can include user identity information, the application programming interface (API) corresponding to the map service requested by the user, and request timestamp information. User identity information can include the user's unique identifier, password, or other authentication information. By signing the first target authentication request with the private key corresponding to the user information to obtain the second target authentication request, it can be clearly confirmed that the request was indeed issued by a legitimate user, and not a request forged by impersonation or malicious forgery.

[0051] Upon receiving a request, the authentication gateway uses the public key corresponding to the private key associated with the user's information to verify it. Only requests that pass verification are considered legitimate and valid, thus ensuring the authenticity of the user's identity and the legitimacy of the request. During network transmission, data may be tampered with or corrupted. After signing the first target authentication request, the generated second target authentication request contains the signature information. The receiver can verify the signature to determine whether the data has been tampered with during transmission. If the signature verification passes, it indicates that the data is intact and has not been tampered with; otherwise, the request will be rejected, thereby ensuring the integrity and security of the user's requested data.

[0052] Furthermore, after signing, the second target authentication request becomes non-repudiable, meaning the user cannot deny having issued the request. This is crucial for system operation logging and auditing. In the event of problems or disputes, such as a user objecting to a map service operation or a security incident, the system can trace the source and process of the request by verifying the signature, clarifying responsibility and facilitating subsequent investigation and handling.

[0053] For map service providers, analyzing a large number of signed authentication requests provides a better understanding of user behavior and habits, such as the time distribution of user map service requests, location preferences, and frequency of feature usage. This data helps in creating accurate user profiles and behavioral analysis, providing a basis for service optimization and personalized recommendations, and also facilitating the tracking of user usage and activity levels for map services.

[0054] In some cases, map services may need to interact and integrate with other third-party services or systems, such as sharing user map request information with travel apps and local service platforms. Signing user requests ensures the authenticity and integrity of these requests during cross-platform and cross-system interactions, enabling secure and reliable data sharing and collaboration between different systems. When external developers use the map service's application programming interface (API) to develop related applications, the user request signing mechanism serves as a security measure, ensuring that only authorized applications and legitimate user requests can invoke the map service's API, preventing its misuse and protecting the security and stability of the map service.

[0055] With increasingly stringent data security laws and regulations, some companies need to take effective measures to protect the security and privacy of user data. Signing user requests and ensuring their legality and integrity helps map service providers meet relevant regulatory requirements regarding data security and user authorization, avoiding legal risks due to data leaks or violations. Furthermore, the map service industry also has industry norms and standards that require companies to conduct strict identity verification and data protection for user requests. By generating and signing authentication requests, map services can conform to industry best practices and standards, enhancing the company's reputation and competitiveness.

[0056] Step S105: Send the second target authentication request to the authentication gateway for verification.

[0057] Specifically, in practical applications, the authentication gateway, as the security entry point of the map service system, bears the crucial responsibility of verifying the legitimacy of user identities. By verifying the signature in the second target authentication request, the authentication gateway can use the public key corresponding to the user's private key to decrypt and verify, ensuring that the request was indeed issued by a legitimate user holding the correct private key. This prevents unauthorized users from impersonating others to access the map service, thereby effectively avoiding the risk of identity theft.

[0058] Therefore, when a user requests access to the map service, the user's private key is used to sign the second-target authentication request, which is then sent to the authentication gateway for verification. Furthermore, during network transmission, data may be subject to various interferences or malicious tampering. When verifying the second-target authentication request, the authentication gateway checks the validity of the signature. If the signature verification passes, it indicates that the data has not been tampered with during transmission, ensuring the integrity and consistency of the user's requested data and guaranteeing that the map service receives a genuine and complete request from the user.

[0059] In practical applications, the authentication gateway primarily plays a role in centrally managing and controlling user authentication within the entire map service system. Therefore, sending the second target authentication request to the authentication gateway for verification facilitates unified processing and management of all user authentication requests, achieving standardization and normalization of the authentication process. This helps in effective monitoring and auditing of user access, enabling the timely detection of abnormal requests and potential security threats.

[0060] Furthermore, map services typically consist of multiple backend services, such as map data storage, route planning, and geocoding. Centralizing the authentication process within the authentication gateway allows backend services to focus on their own business logic without needing to concern themselves with the specific details of user authentication. This reduces the complexity of backend services, improves system maintainability and scalability, and also facilitates independent upgrades and optimizations of the authentication functionality.

[0061] Furthermore, the authentication gateway can cache verified user information and requests. When the same user sends a request again, the authentication gateway can quickly compare the information in the cache, reducing the time spent on repeated verification and improving the system's response speed and overall performance.

[0062] Furthermore, authentication gateways can intelligently optimize based on factors such as user request frequency and geographical location, dynamically adjusting verification strategies or allocating server resources to improve the user experience. Many industries have stringent security standards and regulations, such as data protection laws and information security management system standards. Sending secondary authentication requests to the authentication gateway for verification can also help map service systems meet the requirements of these regulations and standards regarding user identity verification and data security, ensuring compliant system operation and avoiding legal risks due to violations.

[0063] The authentication gateway records detailed authentication information during the authentication process, such as request time, user IP address, and authentication result. This information is crucial for system auditing and traceability. In the event of a security incident or user dispute, administrators can quickly understand the course and cause of the incident by reviewing the authentication gateway's audit logs, clarify the attribution of responsibility, and provide strong evidence for subsequent investigation and handling.

[0064] Step S106: After the authentication gateway verifies the second target authentication request, it receives the map service data required by the user obtained from the map service server and forwarded by the authentication gateway.

[0065] Specifically, as described above, the authentication gateway can verify the second target authentication request. Successful verification by the authentication gateway indicates that the user's identity has been confirmed. The successful verification of the second target authentication request, signed with the private key corresponding to the user's information, by the authentication gateway demonstrates that the user is a legitimate user registered and authorized to use the map service, and not an unauthorized intruder or impersonator. This establishes a foundation of trust between the map service system and the user, ensuring that only legitimate users can access the corresponding map service data, effectively preventing unauthorized access and data leakage risks. Successful verification means that the integrity and authenticity of the user's request are guaranteed during data transmission. From the time the user sends the request to the authentication gateway's verification, the data is not tampered with or damaged, thus ensuring that subsequent data obtained from the map service server is also secure and reliable when transmitted to the user, and will not be corrupted or maliciously modified due to problems in the transmission process.

[0066] The authentication gateway plays a crucial intermediate role in the map service system, and its successful authentication is a vital node in the entire service request processing flow. This indicates that the user's request has completed the necessary identity verification and security checks according to the system's preset authentication process, meeting the system's access requirements, and thus can proceed to the next stage: receiving the corresponding data provided by the map service server. Furthermore, map service systems typically consist of multiple components, and there is a close collaborative relationship between the authentication gateway and the map service server. After successful authentication, the gateway forwards the request to the map service server. The map service server retrieves and processes the data based on the request content and returns the results to the authentication gateway, which then forwards them to the user. This collaborative mechanism ensures the efficient operation of the entire system and the correct transmission of data; only after successful authentication by the gateway can subsequent data acquisition and transmission processes proceed smoothly.

[0067] Map service data obtained after successful authentication gateway verification is accurately retrieved and processed by the map service server based on the user's legitimate request. This ensures that the data received by the user is accurate information matching their request, including map images, geographic coordinates, route planning, etc., meeting the user's actual needs for map services and providing a high-quality service experience. After successful authentication gateway verification, a stable connection channel is established between the user and the map service system, allowing for efficient data transmission. Users no longer need to undergo complex authentication or wait for additional confirmation processes, enabling them to receive map service data quickly and stably, improving service response speed and efficiency, and enhancing user satisfaction with the map service.

[0068] Furthermore, in an increasingly stringent regulatory environment regarding information security and privacy protection, map service systems need to ensure the legal use of data and the privacy and security of users. The process of providing map service data only after successful authentication by the authentication gateway complies with relevant regulations regarding user identity verification and data access control, ensuring that map service providers operate legally and avoiding legal risks arising from violations. Moreover, if any problems occur during data acquisition and use, such as data errors or privacy leaks, the authentication gateway's rigorous verification process clearly identifies the responsible party. If the problem occurs on the map service server side after successful verification, the responsibility primarily lies with the map service provider's backend service; if the problem occurs during transmission, it can be traced and investigated through system logs and monitoring records, facilitating timely problem resolution and clarifying the responsibilities of all parties. Therefore, once the authentication gateway successfully verifies the second target authentication request, it can receive the map service data requested by the user, forwarded by the authentication gateway from the map service server.

[0069] In practical applications, suppose a map service provider needs to provide services to different customer groups, including ordinary consumers, business partners, and emergency response teams. Using the authentication mechanism of this application, the service provider can create different keys and permission settings for each group. Ordinary consumers use a standard key, allowing only access to basic map views and search functions. Business partners use a higher-level key, allowing access to custom map styles and geographic analysis tools. Emergency response teams, in emergency situations, can be temporarily granted access to real-time traffic and weather data to assist in rescue operations. In this way, the authentication mechanism of this invention not only improves system security but also provides high flexibility, enabling service providers to quickly adjust their service strategies according to actual business needs.

[0070] For example, in multiple user scenarios, using traditional API key authentication methods, 3 instances of API key misuse were found out out of 50 API calls. However, using the method proposed in this application, no key misuse events occurred in any of the 50 calls, demonstrating a significant improvement in security. Under the same network conditions, the average response time for request response using traditional OAuth 2.0 authentication was 300ms, while the average response time using the method provided in this application was reduced to 150ms, resulting in improved system performance. User feedback surveys showed that 92% of users found the key-based authentication method simpler and easier to use than OAuth 2.0, and 92% believed it increased their trust in the service. These experimental data demonstrate that this application has significant security and practical advantages.

[0071] As can be seen from the technical solutions described above, the method provided in this application embodiment can verify the map service request initiated by the user using the public and private keys corresponding to the user information, thereby verifying the user's map service. Compared with the existing simple application programming interface key authentication method, the method provided in this application embodiment effectively improves the security of map service management, simplifies the map service authentication process, effectively reduces vulnerabilities in the map authentication implementation process, and uses private and public keys to control user access permissions, allowing for more flexible management of user map service access requests and more flexible adjustment of key management and permission verification strategies to adapt to dynamically changing service needs. It can effectively control user access to the application programming interface of the map service, and by signing the authentication request initiated by the user with the user's private key, it can also improve the security of data transmission.

[0072] As described above, in practical applications, the authentication gateway can verify the second target authentication request initiated by the user. The verification process will be described below, and it may include the following:

[0073] In step S201, after receiving the second target authentication request, the authentication gateway reads the stored public key corresponding to the user information to verify the signature of the second target authentication request.

[0074] Specifically, in asymmetric encryption systems, public and private keys are generated in pairs and have a unique correspondence. A user uses their private key to sign a first target authentication request, generating a second target authentication request. The authentication gateway can only correctly verify the validity of the signature using the public key corresponding to the user's private key, just as only a specific key can open a corresponding lock. This matching relationship ensures the accuracy and reliability of the verification. The private key is the user's secret information, held only by the user, used to sign requests and ensure that the request originates from the user and has not been tampered with. The public key, on the other hand, can be publicly disclosed. As mentioned above, the authentication server stores the public key corresponding to the user's information, which can be used to verify the signature requests sent by the user. This public-private key characteristic ensures both the confidentiality of the user's identity and allows the verification process to be conducted in a public mechanism.

[0075] Therefore, after receiving the second target authentication request, the authentication gateway can read the stored public key corresponding to the user information to verify the signature of the second target authentication request. By using the stored public key to verify the signature of the second target authentication request, the authentication gateway can confirm whether the request was indeed issued by a legitimate user. If the signature verification is successful, it means that the user holding the corresponding private key is a legitimate user authenticated by the system, and their identity has been verified. This prevents unauthorized users from impersonating others to obtain map services, effectively ensuring the security of the system.

[0076] During network transmission, data may be tampered with or corrupted. The signature verification process not only verifies the user's identity but also checks whether the secondary authentication request remains intact during transmission. If the signature verification passes, it indicates that the data has not been tampered with during transmission, ensuring the integrity and authenticity of the user's request, enabling the system to proceed with subsequent processing based on the correct request.

[0077] As the security core of the system, the authentication gateway centrally stores the public keys corresponding to all user information, facilitating unified management and maintenance. When a user's secondary authentication request is received, the corresponding public key can be directly read for signature verification, improving verification efficiency and overall system performance.

[0078] In practical applications, if a user's key pair needs to be updated or changes for some reason, only the corresponding public key needs to be updated at the authentication server, without requiring large-scale modifications to other parts of the entire system. This centralized management approach makes key updates and maintenance more convenient, reducing system management costs and complexity.

[0079] In the field of information security, using a public key to sign a private key request is a widely accepted security verification method that complies with relevant security standards and specifications. Verification in this way ensures that the map service system meets industry security requirements, enhancing the system's security and trustworthiness. The verification process leaves corresponding records in the authentication gateway, including the verification time, user information, and request content. These records are crucial for system auditing and traceability. In the event of security issues or disputes, these records can be reviewed to identify the cause, clarify responsibilities, and provide strong evidence for subsequent handling.

[0080] Step S202: Based on the public key corresponding to the user information, confirm whether the signature in the second target authentication request includes a private key that matches the public key corresponding to the user information.

[0081] Specifically, in asymmetric encryption systems, public and private keys are generated in pairs, with a unique correspondence. Verifying a signature using the public key corresponding to the user information is essentially confirming whether the signature was generated by the private key that uniquely matches the public key. If the verification is successful, it can be highly confident that the request was issued by the legitimate user holding the corresponding private key, thereby effectively preventing unauthorized users from impersonating others and ensuring the authenticity of the user's identity.

[0082] Various identity forgery risks exist in the network environment. For example, attackers might intercept user requests and attempt to tamper with or forge signatures. This public-key-based verification method ensures that only legitimate users with the correct private key can generate a valid signature that matches the public key, making it difficult for attackers to forge a signature that passes verification and significantly improving the system's resistance to identity forgery attacks. When a user uses their private key to sign a first target authentication request to generate a second target authentication request, this signature is a unique identifier generated based on the content of the request. During transmission, if the request is tampered with, the recalculated signature based on the tampered content will differ from the original signature. By verifying the signature using the public key, it's possible to detect whether the signature matches the request content, thus determining whether the data has been tampered with during transmission and ensuring data integrity. Without such verification, attackers might maliciously modify user requests during transmission, such as changing map service parameters or user access permissions, leading to users receiving incorrect or insecure map service data. The public-key-based signature verification mechanism can promptly detect such tampering, ensuring that users receive complete and undisturbed data.

[0083] When a map service system interacts or integrates with other related systems, adhering to unified encryption and verification standards is the foundation for establishing mutual trust between systems. Other systems can trust the map service system's verification results regarding user identity and data integrity, thereby achieving secure and reliable information exchange and collaborative work.

[0084] By verifying the match between the signature and the public / private key, the entity responsible for each request can be clearly identified. During system operation, if any issues related to user requests arise, such as unauthorized operations or data breaches, the verification logs can quickly determine which user initiated the request, providing a clear basis for subsequent accountability and troubleshooting.

[0085] Within enterprises and organizations, it is often necessary to audit system operations and data access to meet compliance requirements. This public key-based signature verification mechanism can generate clear audit logs, recording the verification results and related information for each request, facilitating auditing and compliance checks, and ensuring that system operations comply with relevant regulations and corporate policies.

[0086] Therefore, based on the public key corresponding to the user information, it can be confirmed whether the signature in the second target authentication request includes a private key that matches the public key corresponding to the user information. If it is determined that the signature in the second target authentication request includes a private key that matches the public key corresponding to the user information, then step S203 can be executed. If it is determined that the signature in the second target authentication request does not include a private key that matches the public key corresponding to the user information, or if it is determined that the second target authentication request is legitimate, but the user's identity information has not been verified, or if it is determined that the second target authentication request is legitimate, and the user's identity information has been verified, but the user does not have access to the application programming interface corresponding to the requested map service, then step S205 can be executed.

[0087] Step S203: Confirm that the second target authentication request is legitimate, verify the user's identity information, and check whether the user has access rights to the application programming interface corresponding to the requested map service.

[0088] Specifically, as described above, the method provided in this application embodiment can determine whether the signature in the second target authentication request includes a private key corresponding to the user information. If it is determined that the signature in the second target authentication request includes a private key that matches the public key corresponding to the user information, it indicates that the user's access request is legitimate and has not been tampered with. However, it is necessary to further confirm whether the user has access to the relevant data. Then, the user's identity information can be further verified, and it can be checked whether the user has access to the application programming interface corresponding to the requested map service.

[0089] Verifying user identity information is fundamental to ensuring system security. In the network environment, there is a risk that malicious actors may impersonate others to obtain sensitive information or perform illegal operations. By verifying identity information, such as usernames, passwords, and digital certificates, the true identity of users can be accurately identified, preventing unauthorized users from using the authentication requests of legitimate users for malicious purposes, thereby avoiding security vulnerabilities caused by identity theft.

[0090] Checking user access permissions to map service application programming interfaces (APIs) reflects adherence to the principles of access control and minimization. Different users may have different roles and permissions within the system, and not all users should have unlimited access to all map service APIs. Strict permission checks ensure that users can only access API resources they are authorized to use, thereby limiting the potential attack surface and reducing security risks caused by permission abuse. Map services typically involve a large amount of sensitive information, such as geographic data and user location information. Dual authentication of user identity and permissions helps ensure that this sensitive data is only accessed and used by legitimately authorized users. Without checking user permissions, users may overstep their boundaries and access unauthorized data, leading to data leaks or misuse, compromising user privacy and data security.

[0091] In some industries and regions, there are strict regulations and compliance requirements for the use and protection of map data. Simultaneously conducting identity verification and permission checks helps ensure that system operations comply with relevant data protection regulations, avoiding legal risks due to unauthorized data use, such as violations of geographic information data confidentiality regulations or user privacy protection regulations. Map service systems have limited resources, including server bandwidth and computing power. By verifying user identity and permissions, it ensures that only legitimate users use system resources according to their permissions, preventing malicious or unauthorized users from excessively consuming system resources, thereby guaranteeing the stable operation of the system and ensuring the provision of efficient and reliable map services to legitimate users.

[0092] Different map service application programming interfaces may correspond to different system function modules or data resources. Checking user access permissions helps to achieve functional isolation in the system architecture, ensuring that each user can only access the functions and data corresponding to their permissions. This facilitates system management and maintenance, and also reduces the impact of user errors or unauthorized operations on the overall system architecture.

[0093] By verifying user identity and permissions, personalized map service experiences can be provided based on users' specific identities and permissions. For example, users with advanced permissions can enjoy richer map functions and data, while ordinary users can receive basic map services, meeting the differentiated needs of different user groups and improving user satisfaction. Ensuring that only legitimate users with the appropriate permissions can successfully access map services helps improve the stability and predictability of service quality. It also prevents service interruptions or anomalies caused by unauthorized or illegal users, providing legitimate users with continuous and stable map services, thus enhancing user experience and service loyalty.

[0094] Therefore, if it is determined that the user's identity information has been verified and the user has access to the application programming interface corresponding to the requested map service, then step S204 can be executed.

[0095] Step S204: Determine that the second target authentication request has passed verification.

[0096] Specifically, as described above, the method provided in this application embodiment can determine whether the signature in the second target authentication request includes the private key corresponding to the user information; and thereby determine whether the second target authentication request is the user's true intention rather than an authentication request initiated by someone impersonating the user; when it is determined that the second target authentication request is indeed the user's true intention, if it can be determined on this basis that the user's identity has been verified and the user has access to the application programming interface corresponding to the requested map service, then it can be determined that the user's second target authentication request has been verified.

[0097] Step S205: Confirm that the second target authentication request is illegal and that the second target authentication request cannot pass verification.

[0098] Specifically, as described above, the method provided in this application embodiment can determine whether the signature in the second target authentication request includes the private key corresponding to the user information; and thereby determine whether the second target authentication request is the user's true intention rather than an authentication request initiated by someone impersonating the user.

[0099] When determining that the second target authentication request is indeed the user's true intention, if the signature in the second target authentication request does not include the private key that matches the public key corresponding to the user information, or if the second target authentication request is legal but the user's identity information has not been verified, or if the second target authentication request is legal and the user's identity information has been verified but the user does not have access to the application programming interface corresponding to the requested map service, then the second target authentication request is illegal and can be determined to fail verification.

[0100] In practical applications, the authentication gateway's verification result for the second target authentication request also includes authentication failure and the return of the corresponding failure reason. For example, if authentication fails, the authentication gateway will return an error message to the user, such as "Authentication failed" or "Access denied." Authentication failure requests are logged in the security log for subsequent security auditing and anomaly analysis. For frequently failed authentication requests, the system may limit the number of retries to prevent brute-force attacks. Through these mechanisms, this solution ensures authentication security while also providing flexible access management and data transmission encryption, thereby improving overall security and reliability.

[0101] As can be seen from the technical solutions described above, the method provided in this application embodiment can verify the second target authentication request initiated by the user, so as to identify the user's access request and determine the security and legitimacy of the user's access.

[0102] In practical applications, the authentication gateway can obtain the map service data required by the user from the map service server. The following describes this process, which may include the following steps:

[0103] Step S301: If the authentication gateway determines that the second target authentication request has passed verification, it forwards the second target authentication request to the map service server to obtain the map service data required by the user from the map service server.

[0104] Specifically, in practical applications, the authentication gateway is only responsible for verifying access requests, while the map service server stores the relevant map service data. The authentication gateway is primarily responsible for user authentication and request legitimacy verification, while the map service server focuses on providing map service data. This clearly defined division of labor allows each component to focus on its core function, improving the overall performance and maintainability of the system. After the authentication gateway completes the verification, it forwards the request to the map service server, enabling collaboration between the two to fulfill the user's need to obtain map service data. Therefore, the authentication gateway rigorously verifies the second target authentication request, including verifying the user's identity information and checking the user's access permissions to the map service application programming interface. Only when all these verifications pass is the request considered a legitimate request from a legitimate user and compliant with the system's security policy. Forwarding such a request to the map service server ensures that the server receives a secure and reliable request, preventing malicious attacks or unauthorized data acquisition by illegal requests.

[0105] As an intermediary between users and map service servers, the authentication gateway establishes a bridge of trust between them upon successful verification. The map service server can then trust requests verified by the gateway, providing users with the corresponding map service data without needing to repeatedly verify user identity and request legitimacy, thus improving the efficiency and security of data interaction.

[0106] In the entire system's operation, the authentication gateway's verification and forwarding operations are standardized steps. This standardized process ensures that user requests, after undergoing necessary security checks, accurately reach the map service server, making the system more stable and predictable, and facilitating system management and maintenance. Users initiate map service requests to obtain the required map service data. Once the authentication gateway verifies the request and promptly forwards it to the map service server, the server can quickly respond to the user's request, providing accurate map service data, meeting the user's immediate needs, and improving the user experience.

[0107] The map service server is a professional storage and processing center for map data. Only by forwarding authenticated and legitimate requests to it can the accuracy, completeness, and compliance with user permissions be ensured in the map service data obtained by the user. This avoids data errors or incompleteness caused by illegal or erroneous requests, providing users with high-quality map services. Furthermore, when the authentication gateway forwards a verified request to the map service server, this process leaves clear request records and logs. These records are also crucial for system auditing and monitoring, allowing administrators to track the entire process of user requests, understand user behavior and system response, promptly identify abnormal behavior or potential security risks, and take appropriate measures to address them.

[0108] In some industries and scenarios, there are strict compliance requirements for data access and use. Through the verification and forwarding operations of the authentication gateway, the legitimacy and responsibility for each request can be clearly defined, ensuring that the system operates in accordance with relevant laws and policies. In case of problems, responsibility can be clearly defined, avoiding unnecessary legal risks. Therefore, if the authentication gateway determines that the second target authentication request has passed verification, it can forward the second target authentication request to the map service server to obtain the map service data required by the user.

[0109] Step S302: After the map service server receives the second target authentication request and analyzes the second target authentication request to determine the map service data required by the user, it forwards the map service data required by the user to the authentication gateway.

[0110] Specifically, as described above, the authentication gateway forwards the second target authentication request to the map service server only after confirming that the second target authentication request has passed verification, in order to obtain the map service data required by the user from the map service server. Therefore, after the map service server receives the second target authentication request, it can analyze the second target authentication request to determine the map service data required by the user, and then forward the map service data required by the user to the authentication gateway.

[0111] As can be seen from the technical solutions described above, the authentication gateway provided in this application verifies the user's identity through a second target authentication request and forwards the verified second target authentication request to the map service server, thereby enabling the acquisition of the map service data required by the user from the map service server. Through the authentication gateway's verification and forwarding, it can be ensured that the map service data obtained by the user is accurate, complete, and compliant with their permissions. This avoids data errors or incompleteness caused by illegal or erroneous requests, providing users with high-quality map services. The map service server can trust requests verified by the authentication gateway, thereby providing users with the corresponding map service data without needing to repeatedly verify the user's identity and the legitimacy of the request, improving the efficiency and security of data interaction.

[0112] The following is combined Figure 2 This application introduces an optional system architecture for map service authentication, as provided in its embodiments. This system can be applied to the aforementioned map service authentication methods, such as... Figure 2 As shown, the system architecture may include a user terminal, an authentication gateway, an authentication server, and a map service server.

[0113] In practical applications, when the client determines that a user has a request to access the map service, it can determine whether this is the user's first time requesting the map service. If the client determines that this is the user's first time requesting the map service, it can generate a public and private key corresponding to the user's information and upload the public key to the authentication server. If it determines that this is not the user's first time requesting the map service, it determines the private key corresponding to the user's information. After determining the private key corresponding to the user's information, when the user initiates a map service request, the client can generate a first target authentication request based on the user's map service request. This first target authentication request is then signed with the private key corresponding to the user's information, thus obtaining a second target authentication request. After obtaining the second target authentication request, it is sent to the authentication gateway for verification. The second target authentication request may include the user's identity information, the application programming interface corresponding to the map service requested by the user, and the request timestamp information.

[0114] This application allows for the assignment of different levels of keys to different users or user groups to control their access permissions. For example, ordinary users may only be granted access to basic map services, while advanced users or partners may be granted access to advanced analytics tools. If a key is leaked or no longer needed, the system can quickly revoke its access permissions without affecting other users' normal use. This flexibility facilitates rapid response to security incidents and protects the system from damage. It allows the system to dynamically adjust permissions based on user roles, geographic location, or other attributes. For example, certain APIs may only be open to users in specific regions or available for specific time periods. When temporary access to specific resources is required, the system can temporarily grant permissions to users. For instance, a user may need temporary access to real-time map data for an emergency event; the system can dynamically grant temporary permissions based on the nature of the event and the user's needs. As business needs change, system administrators can flexibly adjust permission policies without redeploying the entire system. For example, if new business requirements necessitate stricter control over access to specific APIs, administrators can quickly update permission rules to adapt to these changes.

[0115] The authentication server can receive and store the public key corresponding to user information uploaded by the user client, and update the public key periodically according to preset update rules; for example, it can update the public key corresponding to user information monthly or weekly in real time to ensure security. In some cases, it may be necessary to update the key periodically to improve security. This application allows system administrators or users to update the public and private keys at any time without changing other parts of the system. For example, if a security risk is detected, the system can automatically prompt the user to change the key, or automatically rotate the key in the background.

[0116] After receiving the second target authentication request, the authentication gateway can read the public key corresponding to the user information stored in the authentication server. This allows it to verify the signature of the second target authentication request based on the public key, confirming whether the signature in the second target authentication request includes a private key that matches the public key corresponding to the user information. If the signature in the second target authentication request includes a private key that matches the public key, the user-initiated second target authentication request is considered genuine and valid, and its legitimacy can be confirmed. To further confirm the legitimacy and access rights of the user-initiated second target authentication request, the gateway can analyze the request to verify the user's identity information and check whether the user has access rights to the application programming interface (API) corresponding to the requested map service. If the user's identity information is verified and the user has access rights to the API corresponding to the requested map service, the second target authentication request is considered successfully verified.

[0117] If the authentication gateway determines that the signature in the second target authentication request does not include the private key that matches the public key corresponding to the user information, it indicates that the second target authentication request may be a forged request and is not legitimate. Therefore, the second target authentication request can be confirmed as illegitimate and cannot pass the verification.

[0118] If the authentication gateway determines that the second target authentication request is legitimate, but finds that the user's identity information has not been verified, it indicates that someone else has stolen the user's signature to initiate map service access, and the second target authentication request can be determined to fail verification. Alternatively, if the authentication gateway determines that the second target authentication request is legitimate and the user's identity information has been verified, but the user does not have access to the application programming interface corresponding to the requested map service, it indicates that although the user's access request is legitimate and is a genuine access request initiated by the user, the user does not have the relevant map service access permissions, and therefore the corresponding map service data cannot be provided to the user, and the second target authentication request can be determined to fail verification.

[0119] In practical applications, if the authentication gateway determines that the second target authentication request passes verification, it can return a successful authentication message to the user and forward the second target authentication request to the map service server to obtain the map service data required by the user. If the authentication gateway determines that the second target authentication request fails verification, it can return an authentication failure message to the user and record relevant logs of the authentication failure event for traceability. After receiving the second target authentication request forwarded by the authentication gateway, the map service server understands that the map service requested by the user is legitimate and has the corresponding data access permissions, and can then provide the requested map service data. Therefore, after receiving the second target authentication request, the map service server can analyze the second target authentication request forwarded by the authentication gateway to determine the map service data required by the user and forward the determined map service data to the authentication gateway. The authentication gateway, after receiving the map service data required by the user forwarded by the map service server, then forwards it to the user.

[0120] As can be seen from the technical solutions described above, the system provided in this application embodiment can verify the map service request initiated by the user using the public and private keys corresponding to the user information, thereby verifying the user's map service. Compared with the existing simple application programming interface key authentication method, the method provided in this application embodiment effectively improves the security of map service management, simplifies the map service authentication process, effectively reduces vulnerabilities in the map authentication implementation process, and uses private and public keys to control user access permissions, allowing for more flexible management of user map service access requests and more flexible adjustment of key management and permission verification strategies to adapt to dynamically changing service needs. It can effectively control user access to the application programming interface of the map service, and by signing the authentication request initiated by the user with the user's private key, it can also improve the security of data transmission.

[0121] The authentication apparatus for map services provided in the embodiments of this application is described below. The authentication apparatus for map services described below can be referred to in correspondence with the authentication method for map services described above. See also Figure 3 , Figure 3 This is a schematic diagram of the structure of an authentication device for a map service disclosed in an embodiment of this application. Figure 3 As shown, the authentication device for this map service may include:

[0122] The judgment unit 101 is used to determine whether the user is requesting to use the map service for the first time.

[0123] The key generation unit 102 is used to generate a public key and a private key corresponding to the user information when the user requests to use the map service for the first time, and to upload the public key corresponding to the user information to the authentication server.

[0124] The request generation unit 103 is used to generate a first target authentication request for the user to use the map service based on the user's map service usage request, and to sign the first target authentication request with a private key corresponding to the user's information to obtain a second target authentication request. The second target authentication request includes user identity information, application programming interface corresponding to the map service requested by the user, and request timestamp information.

[0125] Verification unit 104 is used to send the second target authentication request to the authentication gateway for verification;

[0126] The data receiving unit 105 is used to receive the map service data required by the user obtained from the map service server, which is forwarded by the authentication gateway after the authentication gateway has verified the second target authentication request.

[0127] As can be seen from the technical solutions described above, the device in this application embodiment can verify the map service request initiated by the user using the public and private keys corresponding to the user information, thereby verifying the user's map service. Compared with the existing simple application programming interface key authentication method, the device provided in this application embodiment effectively improves the security of map service management, simplifies the map service authentication process, effectively reduces vulnerabilities in the map authentication implementation process for developers, and uses private and public keys to control user access permissions, allowing for more flexible management of user map service access requests and more flexible adjustment of key management and permission verification strategies to adapt to dynamically changing service needs. It can effectively control user access to the application programming interface of the map service, and by signing the authentication request initiated by the user with the user's private key, it can also improve the security of data transmission.

[0128] The specific processing flow of each unit included in the authentication device of the aforementioned map service can be found in the relevant introduction of the authentication method of the map service mentioned above, and will not be repeated here.

[0129] The map service authentication device provided in this application embodiment can be applied to map service authentication devices, such as terminals: mobile phones, computers, etc. Optionally, Figure 4 The diagram shows the hardware structure of the authentication device for the map service. Figure 4 The hardware structure of the authentication device for the map service may include at least one processor 1, at least one communication interface 2, at least one memory 3, and at least one communication bus 4. In this embodiment, the number of processor 1, communication interface 2, memory 3, and communication bus 4 is at least one, and the processor 1, communication interface 2, and memory 3 communicate with each other through the communication bus 4. The processor 1 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application; the memory 3 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device; wherein, the memory stores a program, which the processor can call, and the program is used to implement various processing flows in the aforementioned terminal map service authentication scheme. This embodiment also provides a readable storage medium that stores a program suitable for processor execution, the program being used to implement various processing flows in the aforementioned terminal map service authentication scheme.

[0130] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element. The various embodiments described in this specification are presented in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. The various embodiments can be combined with each other. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method of authenticating a map service, the method comprising: The method comprises the following steps: determining whether the user is requesting the map service for the first time; if the user is not requesting the map service for the first time, determining the private key corresponding to the user information; if the user is requesting the map service for the first time, generating the public key and the private key corresponding to the user information for the user, and uploading the public key corresponding to the user information to the authentication server; after determining the private key corresponding to the user information, generating a first target authentication request for the user to request the map service based on the user's request for the map service, and signing the first target authentication request with the private key corresponding to the user information to obtain a second target authentication request, wherein the second target authentication request comprises user identity information, an application programming interface corresponding to the map service requested by the user, and a request timestamp information; sending the second target authentication request to the authentication gateway for verification; wherein the verification process of the authentication gateway for the second target authentication request is as follows: after receiving the second target authentication request, the authentication gateway reads the stored public key corresponding to the user information to verify the signature of the second target authentication request; based on the public key corresponding to the user information, it is determined whether the signature in the second target authentication request comprises a private key matching the public key corresponding to the user information; if it is determined that the signature in the second target authentication request comprises a private key matching the public key corresponding to the user information, it is determined that the second target authentication request is legal, and the user's identity information is verified, and it is checked whether the user has access to the application programming interface corresponding to the requested map service; if it is determined that the user's identity information passes the verification and the user has access to the application programming interface corresponding to the requested map service, it is determined that the second target authentication request passes the verification; if it is determined that the signature in the second target authentication request does not comprise a private key matching the public key corresponding to the user information, it is determined that the second target authentication request is illegal and cannot pass the verification; if it is determined that the second target authentication request is legal, but the user's identity information does not pass the verification, it is determined that the second target authentication request cannot pass the verification; or if it is determined that the second target authentication request is legal and the user's identity information has passed the verification, but the user does not have access to the application programming interface corresponding to the requested map service, it is determined that the second target authentication request cannot pass the verification; after the authentication gateway verifies the second target authentication request, receiving the map service data required by the user forwarded by the authentication gateway from the map service server.

2. The method of claim 1, wherein, The authentication gateway obtains the map service data required by the user from the map service server, comprising: if the authentication gateway determines that the second target authentication request passes the verification, the second target authentication request is forwarded to the map service server to obtain the map service data required by the user from the map service server; After the map service server receives the second target authentication request and analyzes the second target authentication request to determine the map service data required by the user, the map service data required by the user is forwarded to the authentication gateway.

3. The authentication method of the map service according to any one of claims 1-2, characterized in that, the user identity information comprises a unique identifier, a password or other identity verification information of the user; the authentication gateway further comprises authentication failure and corresponding failure reason returned when authentication fails.

4. An authentication system of a map service, characterized by, The system is applied to the authentication method of the map service according to any one of claims 1-3, and comprises a user terminal, an authentication gateway, an authentication server and a map service server. When the user terminal determines that the user has a request for accessing the map service, the user terminal determines whether the user is requesting the map service for the first time; if it is determined that the user is requesting the map service for the first time, the user terminal generates a public key and a private key corresponding to the user information, and uploads the public key corresponding to the user information to the authentication server; if it is determined that the user is not requesting the map service for the first time, the user terminal determines the private key corresponding to the user information; After the user terminal determines the private key corresponding to the user information, the user terminal generates a first target authentication request for the user to request the map service based on the user's request for using the map service, and signs the first target authentication request with the private key corresponding to the user information to obtain a second target authentication request, and then sends the second target authentication request to the authentication gateway for verification, wherein the second target authentication request comprises user identity information, an application programming interface corresponding to the map service requested by the user and request timestamp information; The authentication server receives and stores the public key corresponding to the user information uploaded by the user terminal, and updates the public key corresponding to the user information periodically according to a preset update rule. The authentication gateway receives the second target authentication request, reads the stored public key corresponding to the user information from the authentication server, verifies the second target authentication request based on the public key corresponding to the user information, and determines whether the signature in the second target authentication request includes a private key matching the public key corresponding to the user information. If it is determined that the signature in the second target authentication request includes a private key matching the public key corresponding to the user information, it is determined that the second target authentication request is legal, and the second target authentication request is analyzed to verify the identity information of the user and check whether the user has access to the application programming interface corresponding to the requested map service. If it is determined that the identity information of the user is verified and the user has access to the application programming interface corresponding to the requested map service, it is determined that the second target authentication request is verified. If it is determined that the signature in the second target authentication request does not include a private key matching the public key corresponding to the user information, it is determined that the second target authentication request is illegal and cannot be verified. If it is determined that the second target authentication request is legal, but the identity information of the user is not verified, it is determined that the second target authentication request cannot be verified. Or, if it is determined that the second target authentication request is legal and the identity information of the user is verified, but the user does not have access to the application programming interface corresponding to the requested map service, it is determined that the second target authentication request cannot be verified. If the authentication gateway determines that the second target authentication request is verified, it returns authentication success information to the user terminal and forwards the second target authentication request to the map service server to obtain the map service data required by the user from the map service server. If the authentication gateway determines that the second target authentication request is not verified, it returns authentication failure information to the user terminal and records the relevant logs of the authentication failure event. The map service server receives and analyzes the second target authentication request forwarded by the authentication gateway, determines the map service data required by the user, and forwards the determined map service data to the authentication gateway. The authentication gateway receives the map service data required by the user forwarded by the map service server and forwards it to the user terminal.

5. An authentication apparatus of a map service, characterized by comprising: It includes: A judgment unit for judging whether a user is requesting to use a map service for the first time; A key generation unit for generating a public key and a private key corresponding to user information for a user when the user is requesting to use a map service for the first time, and uploading the public key corresponding to the user information to an authentication server; A request generation unit for generating a first target authentication request for a user to request to use a map service based on a map service use request of the user, and signing the first target authentication request with a private key corresponding to the user's information to obtain a second target authentication request, wherein the second target authentication request includes user identity information, an application programming interface corresponding to a map service requested by the user, and request timestamp information; The verification unit is configured to send the second target authentication request to an authentication gateway for verification. The authentication gateway verifies the second target authentication request by reading a stored public key corresponding to user information, verifying the signature of the second target authentication request based on the public key corresponding to the user information, confirming whether the signature in the second target authentication request includes a private key matching the public key corresponding to the user information, confirming that the second target authentication request is legitimate if the signature in the second target authentication request includes the private key matching the public key corresponding to the user information, verifying the identity information of the user, checking whether the user has access to the application programming interface corresponding to the requested map service, determining that the second target authentication request is verified if the identity information of the user is verified and the user has access to the application programming interface corresponding to the requested map service, determining that the second target authentication request is not verified if the signature in the second target authentication request does not include the private key matching the public key corresponding to the user information, determining that the second target authentication request is not verified if the identity information of the user is not verified although the second target authentication request is legitimate, or determining that the second target authentication request is not verified if the user does not have access to the application programming interface corresponding to the requested map service although the second target authentication request is legitimate and the identity information of the user is verified. The data receiving unit is configured to receive map service data required by the user from a map service server after the authentication gateway verifies the second target authentication request.

6. An authentication device of a map service, characterized by, One or more processors and a memory; The memory stores computer readable instructions that, when executed by the one or more processors, implement the steps of the map service authentication method of any one of claims 1 to 3. The readable storage medium stores computer readable instructions that, when executed by one or more processors, cause the one or more processors to implement the steps of the map service authentication method of any one of claims 1 to 3.

7. A readable storage medium characterized by: ​

Images