WO2016122623A1 - Secure api communication - Google Patents

Secure api communication Download PDF

Info

Publication number
WO2016122623A1
WO2016122623A1 PCT/US2015/013864 US2015013864W WO2016122623A1 WO 2016122623 A1 WO2016122623 A1 WO 2016122623A1 US 2015013864 W US2015013864 W US 2015013864W WO 2016122623 A1 WO2016122623 A1 WO 2016122623A1
Authority
WO
WIPO (PCT)
Prior art keywords
device
api
access token
dynamic
communication
Prior art date
Application number
PCT/US2015/013864
Other languages
French (fr)
Inventor
Yeon WHANG
Original Assignee
Hewlett Packard Enterprise Development Lp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Enterprise Development Lp filed Critical Hewlett Packard Enterprise Development Lp
Priority to PCT/US2015/013864 priority Critical patent/WO2016122623A1/en
Publication of WO2016122623A1 publication Critical patent/WO2016122623A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • G06F21/33User authentication using certificates
    • G06F21/335User authentication using certificates for accessing specific resources, e.g. using Kerberos tickets
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2103Challenge-response

Abstract

An example computing device provides secure Application Programming Interface (API) communication. The example computing device may comprise an API communication engine to communicate with an application executing on a second computing device. The API communication engine may communicate with the application by sending an API call to the second device, the API call comprising a dynamic device access token and first meter information, the first meter information related to first usage of the application. The API communication engine may then receive, from the second computing device, an API response comprising a dynamic first device access token and second meter information, the second meter information related to second usage of the application. The API communication engine may determine whether the communication between the first device and the second device is secure based on a comparison of the API call and the API response.

Description

SECURE API COMMUNICATION

BACKGROUND

[0001 ] Devices communicate with applications using Application Programming Interfaces ("APIs"). An API for an application may comprise a set of API calls that a device may use to interact with the application. Each API call may be associated with a set of functionality and/or other API calls. Use of an API call may specify how an application should act responsive to receiving the call. A conversation between a device and an application (e.g., an application executing on a separate device) may comprise a plurality of API calls sent by the device to the application and a corresponding plurality of API responses sent by the application to the device,

BREF DESCRIPTION OF THE DRAWS GS

[0002] The following detailed description references the drawings, wherein:

[0003] FIG. 1 is a block diagram of an example device engaging in secure API communication;

[0004] FIG. 2 is a block diagram of an example consumer device and provider device engaging in secure API communication;

[0005] FIG. 3A is a flow diagram of an example method for execution by an example consumer device and provider device engaging in secure API communication;

[0006] FIG. 3B is a flow diagram of an example method for execution by an example consumer device and provider device engaging in secure API communication;

[0007] FIG. 4 is a flowchart of an example method for execution by an example consumer device and provider device engaging in secure API communication;

[0008] FIG. 4A is a flowchart of an example method for execution by an example consumer device and provider device engaging in secure API communication;

[0009] FIG. 5 is a block diagram of an example device engaging in secure API communication; and [0010] FIG. 8 is a block diagram of an example device engaging in secure API communication.

DETAILED DESC IPTSON

[001 1 ] The following detailed description refers to the accompanying drawings. Wherever possible, the same reference numbers are used in the drawings and the following description to refer to the same or similar parts, it is to be expressly understood, however, that the drawings are for the purpose of illustration and description only. While several examples are described in this document, modifications, adaptations, and other implementations are possible. Accordingly, the following detailed description does not limit the disclosed examples, instead, the proper scope of the disclosed examples may be defined by the appended claims.

[0012] Devices communicate with applications using Application Programming Interfaces ("APIs"). An API for an application may comprise a set of API calls that a device may use to interact with the application. Each API call may be associated with a set of functionality and/or other API calls. Use of an API call may specify how an application should act responsive to receiving the call. A conversation between a device and an application (e.g., an application executing on a separate device) may comprise a plurality of API calls sent by the device to the application and a corresponding plurality of API responses sent by the application to the device.

[0013] A provider device may provide the application for access by a user via a consumer device. As such API communication may occur between the provider device and the consumer device. A technical challenge may exist in this API communication, as the consumer device may have no knowledge of whether a security breach occurs in the communication, and may be reliant on the provider device to detect breaches and notify the user of the consumer device. Further, the only authentication provided by a user of the consumer device may comprise, for example, authentication via user name and password, authentication tokens, and/or other similar discrete authentication methods.

[0014] Examples disclosed herein provide technical solutions to these technical challenges. An example computing device provides secure Application Programming interface (API) communication. The example computing device may comprise an API communication engine that communicates with an application executing on a second computing device. The API communication engine may communicate with the application by sending an API call to the second device, the API call comprising a dynamic device access token and first meter information, the first meter information related to first usage of the application. The API communication engine may then receive, from the second computing device, an API response comprising a dynamic first device access token and second meter information, the second meter information related to second usage of the application. The API communication engine may determine whether the communication between the first device and the second device is secure based on a comparison of the API call and the API response.

[0015] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. The term "plurality," as used herein, is defined as two or more than two. The term "another," as used herein, is defined as at least a second or more. The term "coupled," as used herein, is defined as connected, whether directly without any intervening elements or indirectly with at least one intervening elements, unless otherwise indicated. Two elements can be coupled mechanically, electrically, or communicatively linked through a communication channel, pathway, network, or system. The term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items, it will also be understood that, although the terms first, second, third, etc. may be used herein to describe various elements, these elements should not be limited by these terms, as these terms are only used to distinguish one element from another unless stated otherwise or the context indicates otherwise. As used herein, the term "includes" means includes but not limited to, the term "including" means including but not limited to. The term "based on" means based at least in part on.

[0016] FIG. 1 is an example first computing device 100 that provides secure API communication. The first computing device 100 may be any type of computing device providing a user interface through which a user can interact with a software application and communicate with a second computing device. For example, first computing device 100 may include a laptop computing device, a desktop computing device, an all-in-one computing device, a tablet computing device, a mobile phone, an electronic book reader, a network-enabled appliance such as a "Smart" television, a server, and/or other electronic device suitable for processing user interactions with an application.

[0017] The various components (e.g., components 110 and 120) depicted in FIG. 1 may be coupled to at least one other component via a network. According to various implementations, the API communication engine 120 and the various components described herein may be implemented in hardware and/or a combination of hardware and programming that configures hardware. The term "engine", as used herein, refers to a combination of hardware and programming that performs a designated function. The hardware of each engine, for example, may include one or both of a processor (e.g., processor 110) and a machine-readable storage medium, while the programming is instructions or code stored on the machine-readable storage medium and executable by the processor to perform the designated function. Furthermore, in FIG. 1 and other Figures described herein, different numbers of components, engines, or entities than depicted may be used.

[0018] API communication engine 120 may facilitate secure communication between the first device 100 and a second device. For example, the API communication engine 120 may facilitate secure communication between the first device 100 and an application executing on the second device. The API communication engine 120 may facilitate authentication and initial communication between the first device 100 and the second device, and may then provide for continued secure communication between the first device 100 and the second device. The API communication engine 120 may provide for secure communication by determining whether a security breach has occurred at the first device 100 and/or at the second device.

[0019] The API communication engine 120 may comprise a set of handlers that may interrupt communication from the first device 100 to the second device. The API communication engine 120 may use the set of handlers to interrupt the communication to insert an API call and/or an API response into the communication, to determine whether a security breach exists based on communication between the first device 100 and the second device, and/or otherwise facilitate provision of secure communication between the first device 100 and the second device. As such, functionality performed by the API communication engine 120 as described herein may be performed responsive to the set of handlers interrupting the communication between the first device and the second device.

[0020] API communication engine 120 may facilitate authentication and initial communication between the first device 100 and the second device. For example, the API communication engine 120 may require an initial authentication of a user using the first device 100 based on a usemame and password, an authentication token, biometric authentication, any combination thereof, and/or other authentication techniques.

[0021 ] Responsive to the initial authentication being verified, the API communication engine 120 may send an initial API call from the first device 100 to the second device. Each API call (including an initial API call and subsequent API calls) may comprise, for example, a first dynamic access token related to the first device, metering information related to usage of the application, a second dynamic access token related to the second device, and a security label indicating a security status of the first device.

[0022] The initial API call may comprise a first dynamic access token generated by the first device 100, a security label indicating that the communication is new, and/or other information. The initial API call may have null or empty values for the metering information and the second dynamic access token. In some examples, the initial API call may also comprise a user authentication credential. The API communication engine 120 may store the first dynamic access token for later verification of an incoming initial API response from the second device.

[0023] The second device may authenticate the user (e.g., based on the user authentication credential).

[0024] Responsive to the second device not authenticating the user (e.g., based on the user authentication credential not being authorized), the second device may indicate that a breach has occurred. For example, the second device may indicate that a breach has occurred by facilitating provision of an alert to the user to notify the user of a security breach and/or force the user to perform authentication again. The alert may be provided to the user via a communication method separate from the communication method between the first device 100 and the second device (e.g., via email, text, and/or other separate communication method). In some examples, the alert may be provided to a separate device of the user. The alert may provide information which may be needed for the authentication of the user. For example, the alert may comprise a token, information, and/or other data that may need to be entered at the first device 100 and verified by the first device 100 and/or the second device in order for the authentication to be validated. Responsive to the authentication being validated, the API communication engine 120 may again facilitate the initial communications between the first device 100 and the second device.

[0025] Responsive to authenticating the user, the second device may respond to the initial API call by saving the first dynamic access token received in the initial API call and by sending the first device an initial API response. Each API response (including an initial API response and subsequent API response) may comprise, for example, a first dynamic access token related to the first device, metering information related to usage of the application, a second dynamic access token related to the second device, and a security label indicating a security status of the second device. The initial API response may comprise first metering information, a second dynamic access token, and a security label. The initial API response may comprise a null or empty value for the first dynamic access token. The second device may store the second dynamic access token for later verification of an incoming API call from the first device.

[0028] Responsive to receiving the initial API response, the API communication engine 120 of the first device 100 may store the metering information, the second dynamic access token, and/or other information from the initial API response.

[0027] Responsive to receiving the initial API response and storing the relevant information, the API communication engine 120 may engage in continued communication with the second device. The API communication engine 120 may generate a first API call and send the first API call to the second device. As mentioned above, each API call may comprise a plurality of fields including, for example, a first dynamic access token related to the first device, metering information related to usage of the application, a second dynamic access token related to the second device, and a security label indicating a security status of the first device.

[0028] An API call used in communication after the initial communication between the first device 100 and the second device may comprise values for each field of the API call. The API communication engine 120 may generate the first dynamic access token for the API call. The API communication engine 120 may generate the first dynamic access token using a random generator, based on information associated with the first device 100, a combination thereof, and/or by other token generation methods.

[0029] The API communication engine 120 may determine metering information related to usage of the application based on metering information received from a previous API response (e.g., from the initial API response or the immediately previously received API response). The metering information of the API call may comprise, for example, information related to a total amount of data communicated between the first device 100 and the second device, an amount of data communicated during the immediately prior API call and API response, a total amount of communications between the first device 100 and the second device, and/or any other measurement of the usage of the application. In some examples, the API communication engine 120 may also determine the metering information based on metering information stored from one or more previously received API responses.

[0030] The API communication engine 120 may select the previous second dynamic access token from the immediately previously received API response as the second dynamic access token for the API call.

[0031 ] The API communication engine 120 may determine a security label for the API call based on a determination of whether a security breach occurred with the immediately previously received API response. Examples of security labels include "new," "no breach," "breach,", and/or other security labels that indicate a security status of the first device 100.

[0032] Responsive to receiving the API call from the first device 100, the second device may determine whether a security breach occurred regarding the received API call. The second device may determine whether a security breach occurred by comparing the second dynamic access token of the received APi call with the second dynamic access token generated for the previously sent API response from the second device. In some examples, the second device may store a set of second dynamic access tokens generated for a set of previously sent API responses. The second device may determine whether the security breach occurred by comparing the second dynamic access token of the received API call with the set of second dynamic access tokens. The set of second dynamic access tokens may comprise a predetermined number of second dynamic access tokens. The predetermined number of second dynamic access tokens may depend upon a latency of communication between the first device 100 and the second device.

[0033] Responsive to the received second dynamic access token not matching the previously generated second dynamic access token (or any of the set of second dynamic access tokens), the second device may generate an alert indicating that a security breach has occurred and/or may force authentication of the user of the first device 100. The alert may be generated and used in a manner the same as or similar to the alert generated responsive to failed authentication at the first device. Authentication may be forced in a manner the same as or similar to that described above as well.

[0034] Responsive to the received second dynamic access token matching the previously generated second dynamic access token (or any of the set of second dynamic access tokens), the second device may determine whether the metering information received in the API call corresponds to metering information of the second device (e.g., metering information stored at the second device, metering information included in the immediately previously sent APi response, metering information related to current usage of the application executing on the second device, and/or some other measurement of usage of the application). The received metering information may correspond to the metering information of the second device based on calculations performed based on the received metering information and the metering information of the second device. For example, the second device may determine that the metering information corresponds responsive to an addition of an amount of usage of the application since the immediately previously sent API response and the received metering information equal the current amount of usage of the application.

[0035] Responsive to the received metering information not corresponding to the metering information of the second device, the second device may generate an alert indicating that a security breach has occurred and/or may force authentication of the user of the first device 100. Again, the alert may be generated used in a manner the same as or similar to the alert generated responsive to failed authentication at the first device and authentication may be forced in a manner the same as or similar to that described above.

[0036] Responsive to the received metering information corresponding to the metering information of the second device, the second device may determine that no security breach has occurred.

[0037] Responsive to determining that no security breach has occurred, the second device may then generate and send a first API response to the first device 100. The second device may also store the first dynamic access token of the API call. As mentioned above, each API response may comprise, for example, a first dynamic access token related to the first device, metering information related to usage of the application, a second dynamic access token related to the second device, and a security label indicating a security status of the first device.

[0038] An API response used in communication after the initial communication between the first device 100 and the second device may comprise values for each field of the API response. The second device may select the previous first dynamic access token from the immediately previously received API call as the first dynamic access token for the API response.

[0039] The second device may determine metering information related to usage of the application based on metering information received from a previous API response (e.g., from the initial API response or the immediately previously received API response), metering information stored at the second device, and/or may otherwise determine metering information. The metering information of the API response may comprise, for example, information related to a total amount of data communicated between the first device 100 and the second device, an amount of data communicated during the immediately prior API call and API response, a total amount of communications between the first device 100 and the second device, and/or any other measurement of the usage of the application.

[0040] The second device may generate the second dynamic access token for the API response. The second device may generate the second dynamic access token using a random generator, based on information associated with the second device, a combination thereof, and/or by other token generation methods.

[0041 ] The second device may determine a security label for the API response based on a determination of whether a security breach occurred with the immediately previously received API call. Examples of security labels include "new," "no breach," "breach,", and/or other security labels that indicate a security status of the second device.

[0042] The second device may send the generated API response to the first device 100. Responsive to receiving the generated API response from the second device, the API communication engine 120 of the first device 100 may determine whether a security breach occurred regarding the received API response. The API communication engine 120 may determine whether a security breach occurred by comparing the first dynamic access token of the received API response with the first dynamic access token generated for the previously sent API call from the first device 100. In some examples, the API communication engine 120 may store a set of first dynamic access tokens generated for a set of previously sent API calls. The API communication engine 120 may determine whether the security breach occurred by comparing the first dynamic access token of the received API call with the set of first dynamic access tokens. The set of first dynamic access tokens may comprise a predetermined number of first dynamic access tokens. The predetermined number of first dynamic access tokens may depend upon a latency of communication between the first device 100 and the second device.

[0043] Responsive to the received first dynamic access token not matching the previously generated first dynamic access token (or any of the set of first dynamic access tokens), the API communication engine 120 may generate an alert indicating that a security breach has occurred and/or may force authentication of the user of the first device 100. The alert may be generated and used in a manner the same as or similar to the alert generated responsive to failed authentication at the first device 100, Authentication may be forced in a manner the same as or similar to that described above as well.

[0044] Responsive to the received first dynamic access token matching the previously generated first dynamic access token (or any of the set of first dynamic access tokens), the API communication engine 120 may determine whether the metering information received in the API response corresponds to metering information of the first device 100 (e.g., metering information stored at the first device 100, metering information included in the immediately previously sent API call, metering information related to current usage of the application executing on the second device, and/or some other measurement of usage of the application). The received metering information may correspond to the metering information of the first device 100 based on calculations performed based on the received metering information and the metering information of the first device 100. For example, the API communication engine 120 may determine that the metering information corresponds responsive to an addition of an amount of usage of the application since the immediately previously sent API call and the received metering information equal the current amount of usage of the application.

[0045] Responsive to the received metering information not corresponding to the metering information of the first device 100, the API communication engine 120 may generate an alert indicating that a security breach has occurred and/or may force authentication of the user of the first device 100. Again, the alert may be generated and used in a manner the same as or similar to the alert generated responsive to failed authentication at the first device and authentication may be forced in a manner the same as or similar to that described above as well.

[0046] Responsive to the received metering information corresponding to the metering information of the first device 100, the API communication engine 120 may determine that no security breach has occurred.

[0047] The first device 100 and the second device may continue to engage in secured API communication in the manner described above.

[0048] In performing their respective functions, engine 120 may access data stored in a non-transitory machine-readable storage medium of first device 100. The non-transitory machine-readable storage medium of first device 100 may represent any memory accessible to first device 100 that can be used to store and retrieve data. The non-transitory machine-readable storage medium of first device 100 and/or other database may comprise random access memory (RAM), read-only memory (ROM), electrically-erasable programmable read-only memory (EEPROM), cache memory, floppy disks, hard disks, optical disks, tapes, solid state drives, flash drives, portable compact disks, and/or other storage media for storing computer-executable instructions and/or data. In some examples, the first device 100 may access non-transitory machine- readable storage medium locally or remotely via a network.

[0049] The non-transitory machine-readable storage medium of first device 100 may include a database to organize and store data. The non-transitory machine-readable storage medium of first device 100 may be, include, or interface to, for example, a relational database. The database may reside in a single or multiple physical device(s) and in a single or multiple physical location(s). The database may store a plurality of types of data and/or files and associated data or file description, administrative information, or any other data.

[0050] In some examples, the non-transitory machine-readable storage medium of first device 100 may be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. In some implementations, the non-transitory machine-readable storage medium of first device 100 may be a non-transitory storage medium, where the term "non- transitory" does not encompass transitory propagating signals. The non- transitory machine-readable storage medium of first device 100 may be implemented in a single device or distributed across devices. Likewise, processor 1 10 may represent any number of processors capable of executing instructions stored by the machine-readable storage medium. The processor 110 may be integrated in a single device or distributed across devices. Further, the machine-readable storage medium may be fully or partially integrated in the same device as the processor 1 10, or it may be separate but accessible to that device and the processor 110.

[0051 ] In one example, the machine-readable storage medium may comprise instructions that may be part of an installation package that when installed can be executed by processor 1 10 to implement the functionality described herein. For example, the machine-readable storage medium may be a portable medium such as a floppy disk, CD, DVD, or flash drive or a memory maintained by a server from which the installation package can be downloaded and installed. In another example, the program instructions may be part of an application or applications already installed. Here, the machine-readable storage medium may include a hard disk, optical disk, tapes, solid state drives, RAM, ROM, EEPROM, or the like.

[0052] The processor 1 10 may be at least one centra! processing unit (CPU), microprocessor, and/or other hardware device suitable for retrieval and execution of instructions stored in the machine-readable storage medium. The processor 1 10 may fetch, decode, and execute program instructions. As an alternative or in addition to retrieving and executing instructions, the processor 110 may include at least one electronic circuit comprising a number of electronic components for performing the functionality of at least one of instructions.

[0053] FIG. 2 is an example first computing device 100 and a second computing device 200 that each provide secure API communication. In this example, the first computing device 100 may comprise a consumer device that accesses an application executing on second computing device 200, which may act as a provider device. The first computing device 100 may be the same as or similar to the first device 100 of FIG. 1. The second computing device 200 may comprise an API communication engine 220 that performs functionality the same as or similar to the functionality performed by the second device described in FIG. 1.

[0054] The first computing device 100 may communicate with second computing device 200 over a network 50. in some examples, the first computing device 100 may be any type of computing device providing a user interface through which a user can interact with a software application and communicate with a second device. For example, first computing device 100 may include a laptop computing device, a desktop computing device, an all-in- one computing device, a tablet computing device, a mobile phone, an electronic book reader, a network-enabled appliance such as a "Smart" television, and/or other electronic device suitable for processing user interactions with the second device 200.

[0055] The second computing device 200 may similarly comprise a laptop computing device, a desktop computing device, an all-in-one computing device, a tablet computing device, a mobile phone, an electronic book reader, a network-enabled appliance such as a "Smart" television, server, and/or other electronic device suitable for processing user interactions with the second device 200. While second computing device 200 is depicted as a single computing device, second computing device 200 may include any number of integrated or distributed computing devices serving at least one software application for consumption by first computing device 100.

[0058] Similar to the components of first device 100, the various components (e.g., components 210 and 220) depicted in second device 200 of FIG. 2 may be coupled to at least one other component via a network (e.g., network 50). According to various implementations, the API communication engine 220 and the various components described herein may be implemented in hardware and/or a combination of hardware and programming that configures hardware. As mentioned above, the term "engine", as used herein, refers to a combination of hardware and programming that performs a designated function. The hardware of each engine, for example, may include one or both of a processor (e.g., processor 210) and a machine-readable storage medium, while the programming is instructions or code stored on the machine-readable storage medium and executable by the processor to perform the designated function. The processor 210 and the machine-readable storage medium of second device 200 may comprise components and functionality the same as or similar to the respective processor 1 10 and machine-readable storage of the respective processor 110 and machine-readable storage medium of the first device 100.

[0057] API communication engine 220 may facilitate secure communication between the first device 100 and a second device. For example, the API communication engine 220 may facilitate secure communication between the first device 100 and an application executing on the second device 200. The API communication engine 220 may facilitate authentication and initial communication between the first device 100 and the second device 200, and may then provide for continued secure communication between the first device 100 and the second device 200. The API communication engine 220 may provide for secure communication by determining whether a security breach has occurred at the first device 100 and/or at the second device. [0058] FIGS. 3A and 3B are flow diagrams of an example method for execution by an example consumer device and provider device engaging in secure API communication. Although execution of the methods described below are with reference to system described in FIG. 2, other suitable devices for execution of this method may be employed to practice the present techniques. The flow diagram described in FIG. 3A and other figures may be implemented in the form of executable instructions stored on a machine- readable storage medium, such as the storage medium of the hypervisor, by one or more components described herein, and/or in the form of electronic circuitry.

[0059] The various processing blocks and/or data flows depicted in FIG. 3A (and in the other drawing figures such as FIG. 4) are described in greater detail herein. The described processing blocks may be accomplished using some or all of the system components described in detail above and, in some implementations, various processing blocks may be performed in different sequences and various processing blocks may be omitted. Additional processing blocks may be performed along with some or ail of the processing blocks shown in the depicted flow diagrams. Some processing blocks may be performed simultaneously. Accordingly, the operations depicted in the flow diagram as illustrated (and described in greater detail below) are meant be an example and, as such, should not be viewed as limiting.

[0080] In an operation 300, the first device may send a first API call to the second device. For example, the first device 100 (and/or the API communication engine 120, or other resource of the first device 100) may send the first API call. The first device may send the first API call in a manner similar or the same as that described above in relation to the execution of the API communication engine 120, and/or other resource of the first device 100. The first API call may be depicted as the request of the first API call in FIG. 3B. in some examples, and as depicted in FIG. 3B, an initial communication may occur between the first device and the second device prior to the first device sending a first API call to the second device. The initial communication, as depicted in FIG. 3B, may include initialization with a user name and password and/or other type of authentication from the user. [0081] In an operation 310, the second device may send a first APi response to the first device. For example, the second device 100 (and/or the API communication engine 220, or other resource of the second device 100) may send the first API response. The second device may send the first API response in a manner similar or the same as that described above in relation to the execution of the APi communication engine 220, and/or other resource of the second device 100. The first API response may be depicted as the response of the first API call in FIG. 3B.

[0082] In an operation 320, the first device may determine whether communication between the first device and the second device is secure. For example, the first device 100 (and/or the API communication engine 120, or other resource of the first device 100) may determine whether communication between the first device and the second device is secure. The first device may whether communication between the first device and the second device is secure in a manner similar or the same as that described above in relation to the execution of the APi communication engine 120, and/or other resource of the first device 100.

[0083] In an operation 330, the first device may send a second API call to the second device. For example, the first device 100 (and/or the API communication engine 120, or other resource of the first device 100) may send the second API call. The first device may send the second API call in a manner similar or the same as that described above in relation to the execution of the APi communication engine 120, and/or other resource of the first device 100. The second API call may be depicted as the request of the second APi call in FIG. 3B.

[0084] In an operation 340, the second device may determine whether communication between the first device and the second device is secure. For example, the second device 200 (and/or the APi communication engine 220, or other resource of the second device 200) may determine whether communication between the first device and the second device is secure. The second device may whether communication between the first device and the second device is secure in a manner similar or the same as that described above in relation to the execution of API communication engine 220, and/or other resource of the second device 200. [0085] FIG. 4 Is a flowchart of an example method for execution by an example consumer device and provider device engaging In secure API communication.

[0086] In an operation 400, the first device may send an APi call to the second device. For example, the first device 100 (and/or the API communication engine 120, or other resource of the first device 100) may send the first API call. The first device may send the first APi call in a manner similar or the same as that described above in relation to the execution of API communication engine 120, and/or other resource of the first device 100.

[0087] In an operation 410, the first device may receive, from the second device, a first API response to the first device. For example, the first device 100 (and/or the APi communication engine 120, or other resource of the second device 100) may receive the APi response. The first device may receive the API response in a manner similar or the same as that described above in relation to the execution of APi communication engine 220, and/or other resource of the first device 100.

[0088] In an operation 420, the first device may determine whether communication between the first device and the second device is secure. For example, the first device 100 (and/or the API communication engine 120, or other resource of the first device 100) may determine whether communication between the first device and the second device is secure. The first device may whether communication between the first device and the second device is secure in a manner similar or the same as that described above in relation to the execution of APi communication engine 120, and/or other resource of the first device 100.

[0089] In some examples, the determination of whether communication between the first device and the second device is secure may be performed in various manners. FIG. 4A is a flowchart of an example method for execution by an example consumer device and provider device engaging in secure API communication.

[0070] In an operation 421 , the first device may determine whether the first dynamic device access token of the API call matches the first dynamic access token of the APi response. For example, the first device 100 (and/or the API communication engine 120, or other resource of the first device 100) may determine whether the first dynamic device access token of the API caii matches the first dynamic access token of the API response. The first device may determine whether the first dynamic device access token of the API call matches the first dynamic access token of the API response in a manner similar or the same as that described above in relation to the execution of API communication engine 120, and/or other resource of the first device 100,

[0071 ] Responsive to the tokens not matching, in an operation 422, the first device may indicate that a security breach has occurred. For example, the first device (and/or the API communication engine 120, or other resource of the second device 100) may indicate that a breach has occurred by providing an alert. The first device may indicate that a breach has occurred by providing an alert in a manner similar or the same as that described above in relation to the execution of API communication engine 120, and/or other resource of the first device 100.

[0072] Responsive to the tokens not matching, in an operation 423, the first device may require authentication of the user. For example, the first device 100 (and/or the API communication engine 120, or other resource of the first device 100) may require authentication. The first device may require authentication in a manner similar or the same as that described above in relation to the execution of API communication engine 120, and/or other resource of the first device 100.

[0073] Responsive to the tokens matching, in an operation 424, the first device may determine whether the first meter information of the API call corresponds to the second meter information of the API response. For example, the first device 100 (and/or the API communication engine 120, or other resource of the first device 100) may determine whether the first meter information corresponds to the second meter information. The first device may determine whether the first meter information corresponds to the second meter information in a manner similar or the same as that described above in relation to the execution of API communication engine 120, and/or other resource of the first device 100.

[0074] Responsive to the first meter information not corresponding to the second meter information, in an operation 425, the first device may indicate that a security breach has occurred. For example, the first device (and/or the API communication engine 120, or other resource of the second device 100) may indicate that a breach has occurred by providing an alert. The first device may indicate that a breach has occurred by providing an alert in a manner similar or the same as that described above in relation to the execution of API communication engine 120, and/or other resource of the first device 100.

[0075] Responsive to the first meter information not corresponding to the second meter information, in an operation 426, the first device may require authentication of the user. For example, the first device 100 (and/or the API communication engine 120, or other resource of the first device 100) may require authentication. The first device may require authentication in a manner similar or the same as that described above in relation to the execution of API communication engine 120, and/or other resource of the first device 100.

[0076] Responsive to the first meter information corresponding to the second meter information, in an operation 427, communication between the first device and the second device may continue. For example, the first device 100 (and/or the API communication engine 120, or other resource of the first device 100) may continue communicating with the second device 200 (and/or the API communication engine 220 or other resource of the second device 200). The first device may communicate with the second device in a manner similar or the same as that described above in relation to the execution of API communication engine 120, API communication engine 220, another resource of the first device 200 and/or other resource of the second device 200.

[0077] FIG. 5 is a block diagram of an example device engaging in secure API communication. In the example depicted in FIG. 5, first device 500 includes a non-transitory machine-readable storage medium 520 and a processor 510.

[0078] Processor 510 may be one or more central processing units (CPUs), microprocessors, and/or other hardware devices suitable for retrieval and execution of instructions stored in machine-readable storage medium 520.

[0079] Processor 510 may fetch, decode, and execute program instructions 521 , and/or other instructions to provide secure API communication, as described below. As an alternative or in addition to retrieving and executing instructions, processor 510 may include one or more electronic circuits comprising a number of electronic components for performing the functionality of one or more of program instructions 521 , and/or other instructions. [0080] In one example, the program instructions can be part of an installation package that can be executed by processor 510 to implement the functionality described herein. In this case, machine-readable storage medium 520 may be a portable medium such as a CD, DVD, or flash drive or a memory maintained by another backup storage device from which the installation package can be downloaded and installed. In another example, the program instructions may be part of an application or applications already installed on backup storage device 500.

[0081 ] Machine-readable storage medium 520 may be any hardware storage device for maintaining data accessible to first device 500. For example, machine-readable storage medium 520 may include one or more hard disk drives, solid state drives, tape drives, and/or any other storage devices. The storage devices may be located in first device 500 and/or in another device in communication with first device 500. For example, machine-readable storage medium 520 may be any electronic, magnetic, optical, or other physical storage device that stores executable instructions. Thus, machine-readable storage medium 520 may be, for example, Random Access Memory (RAM), an Electrically-Erasable Programmable Read-Only Memory (EEPROM), a storage drive, an optical disc, and the like. As detailed below, storage medium 520 may maintain and/or store the data and information described herein.

[0082] Machine-readable storage medium 520 may also be encoded with executable instructions for enabling execution of the functionality described herein. For example, machine-readable storage medium 520 may store API communication instructions 521 , and/or other instructions that may be used to carry out the functionality of the herein disclosed present techniques.

[0083] API communication instructions 521 , when executed by processor 510, may communicate with an application executing on a second device. For example, API communication instructions 521 may comprise instructions to send an API call to the second device, the API call comprising a dynamic device access token, first meter information related to first usage of the application, and a second device dynamic access token. API communication instructions 521 may also comprise instructions to receive, from the second computing device, an API response comprising a dynamic first device access token, second meter information related to second usage of the application, and a second dynamic access token, API communication instructions 521 may further comprise instructions to determine whether the communication between the first device and the second device is secure based on a comparison of the dynamic device access token of the API call and the dynamic first device access token of the API response. In some examples, the functionality performed by the API communication instructions 521 , when executed by processor 510, may be the same as or similar to functionality performed by API communication engine 120 of first device 100.

[0084] FIG. 6 is a block diagram of an example device engaging in secure API communication. In the example depicted in FIG. 6, second device 600 includes a non-transitory machine-readable storage medium 620 and a processor 810. Processor 610, similar to processor 510, may be one or more central processing units (CPUs), microprocessors, and/or other hardware devices suitable for retrieval and execution of instructions stored in machine- readable storage medium 820. Machine-readable storage medium 620 may comprise hardware, functionality, and data stored thereon that is the same as or similar to machine-readable storage medium 620. Machine-readable storage medium 620 may also be encoded with executable instructions for enabling execution of the functionality described herein. For example, machine-readable storage medium 620 may store API communication instructions 621 , and/or other instructions that may be used to carry out the functionality of the herein disclosed present techniques. Machine-readable storage medium 620 may also store metering information 622. Metering information 622 may comprise the metering information stored at second device 200 as discussed above.

[0085] API communication instructions 621 , when executed by processor 610, may communicate with a first device. For example, API communication instructions 621 may comprise instructions to send an API response to the first device. API communication instructions 621 may also comprise instructions to receive, from the second computing device, an API call. API communication instructions 621 may further comprise instructions to determine whether the communication between the first device and the second device is secure based on a comparison of the API call and the API response. In some examples, the functionality performed by the API communication instructions 821 , when executed by processor 810, may be the same as or similar to functionality performed by API communication engine 220 of first device 200.

[0086] The foregoing disclosure describes a number of examples for providing secure API communication. The disclosed examples may include systems, devices, computer-readable storage media, and methods for providing secure API communication. For purposes of explanation, certain examples are described with reference to the components illustrated in FIGS. 1-8. The functionality of the illustrated components may overlap, however, and may be present in a fewer or greater number of elements and components. Further, all or part of the functionality of illustrated elements may co-exist or be distributed among several geographically dispersed locations. Further, the disclosed examples may be implemented in various environments and are not limited to the illustrated examples.

[0087] Further, the sequence of operations described in connection with FIGS. 1-6 are examples and are not intended to be limiting. Additional or fewer operations or combinations of operations may be used or may vary without departing from the scope of the disclosed examples. Furthermore, implementations consistent with the disclosed examples need not perform the sequence of operations in any particular order. Thus, the present disclosure merely sets forth possible examples of implementations, and many variations and modifications may be made to the described examples.

Claims

CLAIMS We claim:
1. A first computing device to provide secure Application Programming interface (API) communication, the first computing device comprising:
an API communication engine to communicate with an application executing on a second computing device, wherein the API communication engine to communicate with the application that includes to:
send an API call to the second device, the API call comprising a dynamic device access token and first meter information, the first meter information related to first usage of the application;
receive, from the second computing device, an API response comprising a dynamic first device access token and second meter information, the second meter information related to second usage of the application; and
determine whether the communication between the first device and the second device is secure based on a comparison of the API call and the API response.
2. The first computing device of claim 1 , wherein the API communication engine to determine whether the communication is secure that includes to:
determine whether the dynamic device access token of the API call matches the dynamic first device access token of the API response;
responsive to the dynamic device access token not matching the dynamic first device access token, indicate that a security breach has occurred.
3. The first computing device of claim 2, wherein the API communication engine further to determine whether the communication is secure that includes to:
responsive to the dynamic device access token matching the dynamic first device access token, determine whether the first meter information corresponds to the second meter information; responsive to the first meter information not corresponding to the second meter information, indicate that a security breach has occurred.
4. The first computing device of claim 1 , wherein the API communication engine to:
generate a new dynamic device access token subsequent to receiving the API response;
generate a second API call by replacing the dynamic device access token with the new dynamic device access token; and
send the second API call to the second computing device.
5. The first computing device of claim 4, wherein the API communication engine to generate the new dynamic device access token using a random generator.
6. The first computing device of claim 4, wherein the API communication engine to generate the second API call further includes to:
determine updated first meter information; and
replace the first meter information with the determined updated first meter information.
7. A method that provides secure Application Programming Interface (API) communication between a first device and a second device, the method comprising:
sending an API call from the first device to the second device, the API call comprising a dynamic device access token and first meter information, the first meter information related to first usage of an application executing on the second device;
receiving, by the first device and from the second computing device, an API response, the API response comprising a dynamic first device access token, second meter information, and a dynamic second device access token, the second meter information related to second usage of the application; and determining, by the first device, whether the communication between the first device and the second device is secure based on a comparison of the AP! call and the API response.
8. The method of ciaim 7, wherein determining whether the
communication is secure comprises:
determining, by the first device, whether the dynamic device access token of the API call matches the dynamic first device access token of the API response;
responsive to the dynamic device access token not matching the dynamic first device access token, indicating, by the first device, that a security breach has occurred.
9. The method of claim 8, further comprising:
responsive to the dynamic device access token matching the dynamic first device access token, determining, by the first device, whether the first meter information corresponds to the second meter information;
responsive to the first meter information not corresponding to the second meter information, indicating, by the first device, that a security breach has occurred.
10. The method of claim 8, further comprising:
responsive to determining that the security breach has occurred, performing authentication of a user of the first device, wherein performing authentication comprises:
sending, to a user device separate from the first device, user authentication information;
receiving, at the first device, authentication information from the user; determining, by the first device, whether the received authentication information matches the user authentication information;
enabling, by the first device, communication between the first device and the second device responsive to the received authentication information matching the user authentication information.
1 1. The method of claim 7, further comprising:
generating, by the first device, a new dynamic device access token subsequent to receiving the API response;
generating, by the first device, a second API call by replacing the dynamic device access token with the new dynamic device access token, wherein the second API call comprises the new dynamic device access token, updated first meter information, and the dynamic second device access token; and
sending, by the first device, the second API call to the second computing device.
12. The method of claim 1 1 , further comprising:
receiving, by the second device, the second API call;
determining, by the second device, whether the dynamic second device access token of the API call matches the dynamic second device access token of the API response;
responsive to the dynamic second device access token of the second API call not matching the dynamic second device access token of the API response, indicating, by the second device, that a security breach has occurred.
13. The method of claim 12, further comprising:
responsive to the dynamic second device access token of the second API call matching the dynamic second device access token of the API response, determining, by the second device, whether the updated first meter information corresponds to meter information stored at the second device; responsive to the updated first meter information not corresponding to the stored meter information, indicating, by the second device, that a security breach has occurred.
14. The method of claim 1 1 ,
wherein the API call comprises a first security label, the first security label indicating a first security status of the first device, and wherein the API response comprises a second security label, the second security label indicating a second security status of the second device.
15. A non-transitory machine-readable storage medium comprising instructions executable by a processor of a computing device to provide secure Application Programming Interface (API) communication, the machine- readable storage medium comprising instructions when executed by the processor to:
communicate with an application executing on a second computing device,
wherein the instructions to communicate with the application comprise instructions to:
send an API call to the second device, the API call comprising a dynamic device access token, first meter information related to first usage of the application, and a second device dynamic access token; receive, from the second computing device, an API response comprising a dynamic first device access token, second meter information related to second usage of the application, and a second dynamic access token; and
determine whether the communication between the first device and the second device is secure based on a comparison of the dynamic device access token of the API call and the dynamic first device access token of the API response.
PCT/US2015/013864 2015-01-30 2015-01-30 Secure api communication WO2016122623A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2015/013864 WO2016122623A1 (en) 2015-01-30 2015-01-30 Secure api communication

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2015/013864 WO2016122623A1 (en) 2015-01-30 2015-01-30 Secure api communication

Publications (1)

Publication Number Publication Date
WO2016122623A1 true WO2016122623A1 (en) 2016-08-04

Family

ID=56544039

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2015/013864 WO2016122623A1 (en) 2015-01-30 2015-01-30 Secure api communication

Country Status (1)

Country Link
WO (1) WO2016122623A1 (en)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050289072A1 (en) * 2004-06-29 2005-12-29 Vinay Sabharwal System for automatic, secure and large scale software license management over any computer network
US7016965B2 (en) * 2001-11-13 2006-03-21 International Business Machines Corporation System and method for asynchronously reading data across secure sockets layer sessions
US20100031308A1 (en) * 2008-02-16 2010-02-04 Khalid Atm Shafiqul Safe and secure program execution framework
US20110191593A1 (en) * 2009-10-12 2011-08-04 Safenet, Inc. Software License Embedded In Shell Code
US20140304771A1 (en) * 2010-12-27 2014-10-09 Microsoft Corporation Application execution in a restricted application execution environment

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7016965B2 (en) * 2001-11-13 2006-03-21 International Business Machines Corporation System and method for asynchronously reading data across secure sockets layer sessions
US20050289072A1 (en) * 2004-06-29 2005-12-29 Vinay Sabharwal System for automatic, secure and large scale software license management over any computer network
US20100031308A1 (en) * 2008-02-16 2010-02-04 Khalid Atm Shafiqul Safe and secure program execution framework
US20110191593A1 (en) * 2009-10-12 2011-08-04 Safenet, Inc. Software License Embedded In Shell Code
US20140304771A1 (en) * 2010-12-27 2014-10-09 Microsoft Corporation Application execution in a restricted application execution environment

Similar Documents

Publication Publication Date Title
Chin et al. Measuring user confidence in smartphone security and privacy
US9571509B1 (en) Systems and methods for identifying variants of samples based on similarity analysis
TWI277904B (en) Method, recording medium and system for protecting information
US20190188394A1 (en) Security engine for a secure operating environment
US9882912B2 (en) System and method for providing authentication service for internet of things security
JP5624620B2 (en) Plug-in authority control method and system
US8352679B2 (en) Selectively securing data and/or erasing secure data caches responsive to security compromising conditions
WO2012064171A1 (en) A method for enabling a trusted platform in a computing system
WO2014124023A1 (en) Integrated circuit identification and dependability verification using ring oscillator based physical unclonable function and age detection circuitry
US8904507B2 (en) System and method for controlling user access to a service processor
US9619654B2 (en) Application monitoring through collective record and replay
US8245053B2 (en) Methods and systems for binding a removable trusted platform module to an information handling system
EP2672420A2 (en) System and method for remotely initiating lost mode on a computing device
TWI330769B (en) Apparatus method and system for feature activation
TWI549013B (en) Providing a persona-based application experience
US9520998B2 (en) System and method for recovery key management
WO2013123829A1 (en) Software installation method, device and system
US9529990B2 (en) Systems and methods for validating login attempts based on user location
CN102301641A (en) Software application verification
CN103329095B (en) Authenticate a hypervisor with encoded information
US8086838B2 (en) Methods and systems for providing manufacturing mode detection and functionality in a UEFI BIOS
US20130312088A1 (en) Electronic device and method for managing accounts and passwords of application systems
US9401925B1 (en) Systems and methods for detecting security threats based on user profiles
US8904503B2 (en) Systems and methods for providing access to data accounts within user profiles via cloud-based storage services
JP2015525932A (en) Login verification method, client, server, and system

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15880513

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase in:

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15880513

Country of ref document: EP

Kind code of ref document: A1