Patent Description:
Embodiments of this application relate to the field of communications technologies, and in particular, to a message push method, an electronic device, and a storage medium.

Currently, the open authorization (Open Authorization, OAUTH) protocol provides a secure, open, and simple standard for user resource authorization. A difference from previous authorization is that authorization of the OAUTH protocol does not allow a third party to access user account information (such as a user name and a password). In other words, the third party can apply for user resource authorization without using the user name and the password. The OAUTH protocol further provides authentication between servers based on a network verification code (Json Web Token, JWT) manner.

However, in a push hierarchy, a message provider may send a message to an incorrect message receiver (message crosstalk), causing a security event. For example, a message provider A can only send a message to a message receiver A, but may send a message to a message receiver B or a message receiver C, causing message crosstalk. The document <CIT> (<NUM>-<NUM>-<NUM>), discloses a method for controlling push messages and a mobile terminal, which can reduce the memory burden of a user and improve user experience. The document <CIT> (<NUM>-<NUM>-<NUM>), discloses a push message processing method.

Further embodiments are described by the dependent claims.

The following describes technical solutions in embodiments of this application with reference to the accompanying drawings in embodiments of this application. In the description of embodiments of this application, unless otherwise specified, "/" indicates an "or" relationship. For example, A/B may represent A or B. "and/or" in this specification is merely an association relationship for describing associated objects, and represents that three relationships may exist.

The terms "first" and "second" mentioned below are merely intended for a purpose of description, and shall not be understood as an indication or implication of relative importance or implicit indication of the number of indicated technical features. Therefore, a feature limited by "first" or "second" may explicitly indicate or implicitly include one or more such features. In the description of embodiments of this application, unless otherwise specified, "a plurality of" means two or more.

JWT is a JSON-based open standard executed to transfer a declaration between network application environments. JWT is designed to be compact and secure and is especially suitable for single sign-on (SSO) of distributed sites, the declaration of the JWT is generally used to transfer authenticated user identity information between an identity provider and a service provider, to obtain resources from a resource server. Some additional declaration information required by other service logic may also be added. In addition, the JWT may also be directly used for authentication, or may be encrypted. The JWT may include three parts: a first part is a header, a second part is a payload, and a third part is a signature.

The JWT may be used for signature authentication. For example, the message provider may send a message push request to the message pusher in a JWT manner. After performing signature authentication on the message push request, the message pusher determines whether the identity of the message provider is valid, that is, determines whether the message provider can push the to-be-pushed message to a message receiver. However, the current signature authentication manner cannot determine the message receiver to which the to-be-pushed message will be pushed, and it is possible that the to-be-pushed message sent to a message receiver A is sent to a message receiver B. Therefore, the foregoing signature authentication manner cannot resolve a problem of message crosstalk, and may bring a security risk to data push of a message provider.

Based on the foregoing problem, an embodiment of this application provides a message push method.

The message push method provided in this embodiment of this application may be applied to a data processing device. The data processing device may be a server. A specific form of the data processing device that performs the technical solution is not specially limited in this application.

An application scenario of this embodiment of this application is shown in <FIG>. The application scenario includes a message provider <NUM>, a message pusher <NUM>, and a message receiver <NUM>. The message provider <NUM> is configured to send a to-be-pushed message and a message push request to the message pusher <NUM>, so that the message pusher <NUM> pushes the to-be-pushed message after verifying the message push request. For example, the to-be-pushed message may include a bulletin message, a notification message, and another type of message that are related to an application. For example, the to-be-pushed message may be "bulletin information about upgrading a service at <NUM>:<NUM> a. Alternatively, the to-be-pushed message may be another type of message. This is not specially limited in this embodiment of this application.

The message pusher <NUM> is configured to receive the to-be-pushed message and the message push request that are sent by the message provider <NUM>, verify the message push request, and push the to-be-pushed message to the correct message receiver <NUM>. The message pusher <NUM> includes a push system <NUM> and a verification system <NUM>. The verification system <NUM> is configured to verify the message push request. The push system <NUM> is configured to push the to-be-pushed message to the message receiver <NUM> after the message push request passes the verification.

It should be noted that the to-be-pushed message sent by the message provider <NUM> is based on an application. Therefore, the message pusher <NUM> may push the to-be-pushed message to a corresponding application installed on the message receiver <NUM> (for example, a mobile terminal). For example, when the message pusher <NUM> pushes a bulletin message corresponding to a music application <NUM>, if the music application <NUM> is installed on the message receiver <NUM>, the bulletin message may be received.

The message receiver <NUM> is configured to receive messages pushed by the message pusher <NUM>. The message receiver <NUM> may be a mobile terminal on which an application (for example, the music application <NUM> or a map application <NUM>) is installed, or may be another type of terminal on which the foregoing application is installed. This is not specially limited in this application.

With reference to <FIG>, a message push method provided in an embodiment of this application is described by using an example in which a message provider <NUM> sends two to-be-pushed messages respectively corresponding to the music application <NUM> and the map application <NUM>. <FIG> is a schematic flowchart of an interaction procedure of an embodiment of a message push method according to this application, and the method includes the following steps.

Step <NUM>: A message pusher <NUM> creates an application key corresponding to an application.

Specifically, the message pusher <NUM> may preset identifiers of a plurality of applications (for example, a music application, a map application, and a meal ordering application). For example, a music application ID may be set for the music application <NUM>, or a map application ID may be set for the map application <NUM>. It may be understood that the application identifier is used to identify the application. Optionally, the application identifier may also be sent by the message provider <NUM> to the message pusher <NUM> in advance. This is not specially limited in this application.

After obtaining the application identifier, the message pusher <NUM> may create a corresponding application key for each application. For example, the message pusher <NUM> may create a corresponding application key (referred to as a music application key) for the music application <NUM> and may create a corresponding application key (referred to as a map application key) for the map application <NUM>. The application key may be a symmetric or an asymmetric key commonly used in the art. This is not specially limited in this embodiment of this application.

Step <NUM>: The message pusher <NUM> sends a mapping relationship between the application and the application key to the message provider <NUM>.

Specifically, the message pusher <NUM> may establish a one-to-one mapping relationship between the application and the application key and may store the mapping relationship in a local database. Next, the message pusher <NUM> may send the mapping relationship to the message provider <NUM>. In a specific implementation, the local database may be disposed in the verification system <NUM> in the message pusher <NUM>.

Step <NUM>: The message provider <NUM> obtains declaration information, an identifier of the music application <NUM>, and an identifier of the map application <NUM>, performs digest extraction on the declaration information, the identifier of the music application <NUM>, and the identifier of the map application <NUM> by using the music application key to generate a corresponding digest (referred to as a music application digest), and performs digest extraction on the declaration information, the identifier of the music application <NUM>, and the identifier of the map application <NUM> by using the map application key, to generate a corresponding digest (referred to as a map application digest).

Specifically, the declaration information may include information related to the message push request, where the message push request is used by the message provider <NUM> to request the message pusher <NUM> to push the to-be-push message. The message push request may be sent in a JWT manner. Therefore, the declaration information may include declaration information registered by the JWT in a standard protocol. For example, the declaration information may include an issuer (for example, a server that issues the JWT), an issuance time (for example, a moment at which the JWT is issued), an issuance effective time (for example, an effective time period of the JWT), and related information. For details, refer to the protocol RFC <NUM>. In addition, the declaration information may also include other related information. Specific content and a form of the declaration information are not specially limited in this embodiment of this application.

Further, because the mapping relationship between the application and the application key is stored in the local database of the message provider <NUM>, after obtaining the declaration information, the identifier of the music application <NUM>, and the identifier of the map application <NUM>, the message provider <NUM> may use the mapping relationship to obtain the corresponding music application key by query based on the identifier of the music application <NUM> and obtain the corresponding map application key by query based on the identifier of the map application <NUM>. Digest extraction on the declaration information, the identifier of the music application <NUM>, and the identifier of the map application <NUM> is performed by using the music application key, to obtain the music application digest corresponding to the identifier of the music application <NUM>. Similarly, the message provider <NUM> may further perform digest extraction on the declaration information, the identifier of the music application <NUM>, and the identifier of the map application <NUM> by using the map application key, to obtain the map application digest corresponding to the identifier of the map application <NUM>. A digest extraction manner may be an HASHMAC512 manner, or may be another digest extraction manner. This is not specially limited in this embodiment of this application.

It should be noted that, when performing digest extraction, the message provider <NUM> may not perform digest extraction on the declaration information. For example, the message provider <NUM> may perform digest extraction on the identifier of the music application <NUM> and the identifier of the map application <NUM>, to obtain the music application digest corresponding to the identifier of the music application <NUM>, and perform digest extraction on the identifier of the music application <NUM> and the identifier of the map application <NUM>, to obtain the map application digest corresponding to the identifier of the map application <NUM>. That is, the declaration information is optional information when the message provider <NUM> performs digest extraction.

Step <NUM>: The message provider <NUM> sends a to-be-pushed message and a message push request to the message pusher <NUM>, where the message push request includes the declaration information, the identifier of the music application <NUM>, the identifier of the map application <NUM>, the music application digest, and the map application digest.

Specifically, after obtaining the music application digest and the map application digest, the message provider <NUM> may generate the message push request based on the declaration information, the identifier of the music application <NUM>, the identifier of the map application <NUM>, the music application digest, and the map application digest. The message push request may be used by the message provider <NUM> to request the message pusher <NUM> to push the to-be-pushed message sent by the provider <NUM>, and the message push request may be in a form of a JWT.

Description is now provided with reference to <FIG> and <FIG>. <FIG> shows an existing message push request data packet <NUM> in a JWT format. The data packet <NUM> includes a header, a payload, and a signature. The header of the data packet <NUM> includes an application identifier field (sub) and a first field (aa), where the sub field is used to indicate a location of the application identifier in the payload, and the aa field is used to identify a location of the declaration information in the payload. The payload of the data packet <NUM> may include the declaration information and information corresponding to the sub field (for example, the application identifier). The signature of the data packet <NUM> is used for validity of the identity of the message provider. For example, the message pusher <NUM> may verify the identity of the message provider <NUM> to determine validity of the identity of the message provider <NUM>. The signature may be used to identify the identity of the message provider <NUM>. That is, the message push request of the message provider <NUM> may be verified by verifying the signature, to determine whether the message push request is valid. It can be learned from the foregoing data packet <NUM> that, the data packet <NUM> includes only an application identifier field, and after receiving the data packet <NUM>, the message pusher <NUM> cannot verify the correspondence between the message provider <NUM> and the message receiver <NUM>. Therefore, the message pusher <NUM> directly pushes the to-be-pushed message to the message receiver <NUM> corresponding to the application identifier in the payload information, which may cause message crosstalk and bring a data security problem.

<FIG> shows a message push request data packet <NUM> in a JWT format according to this application. The data packet <NUM> may include a header, a payload, and a signature. In addition to an application identifier field (sub) and a first field (aa), the header of the data packet <NUM> may further include a digest field (vfs), or may include another field. This is not limited in this embodiment of this application. The vfs field is used to identify a location of digest information in the payload. The payload of the data packet <NUM> may include declaration information, application identifier information, and digest information. The application identifier information corresponds to the sub field, the digest information corresponds to the vfs field, and the declaration information corresponds to the aa field. The application identifier information includes an identifier of the music application <NUM> and an identifier of the map application <NUM>. The digest information includes a music application digest and a map application digest. A function of the signature of the data packet <NUM> is the same as that of the signature of the data packet <NUM>, and details are not described herein again. The data packet <NUM> carries digest information (for example, the music application digest and the map application digest). Therefore, the message pusher <NUM> may perform verification based on the digest information, to determine whether the to-be-pushed message can be sent to a mobile terminal on which the music application and the map application are installed. In this way, message crosstalk can be avoided, and data security can be ensured.

Further, after generating the message push request, the message provider <NUM> may send the message push request together with the current to-be-pushed message to the message pusher <NUM>, so that the message pusher <NUM> may push the to-be-pushed message to the message receiver <NUM> (for example, a mobile terminal on which the music application <NUM> and/or the map application <NUM> are/is installed) corresponding to the identifier of the music application <NUM> and/or the identifier of the map application <NUM>.

Step <NUM>: The message pusher <NUM> reads the message push request.

Specifically, after receiving the message push request from the message provider <NUM>, the message pusher <NUM> may read the message push request to obtain the declaration information, the identifier of the music application <NUM>, the identifier of the map application <NUM>, the music application digest, and the map application digest in the message push request.

During a specific implementation, the message push request may be read by using a push system <NUM> in the message pusher <NUM>, to obtain the declaration information, the identifier of the music application <NUM>, the identifier of the map application <NUM>, the music application digest, and the map application digest; and the declaration information, the identifier of the music application <NUM>, the identifier of the map application <NUM>, the music application digest, and the map application digest may be sent to the verification system <NUM> in the message pusher <NUM>, so that the verification system <NUM> can perform verification based on the declaration information, the identifier of the music application <NUM>, the identifier of the map application <NUM>, the music application digest, and the map application digest.

Optionally, before verifying the message push request, the message pusher <NUM> may further perform identity verification based on signature information in the message push request, where the signature information may be used to verify validity of an identity of the message provider <NUM>. If the signature verification succeeds, it indicates that the identity of the message provider <NUM> is legal, and further verification may be performed to determine to which message receivers <NUM> the message provider <NUM> can push the to-be-pushed message. If the signature verification fails, the message pusher <NUM> may directly end the verification, and may return a failure message to the message provider <NUM>, to notify the message provider <NUM> that the message push task fails.

It should be noted that the JWT may be further applied to another scenario. Therefore, in the application scenario of this embodiment of this application, a verification interface corresponding to the JWT, for example, a first interface, may be added between the message provider <NUM> and the message pusher <NUM>, and the first interface may be configured to transmit the JWT. A code example is as follows:
<IMG>.

Step <NUM>: The message pusher <NUM> performs query based on the identifier of the music application <NUM> and the identifier of the map application <NUM>, to obtain a music application key corresponding to the identifier of the music application <NUM> and a map application key corresponding to the identifier of the map application <NUM>.

Specifically, because the mapping relationship between the application and the application key is stored in the local database of the message pusher <NUM>, after obtaining the identifier of the music application <NUM> and the identifier of the map application <NUM> by reading, the message pusher <NUM> may query the mapping relationship in the local database of the message pusher <NUM> based on the identifier of the music application <NUM> and the identifier of the map application <NUM>, to obtain the music application key corresponding to the identifier of the music application <NUM> and the map application key corresponding to the identifier of the map application <NUM>.

In a specific implementation, the local database may be disposed in the verification system <NUM> in the message pusher <NUM>. Therefore, after receiving the identifier of the music application <NUM> and the identifier of the map application <NUM> that are sent by the push system <NUM>, the verification system <NUM> may perform query in the local database of the verification system <NUM> based on the identifier of the music application <NUM> and the identifier of the map application <NUM>, to obtain the music application key corresponding to the identifier of the music application <NUM> and the map application key corresponding to the identifier of the map application <NUM>.

It should be noted that, if either of the music application key corresponding to the identifier of the music application <NUM> and the map application key corresponding to the identifier of the map application <NUM> is not found through query by the verification system <NUM>, it may be considered that the message push request is invalid. Therefore, the verification system <NUM> may send a verification failure message to the push system <NUM>. After receiving the verification failure message, the push system <NUM> may end the verification and feed back a failure message to the message provider <NUM>, to notify the message provider <NUM> that the message push task fails.

Step <NUM>: The message pusher <NUM> performs digest extraction on the declaration information, the identifier of the music application <NUM>, and the identifier of the map application <NUM> by using the music application key, to generate a music application digest, and performs digest extraction on the declaration information, the identifier of the music application <NUM>, and the identifier of the map application <NUM> by using the map application key, to generate a map application digest.

Specifically, after obtaining the music application key and the map application key by query, the message pusher <NUM> may perform digest extraction on the declaration information, the identifier of the music application <NUM>, and the identifier of the map application <NUM> by using the music application key, to generate the corresponding music application digest, and perform digest extraction on the declaration information, the identifier of the music application <NUM>, and the identifier of the map application <NUM> by using the map application key, to generate the corresponding map application digest. A digest extraction manner may be the same as the manner in step <NUM>, for example, an HASHMAC512 manner, and details are not described herein again.

Step <NUM>: The message pusher <NUM> compares the music application digest generated at the message pusher <NUM> with the music application digest in the message push request, and compares the map application digest generated at the message pusher <NUM> with the map application digest in the message push request.

Specifically, after generating the music application digest and the map application digest, the message pusher <NUM> may compare the generated music application digest with the music application digest in the message push request, and compare the generated map application digest with the map application digest in the message push request, to verify the message push request.

Step <NUM>: If both the music application digest comparison and the map application digest comparison succeed, the message pusher <NUM> pushes the to-be-pushed message to the message receiver <NUM> on which the music application <NUM> and/or the map application <NUM> are/is installed.

Specifically, if both the music application digest comparison and the map application digest comparison succeed, for example, the music application digest generated by the message pusher <NUM> is consistent with the music application digest in the message push request, and the map application digest generated by the message pusher <NUM> is consistent with the map application digest in the message push request, it may be considered that the verification on the message push request succeeds, and the message pusher <NUM> may push the to-be-pushed message to the message receiver <NUM> on which the music application <NUM> and/or the map application <NUM> are/is installed.

Step <NUM>: If either of the music application digest comparison and the map application digest comparison fails, the message pusher <NUM> returns a verification failure message to the message provider <NUM>.

Specifically, if either of the music application digest comparison and the map application digest comparison fails, it may be considered that the verification on the message push request fails. The message pusher <NUM> may send a verification failure message to the message provider <NUM>, to notify the message provider <NUM> that the message push task fails, and end the message push.

In this embodiment, verification is performed at the message pusher <NUM> based on the digest information in the message push request to determine whether the digest information in the message push request is consistent with the digest information generated by the message pusher <NUM>. In addition, it may be further determined whether the to-be-pushed message can be sent to the application corresponding to the application identifier in the message push request. In this way, message crosstalk can be avoided, and security of message push can be improved.

In <FIG> and <FIG>, an example in which the message provider <NUM> sends two to-be-pushed messages respectively corresponding to the music application <NUM> and the map application <NUM> and performs digest comparison is used for description. It may be understood that the message provider <NUM> may push messages to only one or more than two applications, the principles are similar, and details are not described herein again.

The following describes another message push method by using an example in which the message provider <NUM> separately sends two to-be-pushed messages corresponding to the music application <NUM> and the map application <NUM> and compares data sources.

<FIG> is a schematic flowchart of an interaction procedure of another embodiment of a message push method according to this application. The method includes the following steps:.

Step <NUM>: The message provider <NUM> sends an identity registration request to a message pusher <NUM> to obtain an identifier of the message provider <NUM>.

Specifically, the identity registration request may be used by the message provider <NUM> to request to obtain the identifier of the message provider <NUM> from the message pusher <NUM>. It should be noted that the message provider <NUM> has an identifier, and the identifier of the message provider <NUM> is used to identify the message provider <NUM> in a network, but different from the identifier of the message provider, the identifier obtained by the request is used to subsequently verify the message push request at the message pusher <NUM>, where the identifier obtained by the request may be represented by a number. For ease of description, the identifier of the message provider <NUM> mentioned below refers to the identifier requested by the message provider <NUM> or allocated by the message pusher <NUM> to the message provider <NUM>.

The identity registration request may include an identity registration type. The identity registration type is used by the message pusher <NUM> to identify a target object registered by the message provider <NUM> this time. It may be identified, by using the identity registration type, whether to register an identifier for the application or register an identifier for the message provider <NUM> this time. For example, the identity registration type may include an application type and a service party type. If the message pusher <NUM> identifies that the identity registration type is an application type, the message pusher <NUM> may register an identifier for the application, to complete identity registration of the application with the message pusher <NUM>. If the message pusher <NUM> identifies that the type is a service party type, the message pusher <NUM> may register an identifier for the message provider <NUM>, to complete identity registration of the message provider <NUM> with the message pusher <NUM>.

In addition, the identity registration request may further include a data source. The data source may be used to represent a source address of data of each service provided by the message provider <NUM>. The data source may correspond to the message provider <NUM>. For example, the data source may be an address of a target server that stores service data by the message provider <NUM>, for example, assuming that the message provider <NUM> may provide a meal ordering service, a music service, and a map service, addresses of servers that provide the foregoing meal ordering service, music service, and map service may be a same address, that is, a data source corresponding to the message provider <NUM> should be the same as data sources of all applications (for example, a meal ordering application, a music application, and a map application) belonging to the same message provider <NUM>, that is, the data sources are the same, a user may receive the meal ordering service by using the meal ordering application on a mobile terminal, receive the music service by using the music application <NUM> on the mobile terminal, and receive the map service by using the map application <NUM> on the mobile terminal. During a specific implementation, the data source may be represented by using a unique IP address, or may be represented by using a unique ID number. This is not limited in this embodiment of this application.

During a specific implementation, the identity registration request may carry two fields, for example, a data source (source) field and a type (evidence) field. The source field may be used to identify a data source corresponding to the message provider <NUM>, and the evidence field may be used to identify an identity registration type of this registration. The evidence field may include two numeric types, for example, a character type and a numeric type. For example, if a value of the evidence field is a character string NEW_APP, that is, a numeric type of the evidence field is a character type, the message pusher may determine, based on the identity registration request, that the identity registration type is a service party type, that is, the identity is registered for the message provider <NUM> this time.

Further, a registration interface may be further established between the message provider <NUM> and the message pusher <NUM>, so that the message provider <NUM> may invoke the registration interface to transmit the identity registration request and complete the identity registration process. A code example is as follows:
POST /register HTTP/<NUM>
Content-Type: application/json
Accept: application/json
Host: server. com
{
"redirect_uris": [
"https://client. org/callback",
"https://client. org/callback2"],
"client_name": "My Example Client",
"client_name#ja-Jpan-JP":"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
"token_endpoint_auth_method": "client_secret_basic",
"logo_uri": "https://client. png",
"jwks_uri": "https://client. org/my_public_keys. jwks",
"example_extension_parameter": "example_value",
"source": "example_source",
"evidence": "example_evidence"
}.

Step <NUM>: The message pusher <NUM> reads the identity registration request to obtain an identity registration type in the identity registration request.

Step <NUM>: If it is determined that the identity registration type is a service party type, the message pusher <NUM> allocates an identifier of the message provider <NUM> and stores the identifier of the message provider <NUM> after associating the identifier of the message provider <NUM> with the data source in the identity registration request.

Specifically, after receiving the identity registration request, the message pusher <NUM> reads the identity registration request to obtain the data source and the identity registration type in the identity registration request. If it is determined after reading that the identity registration type is the service party type, an identifier may be allocated to the message provider <NUM>, the identifier of the message provider <NUM> may be associated with the data source in the identity registration request and then stored, and then the identifier of the message provider <NUM> may be sent to the message provider <NUM>. The data source stored in association with the identifier of the message provider <NUM> may be considered as a service party data source.

In a specific implementation, the identity registration request of the message provider <NUM> may be directly sent to the verification system <NUM> of the message pusher <NUM>. After receiving the identity registration request, the verification system <NUM> may first read an evidence field in the identity registration request. If a value of the evidence field is a character string, for example, it may be NEW_APP, which may be considered that the identifier of the message provider <NUM> is allocated this time, the verification system <NUM> may allocate an identifier, and the allocated identifier is used as an identifier subsequently used by the message provider <NUM> for verification, where the identifier of the message provider <NUM> may be a number. Then, the verification system <NUM> may store the identifier of the message provider <NUM> in the local database of the verification system <NUM> after associating the identifier of the message provider <NUM> with the source field information in the identity registration request, and return the identifier of the message provider <NUM> to the message provider <NUM>. Therefore, the message provider <NUM> completes the task of registering the identifier of the message provider <NUM> with the message pusher <NUM>.

After parsing out the evidence field information, the verification system <NUM> may further read the source field information, and may query the local database of the verification system <NUM> to check whether a data source corresponding to the source field information already exists. If the data source corresponding to the source field information already exists, in this case, it may be considered that the data source is registered, that is, the current registration request may be ended, and a failure message may be returned to the message provider <NUM>, to notify the message provider that the current registration fails. If the data source corresponding to the source field information does not exist, the identifier of the message provider <NUM> may be allocated.

Step <NUM>: The message pusher <NUM> sends the allocated identifier of the message provider <NUM> to the message provider <NUM>.

Step <NUM>: The message provider <NUM> sends an identifier registration request to the message pusher <NUM>, to obtain an application identifier.

Similarly, the application identifier is different from the identifier of the application, and is an identifier that is requested to be allocated and subsequently used for message push request verification. For ease of description, the application identifier mentioned below refers to an identifier that the message provider <NUM> requests to obtain for the application or that the message pusher <NUM> allocates for the application.

Specifically, after the message provider <NUM> completes registration with the message pusher <NUM>, that is, after obtaining the identifier allocated by the message pusher <NUM>, the message provider <NUM> may further register, by using the identity registration request, the identifier for the application corresponding to the message provider <NUM>. For example, if the message provider <NUM> includes a meal ordering application, a music application, and a map application, the message provider <NUM> may register the meal ordering application, the music application, and the map application, to obtain identifiers corresponding to the meal ordering application, the music application, and the map application. It should be noted that the message provider <NUM> may register an identifier for one application by using one identity registration request, or the message provider <NUM> may separately register identifiers for a plurality of applications by using one identity registration request. This is not specially limited in this embodiment of this application.

In a specific implementation, as described above, because the identifier allocated to the message provider <NUM> may be represented by a number, the value of the evidence field may be set to the identifier of the message provider <NUM>, that is, the numeric type of the evidence field is the numeric type representing the identifier of the message provider <NUM>, so that the message pusher <NUM> may determine, based on the identity registration request, that the identity registration type is the application type. That is, it indicates that the identifier is registered for the corresponding application in the message provider <NUM> this time, and it may also indicate that the currently registered application is associated with the message provider <NUM> corresponding to the value of the evidence field. For example, assuming that a message provider corresponding to a value of the evidence field is AA, an identifier may be registered for a music application <NUM> to which the message provider AA belongs, or an identifier may be registered for a map application <NUM> to which the message provider AA belongs, or an identifier may be registered for another application (a meal ordering application) to which the message provider AA belongs.

Step <NUM>: If it is determined that the current identity registration type is the application type, the message pusher <NUM> allocates an application identifier and stores the application identifier after associating the application identifier with the data source.

Specifically, if the message pusher <NUM> determines, by reading the identity registration request, that the identity registration type is the application type, the message pusher <NUM> may allocate the application identifier, and store the application identifier after associating the application identifier with the data source, and then send the application identifier to the message provider <NUM>. The data source stored in association with an application may be considered as an application data source. For example, the data source stored in association with the music application may be considered as a music application data source, the data source stored in association with the map application may be considered as a map application data source, and the data source stored in association with the meal ordering application may be considered as a meal ordering application data source or the like.

In a specific implementation, the identity registration request of the message provider <NUM> may be directly sent to the verification system <NUM> of the message pusher <NUM>. After receiving the identity registration request, the verification system <NUM> may first read the evidence field in the identity registration request. If the value of the evidence field is a number, in this case, it may be considered that the application identifier is allocated this time. As described above, the value of the evidence field may be an identifier of the message provider <NUM>. It may be determined that an identifier is allocated to the application, and it may be further known that the application registered this time is an application corresponding to the message provider <NUM> corresponding to the numeric value in the evidence field. Then, the local database in the verification system <NUM> may be queried based on the identifier of the message provider <NUM> in the evidence field, to obtain the service party data source corresponding to the identifier of the message provider <NUM>. In addition, the data source obtained through query may be compared with the data source corresponding to the source field information in the identity registration request. If the service party data source obtained through query is inconsistent with the data source corresponding to the source field information in the identity registration request, the registration request may be ended. In addition, a failure message may be returned to the message provider <NUM> to notify the message provider that the registration fails. If the service party data source obtained through query is consistent with the data source corresponding to the source field information in the identity registration request, an application identifier may be allocated, and the application identifier is stored after being associated with the data source corresponding to the source field information in the identity registration request, and the application identifier is sent to the message provider <NUM>, so that the message provider <NUM> completes the task of registering the application identifier with the message pusher <NUM>.

Step <NUM>: The message pusher <NUM> sends the allocated application identifier to the message provider <NUM>.

Step <NUM>: The message provider <NUM> sends the message push request and the to-be-pushed message to the message pusher <NUM>.

Specifically, after completing the identity registration task, the message provider <NUM> may send the message push request and the to-be-pushed message to the message pusher <NUM>. For example, the message push request may include an identifier of the message provider <NUM>, an identifier of the music application <NUM>, and an identifier of the map application <NUM>, and the message push request may be in a form of a JWT.

Description is now provided with reference to <FIG>. As shown in <FIG>, the JWT may include a header, a payload, and a signature. The JWT header may include a plurality of fields. For example, the JWT header may include an application identifier field (sub) and a message provider identifier field (aud), where the sub field is used to identify a location of the application identifier in the payload, and the aud field is used to identify a location of the message provider identifier in the payload. The payload may include data information corresponding to the field information. For example, the data information may include application identifier information (for example, the identifier of the music application <NUM> and the identifier of the map application <NUM>) corresponding to the sub field, and the identifier information of the message provider <NUM> corresponding to the aud field.

Step <NUM>: The message pusher <NUM> reads the message push request, and obtains the identifier of the message provider <NUM>, the identifier of the music application <NUM>, and the identifier of the map application <NUM>.

Specifically, after receiving the message push request, the message pusher <NUM> may read the message push request, to obtain the application identifier (for example, the identifier of the music application <NUM> and the identifier of the map application <NUM>) and the identifier of the message provider <NUM> in the message push request.

In a specific implementation, the message provider <NUM> may send the message push request to the push system <NUM> of the message pusher <NUM>. Therefore, a second interface may be established between the message provider <NUM> and the push system <NUM> to transmit the message push request. A code example is as follows:
<IMG>.

Step <NUM>: The message pusher <NUM> performs query, based on the identifier of the music application <NUM>, the identifier of the map application <NUM>, and the identifier of the message provider <NUM>, to obtain a music data source corresponding to the identifier of the music application <NUM>, a map data source corresponding to the identifier of the map application <NUM>, and the service party data source corresponding to the identifier of the message provider <NUM>.

Specifically, after obtaining the identifier of the message provider <NUM>, the identifier of the music application <NUM>, and the identifier of the map application <NUM> in the message push request, the message pusher <NUM> may obtain, by query, the application data source corresponding to the identifier of the music application <NUM> and the identifier of the map application <NUM> (for example, the music application data source corresponding to the identifier of the music application <NUM> and the map application data source corresponding to the identifier of the map application <NUM>), and the service party data source corresponding to the identifier of the message provider <NUM>.

In a specific implementation, after obtaining the identifier of the music application <NUM>, the identifier of the map application <NUM>, and the identifier of the message provider <NUM> through reading, the push system <NUM> of the message pusher <NUM> may send the identifier of the music application <NUM>, the identifier of the map application <NUM>, and the identifier of the message provider <NUM> to the verification system <NUM>. After receiving the identifier of the music application <NUM>, the identifier of the map application <NUM>, and the identifier of the message provider <NUM>, the verification system <NUM> may query the local database of the verification system <NUM> to respectively obtain the music application data source, the map application data source, and the service party data source corresponding to the identifier of the music application <NUM>, the identifier of the map application <NUM>, and the identifier of the message provider <NUM>.

Further, when the verification system <NUM> queries, if at least one of the music application data source, the map application data source, and the service party data source does not exist, it may be considered that a counterfeiter exists in the current identifier of the music application <NUM>, the identifier of the map application <NUM>, and the identifier of the message provider <NUM>. Therefore, the verification may be ended, and a verification failure message may be returned to the push system <NUM>. After receiving the verification failure message, the push system <NUM> may stop the message push task, and may return a failure message to the message provider <NUM>.

Step <NUM>: The message pusher <NUM> compares the music application data source, the map application data source, and the service party data source.

Specifically, the data source comparison may include separately comparing the music application data source and the map application data source with the service party data source. In a specific implementation, after obtaining the music application data source, the map application data source, and the service party data source by query, the verification system <NUM> of the message pusher <NUM> may separately compare the music application data source and the map application data source with the service party data source. For example, the music application data source may be first compared with the service party data source, and then the map application data source is compared with the service party data source; or the map application data source may be first compared with the service party data source, and then the music application data source may be compared with the service party data source. Alternatively, the music application data source may be compared with the service party data source and the map application data source may be compared with the service party data source at the same time. This is not specially limited in this embodiment of this application.

Step <NUM>: If the data sources are consistent through comparison, push the to-be-pushed message sent by the message provider <NUM> to the message receiver <NUM> on which the music application <NUM> and/or the map application <NUM> are/is installed.

Specifically, if the data sources are consistent through comparison, the message pusher <NUM> may push the to-be-pushed message sent by the message provider <NUM> to the message receiver <NUM> on which the music application <NUM> and/or the map application <NUM> are/is installed. For example, if the music application data source is consistent with the service party data source through comparison, and the map application data source is consistent with the service party data source through comparison, it may be considered that the data sources are consistent through comparison.

During a specific implementation, the foregoing data sources are compared in the verification system <NUM> to determine that the foregoing data sources are consistent. For example, if the music application data source is consistent with the service party data source, and the map application data source is consistent with the service party data source, it may be considered that the verification succeeds. The verification system <NUM> may send a verification success message to the push system <NUM>. After receiving the verification success message from the verification system <NUM>, the push system <NUM> may push the to-be-pushed message received this time to the message receiver <NUM> on which the music application <NUM> and/or the map application <NUM> are/is installed.

Step <NUM>: If at least one group of data sources in the foregoing data source comparison are inconsistent, end the message push task, and return a verification failure message to the message provider <NUM>.

Specifically, if at least one group of data sources in the foregoing data source comparison are inconsistent, it may be considered that the verification fails, and the message pusher <NUM> may end the current message push task. For example, if the music application data source is inconsistent with the service party data source, and/or the map application data source is inconsistent with the service party data source, it may be considered that the data sources are inconsistent.

During a specific implementation, the foregoing data sources are compared in the verification system <NUM>. If it is determined that at least one group of data sources in the foregoing data sources are inconsistent, for example, the music application data source is inconsistent with the service party data source, and/or the map application data source is inconsistent with the service party data source, in this case, it may be considered that the verification fails. The verification system <NUM> may send a verification failure message to the push system <NUM>. If the push system <NUM> receives the verification failure message from the verification system <NUM>, the push system <NUM> may stop the current message push task, and may return a verification failure message to the message provider <NUM>.

In this embodiment, verification is performed at the message pusher <NUM> based on the data source in the message push request, to determine whether the data source of the application corresponding to the to-be-pushed message is consistent with the data source of the message provider. In addition, it may be further determined whether the to-be-pushed message can be sent to the application corresponding to the application identifier in the message push request. In this way, message crosstalk can be avoided, and security of message push can be improved.

<FIG> is a schematic diagram of a structure of a message push apparatus according to an embodiment of this application. As shown in <FIG>, the message push apparatus <NUM> may include a creation module <NUM>, a sending module <NUM>, a receiving module <NUM>, a verification module <NUM>, and a push module <NUM>.

The creation module <NUM> is configured to create a mapping relationship between an application identifier and a preset key.

The sending module <NUM> is configured to send the mapping relationship to a message provider.

The receiving module <NUM> is configured to receive a to-be-pushed message and a message push request that are sent by the message provider, where the message push request includes first information and a first digest used for verification, the first digest is obtained after the message provider performs digest extraction on the first information by using the preset key, and the first information includes at least the application identifier.

The verification module <NUM> is configured to query whether the preset key corresponding to the application identifier in the message push request exists; and if the preset key corresponding to the application identifier exists, perform digest extraction on the first information in the message push request by using the preset key, to obtain a second digest.

The push module <NUM> is configured to compare the second digest with the first digest, and push the to-be-pushed message to a message receiver corresponding to the application identifier if the second digest is consistent with the first digest.

In a possible implementation, the message push apparatus <NUM> may further include a signature verification module <NUM>.

The signature verifying module <NUM> is configured to perform identity authentication on the message push request based on the signature to determine whether an identity of the message provider is legal.

In a possible implementation, the verification module <NUM> may be further configured to: if the preset key corresponding to the application identifier does not exist, terminate push of the current to-be-pushed message.

In a possible implementation, the first information includes a plurality of application identifiers, the message push request includes a plurality of first digests corresponding to the application identifiers, and the verification module <NUM> is further configured to separately perform digest extraction on the first information in the message push request by using preset keys corresponding to the application identifiers, to obtain a plurality of second digests corresponding to the application identifiers.

In a possible implementation, the push module <NUM> may be further configured to compare the first digest and the second digest that correspond to a same application identifier; and if the first digests and the second digests of all the application identifiers are consistent, push the to-be-pushed message to message receivers corresponding to the application identifiers.

<FIG> is a schematic diagram of a structure of another message push apparatus according to an embodiment of this application. As shown in <FIG>, the message push apparatus <NUM> may include a receiving module <NUM>, a verification module <NUM>, and a push module <NUM>.

The receiving module <NUM> is configured to receive a to-be-pushed message and a message push request that are sent by a message provider, where the message push request includes an application identifier and a message provider identifier.

The verification module <NUM> is configured to query whether a first data source corresponding to the application identifier in the message push request and a second data source corresponding to the message provider identifier in the message push request exist.

The push module <NUM> is configured to: if the first data source and the second data source exist, compare the first data source with the second data source, and if the first data source is consistent with the second data source, push the to-be-pushed message to a message receiver corresponding to the application identifier.

In a possible implementation, the message push apparatus <NUM> further includes a registration module <NUM>.

The registration module <NUM> is configured to: receive an identity registration request sent by the message provider, where the identity registration request includes a data source and an identity registration type, and the identity registration type includes a first type and a second type; and if it is determined that the identity registration type is the first type, determine that the data source includes a first data source, allocate a message provider identifier, associate the message provider identifier with the first data source for storage, and send the message provider identifier to the message provider; or if it is determined that the identity registration type is the second type, determine that the data source includes a second data source, allocate an application identifier, associate the application identifier with the second data source for storage, and send the application identifier to the message provider.

In a possible implementation, if it is determined that the identity registration type is the second type, the identity registration request further includes a message provider identifier, and the message push apparatus <NUM> further includes a check module <NUM>.

The check module <NUM> is configured to: perform query based on the message provider identifier to obtain a corresponding first data source; and compare the first data source obtained through query with the second data source in the identity registration request, and determine, based on a comparison result, whether to allocate an application identifier.

In a possible implementation, the message push request includes a plurality of application identifiers, and the push module <NUM> may be further configured to: compare each first data source and each second data source corresponding to the application identifier; and if each first data source is consistent with each second data source, push the to-be-pushed message to message receivers corresponding to the application identifiers.

It should be understood that division of the modules of the message push apparatuses shown in <FIG> and <FIG> is merely logical function division. In an actual implementation, the modules may be all or partially integrated into a physical entity, or may be physically separated. In addition, the modules may be all implemented in a form of software invoked by a processing component, or may be all implemented in a form of hardware; or a part of modules may be implemented in a form of software invoked by a processing component, and another part of modules may be implemented in a form of hardware. For example, a detection module may be an independently disposed processing component, or may be integrated into a chip of an electronic device for implementation. Implementations of other modules are similar to this. In addition, the modules may be all or partially integrated, or may be implemented independently. In an implementation process, steps in the foregoing methods or the foregoing modules can be implemented by using a hardware integrated logical circuit in the processing element, or by using instructions in a form of software.

For example, the foregoing modules may be one or more integrated circuits configured to implement the foregoing method, for example, one or more application-specific integrated circuits (Application-Specific Integrated Circuit, ASIC for short), or one or more microprocessors (Digital Signal Processor, DSP for short), or, one or more field programmable gate arrays (Field Programmable Gate Array, FPGA for short) or the like. For another example, these modules may be integrated and implemented in a form of a system-on-a-chip (System-On-a-Chip, SOC for short).

<FIG> is a schematic diagram of a structure of an electronic device according to an embodiment of this application. A message pusher <NUM> may be the electronic device. As shown in <FIG>, the electronic device may be a data processing device, for example, a server, or may be a circuit device built in the data processing device. The electronic device may be configured to perform functions/steps in the methods provided in embodiments shown in <FIG> of this application.

As shown in <FIG>, the electronic device <NUM> is represented in a form of a general-purpose computing device.

The electronic device may include one or more processors <NUM>, a communications interface <NUM>, a memory <NUM>, a communications bus <NUM> connecting various system components (including the memory <NUM> and the processor <NUM>), a database <NUM>, and one or more computer programs.

The one or more computer programs are stored in the memory, the one or more computer programs include instructions, and when the instructions are executed by the electronic device, the electronic device is enabled to perform the following steps:.

In a possible implementation, the message push request further includes a signature of the message provider, and when the instructions are executed by the electronic device, before comparing the second digest with the first digest, the electronic device further executes the following step:
performing identity authentication on the message provider based on the signature to determine whether an identity of the message provider is legal.

In a possible implementation, when the instructions are executed by the electronic device, the electronic device is further enabled to perform the following step:
if the preset key corresponding to the application identifier does not exist, terminating push of the current to-be-pushed message.

In a possible implementation, the first information includes a plurality of application identifiers, the message push request includes a plurality of first digests corresponding to the application identifiers, and when the instructions are executed by the electronic device, that the electronic device is enabled to perform the step of performing digest extraction on the first information in the message push request by using the preset key, to obtain a second digest includes:
separately performing digest extraction on the first information in the message push request by using preset keys corresponding to the application identifiers, to obtain a plurality of second digests corresponding to the application identifiers.

In a possible implementation, when the instructions are executed by the electronic device, that the electronic device is enabled to perform the step of comparing the second digest with the first digest, and pushing the to-be-pushed message to a message receiver corresponding to the application identifier if the second digest is consistent with the first digest includes:.

An embodiment of this application further provides an electronic device. As shown in <FIG>, the one or more computer programs are stored in the memory, the one or more computer programs include instructions, and when the instructions are executed by the electronic device, the electronic device is enabled to perform the following steps:.

In a possible implementation, when the instructions are executed by the electronic device, before receiving the to-be-pushed message and the message push request that are sent by the message provider, the electronic device is further enabled to perform the following steps:.

In a possible implementation, if it is determined that the identity registration type is the second type, the identity registration request further includes a message provider identifier, and when the instructions are executed by the electronic device, the electronic device is enabled to further perform the following steps:.

In a possible implementation, the message push request includes a plurality of application identifiers, and when the instructions are executed by the electronic device, that the electronic device is enabled to perform the step of comparing the first data source with the second data source, and if the first data source is consistent with the second data source, pushing the to-be-pushed message to a message receiver corresponding to the application identifier includes:.

An embodiment of this application further provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, and when the computer program is run on a computer, the computer is enabled to perform the methods provided in embodiments shown in <FIG> of this application.

In embodiments of this application, the foregoing device and the like may be divided into functional modules based on the foregoing method examples. For example, each functional module may be obtained through division based on each corresponding function, or two or more functions may be integrated into one processing module. The integrated module may be implemented in a form of hardware, or may be implemented in a form of a software functional module. It should be noted that, the module division in embodiments of the present invention is an example and is merely logical function division. There may be another division manner in an actual implementation.

The foregoing descriptions about implementations allow a person skilled in the art to understand that, for the purpose of convenient and brief description, division of the foregoing functional modules is taken as an example for illustration. In actual application, the foregoing functions can be allocated to different modules and implemented according to a requirement, that is, an inner structure of an apparatus is divided into different functional modules to implement all or part of the functions described above. For a detailed working process of the foregoing system, apparatus, and unit, refer to a corresponding process in the foregoing method embodiments, and details are not described herein again.

Function units in embodiments of this application may be integrated into one processing unit, or each of the units may exist alone physically, or two or more units may be integrated into one unit.

When the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, the integrated unit may be stored in a computer-readable storage medium. Based on such an understanding, the technical solutions of embodiments of this application essentially, or the part contributing to the conventional technology, or all or some of the technical solutions may be implemented in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for instructing a computer device (which may be a personal computer, a server, or a network device) or a processor to perform all or some of the steps of the methods described in embodiments of this application. The foregoing storage medium includes any medium that can store program code, for example, a flash memory, a removable hard disk, a read-only memory, a random access memory, a magnetic disk, or an optical disc.

Claim 1:
A message push method, wherein the method comprises:
creating a mapping relationship between an application identifier and a preset key;
sending the mapping relationship to a message provider;
receiving a to-be-pushed message and a message push request that are sent by the message provider, wherein the message push request comprises first information and a first digest used for verification, the first digest is obtained after the message provider performs digest extraction on the first information by using the preset key, and the first information comprises at least the application identifier;
querying whether the preset key corresponding to the application identifier in the message push request exists;
if the preset key corresponding to the application identifier exists, performing digest extraction on the first information in the message push request by using the preset key, to obtain a second digest; and
comparing the second digest with the first digest, and pushing the to-be-pushed message to a message receiver corresponding to the application identifier if the second digest is consistent with the first digest.