Patent Description:
When the client application is making an API call, in most cases, the API may respond to a request from a client application quickly, such as on the order of <NUM> milliseconds (ms) or less. However, in some situations execution of the request may exceed the token expiration, which may be due to a variety of factors, such as current load, time for backend processing of the request, size of the request payload, etc. In these situations, the token becomes invalid. As a result, the request from the client application cannot be successfully performed.

<NPL>), relates to how to handle batch processing with OAuth <NUM>. OAuth <NUM> isn't really designed for batch processing. OAuth is typically used more synchronously - as in, you send a request and you get an immediate response. Dealing with OAuth, you usually have the communication channel open. Batch processes, on the other hand, are often asynchronous, meaning that you may not have an open channel as operations occur over a longer time scale. Though many API providers are moving toward flashy RESTful microservices, asynchronous behavior in mobile APIs or enterprise service architectures still exist, and need to be dealt with in a secure and scalable method that considers the identity of the request along each step of the way. When the action is finally triggered, often the identity of the final call is not coupled with the initial call in any way. Using a typical OAuth flow here is awkward, since OAuth tokens are intended to be very short lived, meaning they shouldn't be stored in the queue for an indefinite batch job (see first and third paragraph on page <NUM>). The permissions of the access token are downscoped into a single action that can rest safely in the queue. This does require a little bit more action on the part of the server. It will take the savings operation data, and sign it, using the OAuth server key to create a signature out of that content. It will then respond with an access token that is more Long Lived (LL), which we'll call JWT Access Token LL.

<NPL>), relates to how to handle user token expiration on long running asynchronous jobs. Either, the OAuth <NUM> client credentials grant can be used in the authorization server so that the back-end services can request tokens on their own behalf without involving the user. Alternatively, a token exchange mechanism can be supported that allows for a back-end service to exchange the received access token with another one that allows to call other services using either user impersonation or delegation. Since the tokens were being issued to trusted back-end services and would never leave the server-side boundary, the lifetime of the token obtained could be much larger than the one used in the access token available to the web application which would also solve the expiration issue.

<CIT> relates to a system and method for providing an interface for a blockchain cloud service. A system and method implement a distributed ledger as a Blockchain Cloud Service (BCS). The BCS includes a complete set of infrastructure services and embedded resources: compute, containers, storage, identity management, and event streaming to enable the setup and execution of a production-ready blockchain. The BCS provisions an underlying infrastructure with the required blockchain network components, interface, a representational state transfer (REST) proxy service component, and a management console component, in response to an administrator specifying one or more parameters.

It is the object of the present invention to improve efficiency of executing long-lasting asynchronous procedures when a token expires during the execution.

Features of the present disclosure are illustrated by way of examples shown in the following figures. In the following figures, like numerals indicate like elements, in which:.

For simplicity and illustrative purposes, the present disclosure is described by referring to examples thereof. It will be readily apparent however that the present disclosure may be practiced without limitation to these specific details.

According to an example of the present disclosure, token management is provided for an asynchronous request-reply pattern of communication that can be employed between a client application and a remote API to which the client application makes API calls. The asynchronous request-reply pattern allows the API to absolve itself from providing an immediate response to a request, and instead provides a way to provide a response later in time.

Furthermore, the token management includes a process for managing long-lasting procedures that are executed for a request and which otherwise may be difficult to manage due to the expiration of a token during the long-lasting procedure. Tokens are required for AuthN and AuthZ. A token has an expiration. Often, the default is set at one hour but expiration can be set at shorter time periods, such as within seconds or minutes. If a request in the asynchronous request-reply pattern requires execution of backend processes that takes longer than the expiration period of the token, it can result in failed execution of the requested operation that is requested in the API call to the remote API. To obviate the issue with token expiration, some systems may create a certificate that gives blind trust to the user, such as authorizes rights for the user for an extended period of time that exceeds the expiration of the token. However, this creates a security risk, because the certificate holder is allowed to perform various operations for an extended period of time even if the token is invalid.

According to an example of the present disclosure, token expiration is handled in a much more secure manner. For example, after a request from a client is accepted, the client is provided with a tracking key and a new location, such as a location of a status checker API, for checking the status of the request. The client, after a stated period of time, can send a status request to the status checker API along with the tracking key. When the client sends a request to a new location, such as the status request being sent to the status checker API instead of the initial request being sent to the remote API, the client automatically includes a new token according to existing client procedure. This new token is then used to determine status and respond to the client status request and to process the request if the initial token is expired. Accordingly, if the initial token is expired, the new token, which is unexpired, is available for authorization to process the request, and this process may be repeated as needed until the processing of the requested operation is completed. By way of this process, token expiration is managed in a more secure manner than issuing a certificate that allows the request to be processed despite an expired token. Furthermore, the client is not required to re-submit the initial request, so the client <NUM> is not required to perform any additional operations.

<FIG> shows an end-to-end asynchronous request-reply message flow according to an example of the present disclosure. Client <NUM> may include an application, also referred to as a client application, executed by a processor. In an example, the client <NUM> comprises code running in a web browser, or in another example the client <NUM> may include a standalone application that may not need a web browser to run. The client <NUM> communicates with remote APIs, e.g., API <NUM> and status checker API <NUM>, such as to execute business logic or to perform other operations. The API <NUM> may also be referred to herein as a work process API. In an example, API <NUM>, status checker API <NUM>, storage <NUM>, legacy API <NUM> and background request processor <NUM>, which are described in detail below, are provided on a cloud of a cloud provider, and the client <NUM> accesses the cloud via the APIs to execute the request. The client <NUM> can access the APIs and the cloud via a network not shown.

The client <NUM> makes API calls to API <NUM> which by way of example may take place over the HTTP(S) protocol and follow REST semantics. In a running example which is used herein to describe the end-to-end asynchronous request-reply flow, the API <NUM> is for a tenant order service to order cloud resources from a cloud provider, such as orders for creating virtual machines (VMs), assigning database servers, performing billing tasks, etc..

At <NUM>, the client <NUM> makes an API call to the API <NUM>, e.g., an HTTP post request. The API call includes a request to perform an operation, which may trigger a long-running operation on the backend. For example, the request in the API call includes an order from a tenant for multiple VMs with particular images and database servers to be provided to the tenant by the cloud provider of the tenant. The request also includes a token, also referred to as an authorization token. The token may be one or more tokens used for AuthN and/or AuthZ. Also, the request may include a tag that identifies itself as an asynchronous request as opposed to a synchronous request. The API <NUM> can check for other errors in the request. Also, the API <NUM> can validate the client <NUM> and the request using the token, or the client <NUM> and the request may be subsequently validated using the token by the background request processor <NUM> before the requested operation in the request is executed by a request processing endpoint. The API <NUM> responds with an acknowledgement if the request is accepted, such as shown at <NUM>, and the API <NUM> performs other operations, shown at <NUM>, to have the request processed. If the request is not accepted, the API <NUM> responds with an indication that the request is not accepted as soon as possible, so the user can take corrective action as needed.

As indicated above, if the request is accepted for processing by the API <NUM>, the operations are performed at <NUM> to get the request processed. For example, the API <NUM> creates a tracking key entry in storage <NUM> to track the progress of the order, which may include a requested operation, made in the request. Accordingly, the API <NUM> creates a tracking key for the request which is stored in storage <NUM>. Storage <NUM> may include storage of the cloud provider that is accessible by the APIs and background request processor <NUM> shown in <FIG>. In an example, the storage <NUM> may include object storage (e.g., blob storage) in the cloud. The API <NUM> forwards the order to the background request processor <NUM> for execution, shown as forward post request. The background request processor <NUM> may forward the order to a legacy API <NUM> if needed for execution, e.g., post request to legacy API <NUM>. The background request processor <NUM> can update the progress of the execution of the order of the request from client in the storage <NUM>, such as by storing status codes in the storage <NUM> for the corresponding tracking key of the request. The status codes indicate the progress of the processing of the request. For example, the storage <NUM> may store a status code, such as for waiting, processing, finished, or error (when listener can't process it). At <NUM>, the API <NUM> responds back to the client <NUM> with an acknowledgment. The acknowledgment includes (<NUM>) the status code, such as HTTP status code <NUM> indicating that the request has been accepted for processing but is not completed (in fact processing may not have been started), (<NUM>) the tracking key, (<NUM>) a location, such as a URL for status checker API <NUM>, for checking the ongoing status of the order, and (<NUM>) a retry-after value indicating an amount of time to wait before checking the location for the status of the order. Subsequently, the client <NUM> can send a message, including the tracking key, to the location, such as the location of status checker API <NUM> instead of API <NUM>, after waiting for the amount of time specified by the retry-after value to check on the progress of the execution of the order. Location may refer to a URL, IP address or another type of address that is used to identify a destination for a message or request that may be sent over a network. The operations performed at <NUM> may be performed by the API <NUM>, status checker API <NUM>, the storage <NUM>, the background request processor <NUM>, and the legacy API <NUM>. The API <NUM>, status checker API <NUM>, the storage <NUM>, the background request processor <NUM>, and the legacy API <NUM> may comprise machine readable instructions executable by a processor on different servers, but it will be apparent to one of ordinary skill in the art that one or more of these elements may reside on the same server. The storage <NUM> may include storage in a cloud environment as was indicated above.

At <NUM>, operations are performed to check the status of the processing of the request that was initially made at <NUM>, such as the status of the order for the VMs and database servers. For example, the client <NUM> sends a status check (e.g., HTTP get message), including the tracking key, to the status checker API <NUM> after waiting for the amount of time specified by the retry-after value to check on the progress of the order. Because the client <NUM> is sending the status check to a new location, such as sending the status check to the status checker API <NUM> instead of the API <NUM>, the client <NUM> includes a new token in the status check. This new token may be used for processing the status check and for processing the execution of the order if the original token provided by the client <NUM> at <NUM> is expired, as is further described below with respect to <FIG> and other figures. The status checker API <NUM> uses the tracking key provided in the status check to check the current status of the order in the storage <NUM>. The background request processor <NUM> may have previously updated the current status in the storage <NUM> with a status code indicating that the execution of the order is in progress, such as shown at <NUM>, and, at <NUM>, the status checker API <NUM> retrieves the code indicating the current status from the storage <NUM> and sends it back to the client <NUM> along with a retry-after value and the URL for the status checker API for the client <NUM> to subsequently check the status of the initial request.

At <NUM>, the legacy API <NUM> updates the progress of the processing of the request. For example, order processing is completed and the legacy API <NUM> sends a progress update to the background request processor <NUM> to indicate that the processing is finished. The background request processor <NUM> updates the storage <NUM> to indicate that the current status of the order is completed. At <NUM>, the client <NUM> checks the status of the order again, such as similarly described with respect to <NUM>. For example, the client <NUM> sends a status check (e.g., HTTP get message), including the tracking key, to the status checker API <NUM> after waiting for the amount of time specified by the retry-after value to check on the progress of the order. The status checker API <NUM> retrieves the code indicating finished from the storage <NUM> using the tracking key and sends it back to the client <NUM>.

<FIG> illustrates a flow chart for managing token expiration for the asynchronous request-reply flow, according to an example of the present disclosure. The steps of <FIG> may be performed by the background request processor <NUM>. Referring back to <FIG>, in the running example discussed above, the initial request at <NUM> includes an order for VMs and database servers to be provided to a tenant of a cloud provider. The execution of the order may take longer than the expiration time of the token provided by the client <NUM> at <NUM>. To prevent the order from not being processed due to token expiration, the new token provided by the client <NUM> at <NUM> is used to continue processing of the order if the initial token expired, as is further discussed below.

At <NUM>, the background request processor <NUM> checks whether the token provided by the client <NUM> is valid. This may include a validation for AuthN and AuthZ. For example, the token was previously extracted from a request sent from the client <NUM> and stored in the storage <NUM>, and the background request processor <NUM> validates the token for AuthN and AuthZ. If the token is valid, the request, such as the requested order for VMs and database servers, is queued on a service bus, such as service bus <NUM> shown in <FIG>, at <NUM>, and, at <NUM>, the request is processed by the service bus to dispatch to a request processing endpoint, such as one of the request processing endpoints <NUM> shown in <FIG>, that can process the request. For example, the background request processor <NUM> may include a service bus to handle a high volume of incoming requests and to dispatch the requests to proper endpoints for servicing the requests. In an example, the service bus implements topics for message brokering and enables multiple receivers or request processing endpoints to process different messages based on topic at any given point of time. This helps with surges in requests and keeps total turnaround time for any operation at a minimum. Also, the background request processor <NUM> includes a listener function, such as listener function <NUM> shown in <FIG>, that receives the request at <NUM> and checks whether the token is expired at <NUM>. If the listener function determines the token is not expired, the request and the token are submitted to a request processing endpoint that can process the request. However, if the token is expired, the request cannot be executed. To overcome the issue of an expired token, the listener function acquires a new token from the status checker API <NUM> at <NUM>. For example, the listener function instructs the status checker API <NUM> to get the new token at <NUM> when the status check is received, the status checker API waits for the status check from the client <NUM> at <NUM> and extracts the new token at <NUM> when the status check is received, and requeues the request for the order with the new token at <NUM>. The new token that is not expired may be stored in the storage <NUM> so the request for the order can be executed by the proper request processing endpoint. In the running example of the request including the order for creating VMs and assigning database servers, the proper endpoint may be a provisioning endpoint comprised of a server or VM of the cloud provider that is available and capable of executing the order. By way of steps <NUM>-<NUM>, token expiration is managed without issuing a certificate that allows the request to be processed despite an expired token. Also, the client <NUM> is not required to re-submit the request with the initial order, so the client <NUM> is not required to perform any additional operations.

At <NUM>, if the token is not expired, then the listener function decrypts the token and submits it with the request to the endpoint that will execute the request at <NUM>. At <NUM>, if the order execution is determined to be successful, then, at <NUM>, a response is stored in the storage <NUM>. For example, the background request processor <NUM> updates the storage <NUM> with a status code for the request indicating the order is finished. Then, the status checker API <NUM> can retrieve the status code from the storage <NUM> and send the response to the client <NUM> indicating the request is finished processing, such as shown at <NUM> in <FIG>. At <NUM>, if the order execution is determined not to be successful, then, at <NUM>, a determination is made as to whether the number of attempts is greater than a threshold. If so, order execution is terminated and status may be updated accordingly in the storage <NUM> so the client <NUM> can be notified. If the number of attempts does not exceed the threshold as determined at <NUM>, then, at <NUM>, a determination is made as to whether the token has sufficient lease. For example, the amount of time left until expiration of the token is determined The amount of time left until expiration of the token must be sufficient to complete processing of the request. If the amount of time left until expiration of the token is considered insufficient, such as by comparing the amount of time left until expiration of the token to average times or another preset threshold time to complete requests of a particular type, the token is determined to have insufficient lease. If the token lease is determined to be insufficient at <NUM>, the processing continues to step <NUM> where the new token is extracted from a recent client status check such as described above. If the token lease is determined to be sufficient at <NUM>, the request is requeued to the service bus with the existing token at <NUM>.

<FIG> shows a system block diagram of the components described above with respect to <FIG>, according to an example of the present disclosure. Client <NUM> may communicate with APIs of API <NUM>, such as API <NUM> and status checker API <NUM> to submit requests and status checks such as described above. The client <NUM> may communicate with the APIs over a network, not shown. The client <NUM> may include a web application or a standalone application executed by a processor of a computer.

The storage <NUM> is used for request tracking and storing status. It follows the below-described schema. The storage <NUM> stores a tracking key used to identify the user when the client <NUM> sends a status check. The storage <NUM> also stores the state of a request, such as waiting, processing, finished, and error (e.g., when the listener function <NUM> can't process the request). The storage <NUM> also stores a status code, such as an HTTP status code that is returned to the client <NUM>. The storage <NUM> also stores a number of status checks, which represent how many times the status check API <NUM> has checked for given request status. The storage <NUM> also stores a response (once available) for a current request. This can represent successful response provided by an underlying API or error message. The storage <NUM> also stores a number of requeuings, such as how many times the listener function <NUM> must requeue a request back to the service bus. The storage <NUM> also stores the encrypted token, and a timestamp for each update, such as for analytics purposes. In an example, the storage <NUM> is a cloud storage of the cloud provider that supports the order service for tenants to order cloud resources.

The background request processor <NUM> may include service bus <NUM>, listener function <NUM> and request processing endpoints <NUM>. In an example, the request processing endpoints <NUM> may be external to the background request processor <NUM>, and the listener function <NUM> and/or service bus <NUM> send requests to the appropriate request processing endpoints to process the requests queued on the service bus <NUM>. The operations performed by the service bus <NUM> and the listener function <NUM> are further described above with respect to <FIG>. The service bus <NUM> and the listener function <NUM> may include machine readable instructions executed by a processor. The request processing endpoints <NUM> may include hardware and software for executing requests. For example, assuming the client <NUM> sends requests to a cloud provider for managing virtual resources, the request processing endpoints <NUM> perform the requests, such as provisioning and deprovisioning cloud resources for a tenant, etc..

The legacy API <NUM> may be called by the background request processor <NUM> to execute a request. In an example, the API <NUM> is for an order service that client <NUM> interacts with to order resources from the cloud provider. The order service may interact with customers and have dependencies <NUM> on other downstream services. The background request processor <NUM> may make API calls to the legacy API <NUM> when a downstream service is required to execute an order. In some instances, the dependencies <NUM> have low reliability due to scaling constraints or other factors. By using the legacy API <NUM>, the order service can be decoupled from less reliable dependencies. This way the order service can be shielded from reliability dips caused by the dependencies <NUM>. Thus, a buffer is provided between the order service or another service provided by the background request processor <NUM> and dependency failures.

<FIG> shows a block diagram for the background request processor <NUM>, according to an example of the present disclosure. The processor <NUM> may include a single or multiple hardware processors or other hardware processing circuit, to execute the methods, functions, and other processes described herein. These methods, functions, and other processes may be embodied as machine-readable instructions stored on a computer-readable medium, which may be non-transitory, such as hardware storage devices (e.g., RAM (random access memory), ROM (read-only memory), EPROM (erasable, programmable ROM), EEPROM (electrically erasable, programmable ROM), hard drives, and flash memory). The memory <NUM> may include one or more storage devices, such as RAMs, where the machine-readable instructions and data for a processor may reside during runtime. Also, APIs <NUM> and other processes described herein may comprise machine readable instructions stored on a non-transitory machine readable medium and executed by a hardware processor. Referring to the block diagram shown in <FIG>, the memory <NUM> may include machine readable instructions executable by the processor <NUM>. The machine-readable instructions may include instructions <NUM> to receive a request to perform an operation, wherein the request includes a token with an expiration; instructions <NUM> to determine whether the token expired prior to or during execution of the request; and instructions <NUM> to in response to determining the token expired, prompt status checker API <NUM> to obtain a new token, and utilize the new token to execute the request.

<FIG> shows a block diagram for a computer-implemented method to manage execution of a request that outlasts token expiration in an asynchronous request-reply pattern, according to an example of the present disclosure. The computer-implemented method is described by way of example as being performed by one or more of the components shown in <FIG> and <FIG>. At <NUM>, a request is received from client <NUM> at work process API <NUM> to perform an operation, wherein the request includes a token with an expiration. At <NUM>, the request is posted for processing. For example, the request is posted to service bus <NUM> so it can be processed by a request processing endpoint. At <NUM>, a response is transmitted to the client <NUM> indicating the response is accepted for processing, wherein the response includes a reply-after time period, and a location to poll for the status of the request after expiration of the reply-after time period, and wherein the location to poll is different from the work process API. At <NUM>, a status check for the request is received from the client <NUM> at the location to poll, e.g., the status checker API <NUM>, based on the reply-after time period. At <NUM>, a new token is from the status check if the token is expired. At <NUM>, a reply to the status check is transmitted to the client <NUM> with a current status of the request. The computer implemented method may be executed by processor <NUM> which may include a single or multiple hardware processors or other hardware processing circuit, to execute the methods, functions, and other processes described herein. The steps of the method may be embodied as machine-readable instructions stored on a computer-readable medium, which may be non-transitory, such as hardware storage devices (e.g., RAM (random access memory), ROM (read-only memory), EPROM (erasable, programmable ROM), EEPROM (electrically erasable, programmable ROM), hard drives, and flash memory). The memory <NUM> may include one or more storage devices, such as RAMs, where the machine-readable instructions and data for a processor may reside during runtime.

Claim 1:
A system operable to manage execution of a request that outlasts token expiration in an asynchronous request-reply pattern, the system comprising:
at least one hardware processor;
a work process application program interface, API, executed by the at least one hardware processor to:
receive (<NUM>) a request from a client to perform an operation, wherein the request includes a token with an expiration;
create a tracking key for the request;
post (<NUM>) the request for processing; and
transmit (<NUM>) a response to the client in response to accepting the request, wherein the response includes a reply-after time period, the tracking key, and a location to poll for a status of the request after expiration of the reply-after time period; and
a status checker API executed by the at least one hardware processor to:
receive (<NUM>) a status check for the request from the client based on the reply-after time period and the location to poll, wherein the status check includes the tracking key;
check the status of the request using the tracking key;
extract (<NUM>) a new token from the status check based on the new token being needed to execute the request; and
send (<NUM>) a reply to the status check with a current status of the request.