CN115622747A - API authorization authentication processing method and device, electronic equipment and storage medium - Google Patents
API authorization authentication processing method and device, electronic equipment and storage medium Download PDFInfo
- Publication number
- CN115622747A CN115622747A CN202211158054.1A CN202211158054A CN115622747A CN 115622747 A CN115622747 A CN 115622747A CN 202211158054 A CN202211158054 A CN 202211158054A CN 115622747 A CN115622747 A CN 115622747A
- Authority
- CN
- China
- Prior art keywords
- application
- api
- digital signature
- service
- party
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
Abstract
The application discloses an API authorization authentication processing method, an API authorization authentication processing device, electronic equipment and a storage medium, and relates to the technical field of big data access, wherein the method comprises the following steps: receiving a service request sent by an application party when a target API of an API authorization platform is called, wherein the service request comprises a first digital signature associated with service request parameters; verifying the first digital signature; under the condition that the first digital signature passes the verification, forwarding the service request to a corresponding service server to obtain a service result returned by the service server; and returning the service result to the application party. The method realizes the verification of the identity of the application party by verifying the first digital signature, realizes the authorization, authentication and management of the API, and reduces the docking cost between the application party and the service provider.
Description
Technical Field
The present application relates to the field of big data access technologies, and in particular, to an API authorization authentication processing method and apparatus, an electronic device, and a storage medium.
Background
With the development of internet technology, more and more service systems are provided, and therefore, more and more services are provided for users. In the related art, an application party and a service system are usually connected, and when the application party initiates a call request, the service system provides a corresponding service according to the request.
However, most service providers use different API (Application Programming Interface) styles, which results in higher interfacing cost between the Application and the service provider.
Disclosure of Invention
The application provides an API authorization authentication processing method, an API authorization authentication processing device, an electronic device and a storage medium, so as to solve at least one of the technical problems in the related art to a certain extent. The technical scheme of the application is as follows:
according to a first aspect of the embodiments of the present application, there is provided an API authorization authentication processing method, which is applicable to an API authorization authentication platform, the method including:
receiving a service request sent by an application party when a target API of the API authorization platform is called, wherein the service request comprises a first digital signature associated with the service request parameters;
verifying the first digital signature;
under the condition that the first digital signature passes verification, forwarding the service request to a corresponding service server to obtain a service result corresponding to the service request returned by the service server;
and returning the service result to the application party.
According to a second aspect of the embodiments of the present application, there is provided an API authorization authentication processing apparatus, including:
the receiving module is configured to receive a service request sent by an application party when a target API of the API authorization platform is called, wherein the service request comprises a first digital signature associated with the service request parameters;
a verification module configured to verify the first digital signature;
the forwarding module is configured to forward the service request to a corresponding service server to obtain a service result corresponding to the service request returned by the service server under the condition that the first digital signature passes verification;
and the sending module is configured to return the service result to the application side.
According to a third aspect of embodiments of the present application, there is provided an electronic apparatus, including: a processor; a memory for storing the processor-executable instructions; wherein the processor is configured to execute the instructions to implement the method according to the above-mentioned embodiment of the present application.
According to a fourth aspect of embodiments herein, there is provided a computer-readable storage medium, in which instructions, when executed by a processor of an electronic device, enable the electronic device to perform a method as described in the above-mentioned embodiments herein.
According to a fifth aspect of embodiments herein, there is provided a computer program product comprising: a computer program which, when executed by a processor, implements a method as described in the above embodiments of the present application.
The technical scheme provided by the embodiment of the application at least has the following beneficial effects: the API authorization and authentication platform can verify the identity of the application party by verifying the first digital signature, if the verification is passed, the application party is indicated to have the authority to call the target API, and the API authorization and authentication management is realized, so that the application party can call the API of the service provider through the API authorization and authentication platform, the docking cost between the application party and the service provider is reduced, the service provider does not need to repeatedly realize API access control logic, and the processing burden of the service provider is reduced.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the application and are not to be construed as limiting the application.
Fig. 1 is a schematic flowchart of an API authorization authentication processing method according to an embodiment of the present application.
Fig. 2 is a schematic diagram of a relationship between an application party, an API authorization and authentication platform, and a service provider according to an embodiment of the present disclosure.
Fig. 3 is a flowchart illustrating an API authorization authentication processing method according to another embodiment of the present application.
Fig. 4 is a flowchart illustrating an API authorization authentication processing method according to another embodiment of the present application.
Fig. 5 is a flowchart illustrating an API authorization authentication processing method according to another embodiment of the present application.
Fig. 6 is a flowchart illustrating an API authorization authentication processing method according to another embodiment of the present application.
Fig. 7 is a schematic view of an interaction flow provided by an embodiment of the present application.
Fig. 8 is a schematic view of another interaction flow provided in the embodiment of the present application.
Fig. 9 is a schematic view of another interaction flow provided in the embodiment of the present application.
Fig. 10 is a schematic structural diagram of an API authorization authentication processing apparatus according to an embodiment of the present application.
Fig. 11 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
Detailed Description
In order to make the technical solutions of the present application better understood by those of ordinary skill in the art, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.
It should be noted that the terms "first," "second," and the like in the description and claims of this application and in the drawings described above are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It should be understood that the data so used may be interchanged under appropriate circumstances such that embodiments of the application described herein may be implemented in sequences other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the application, as detailed in the appended claims.
According to the technical scheme, the data acquisition, storage, use, processing and the like meet relevant regulations of national laws and regulations.
With the development of internet technology, more and more service systems are provided, and therefore, more and more services are provided for users. In the related art, an application party and a service system are usually connected, and when the application party initiates a call request, the service system provides a corresponding service according to the request.
However, the API styles used by most service providers are different, and the interfacing cost between the application and the service provider is high. Moreover, the service system needs to repeatedly implement API access control logic, such as verification, authentication, etc., which is cumbersome. Based on this, the embodiment of the application provides an API authorization authentication processing method.
An API authorization authentication processing method, apparatus, electronic device, and storage medium according to embodiments of the present application are described below with reference to the accompanying drawings. Fig. 1 is a schematic flowchart of an API authorization authentication processing method according to an embodiment of the present application.
The API authorization and authentication processing method is configured in an API authorization and authentication platform, which may be applied to any electronic device, so that the electronic device may perform the API authorization and authentication processing function.
The electronic device may be any device with computing capability, and may be a server or the like, for example.
The API authorization authentication platform can comprise an API access platform, a user authorization authentication system, an API background manager portal, an API monitoring platform and the like.
The API access platform provides protocol conversion adaptation of an external network HTTPS, HTTP2, HTTP and the like to an internal network HTTP protocol or other internal protocols, provides authentication signature verification, signature verification reinforcement, WAF, anti-brushing, current limiting and wind control in the aspect of safety, optimizes mobile access such as SSL encryption and decryption asynchronization, flow control, multi-activity in different places, and provides light weight data aggregation, multi-tenant and the like in other aspects.
The user authorization authentication system can provide authority control in the external interface. For example, an access token is generated for the access of an internal resource transaction interface of a legally registered application, the validity of the access token attached to a third party request is checked, and the authorization of the user to access the personal information of the user is supported.
As shown in fig. 1, the API authorization authentication processing method may include the following steps 101 to 105.
According to the method and the system, the service provider can develop the API according to the unified interface standard and register and issue on the API authorization and authentication platform, therefore, the API authorization and authentication platform can integrate the APIs of a plurality of service providers, the application party can call the API of the service provider through the API authorization and authentication platform, the butt joint cost between the application party and the service provider can be reduced, and the service server does not need to repeatedly realize API access control logic. The application side can be an application client side or an application server side.
In the application, when a certain service provider applies for registering the API, the API authorization and authentication platform may obtain an API registration request, where the registration request may include an identifier of the API to be registered, and the API authorization and authentication platform may query the API database according to the identifier of the API to be registered, so as to determine whether the API to be registered has been registered. If the API database does not contain the identifier of the API to be registered, the identifier of the API to be registered can be added to the API database, and if the API database contains the identifier of the API to be registered, the API is indicated to be registered, and prompt information that the API is registered can be returned to the service provider. Thus, the API authorization authentication platform may integrate APIs of the service provider.
For convenience of understanding, the following description is made with reference to fig. 2, and fig. 2 is a schematic diagram of a relationship between an application party, an API authorization and authentication platform, and a service provider according to an embodiment of the present application.
As shown in fig. 2, a service provider may develop APIs using a unified interface standard and register on a platform, where the service provider may include a cell phone service, a public cloud service, a third party service, and the like.
The service user side may be a front-end application or a back-end service, where the front-end application may be, for example, a front-end PC end, a mobile APP, an applet, and the like, which may initiate a front-end call. The front-end application of the service user can initiate a service request through a uniformly provided JavaScript software development toolkit. And if the service user is the back-end service, initiating a service request by using a Java software development toolkit.
In the application, when the application client or the application server needs to initiate a service request, a target API of the API authorization authentication platform may be called, so that the API authorization authentication platform may receive the service request sent by the application party.
For example, when a user performs a face brushing authentication operation on an application client, the application client needs to use a face brushing authentication service of a third party. For another example, when the user performs an operation of querying the interest rate disclosure information on a certain browser page, the page needs to use an interest rate service of a third party.
In the application, before sending the service request to the API authorization authentication platform, the application may encrypt the service request parameter, or encrypt information related to the service request to generate the first digital signature, and the application may carry the first digital signature in sending the service request to the API authorization authentication platform.
In the application, the API authorization authentication platform can verify the first digital signature according to a preset encryption and decryption rule. For example, if the first digital signature is encrypted by the private key of the application party, the API authorization authentication platform may verify the first digital signature by using the public key paired with the private key of the application party.
In the application, the API authorization authentication platform verifies the first digital signature of the application party, and can determine the identity of the application party and verify whether the transmitted plaintext data is tampered on the basis of verifying the identity.
And 103, forwarding the service request to a corresponding service server to obtain a service result corresponding to the service request returned by the service server under the condition that the first digital signature passes verification.
In the application, if the first digital signature passes the verification, the application party can be considered to have the authority of calling the target API, and the service request is a legal request, the API authorization and authentication platform can forward the service request of the application party to the corresponding service server, and the service server can process the service request and return a service result corresponding to the service request.
Taking fig. 2 as an example, a request initiated by a service user, that is, an application side, is routed to an API of a service provider through authentication and addressing of a platform, so that the service provider can obtain the service request and process the service request.
In practical applications, there may be multiple service providers offering the same business service, and an application party may specify which service provider's business service to invoke. In this application, when the API authorizes the authentication platform to forward the service request, if the service request includes a Uniform Resource Locator (URL), the service request may be forwarded to the specified service server according to the URL.
For example, if the service is configured as my-service, the API Path is empty, the URL of the service server is http:// 127.0.0.1.
Alternatively, in the present application, the request path of the service request may also be determined according to the service requested by the service request, so that the service request is forwarded to the corresponding service server according to the request path of the service request. For example, if the service request is related to the face-brushing authentication, a request path of the service request is determined, and the service request is forwarded to a service server providing the face-brushing authentication service.
Therefore, in the application, the API authorization authentication platform can provide different types of forwarding modes, can forward according to the request path, and can also forward to the appointed service server according to the URL, so that diversified requirements can be met.
And step 104, returning the service result to the application party.
In the application, the API authorization authentication platform may directly return the service result to the application party, or may encrypt the service result and return the encrypted service result to the application party in order to improve data security.
In the embodiment of the application, the service request sent by the application party when the target API of the API authorization platform is called is received, the first digital signature associated with the service request parameter in the service request is verified, and the service request is forwarded to the corresponding service server under the condition that the first digital signature is verified, so that the service result corresponding to the service request returned by the service server is obtained, and the service result is returned to the application party. Therefore, the API authorization authentication platform can verify the identity of the application party by verifying the first digital signature, if the identity passes the verification, the application party has the authority to call the target API, and the API authorization authentication management is realized, so that the application party can call the API of the service provider through the API authorization authentication platform, the docking cost between the application party and the service provider is reduced, the service provider does not need to repeatedly realize API access control logic, and the processing burden of the service provider is reduced.
Fig. 3 is a flowchart illustrating an API authorization authentication processing method according to another embodiment of the present application.
As shown in fig. 3, the API authorization authentication processing method includes:
In the present application, steps 301 to 303 are similar to those described in the above embodiments, and therefore are not described herein again.
And step 304, encrypting the service result by using a first private key of the API authorization authentication platform to obtain a second digital signature.
In order to improve security, in the present application, the API authorization and authentication platform may generate a pair of private key and public key in advance, and the API authorization and authentication platform may encrypt the service result by using its own private key to generate the second digital signature.
And 305, returning the second digital signature to the application party so that the application party verifies the second digital signature by using the first public key corresponding to the first private key.
In the application, the API authorization authentication platform returns the second digital signature to the application party, namely returns the service result after the digital signature to the application party.
If the application party is the application client, the application client can send the second digital signature to the application server, and the application server can verify the second digital signature by using the first public key corresponding to the first private key, which is obtained in advance, namely by using the public key of the API authorization authentication platform. If the verification is passed, the service result is returned by the API authorization authentication platform, and the application server side can return the service result obtained after decryption to the application client side; if the verification is not passed, the service result is not returned by the API authorization authentication platform.
If the application party is the application server, the application server can verify the second digital signature by using the first public key of the API authorization authentication platform, and if the verification is passed, a decrypted service result is obtained.
In the embodiment of the application, when the service result is returned to the application party, the first private key of the API authorization authentication platform may be used to encrypt the service result to obtain the second digital signature, and the second digital signature is returned to the application party, so that the application party obtains a result obtained by verifying the second digital signature by using the first public key corresponding to the first private key. Therefore, the second digital signature is obtained by encrypting the service result, and is returned to the application party, so that the application party can conveniently verify the identity of the API authorization authentication platform, and the safety is improved.
Fig. 4 is a flowchart illustrating an API authorization authentication processing method according to another embodiment of the present application. As shown in fig. 4, the API authorization authentication processing method includes steps 401 to 408.
In the application, the application party may be an application client, when the application client uses a certain service, the application client may send corresponding information to the application server, the application server may encrypt the information with a second private key of the application party to obtain a first digital signature, the application client may call a target API of the API authorization authentication platform according to the first digital signature, the API authorization authentication platform receives the service request, the service request may include the first digital signature, and the first digital signature is generated by encrypting with the second private key of the application party.
In the application, when the application client successfully registers in the API authorization authentication platform, the API authorization authentication platform may generate a public and private key of the application party, that is, the second private key and the second public key, in the tool interface.
In the application, after the application party acquires the second private key and the second public key, the application party can log in the API authorization and authentication platform to register the public key, so that the API authorization and authentication platform can acquire the second public key of the application party.
And step 403, verifying the first digital signature according to the second public key.
In the application, the API authorization authentication platform may decrypt the first digital signature using the second public key of the application to obtain a decryption result, compare the decryption result with the request parameter in the service request, and determine whether the first digital signature passes verification according to the comparison result. If the decryption result is consistent with the request parameter, the first digital signature can be considered to pass the verification; if the decryption result is not consistent with the request parameter, the first digital signature may be considered to be unverified.
In the application, if the first digital signature passes the verification, the service request can be forwarded to the corresponding service server.
And step 406, encrypting the service result by using the first private key of the API authorization authentication platform to obtain a second digital signature.
In the present application, steps 405 to 407 are similar to those described in the above embodiments, and therefore are not described herein again.
And step 408, returning a prompt message that the application party has no authority to call the target API.
In the application, if the first digital signature is not verified, the application party does not have the right to call the target API, and the API authorization authentication platform can return prompt information that the application party does not have the right to call the target API to the application party.
In the embodiment of the application, the first digital signature is generated by encrypting the second private key of the application party, and when the first digital signature is verified, the first digital signature can be verified by obtaining the second public key corresponding to the second private key and according to the second public key, so that the API authorization authentication platform can verify the first digital signature by using the public key of the application party to determine whether the application party has the authority to call the target API, that is, determine whether the service request of the application party is a legal request, thereby realizing API authorization authentication management.
Fig. 5 is a flowchart illustrating an API authorization authentication processing method according to another embodiment of the present application. As shown in fig. 5, the API authorization authentication processing method includes steps 501 to 508.
In the application, an application party may register on an API authorization and authentication platform, and the API authorization and authentication platform may receive a registration request of the application party, where the registration request may include information of the application party, and the API authorization and authentication platform may verify the registration request, that is, perform verification on the information of the application party, and return a first application identifier (APPID) and a first application key (APPSECRET) to the application party when the verification is passed.
The first application identifier may uniquely identify the application party, and the first application identifier may be calculated by a hash algorithm according to the application name and time.
In this application, the application side may be an application server side, and the application server side may encrypt the service request parameter by using a first application key of the application side to generate a first digital signature.
In the application, when an application side encrypts service request parameters by using a first application key, the request parameters can be sequenced from small to large according to a key = value format and ASCII (American standard code for information interchange) code to obtain a first text, the first text is converted into a lower case to obtain a second text, and the first application key is spliced on the second text to obtain a third text; and encrypting the third text by using an MD5 information abstract algorithm to obtain a signature parameter sign, namely the first digital signature.
After the first digital signature is obtained, the application party may splice the first digital signature to the request parameter and send the request parameter to the API authorization platform, that is, the service request may include the first digital signature, the request parameter, and the like.
In this application, the service request further includes a first application identifier of the application party, and the API authorization authentication platform may query, according to the first application identifier, a correspondence between the application identifier of each application party and the application key, so as to determine the first application key corresponding to the first identifier of the application party.
For example, the service request includes a first application identifier a of an application party, and the API authorization and authentication platform may query a corresponding relationship between the application identifier and the application key according to the first application identifier a to determine a first application key corresponding to the first application identifier a.
In the application, the API authorization authentication platform may encrypt the request parameter in the service request by using the same signature algorithm according to the first application key to generate a third digital signature, and may determine that the first digital signature passes verification if the first digital signature is consistent with the third digital signature, and may determine that the first digital signature fails verification if the first digital signature is inconsistent with the third digital signature.
And 507, returning the second digital signature to the application party so that the application party obtains a result of verifying the second digital signature by using the first public key corresponding to the first private key.
And step 508, returning the prompt information that the application side does not have the right to call the target API.
In the present application, steps 505 to 508 are similar to those described in the above embodiments, and therefore are not described herein again.
In this embodiment of the present application, the first digital signature may be generated by encrypting with a first application key of an application side, and when the first digital signature is verified, the corresponding relationship between the application identifier and the application key may be queried according to the first application identifier in the service request to determine the first application key corresponding to the first application identifier, and the request parameter in the service request is encrypted with the first application key to generate a third digital signature, and the first digital signature is verified according to the third digital signature. Therefore, the API authorization authentication platform can verify the first digital signature through the application key of the application party to determine whether the application party has the authority to call the target API, namely, whether the service request of the application party is a legal request, thereby realizing the authorization authentication management of the API.
Fig. 6 is a flowchart illustrating an API authorization authentication processing method according to another embodiment of the present application. As shown in fig. 6, before receiving the service request sent by the application side, the API authorization authentication processing method further includes steps 601 to 607.
In this application, the second application identifier may be the same as the first application identifier, the second application key may be the same as the first application key, and the obtaining manner of the second application identifier and the second application key is also similar to the obtaining manner of the first application identifier and the first application key, and therefore, the details are not repeated here.
In the application, when the application party needs to call the third-party service, the application party can firstly send the API call request to the API authorization and authentication platform, and therefore the API authorization and authentication platform can obtain the API call request of the application party. The call request may include an identifier of the target API, a second application identifier of the application party, a second application key of the application party, and the like.
In step 602, according to the second application identifier and the second application key, the application party is registered in the API authentication platform. Step 603 may be performed if the application party is registered with the API authentication platform, and step 604 may be performed if the application party is not registered with the API authentication platform.
In the application, a corresponding relationship between the application identifier and the application key may be queried according to the second application identifier and the second application key, and if the corresponding relationship includes the second application identifier and the second application key, and the second application identifier corresponds to the second application key, it may be determined that the application party is registered on the API authorization authentication platform, and if the corresponding relationship does not include the second application identifier or the second application key, or the second application identifier does not correspond to the second application key, it may be determined that the application party is not registered on the API authorization authentication platform.
In the application, if the API authorization authentication platform is successfully registered, the application party can specify the API that the application party can call. In the application, if the application party is registered in the API authentication platform, the API authentication platform may query the API list corresponding to the application party. The API list includes an identifier of an API that the application can call.
And step 604, returning prompt information that the application party does not have the authority to call the API of the API authorization authentication platform.
In the application, if the application party is not registered in the API authorization authentication platform, it indicates that the application party does not have the right to call the target API, and the API authorization authentication platform may return a prompt message that the application party does not have the right to call the API of the API authorization authentication platform to the application party.
Step 605 is to determine whether the API list contains the identification of the target API. Step 606 may be performed if the API list includes the identification of the target API, and step 607 may be performed if the API list does not include the identification of the target API.
At step 606, the application is allowed to call the target API.
In the application, if the API list includes the identifier of the target API, it indicates that the application party can call the target API, so that the application party can be allowed to call the target API.
In the application, if the API list does not include the identifier of the target API, it indicates that the application party has registered in the API authorization and authentication platform but does not have the authority to call the target API, and the API authorization and authentication platform may return a prompt message that the application party does not have the authority to call the target API to the application party.
In the embodiment of the application, before receiving a service request sent by an application party, an API call request of the application party may also be obtained, and according to a second application identifier and the second application key in the call request, it is determined whether the application party is registered on the API authorization authentication platform, if the application party is registered on the API authorization authentication platform, an API list corresponding to the application party is queried according to the second application identifier, and if the API list includes an identifier of a target API, the application party is allowed to call the target API. Therefore, before the service request sent by the application party is received, whether the application party has the authority to call the target API can be verified, if the application party is allowed to call the target API, the digital signature in the service request can be further verified, and the safety is further improved.
In an embodiment of the present application, the API authorization and authentication platform may further count interface access information of the API authorization and authentication platform in the target time period, and display the counted interface access information.
The target time period may be, for example, one or more time periods per day, which is not limited in this application.
The received access information may include which APIs are accessed in the target time period, the number of times of accessing the same API, and the like.
In the present application, when the interface is displayed to access information, the information may be displayed in a text form, may be displayed in an icon form, or may be displayed in other forms, which is not limited in the present application.
In the embodiment of the application, the interface access information of the authentication platform is authorized through the API in the target time period, and the interface access information is displayed, so that the access condition of the interface can be observed conveniently.
For convenience of understanding, an application side is taken as an application client side, and a face brushing call is taken as an example, which is described below with reference to fig. 7, and fig. 7 is an interaction flow diagram provided in the embodiment of the present application.
The API authorization authentication platform may include an authentication platform client and an authentication platform server.
As shown in fig. 7, the interaction flow includes steps 701-711.
In step 701, a user initiates a face brushing call.
In step 702, the application client sends an authentication face-refreshing request to the application server.
In the application, the application server side can encrypt the face brushing information by using the private key of the application party and adopting the RSA algorithm to obtain the face brushing information after signature.
And 703, the application server returns the signed face refreshing information to the application client.
Step 704, the application client calls an authentication face-brushing API.
Step 705, the authentication platform client sends an authentication face-refreshing request to the authentication platform server.
And step 706, the authentication platform server finishes face brushing calling.
In the application, the authentication platform server can decrypt the digital signature by using the public key of the application party, and the successful decryption indicates that the authentication face-refreshing request is a legal request. And calling the real face brushing business operation by the authentication platform server side, and encrypting the face brushing result by using the authentication platform private key.
And step 707, the authentication platform server returns the encrypted face refreshing result to the authentication platform client.
In step 708, the authentication platform client returns the encrypted face-brushing result to the application client.
And step 709, the application client synchronizes the encrypted face brushing service result to the application server.
In the application, the application server side can verify the signature of the encrypted face brushing result by using the authentication platform public key, and if the confirmation result can be unlocked by using the platform public key, the application server side returns the final face brushing result to the application client side.
And step 710, the application server returns the final face brushing result to the application client.
And step 711, displaying the final face brushing result by the application client.
For convenience of understanding, the following takes an application side as an application server side and an interest rate query request as an example, and is described with reference to fig. 8, where fig. 8 is another interaction flow diagram provided in the embodiment of the present application.
As shown in fig. 8, the interaction flow includes steps 801-808.
Step 801, a user carries out service operation request to inquire interest rate public information.
Step 802, the application server side obtains the interest rate public information query request.
In the application, the application server encrypts the request parameter by using the application key to generate a digital signature, and the digital signature is spliced behind the request parameter and is sent to the authentication platform together.
Step 803, the application server sends the interest rate public information inquiry request to the authentication platform
Step 804, the authentication platform verifies the signature.
In the application, the authentication platform uses the same signature algorithm, encrypts the request parameter by using the application key to obtain a digital signature (i.e. the third digital signature), and compares the digital signature with the digital signature in the request to determine whether the digital signature in the request passes the verification.
Step 805, if the verification is passed, the authentication platform forwards the interest rate public information inquiry request to the interest rate service server.
In the application, the authentication platform can obtain the query result returned by the interest rate service server.
Step 806, the interest rate service server returns the query result to the authentication platform;
in step 807, the authentication platform encrypts the query result with the platform private key and returns the result to the application server.
Step 808, the application server verifies the signature by the platform public key and returns the query result
Step 809, the application server returns the query result to the application client.
For convenience of understanding, the following takes a personal information range as an example, and the description is made with reference to fig. 9, where fig. 9 is another interaction flow diagram provided by the embodiment of the present application.
As shown in fig. 9, the interaction flow includes steps 901-913.
Step 901, the user performs service operation triggering authorization.
Step 902, the application server applies for user authorization.
The authorization scope of the application is the personal information of the user.
And step 903, the application server attaches the application identifier of the application party and the application callback url to redirect the user to an official authorization page and request an address.
At step 904, the user agrees to authorization.
In the application, the user agrees to authorization, the authorization server receives the user request, verifies the validity of the application callback URL, and generates an authorization code if the application identifier and the application key are correct.
In step 905, the authorization server redirects the authorization code to the callback URL.
In the application, the authorization server redirects the authorization code to the callback URL, and the application server side fetches the authorization code.
At step 906, the application server requests an access token from the authorization server.
In the application, the application server side requests the access token from the authorization server according to the authorization code, the application identifier and the application key so as to obtain the access token.
Step 907, the authentication platform returns an access token to the application server.
In the application, the authentication platform verifies the authorization code, the application identifier and the application key, and returns an access token to the application server. Wherein the validity time of the access token is 30 minutes.
Step 908, the application server sends a request for accessing personal information of the user to the authentication platform.
In the application, the application server side accesses the service interface of the user personal information according to the access token.
The authentication platform verifies the access token and forwards the access user's personal information request to the resource server, step 909.
At step 910, the resource server returns the personal information to the authentication platform.
And step 911, the authentication platform encrypts the personal information by using a platform private key and returns the personal information to the application server.
Step 912, the application server decrypts the encrypted personal information with the platform private key and returns the personal information to the authorization page.
In step 913, the application client displays the personal information.
Corresponding to the API authorization authentication processing method provided in the embodiments of fig. 1 and fig. 3 to fig. 6, the present application also provides an API authorization authentication processing apparatus, and since the API authorization authentication processing apparatus provided in the embodiments of the present application corresponds to the API authorization authentication processing method provided in the embodiments of fig. 1 and fig. 3 to fig. 6, the implementation manner of the API authorization authentication processing method is also applicable to the API authorization authentication processing apparatus provided in the embodiments of the present application, and will not be described in detail in the embodiments of the present application. Fig. 10 is a schematic structural diagram of an API authorization authentication processing apparatus according to an embodiment of the present application.
Referring to fig. 10, the API authentication processing apparatus 1000 may include:
a receiving module 1010 configured to receive a service request sent by an application party when a target API of the API authorization platform is called, where the service request includes a first digital signature associated with the service request parameter;
a verification module 1020 configured to verify the first digital signature;
the forwarding module 1030 is configured to forward the service request to a corresponding service server to obtain a service result corresponding to the service request returned by the service server when the first digital signature is verified;
the sending module 1040 is configured to return the second digital signature to the application party, so that the application party obtains a result of verifying the second digital signature by using the first public key corresponding to the first private key.
In a possible implementation manner of this embodiment of the present application, the sending module 1040 is configured to:
encrypting the service result by using a first private key of the API authorization authentication platform to obtain a second digital signature;
and returning the second digital signature to the application party so that the application party obtains a result of verifying the second digital signature by using the first public key corresponding to the first private key.
In a possible implementation manner of this embodiment of the present application, the first digital signature is generated by encrypting with a second private key of the application side, and the verification module 1020 is configured to:
acquiring a second public key corresponding to the second private key;
and verifying the first digital signature according to the second public key.
In a possible implementation manner of this embodiment of the present application, the first digital signature is generated by encrypting a first application key of the application side, and the verification module 1020 is configured to:
according to a first application identifier in the service request, inquiring the corresponding relation between the application identifier and an application key to determine the first application key corresponding to the first application identifier;
encrypting request parameters in the service request by using the first application key to generate a third digital signature;
and verifying the first digital signature according to the third digital signature.
In a possible implementation manner of this embodiment of the present application, the receiving module 1010 is further configured to receive a registration request sent by the application party;
the sending module 1040 is further configured to return the first application identifier and the first application key to the application party if the registration request is verified.
In a possible implementation manner of this embodiment of the present application, the receiving module 1010 is further configured to obtain an API call request of the application party, where the call request includes an identifier of the target API, a second application identifier of the application party, and a second application key;
the apparatus may further include:
a determining module configured to determine that the application party is registered in the API authorization authentication platform according to the second application identifier and the second application key;
the first query module is configured to query an API list corresponding to the application party according to the second application identifier under the condition that the application party is determined to be registered in the API authorization authentication platform; and allowing the application party to call the target API under the condition that the API list comprises the identification of the target API.
In a possible implementation manner of this embodiment of the present application, the forwarding module 1030 is configured to:
determining a request path corresponding to the service request;
and forwarding the service request to the service server according to the request path.
In a possible implementation manner of this embodiment of the present application, the forwarding module 1030 is configured to:
and under the condition that the service request comprises a uniform resource locator, forwarding the service request to the appointed service server according to the uniform resource locator.
In a possible implementation manner of the embodiment of the present application, the apparatus may further include:
the statistical module is configured to count interface access information of the API authorization authentication platform in a target time period;
a presentation module configured to present the interface access information.
In a possible implementation manner of the embodiment of the present application, the receiving module 1010 is further configured to obtain an API registration request, where the creation request includes an identifier of an API to be registered;
the apparatus may further include:
the second query module is also configured to query an API database according to the identifier of the API to be registered;
an adding module configured to add the identifier of the API to be registered to the API database when the API database does not contain the identifier of the API to be registered.
In the embodiment of the application, the identity of the application party can be verified by verifying the first digital signature, if the identity passes the verification, the application party has the authority to call the target API, and the API authorization authentication management is realized, so that the application party can call the API of the service provider through the API authorization authentication platform, and the docking cost between the application party and the service provider is reduced.
It should be noted that the division of the modules of the above apparatus is only a logical division, and the actual implementation may be wholly or partially integrated into one physical entity, or may be physically separated. And these modules can be realized in the form of software called by processing element; or can be implemented in the form of hardware; and part of the modules can be realized in the form of calling software by the processing element, and part of the modules can be realized in the form of hardware.
Fig. 11 is a schematic structural diagram of an electronic device according to an embodiment of the present application. As shown in fig. 11, the electronic device may include: a transceiver 1101, a processor 1102, a memory 1103.
The processor 1102 executes computer-executable instructions stored by the memory, causing the processor 1102 to perform aspects of the embodiments described above. The processor 1102 may be a general-purpose processor including a Central Processing Unit (CPU), a Network Processor (NP), and the like; but also a digital signal processor DSP, an application specific integrated circuit ASIC, a field programmable gate array FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components.
The memory 1103 is connected to the processor 1102 via a system bus and is used for communicating with each other, and the memory 1103 is used for storing computer program instructions.
The transceiver 1101 may be used to obtain a task to be executed and configuration information of the task to be executed.
The system bus may be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The system bus may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, only one thick line is shown, but this does not mean that there is only one bus or one type of bus. The transceiver is used to enable communication between the database access device and other computers (e.g., clients, read-write libraries, and read-only libraries). The memory may include Random Access Memory (RAM) and may also include non-volatile memory (non-volatile memory).
The API authorization authentication platform provided by the embodiment of the application can be configured in the electronic device.
In an exemplary embodiment, a computer-readable storage medium comprising instructions, such as a memory comprising instructions, executable by a processor of an electronic device to perform a method set forth in any one of the embodiments described above is also provided. Alternatively, the computer readable storage medium may be a ROM, a Random Access Memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like.
In an exemplary embodiment, there is also provided a computer program product comprising a computer program/instructions, characterized in that the computer program/instructions, when executed by a processor, implement the method set forth in any of the above embodiments.
Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the application being indicated by the following claims.
It will be understood that the present application is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the application is limited only by the appended claims.
Claims (23)
1. An API authorization authentication processing method is applied to an API authorization authentication platform, and comprises the following steps:
receiving a service request sent by an application party when a target API of the API authorization platform is called, wherein the service request comprises a first digital signature associated with the service request parameters;
verifying the first digital signature;
under the condition that the first digital signature passes verification, forwarding the service request to a corresponding service server to obtain a service result corresponding to the service request returned by the service server;
and returning the service result to the application party.
2. The method of claim 1, wherein said returning the service result to the application side comprises:
encrypting the service result by using a first private key of the API authorization authentication platform to obtain a second digital signature;
and returning the second digital signature to the application party so that the application party obtains a result of verifying the second digital signature by using the first public key corresponding to the first private key.
3. The method of claim 1, wherein the first digital signature is cryptographically generated using a second private key of the application party, the verifying the first digital signature comprising:
acquiring a second public key corresponding to the second private key;
and verifying the first digital signature according to the second public key.
4. The method of claim 1, wherein the first digital signature is generated cryptographically with a first application key of the application side, the verifying the first digital signature comprising:
according to a first application identifier in the service request, inquiring the corresponding relation between the application identifier and an application key to determine the first application key corresponding to the first application identifier;
encrypting request parameters in the service request by using the first application key to generate a third digital signature;
and verifying the first digital signature according to the third digital signature.
5. The method of claim 4, further comprising:
receiving a registration request sent by the application party;
and returning the first application identification and the first application key to the application party under the condition that the registration request passes the verification.
6. The method of claim 1, further comprising, prior to receiving a service request sent by an application party when calling a target API of the API authorization platform:
obtaining an API call request of the application party, wherein the call request comprises an identifier of the target API, a second application identifier of the application party and a second application key;
determining that the application party is registered in the API authorization authentication platform according to the second application identifier and the second application key;
under the condition that the application party is determined to be registered in the API authorization authentication platform, inquiring an API list corresponding to the application party according to the second application identifier;
and allowing the application party to call the target API under the condition that the API list contains the identification of the target API.
7. The method of claim 1, wherein forwarding the service request to a corresponding traffic server comprises:
determining a request path corresponding to the service request;
and forwarding the service request to the service server according to the request path.
8. The method of claim 1, wherein forwarding the service request to a corresponding traffic server comprises:
and under the condition that the service request comprises a uniform resource locator, forwarding the service request to the appointed service server according to the uniform resource locator.
9. The method of claim 1, further comprising:
counting interface access information of the API authorization authentication platform in a target time period;
and displaying the interface access information.
10. The method of claim 1, further comprising:
acquiring an API registration request, wherein the registration request comprises an identifier of an API to be registered;
inquiring an API database according to the identifier of the API to be registered;
and under the condition that the API database does not contain the identifier of the API to be registered, adding the identifier of the API to be registered to the API database.
11. An API authorization authentication processing apparatus, the apparatus comprising:
the receiving module is configured to receive a service request sent by an application party when a target API of the API authorization platform is called, wherein the service request comprises a first digital signature associated with the service request parameters;
a verification module configured to verify the first digital signature;
the forwarding module is configured to forward the service request to a corresponding service server to obtain a service result corresponding to the service request returned by the service server under the condition that the first digital signature passes verification;
a sending module configured to return the service result to the application side.
12. The apparatus of claim 11, wherein the sending module is configured to:
encrypting the service result by using a first private key of the API authorization authentication platform to obtain a second digital signature;
and returning the second digital signature to the application party so that the application party obtains a result of verifying the second digital signature by using the first public key corresponding to the first private key.
13. The apparatus of claim 11, wherein the first digital signature is generated using a second private key of the application party, and wherein the verification module is configured to:
acquiring a second public key corresponding to the second private key;
and verifying the first digital signature according to the second public key.
14. The apparatus of claim 11, wherein the first digital signature is generated by encrypting with a first application key of the application side, and wherein the verification module is configured to:
according to a first application identifier in the service request, inquiring the corresponding relation between the application identifier and an application key to determine the first application key corresponding to the first application identifier;
encrypting request parameters in the service request by using the first application key to generate a third digital signature;
and verifying the first digital signature according to the third digital signature.
15. The apparatus of claim 14,
the receiving module is further configured to receive a registration request sent by the application party;
the sending module is further configured to return the first application identifier and the first application key to the application party if the registration request is verified.
16. The apparatus of claim 11,
the receiving module is further configured to obtain an API call request of the application party, where the call request includes an identifier of the target API, a second application identifier of the application party, and a second application key;
the device further comprises:
a determining module configured to determine that the application party is registered in the API authorization authentication platform according to the second application identifier and the second application key;
the first query module is configured to query an API list corresponding to the application party according to the second application identifier under the condition that the application party is determined to be registered in the API authorization authentication platform; and allowing the application party to call the target API under the condition that the API list contains the identification of the target API.
17. The apparatus of claim 11, wherein the forwarding module is configured to:
determining a request path corresponding to the service request;
and forwarding the service request to the service server according to the request path.
18. The apparatus of claim 11, wherein the forwarding module is configured to:
and under the condition that the service request comprises a uniform resource locator, forwarding the service request to the appointed service server according to the uniform resource locator.
19. The apparatus of claim 11, further comprising:
the statistical module is configured to count interface access information of the API authorization authentication platform in a target time period;
a presentation module configured to present the interface access information.
20. The apparatus of claim 11,
the receiving module is further configured to obtain an API registration request, where the creation request includes an identifier of an API to be registered;
the device further comprises:
the second query module is also configured to query an API database according to the identifier of the API to be registered;
an adding module configured to add the identifier of the API to be registered to the API database when the API database does not contain the identifier of the API to be registered.
21. An electronic device, comprising:
a processor;
a memory for storing the processor-executable instructions;
wherein the processor is configured to execute the instructions to implement the method of any one of claims 1-10.
22. A computer-readable storage medium whose instructions, when executed by a processor of an electronic device, enable the electronic device to perform the method of any of claims 1-10.
23. A computer program product comprising a computer program, characterized in that the computer program realizes the method according to any of claims 1-10 when executed by a processor.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211158054.1A CN115622747A (en) | 2022-09-22 | 2022-09-22 | API authorization authentication processing method and device, electronic equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211158054.1A CN115622747A (en) | 2022-09-22 | 2022-09-22 | API authorization authentication processing method and device, electronic equipment and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115622747A true CN115622747A (en) | 2023-01-17 |
Family
ID=84859056
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211158054.1A Pending CN115622747A (en) | 2022-09-22 | 2022-09-22 | API authorization authentication processing method and device, electronic equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115622747A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116361753A (en) * | 2023-03-17 | 2023-06-30 | 深圳市东信时代信息技术有限公司 | Authority authentication method, device, equipment and medium |
| CN117331964A (en) * | 2023-12-01 | 2024-01-02 | 成都明途科技有限公司 | Data query method, device, equipment and storage medium |
-
2022
- 2022-09-22 CN CN202211158054.1A patent/CN115622747A/en active Pending
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116361753A (en) * | 2023-03-17 | 2023-06-30 | 深圳市东信时代信息技术有限公司 | Authority authentication method, device, equipment and medium |
| CN116361753B (en) * | 2023-03-17 | 2024-03-22 | 深圳市东信时代信息技术有限公司 | Authority authentication method, device, equipment and medium |
| CN117331964A (en) * | 2023-12-01 | 2024-01-02 | 成都明途科技有限公司 | Data query method, device, equipment and storage medium |
| CN117331964B (en) * | 2023-12-01 | 2024-02-27 | 成都明途科技有限公司 | Data query method, device, equipment and storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10848310B2 (en) | Method and device for identifying user identity | |
| CN110061846B (en) | Method, device and computer readable storage medium for identity authentication and confirmation of user node in block chain | |
| US20190116038A1 (en) | Attestation With Embedded Encryption Keys | |
| CN111556006B (en) | Third-party application system login method, device, terminal and SSO service platform | |
| WO2018164955A1 (en) | Device enrollment protocol | |
| CN115622747A (en) | API authorization authentication processing method and device, electronic equipment and storage medium | |
| EP2696557A1 (en) | System and method for accessing third-party applications based on cloud platform | |
| US20100077467A1 (en) | Authentication service for seamless application operation | |
| WO2015143855A1 (en) | Method, apparatus and system for accessing data resources | |
| WO2020140407A1 (en) | Cloud security-based cloud desktop login method, device, equipment and storage medium | |
| CN110365684B (en) | Access control method and device for application cluster and electronic equipment | |
| KR20170056536A (en) | Providing customer information obtained from a carrier system to a client device | |
| CN111753014B (en) | Identity authentication method and device based on block chain | |
| CN112823503B (en) | Data access method, data access device and mobile terminal | |
| CN109831435B (en) | Database operation method, system, proxy server and storage medium | |
| CN111444551B (en) | Account registration and login method and device, electronic equipment and readable storage medium | |
| CN111628871B (en) | Block chain transaction processing method and device, electronic equipment and storage medium | |
| CN113765906A (en) | Method, equipment and system for one-key login of terminal application program | |
| JP2023518662A (en) | Verifying cryptographically secure claims | |
| CN109657170B (en) | Webpage loading method and device, computer equipment and storage medium | |
| CN114513373A (en) | Trusted data exchange method, device, system, electronic equipment and storage medium | |
| CN112528268B (en) | Cross-channel applet login management method and device and related equipment | |
| CN110399706B (en) | Authorization authentication method, device and computer system | |
| CN112702419A (en) | Data processing method, device, equipment and storage medium based on block chain | |
| CN111510421B (en) | Data processing method and device, electronic equipment and computer readable storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |