Step-by-step verification of access tokens

Abstract

Methods, systems, and computer program products are provided for progressive validation of access tokens. In response to intercepting an initial invocation of a transaction related to the service from a client, a token for the initial invocation of the transaction related to the service is validated, which includes querying an authentication server and locally storing a validity period received for the token. In response to intercepting at least one subsequent invocation of the transaction related to the service from the client, the token for the at least one subsequent invocation is determined to be valid based on the locally stored validity period. Passing of the at least one subsequent invocation of the transaction related to the service is permitted without querying the authentication server.

Description

Technical Field

[0001] The present invention generally relates to computer systems, and more particularly to a computer-implemented method, a computer system, and a computer program product configured and arranged to progressively verify access tokens.

Background Art

[0002] In modern secure applications, access tokens are often used to allow users to access appropriate resources, and the expiration times of these access tokens are typically limited. This is for various security reasons, one of which is to limit the time during which an attacker can use a stolen token. Also, the information contained in the access token or the information referred to by the access token may become stale. While the access token expires or becomes invalid, when an application still needs to access protected resources, this application faces the problem of obtaining a new access token without forcing the user to grant access again. To solve this problem, OAuth 2.0 (the industry standard for authorization) has introduced an artifact called a refresh token. According to the refresh token, an application can obtain a new access token without instructing the user.

[0003] Access tokens are used for token-based authentication, enabling applications to access application programming interfaces (APIs). After a user successfully authenticates and grants access, the application receives an access token and passes it as credentials when calling a target API (for example, one associated with a target resource). The passed token informs the API that the token owner is authorized to perform specific actions specified by the scope granted during access and authorization.

[0004] Auth0 issues either an access token or an identification (ID) token in response to an authentication request. Applications can use the access token to make authenticated calls to secure APIs. The ID token, on the other hand, contains user profile attributes expressed in the form of claims. Both are JSON (Java(R)Script Object Notation) web tokens (JWTs), and therefore have security measures such as signatures, in addition to an expiration date indicated by the "exp" (expiration date) claim. Typically, a user requires a new access token when accessing a resource for the first time or after a previously granted access token has expired. As mentioned above, a refresh token is a special type of token used to obtain a refreshed access token, and an application can request a new access token until the refresh token is added to a DenyList, indicating that it cannot be used again. Applications securely store refresh tokens to maintain user authentication.

[0005] While existing technologies for using tokens are suitable for their intended purposes, there is a need for a system having the specific features of the embodiments of the present invention. [Overview of the project]

[0006] Embodiments of the present invention relate to computer implementations for stepwise verification of access tokens. Non-limiting and exemplary computer implementations include verifying a token for an initial call to a service transaction in response to the interception of an initial call to a service transaction from a client, which includes querying an authentication server and locally storing the validity period received for the token. The computer implementation includes determining, based on the locally stored validity period, that a token for at least one consecutive call is valid in response to the interception of at least one consecutive call to a service transaction from a client. The computer implementation includes allowing the delivery of at least one consecutive call to a service transaction without querying an authentication server.

[0007] This significantly enhances the security of managed systems and services by improving known methods through incremental verification of transaction tokens. Other improvements include extending the token duration beyond short periods, ensuring invalid tokens are always caught as quickly as possible, reducing the cost of token verification (e.g., time and repeated communication), and supporting multiple token types.

[0008] In addition to or as an alternative to one or more of the features described above or below, in other embodiments of the present invention, the method includes determining that at least one consecutive call is the final call of a transaction, and executing the transaction. This is convenient because it provides a technique for verifying tokens without querying an authentication server.

[0009] In addition to or as an alternative to one or more of the features described above or below, in other embodiments of the present invention, the method includes determining that the token for the last consecutive call is invalid based on the expiration of a locally stored validity period, preventing the passing of the last consecutive call of a transaction relating to the service, and rolling back the transaction. This is convenient because it provides a technique that can verify the token using locally stored information without querying an authentication server.

[0010] In addition to or as an alternative to one or more of the features described above or below, in other embodiments of the present invention, this method includes preventing unauthorized reuse of tokens by clearing the token's validity period in response to the execution or rollback of a transaction. This is convenient because it allows the token to be verified using locally stored information without querying an authentication server, while providing a technique to prevent misuse of the token.

[0011] As an addition or substitution to one or more of the features described above or below, in other embodiments of the present invention, determining that at least one token for a series of calls is valid based on a locally stored validity period includes preventing the backend service computer system from querying the authentication server to verify the token for at least one series of calls. This is convenient because it provides a technique that allows for rapid verification of tokens using locally stored information without querying the authentication server.

[0012] As an addition or alternative to one or more of the features described above or below, in other embodiments of the present invention, determining that at least one token for a series of calls is valid based on a locally stored validity period avoids the requirement for the backend service computer system to query the authentication server for verification of at least one token for a series of calls. This is convenient because it provides a technique that allows for rapid verification of tokens using locally stored information without querying the authentication server.

[0013] A non-exclusive and exemplary computer implementation includes, in response to the interception of a token call from a client involving an Application Programming Interface (API) key for a service transaction, querying an access decision engine to obtain a token list and an access policy for the API key, wherein the API key, token list, and access policy are associated together and stored locally. The computer implementation also includes, in response to the interception of a service call and token having an API key, determining that the call is granted access to the service based on the locally stored token list and access policy for the API key, and granting access to the resource for the service call without querying the access decision engine.

[0014] This improves upon known methods by restricting token validation access to the access decision engine, thereby reducing the risk of token misuse if the attached API key expires.

[0015] In addition to or as an alternative to one or more of the features described above or below, in other embodiments of the present invention, the method includes determining, based on a locally stored list of API key tokens and access policies, that subsequent calls relating to a service having an API key and that another token is granted access to the service. This is convenient because it provides a technique that can use locally stored information without the need to access a decision engine.

[0016] In addition to or as an alternative to one or more of the features described above or below, in other embodiments of the present invention, the method for determining whether a call is granted access to a service based on a locally stored API key token list and access policy includes verifying that a token is on the token list and verifying that the access policy permits access to the service by the API key, without querying the access decision engine. This is convenient because it provides a technique that can use locally stored information without needing to access the decision engine.

[0017] In addition to or as an alternative to one or more of the features described above or below, in other embodiments of the present invention, this method includes monitoring API key revocation events. This is convenient because it provides a technique that can prevent misuse of API keys by immediately revoking them.

[0018] In addition to or as a substitute for one or more of the features described above or below, in another embodiment of the present invention, the method includes preventing the separate use of the API key by invalidating the token list associated with the expired API key in response to the occurrence of an API key revocation event. This is convenient because it provides a technique that can prevent misuse of the API key by immediately invalidating it.

[0019] In addition to or as an alternative to one or more of the features described above or below, in other embodiments of the present invention, the method includes allowing a locally stored token list to continue to be used in determining access to the API key in response to the absence of an API key revocation event. This is convenient because it provides a technique that can quickly determine that access to the service is permitted when no API key revocation event is present.

[0020] Other embodiments of the present invention implement the features of the above-described method in computer systems and computer program products.

[0021] Additional technical features and benefits are realized by the technology of the present invention. Embodiments and aspects of the present invention are described in detail herein, but these are considered to be part of the subject matter of the claims. For a deeper understanding, refer to the description and drawings for further details.

[0022] The details of the exclusive rights described herein are expressed and asserted in the last claim herein. The above and other features and advantages of embodiments of the present invention will become apparent from the following detailed description in conjunction with the accompanying drawings. [Brief explanation of the drawing]

[0023] [Figure 1] This is a block diagram of an exemplary computer system to be used in conjunction with one or more embodiments of the present invention. [Figure 2] This is a block diagram of an exemplary computing environment configured to validate access tokens step-by-step, according to one or more embodiments of the present invention. [Figure 3] This is a flowchart of a computer implementation process relating to interaction patterns of intercepted transaction calls according to one or more embodiments of the present invention. [Figure 4]A block diagram showing an example of a sidecar computer system as a token interceptor for use in an ID and access management (IAM) policy, according to one or more embodiments of the present invention. [Figure 5] A block diagram further showing an example of a sidecar computer system as a token interceptor for use in an IAM policy, according to one or more embodiments of the present invention. [Figure 6] A block diagram further showing an example of a sidecar computer system as a token interceptor for use in an IAM policy, according to one or more embodiments of the present invention. [Figure 7] A block diagram showing a token initializer, according to one or more embodiments of the present invention. [Figure 8] A block diagram showing a policy manager, according to one or more embodiments of the present invention. [Figure 9] A block diagram showing an example of a rule in a policy database, according to one or more embodiments of the present invention. [Figure 10] A block diagram showing a token manager, according to one or more embodiments of the present invention. [Figure 11] A block diagram showing a token updater, according to one or more embodiments of the present invention. [Figure 12] A block diagram showing a token invalidator, according to one or more embodiments of the present invention. [Figure 13] A block diagram showing a token interceptor, according to one or more embodiments of the present invention. [Figure 14] A flowchart of a computer-implemented method for enabling a transaction with a backend service by means of staged verification of a token, according to one or more embodiments of the present invention. [Figure 15]This is a flowchart of a computer implementation method for enabling transactions with a backend service, access to a backend service, or both, by stepwise verification of tokens, according to one or more embodiments of the present invention. [Figure 16] This figure shows a cloud computing environment according to one or more embodiments of the present invention. [Figure 17] This figure shows an abstraction model layer according to one or more embodiments of the present invention. [Modes for carrying out the invention]

[0024] One or more embodiments of the present invention provide computer implementation methods, computer systems, and computer program products configured to validate access tokens incrementally. As described herein, refresh tokens allow applications to obtain new access tokens without user instruction. However, there are cases where a refresh token expires while an access token remains valid. To address this problem, some methods may set a short expiration or validity period for access tokens, or validate access tokens using a token bucket through interception. One or more embodiments of the present invention validate access tokens incrementally by intercepting traffic to a service using a sidecar and analyzing the traffic to extract token usage patterns and traffic types. For transactional traffic, one or more embodiments validate the token in the first service call of the transaction and store the validity period in the sidecar's token transaction manager. For sequential traffic (i.e., sequential or subsequent service calls of a transaction, or both), one or more embodiments use a calculated validity period instead of performing validation through interaction or communication with an authentication server, or both. In the case of a transaction involving execution or rollback, one or more embodiments of the present invention check the token again to terminate the transaction.In the case of access tokens generated using an Application Programming Interface (API) key, one or more embodiments establish or generate relationships between the API key and identifiable tokens in the token list, and verify all tokens by validating access tokens using discovered rules instead of interacting or communicating with an authentication server (or access decision engine), and check / monitor API key revocation events, provided that if the system detects an API key revocation, the token list associated with the revoked API key also becomes revoked.

[0025] Stepwise verification of transaction access tokens brings about various technical benefits and solutions. For example, the duration of access tokens is not limited to a short period. In one or more embodiments, the cost of token verification (e.g., time, requests to authentication servers, etc.) is reduced by always capturing invalid tokens as quickly as possible. Furthermore, one or more embodiments of the present invention can accommodate multiple types of tokens. Moreover, a system for stepwise verification of transaction access tokens is a technical solution to technical problems that cannot be solved by the human mind, with or without pen / paper aid, in order to significantly ensure the security of managed systems and services. Furthermore, a system for stepwise verification of transaction access tokens can prevent or mitigate malicious computer attacks or intrusions, and can prevent or mitigate computer security threats, and provides confidentiality and security when computer systems are communicating with each other, thereby improving the functionality of the computer system itself as well as multiple interconnected computer systems in a cloud environment, thus preventing further exposure to potential or current computer problems.

[0026] Referring here to Figure 1, this schematically illustrates a computer system 100 according to one or more embodiments of the present invention. As described herein, the computer system 100 can be an electronic computer framework that includes or employs any number of computing devices and networks, or combinations thereof, utilizing various communication technologies. The computer system 100 is easily scalable, expandable, and modular, and can be changed to different services or reconfigured to have some functions independent of others. The computer system 100 may be, for example, a server, desktop computer, laptop computer, tablet computer, or smartphone. In some examples, the computer system 100 may be a cloud computing node. The computer system 100 can be described in the general context that computer system executable instructions, such as program modules, are executed by the computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc., that perform a specific task or implement a specific abstract data type. The computer system 100 may be implemented in a distributed cloud computing environment where tasks are performed by remote processing units linked through a communication network. In a distributed cloud computing environment, program modules may be located on both local and remote computer system storage media, including memory storage devices.

[0027] As shown in Figure 1, the computer system 100 has one or more central processing units (CPUs) 101a, 101b, 101c, etc. (collectively or generally referred to as processor 101). The processor 101 can be a single-core processor, a multi-core processor, a computing cluster, or any number of other configurations. The processor 101 (also referred to as the processing circuit) is coupled to system memory 103 and various other components via a system bus 102. System memory 103 may include read-only memory (ROM) 104 and random-access memory (RAM) 105. ROM 104 is coupled to the system bus 102 and may include a successor system such as a basic input / output system (BIOS) or an integrated expansion firmware interface (UEFI) that controls certain basic functions of the computer system 100. RAM is read-write memory coupled to the system bus 102 and used by the processor 101. System memory 103 provides temporary memory space for the operation of the instructions during operation. System memory 103 may include random access memory (RAM), read-only memory, flash memory, or any other suitable memory system.

[0028] The computer system 100 includes an input / output (I / O) adapter 106 and a communication adapter 107 coupled to a system bus 102. The I / O adapter 106 may be a small computer system interface (SCSI) adapter that communicates with the hard disk 108 or any other similar component, or both. In this specification, the I / O adapter 106 and the hard disk 108 are collectively referred to as mass storage 110.

[0029] Software 111, which runs on the computer system 100, may be stored in mass storage 110. Mass storage 110 is an example of a tangible storage medium readable by the processor 101, and the software 111 is stored as instructions executed by the processor 101, operating the computer system 100 as described later with respect to various drawings. Examples of computer program products and the execution of such instructions will be discussed in more detail herein. A communication adapter 107 interconnects the system bus 102 with a network 112 (which may be an external network) so that the computer system 100 can communicate with such other systems. In one embodiment, a portion of the system memory 103 and mass storage 110 collectively stores an operating system, which may be any suitable operating system that links the functions of the various components shown in Figure 1.

[0030] Additional input / output devices are shown connected to the system bus 102 via the display adapter 115 and the interface adapter 116. In one embodiment, adapters 106, 107, 115, and 116 may be connected to one or more I / O buses connected to the system bus 102 via an intermediate bus bridge (not shown). The display adapter 115 connects the display 119 (e.g., a screen or display monitor) to the system bus 102, which may include a graphics controller and a video controller to improve the performance of graphics-intensive applications. A keyboard 121, mouse 122, speaker 123, etc., may be interconnected to the system bus 102 via the interface adapter 116, which may include a super I / O chip that integrates multiple device adapters into a single integrated circuit. Suitable I / O buses for connecting peripheral devices such as hard disk controllers, network adapters, and graphics adapters typically include common protocols such as Peripheral Component Interconnect (PCI) and Peripheral Component Interconnect Express (PCIe). Thus, as shown in the configuration of Figure 1, the computer system 100 includes processing capabilities in the form of a processor 101, storage capabilities including system memory 103 and mass storage 110, input means such as a keyboard 121 and a mouse 122, and output capabilities including a speaker 123 and a display 119.

[0031] In some embodiments, the communication adapter 107 can transmit data using any suitable interface or protocol, such as the Internet Small Computer System Interface, among others. The network 112 may be a cellular network, a wireless network, a wide area network (WAN), a local area network (LAN), or the Internet, among others. External computing devices may be connected to the computer system 100 through the network 112. In some examples, the external computing devices may be external web servers or cloud computing nodes.

[0032] It should be understood that the block diagram in Figure 1 is not intended to show that computer system 100 comprises all the components shown in Figure 1. Rather, computer system 100 may include fewer arbitrary components, and may also include additional components not shown in Figure 1 (e.g., additional memory components, embedded controllers, modules, additional network interfaces, etc.). Furthermore, the embodiments described herein with respect to computer system 100 may be implemented by any arbitrary logic, and in various embodiments, the logic referred herein may include any suitable hardware (e.g., in particular a processor, embedded controller, or application-specific integrated circuit), software (e.g., in particular an application), firmware, or any suitable combination of hardware, software, and firmware.

[0033] Figure 2 is a block diagram of an exemplary computing environment 200 configured to sequentially verify an access token according to one or more embodiments of the present invention. The computing environment 200 may comprise a computer system 202, a sidecar computer system 205, a client computer system 240, an authentication server 270, and a backend service computer system 280, any of which may include any of the hardware and software components and functions discussed in computer system 100 of Figure 1. The computing environment 200 may represent one or more parts of a cloud computing environment. The functionality of the computing environment 200 can be achieved by using or implementing any or both workloads of workload layer 90 and hardware and software layer 60 components described in Figure 17.

[0034] Figure 3 is a flowchart of a computer implementation process 300 relating to interaction patterns of intercepted transactional calls according to one or more embodiments. Figure 3 can be illustrated by interaction patterns of REST (Representational State Transfer) calls. REST is a software architecture style created to guide the design and development of the World Wide Web architecture. REST APIs provide a flexible and lightweight way to integrate applications and have emerged as the most common way to connect components in microservice architectures. REST APIs are sometimes referred to as RESTful APIs because they are APIs that conform to the design principles of the REST (Representational State Transfer) architecture style.

[0035] According to one or more embodiments, for each transaction, the (only) initial transaction generation call queries the authentication server for verification. This differs from traditional transactional REST calls, where every REST call must query the authentication server, some entity, or both for verification.

[0036] In block 302 of the computer implementation process 300, when the client computer system 240 makes a REST call to the backend transaction service of the backend service computer system 280 using the access token in the header, the token interceptor 218 of the sidecar computer system 250 is configured to intercept the transaction REST call from the client computer system 240 to the authentication server 270 and generate a multi-statement transaction by sending a POST request to obtain a transaction identification (ID) (also called TID) from the token computer system 202. A REST call is a transaction request for a transaction. The client computer system 240 can log in to the token computer system 202 in advance to obtain an access token to use in configuring the transaction REST. The client computer system 240 is a representative of the operating entity and can be an application, client, etc., running on the computer system.

[0037] A transaction is a logical unit of work for performing an operation. A transaction can consist of one or more statements, all of which may either fail or succeed. Depending on the transaction type and the type of statements within the transaction, a transaction can be an update transaction or a query (read-only) transaction. Depending on the execution mode at the time of creation, a transaction can be a single-statement transaction or a multi-statement transaction. A transaction becomes a multi-statement transaction when it is created in the context of an explicitly set execution mode. A transaction ID may be a special set of numbers that defines each transaction.

[0038] A POST request is a request method supported by the Hypertext Transfer Protocol (HTTP) used on the World Wide Web. By design, the POST request method requests a server to accept data enclosed in the request message body. For example, a POST request is used to send data to an API server to generate or update a resource. The data sent to the server is stored in the request body of the HTTP request.

[0039] In block 304, the token interceptor 218 of the sidecar computer system 250 is configured to query the authentication server 270 for verification of the client computer system 240 (or client application computer system) by a transaction REST call requesting a transaction with an access token, and is also configured to receive and store the time to live (TTL) of the access token associated with the client computer system 240. Although the sidecar computer system 250 may query the authentication server 270 via the token computer system 202, in one or more embodiments it may communicate by querying the authentication server 270 directly. After receiving the TTL from the token computer system 202, the sidecar computer system 250 can store the access token's TTL in the local TTL database 252. For convenience of explanation, we assume that the initial transaction generation call of the transaction is requested by the client computer system 240. For subsequent, consecutive, or both subsequent transactional calls / requests of the same transaction by client computer system 240, sidecar computer system 250, client computer system 240, and backend service computer system 280 do not need to query authentication server 270 or token computer system 202 or both for verification.

[0040] In block 306, for a series of transaction calls / requests for a transaction desired by the client computer system 240, the sidecar computer system 250 is configured to use the validity period stored in the local TTL database 252 to verify the access token associated with the transaction, without querying the authentication server 270 for access token verification. For example, the client computer system 240 may use the (same) access token to send subsequent calls to the transaction to the backend service computer system 280, where the subsequent calls / requests follow the initial call of the transaction, for which the sidecar computer system 250 initially requested the authentication server 270 to query for verification. Upon intercepting the subsequent calls / requests from the client computer system 240 to the backend service computer system 280, the sidecar computer system 250 is configured to parse and recognize that the access token is being used for the service calls / requests of the transaction following the initial service call. Therefore, the sidecar computer system 250 can look up the access token in the local TTL database 252 to confirm that it is a subsequent service call / request. In one or more embodiments, the sidecar computer system 250 is configured to prevent the token computer system 202 from querying the authentication server 270 for verification of the access token of a subsequent call / request, or prevent the backend service computer system 250 from querying the authentication server 270 for verification of the access token of a subsequent call / request, or both.Instead, in block 308, the sidecar computer system 250 is configured to check whether the access token in the local TTL database 252 is still valid without querying the authentication server 270 or being queryed by the authentication server 270, or both. For example, the sidecar computer system 250 is configured to check whether the access token in the local TTL database 252 has expired.

[0041] In block 310, if the access token associated with the transaction's subsequent calls / requests is no longer valid (i.e., expired), the sidecar computer system 250 is configured to roll back the transaction so that no potential changes to one or more resources of the backend service computer system 280 are performed or become effective.

[0042] In block 312, if the access token associated with a subsequent call / request of a transaction is still valid (i.e., not expired), the sidecar computer system 250 is configured to execute the transaction to modify one or more resources on the backend service computer system 280. In a transaction system, execution and rollback represent a set of actions that cause an application program to either make all changes to a resource represented by a single recovery unit (UR), or to make no changes at all. Furthermore, subsequent calls / requests of a transaction using the same access token (i.e., any service calls / requests of a transaction after the initial service call / request of the transaction) are permitted by the backend service computer system 280 to be passed directly to the backend transaction service after it has been confirmed that the access token has not expired.

[0043] In one or more embodiments, the sidecar computer system 250 may include HTTP proxy functionality to redirect the original client POST request to a backend service computer system 280 (e.g., a backend server). From the perspective of the backend service, the backend service computer system 280 is unaware that this POST request originates from the sidecar computer system 250, and receives the POST request as if it originated from the client computer system 240. The backend service computer system 280 generates a transaction identifier and then sends back a response. The sidecar computer system 250 intercepts the response, records the transaction identifier in the local TTL database 252, and associates the transaction identifier with the stored TTL of the token. The sidecar computer system 250 reproxys the response to the client computer system 240. The transaction with the transaction identifier is generated by the client computer system 240. The sidecar computer system 250, without accessing the authentication server 270, intercepts and obtains the transaction identifier and TTL of a subsequent transaction call (which includes the transaction identifier in its header), and then obtains the TTL by comparing it with the transaction identifier stored in the local TTL database 252.

[0044] Figure 4 is a block diagram showing an example of a sidecar computer system 250 as a token interceptor used in an Identity and Access Management (IAM) policy, according to one or more embodiments. In this example, an IAM system 276 is available, including an IAM engine 222, an access decision engine 224, and an IAM policy database 226. The IAM engine 222 and the access decision engine 224 may be one or more software applications or modules, or both, running on the token computer system 202. The IAM system 276 is shown on the token computer system 202, but in one or more embodiments, part of it may be on the token computer system 202, or all of it may be on a separate computer system from the token computer system 202. By using the IAM policy management API, the IAM engine 222 can generate, update, view, and delete IAM policies in the IAM policy database 226. IAM policies enable access to target resources. These policies are used for access decisions when a client computer system calls an API to an IAM-enabled service.

[0045] In Figure 4, the IAM policy executed by the IAM engine 222 typically uses an API key to generate an access token. As seen in Figure 4, the access token defines targeted access (e.g., field 402) to a target (e.g., field 404) with specific permissions (e.g., field 406). Typically, all calls made with the access token to the backend service computer system 280 require the access decision engine 224 to decide whether the call is permitted or denied. However, similar to the description in Figure 3 regarding the authentication server 270, but using the access decision engine 224 of the IAM system 276 as an alternative, the token interceptor 218 of the sidecar computer system 250 is configured to reduce the amount of token verification access to the access decision engine 224 of the IAM system 276 according to one or more embodiments, thereby reducing the risk of misuse of the access token if the attached API key expires.

[0046] Figure 5 is a block diagram further illustrating an example of a sidecar computer system 250 as a token interceptor for use in an IAM policy of IAM system 276 according to one or more embodiments. In operation 501.1, the token interceptor 218 of the sidecar computer system 250 is configured to intercept a first IAM generation token call with API key 1 from a client computer system 240 intended for IAM system 276 of token computer system 202. In operation 501.2, the token interceptor 218 of the sidecar computer system 250 is configured to intercept a second IAM generation token call with API key 2 from a client computer system 240 intended for IAM system 276 of token computer system 202. In one or more embodiments, IAM system 276 can notify the token interceptor 218 of the sidecar computer system 250 of IAM generation token calls with API key 1 and API key 2.

[0047] In operation 502.1, the token interceptor 218 of the sidecar computer system 250 is configured to query the IAM engine 222 of the IAM system 276 to generate access tokens for the IAM generated token call for API key 1 (and similarly, API key 2). The IAM engine 222 may generate tokens identified in the token list. In operation 502.2, the token interceptor 218 of the sidecar computer system 250 is configured to query the access decision engine 224 of the IAM system 276 to check that the generated access tokens have privileges to access the relevant resources of the backend service computer system 280. In operation 502.3, the sidecar computer system 250 is configured to store the API keys (e.g., API key 1, API key 2), the privileges from the access decision engine 224 (and the types of privileges for the tokens in the token list), and the token list in the sidecar computer system 250's local policy database 254.

[0048] The token interceptor 218 builds or generates associations between tokens in the token list, access policies for target resources, and API keys in the local policy database 254, or both, so that whenever an API key and its tokens are identified in a service call / request, this additional data is read from the local policy database 254 and applied to grant or deny access to the target resources. Figure 5 shows that in this exemplary scenario, the sidecar computer system 250 has local access to the access policy for API key 1, as well as tokens 1 and 2, which are used to grant or deny access to backend services on the backend service computer system 280 of the client computer system 240.

[0049] Figure 6 is a block diagram further illustrating an example of a sidecar computer system 250 as a token interceptor for use in an IAM policy, according to one or more embodiments. Similar to the description of the authentication server 270 in Figure 3, Figure 6 illustrates the use of a transactional REST call. Naturally, one or more embodiments may be applied to other types of service calls.

[0050] In operation 601.1, the token interceptor 218 of the sidecar computer system 250 is configured to intercept a transactional REST call from the client computer system 240 to the backend service computer system 280, with token 1 of API key 1. In operation 601.2, the sidecar computer system 250 is configured to intercept a transactional REST call from the client computer system 240 to the backend service computer system 280, with token 2 of API key 1.

[0051] In operation 602, the sidecar computer system 250 is configured to check the token access privileges in the local token list in the local policy database 254 for access tokens (for example, tokens 1 and 2 of API key 1). According to the token access policies (privileges) in the local token list in the local policy database 254, the token interceptor 218 of the sidecar computer system 250 determines whether the transaction requested with the access tokens and API key is permitted.

[0052] In operation 603, the token interceptor 218 of the sidecar computer system 250 is configured to either grant or deny access to resources on the backend service computer system 280 depending on whether the access token for an API key (e.g., API key 1) is granted or denied access in the local token list in the local policy database 254.

[0053] In operation 604, the token interceptor 218 of the sidecar computer system 250 is configured to continuously check / monitor API key revocation events, and if the sidecar computer system 250 detects an API key revocation, it is configured to block access to the target resource of the backend service computer system 250 by invalidating / deleting the token list associated with the revoked API key. For example, an API key revocation event may be pushed from or pulled from the IAM engine 222, or both. The IAM engine 222 may invalidate an API key (e.g., API key 1) using standard methods. The invalidation of an API key may also be an operation initiated by an administrator from a cloud graphical user interface (GUI) typically coupled to the token computer system 202 (e.g., communicating with the IAM engine 222), and the API key invalidation operation generates an API key revocation event. This API key revocation event is monitored, and when it occurs, the sidecar computer system 250 invalidates all tokens associated with this API key. As seen in Figures 4, 5, and 6, the sidecar computer system 250, acting as a token interceptor, is configured to reduce the token validation access to the access decision engine of the IAM system 276 in one or more embodiments, thereby reducing the risk of misuse of access tokens when an attached API key revoks.

[0054] Figure 7 is a block diagram showing a token initializer according to one or more embodiments. The token initializer 204 may represent one or more software applications or modules, or both, running on the token computer system 202. The token initializer 204 is configured to accept login requests from client computer systems 240 (e.g., the operating entity) and to obtain access tokens and refresh tokens from authentication identity information providers, such as one of the authentication servers 270. The token initializer 204 is configured to obtain a new access token using the refresh token when the access token expires, i.e., when its validity period expires. The token initializer 204 is also configured to store the refresh token in the token bucket 206 for separate use.

[0055] Figure 8 is a block diagram showing a policy manager according to one or more embodiments. The policy manager 208 may represent one or more software applications or modules, or both, running on the token computer system 202. The policy manager 208 is configured to analyze policies defined in the policy database 210, provide input to the token manager 212 to apply the policies to access tokens and refresh tokens, and analyze patterns in existing token sets to generate new potential token policies.

[0056] Moving on to further details regarding the policy database 210, this policy database 210 includes entities that use tokens to access the management resources and conditions of services and determine trigger conditions, including operating entities (e.g., client computer system 240), users or groups, access tokens or refresh tokens or both, and services. The policy database 210 also has rules including how and when to renew access tokens, how and when to invalidate access tokens and refresh tokens, which access tokens or refresh tokens or both a user should follow, which access tokens or refresh tokens or both a group should follow, and which access tokens or refresh tokens or both a group of services should follow. To implement various token behaviors for users and services as defined in the policy database 210, each token or group of tokens or both can be applied to different combinations of various rules. To illustrate the policies in the policy database 210, Figure 9 is a block diagram showing an example of rules in the policy database 210 according to one or more embodiments.

[0057] Figure 10 is a block diagram showing a token manager according to one or more embodiments. The token manager 212 may represent one or more software applications or modules, or both, running on the token computer system 202. The token manager 212 is configured to manage tokens according to policies defined in the policy database 210 and is configured to manage the token lifecycle (i.e., validity period) for a single user, multiple users, or both by calling the token refresher 214 (detailed separately in Figure 11), the token invalidator 216 (detailed separately in Figure 12), and the token interceptor 218.

[0058] Figure 11 is a block diagram showing a token refresher 214 according to one or more embodiments. The token refresher 214 may represent one or more software applications or modules, or both, running on the token computer system 202. The token refresher 214 is configured to refresh the duration (i.e., validity period) of a token to extend its usable time and to obtain a refreshed access token using a refresh token.

[0059] Figure 12 is a block diagram showing a token invalidator 216 according to one or more embodiments. The token invalidator 216 may represent one or more software applications or modules, or both, running on the token computer system 202. The token invalidator 216 is configured to explicitly invalidate or destroy, or both, tokens in the token bucket 206, in accordance with instructions or policies, or both, enforced by the token manager 212. The token invalidator 216 is configured to invalidate an access token if the access token is invalid (only), and to invalidate both the access token and the refresh token if the refresh token is invalid.

[0060] Figure 13 is a block diagram showing a token interceptor 218 according to one or more embodiments. The token interceptor 218 may represent one or more software applications or modules, or both, running on the sidecar computer system 250. The token interceptor 218 is configured to intercept API calls from the client computer system 240 with HTTP authentication headers and Unified Resource Identifier (URI) query parameters, verify the token using the information stored in the token bucket 206, and either pass the request (i.e., the API call with HTTP authentication headers and URI query parameters) to the backend service of the backend service computer system 280, or reject the request due to token expiration.

[0061] Figure 14 is a flowchart of a computer implementation method 1400 for enabling transactions with a backend service computer system 280 by stepwise verification of an access token, according to one or more embodiments of the present invention. The computer implementation method 1400 may be performed using the sidecar computer system 250 shown in Figure 2. The functionality of the computer system can be achieved by using and / or implementing the hardware components of the hardware and software layer 60 and / or the workloads of the workload layer 90 shown in Figure 17.

[0062] In block 1402 of the computer implementation method 1400, a token interceptor 218 (e.g., one or more software applications) of a sidecar computer system 250 is configured to verify a token for an initial call to a service transaction in response to the interception of an initial call to a service transaction from a client (e.g., from a client computer system 240 to a backend service computer system 280), and this verification includes (by the sidecar computer system 250) querying an authentication server 270 and storing the received validity period for the token locally (e.g., in a local TTL database 252).

[0063] In block 1404, the token interceptor 218 of the sidecar computer system 250 is configured to determine that, in response to the interception of at least one consecutive calls of a service transaction from a client (for example, from the client computer system 240 to the backend service computer system 280), the token for at least one consecutive call is valid based on the validity period stored locally in the local TTL database 252.

[0064] In block 1406, the token interceptor 218 of the sidecar computer system 250 is configured to allow the passing of at least one consecutive calls of service-related transactions (for example, to the backend service computer system 280 for the execution of at least one action on one or more resources managed by the backend service computer system 280) without querying the authentication server 270.

[0065] In one or more embodiments, the token interceptor 218 of the sidecar computer system 250 is configured to determine that at least one consecutive call is the final call of a transaction and to execute the transaction. The initial call and subsequent calls (including the final consecutive call) of the transaction use the same token.

[0066] The token interceptor 218 of the sidecar computer system 250 is configured to determine that a token for the final consecutive call is invalid based on the expiration of the locally stored validity period in the local TTL database 252, thereby preventing the handover of the final consecutive call of the transaction related to the service and rolling back the transaction. For example, the token interceptor 218 checks the validity period in the local TTL database 252 and confirms that the validity period has expired, which means the token is invalid. Therefore, the token interceptor 218 prevents the handover of the final consecutive call to the backend service computer system 280, or the processing of the final consecutive call by the backend service computer system 280, or both. Furthermore, the token interceptor 218 rolls back the transaction, which includes any past calls of the transaction.

[0067] The token interceptor 218 of the sidecar computer system 250 is configured to prevent unauthorized reuse of tokens by clearing / deleting the token's validity period from the local TTL database 252 in response to the execution or rollback of a transaction.

[0068] Determining that at least one token for a series of calls is valid based on the expiration period stored locally in the local TTL database 252 includes preventing the backend service computer system 280 from querying the authentication server 270 (for example, via the token computer system 202) to verify the token for at least one series of calls. Determining that at least one token for a series of calls is valid based on the expiration period stored locally in the local TTL database 252 avoids the requirement for the backend service computer system 280 to query the authentication server 270 (for example, via the token computer system 202) to verify the token for at least one series of calls. The transaction makes a change to at least one resource associated with the backend service computer system 280.

[0069] Figure 15 is a flowchart of a computer implementation method 1500, according to one or more embodiments of the present invention, for enabling transactions with or access to a backend service computer system 280, or both, by stepwise verification of an access token. The computer implementation method 1500 may be performed using the sidecar computer system 250 shown in Figure 2. The functionality of the computer system can be achieved by using and / or implementing hardware components of the hardware and software layer 60 and / or workloads of the workload layer 90, as shown in Figure 17.

[0070] In block 1502 of the computer implementation method 1500, a token interceptor 218 (e.g., one or more software applications) of the sidecar computer system 250 is configured to respond to the interception of a token call with an Application Programming Interface (API) key for a service transaction from a client (e.g., a client computer system 240) by querying an authentication server 270 (e.g., an IAM engine 222 and an access decision engine 224) to obtain a token list and an access policy for an API key, where the API key, token list, and policy are associated together and stored locally in a local policy database 254. For example, the token interceptor 218 can query the IAM engine 222 using an intercepted token call with an API key to generate an access token, and query the access decision engine 224 to obtain the access policy for the generated token, all of which are stored in the local policy database 254.

[0071] In block 1504, the token interceptor 218 is configured to respond to calls relating to services with API keys and the interception of previously generated tokens by determining whether a call is granted access to the service based on a list of API key tokens and access policies stored locally in the local policy database 254. For example, the token interceptor 218 checks the local policy database 254 to confirm that the call is granted access to the desired service on the backend service computer system 280 without querying the authentication server 270.

[0072] In block 1506, the token interceptor 218 is configured to allow service calls to access resources on the backend service computer system 280 without querying the authentication server 270.

[0073] The token interceptor 218 is configured to determine whether subsequent calls to a service possessing an API key and whether another token will be granted access to the service are permitted, based on the token list and access policies of API keys stored locally in the local policy database 254. Determining whether a call will be granted access to a service based on the token list and access policies of API keys stored locally in the local policy database 254 includes, without querying the authentication server 270, verifying that the token is on the token list and verifying that the access policy permits access to the service by the API key. The token interceptor 218 is configured to monitor for API key revocation events, for example, by checks by the authentication server 270 (e.g., push or pull or both).

[0074] The token interceptor 218 is configured to prevent the separate use of an API key by invalidating the token list associated with the revoked API key in response to an API key revocation event. The token interceptor 218 is configured to allow the token list stored locally in the local policy database 254 to continue to be used in determining access to the API key in response to no API key revocation event.

[0075] This disclosure includes a detailed description of cloud computing, but it should be understood that the implementation of the teachings enumerated herein is not limited to cloud computing environments. Rather, embodiments of the present invention can be implemented in conjunction with any other type of computing environment, whether currently known or hereafter developed.

[0076] Cloud computing is a service delivery model that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be quickly set up and exposed with minimal administrative effort or interaction with service providers. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0077] The characteristics are as follows:

[0078] On-demand self-service: Cloud users can unilaterally configure server time and computing functions such as network storage automatically as needed, without the need for human interaction with the service provider.

[0079] Extensive network access: Functionality is available over the network and accessed through standard mechanisms that facilitate use by heterogeneous thin-client or thick-client platforms (e.g., mobile phones, laptops, and PDAs).

[0080] Resource pooling: Using a multi-tenant model, a provider's computing resources are pooled for multiple users. Various physical and virtual resources are dynamically allocated and reallocated as needed. While users generally cannot control or know the exact location of the resources provided, a degree of location independence exists, as the location can be identified at a higher level of abstraction (e.g., country, state, or data center).

[0081] Rapid Flexibility: Features can be configured quickly and flexibly for rapid scale-out and rapidly exposed for rapid scale-in, sometimes automatically. For users, the features available for configuration are often seemingly unlimited and can be purchased at any time and in any quantity.

[0082] Service Measurement: Cloud systems automatically control and optimize resource usage by utilizing measurement capabilities at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both service providers and users.

[0083] The service model is as follows:

[0084] Software as a Service (SaaS): The functionality provided to the user is the use of the provider's applications running on a cloud infrastructure. These applications are accessible from various client devices through thin-client interfaces such as web browsers (e.g., web-based email). The user does not manage or control the underlying cloud infrastructure, including the network, servers, operating system, storage, or individual application functions, except for the configuration of user-specific, limited application configurations.

[0085] Platform as a Service (PaaS): The function provided to the user is to deploy user-created or acquired applications, created using programming languages ​​and tools supported by the provider, onto the cloud infrastructure. The user does not manage or control the underlying cloud infrastructure, including the network, servers, operating system, or storage. However, they do control the deployed applications and, in some cases, the configuration of the application hosting environment.

[0086] Infrastructure as a Service (IaaS): The functionality provided to the user is the configuration of processing, storage, networking, and other basic computing resources, but the user can deploy and run any software, which may include operating systems and applications. The user does not manage or control the underlying cloud infrastructure. However, they do control the operating system, storage, and deployed applications, and in some cases, have limited control over selected network components (e.g., the host's firewall).

[0087] The layout model is as follows:

[0088] Private Cloud: This cloud infrastructure is operated independently for a specific organization. It may be managed by that organization or a third party, and may reside on-premises or off-premises.

[0089] Community Cloud: This cloud infrastructure is shared by multiple organizations and supports specific communities that share common concerns (e.g., mission, security requirements, policies, and compliance matters). It can be managed by this organization or a third party and can reside on-premises or off-premises.

[0090] Public Cloud: This cloud infrastructure is available to the general public or large industry groups and is owned by organizations that sell cloud services.

[0091] Hybrid Cloud: This cloud infrastructure is a combination of two or more clouds (private, community, or public) that maintain their own distinct entities while being coupled together by standard or proprietary technologies (e.g., cloud bursting for load balancing between clouds) to achieve data and application portability.

[0092] Cloud computing environments are service-oriented, focusing on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is infrastructure, including a network of interconnected nodes.

[0093] Referring now to Figure 16, which shows an exemplary cloud computing environment 50, the cloud computing environment 50 comprises one or more cloud computing nodes 10 that enable communication between local computing devices used by cloud users, such as personal digital assistive devices (PDAs) or mobile phones 54A, desktop computers 54B, laptop computers 54C, or automotive computer systems 54N, or a combination thereof. The nodes 10 may communicate with each other. They may be physically or virtually grouped in one or more networks, such as the private cloud, community cloud, public cloud, or hybrid cloud, or a combination thereof (not shown). This allows the cloud computing environment 50 to provide infrastructure as a service, platform as a service, or software as a service, or a combination thereof, without requiring cloud users to maintain resources on their local computing devices. The types of computing devices 54A to 54N shown in Figure 16 are for illustrative purposes only, and it should be understood that the computing node 10 and the cloud computing environment 50 can communicate with any type of computerized device over any type of network or network addressable connection, or both (for example, by using a web browser).

[0094] Referring now to Figure 17, this figure illustrates a set of functional abstraction layers provided by the cloud computing environment 50 (Figure 16). It should be understood that the components, layers, and functions shown in Figure 17 are illustrative only, and embodiments of the present invention are not limited thereto. As illustrated, the following layers and corresponding functions are provided:

[0095] The hardware and software layer 60 includes hardware components and software components. Examples of hardware components include a mainframe 61, RISC (Reduced Instruction Set Computer) architecture-based servers 62, 63, blade servers 64, storage devices 65, and network and networking components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0096] The virtualization layer 70 provides an abstraction layer, which can provide examples of virtual entities such as virtual servers 71, virtual storage 72, virtual networks 73 (including virtual private networks), virtual applications and operating systems 74, and virtual clients 75.

[0097] For example, the management layer 80 may provide the functions described below. Resource configuration 81 provides dynamic procurement of resources, such as computing resources, used to execute tasks in the cloud computing environment. Measurement and pricing 82 provides cost tracking when resources are used in the cloud computing environment and billing or invoicing for the consumption of these resources. For example, these resources may include application software licenses. Security provides verification of the identity of cloud users and tasks, as well as protection of data and other resources. The user portal 83 provides users and system administrators with access to the cloud computing environment. Service level management 84 provides allocation and management of cloud computing resources to satisfy the required service levels. Service level agreement (SLA) planning and execution 85 provides pre-arrangement and procurement of cloud computing resources that are expected to meet future requirements in accordance with the SLA.

[0098] Workload Layer 90 provides examples of available functions in a cloud computing environment. Examples of workloads and functions that can be provided from this layer include mapping and navigation 91, software development and lifecycle management 92, virtual classroom education delivery 93, data analysis processing 94, transaction processing 95, and workloads and functions 96. Workloads and functions 96 may include various software applications (or perform various functions, or both) in the token computer system 202, sidecar computer system 250, backend service computer system 280, authentication server 270, etc., discussed herein.

[0099] In this specification, various embodiments of the present invention are described with reference to the relevant drawings. Alternative embodiments of the present invention can be devised without departing from the scope of the present invention. In the following description and drawings, various connections and positional relationships (e.g., above, below, adjacent, etc.) are defined between elements. These connections or positional relationships, or both, can be direct or indirect unless otherwise specified, and in this respect, the present invention is not intended to limit. Thus, the joining of entities can represent direct or indirect joining, and the positional relationships between entities can be direct or indirect. Furthermore, the various tasks and process steps described herein can be incorporated into more comprehensive procedures or processes having additional steps or functions not described in detail herein.

[0100] One or more of the methods described herein can be implemented by any or a combination of technologies known in the art, such as discrete logic circuits having logic gates for performing logic functions on data signals, application-specific integrated circuits (ASICs) having appropriate combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0101] For the sake of simplification, prior art related to the configuration and use of aspects of the present invention may or may not be described in detail herein. In particular, various embodiments of computing systems and specific computer programs that implement the various technical features described herein are well known. Therefore, for the sake of simplification herein, many prior embodiments will be described only briefly, or omitted entirely, without giving details of the well known systems or processes or both.

[0102] In some embodiments, various functions and operations may occur in a given location, in relation to the operation of one or more devices or systems, or both. In some embodiments, a portion of a given function or operation may be performed on a first device or location, and other portions of this function or operation may be performed on one or more additional devices or locations.

[0103] The technical terms used herein are intended solely to describe specific embodiments and are not intended to limit them. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless otherwise explicitly specified in the context. It should be further understood that the terms "comprise" or "comprising," as used herein, specify the presence of a described feature, integer, step, action, element, or component, or combination thereof, but do not exclude or preclude the presence of one or more other features, integers, steps, actions, elements, components, or groups thereof, or combination thereof.

[0104] In the following claims, the corresponding structures, materials, actions, and equivalents of all means-plus-function elements or step-plus-function elements are intended to include any structures, materials, or actions for performing a function in combination with other specifically claimed elements. This disclosure is presented for illustrative and explanatory purposes only, and is not intended to be exhaustive or to limit the forms of disclosure. Many improvements and modifications will become apparent to those skilled in the art without departing from the scope of this disclosure. The embodiments are selected and described to best illustrate the principles and practical applications of this disclosure and to enable those skilled in the art to understand the disclosure with various improvements suitable for specific conceivable uses.

[0105] The drawings described herein are illustrative. Many variations may exist in the drawings or the steps (or actions) described therein without departing from the scope of this disclosure. For example, actions may be performed in a different order, and actions may be added, deleted, or modified. Furthermore, the term “coupled” indicates the presence of a signal path between two elements and does not imply a direct connection between elements without the intervention of an element / connection. All these variations are considered part of this disclosure.

[0106] The following definitions and abbreviations shall be used for the purposes of the claims and interpretation of this specification. As used herein, the terms “comprise,” “comprising,” “include,” “including,” “have,” “having,” “contain,” or “containing,” or any other variation thereof, are intended to encompass non-exclusive inclusion. For example, a composition, mixture, process, method, item, or apparatus containing a list of elements is not necessarily limited to these elements and may include other elements that are neither expressly listed nor specific to such composition, mixture, process, method, item, or apparatus.

[0107] Furthermore, in this specification, the term “exemplary” is used to mean “serving as an example, case, or illustration.” No embodiment or design described as “exemplary” in this specification shall necessarily be construed as preferable or advantageous to other embodiments or designs. The terms “at least one” and “one or more” are understood to include one or more any integers, i.e., 1, 2, 3, 4, etc. The term “a plurality” is understood to include two or more any integers, i.e., 2, 3, 4, 5, etc. The term “connection” may include both indirect and direct “connections.”

[0108] The terms “about,” “substantially,” “approximately,” and their variations are intended to include the degree of error associated with the measurement of a particular quantity based on equipment available at the time of filing of this application. For example, “about” may include a range of ±8%, 5%, or 2% of a given value.

[0109] The present invention may be a system, method, or computer program product, or a combination thereof, at any possible level of technical detail integration. The computer program product may comprise a computer-readable storage medium (or a set of mediums) having computer-readable program instructions thereon for causing a processor to execute an aspect of the present invention.

[0110] Computer-readable storage media can be tangible devices capable of holding and storing instructions used by instruction execution devices. Computer-readable storage media may be, but are not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any preferred combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random-access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), static random-access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disks (DVDs), memory sticks (R), floppy disks (R), mechanical encoding devices such as punch cards or grooved structures on which instructions are recorded, and any preferred combination thereof. As used herein, computer-readable storage media shall not be interpreted as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through optical fiber cables), or electrical signals transmitted through wires.

[0111] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computer / processor, or they may be downloaded to an external computer or external storage device via, for example, the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. The network adapter card or network interface of each computer / processor receives computer-readable program instructions from the network, transfers these computer-readable program instructions, and stores them in a computer-readable storage medium within each computer / processor.

[0112] The computer-readable program instructions for performing the operation of the present invention may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk(R) and C++, and procedural programming languages ​​such as the C programming language or similar programming languages. The computer-readable program instructions may be executed in whole or in part as a standalone software package on the user's computer, in part on the user's computer and in part on a remote computer, or in whole on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or wide area network (WAN), or it may be connected to an external computer (for example, via the Internet by using an Internet service provider). In some embodiments, to carry out aspects of the present invention, electronic circuits may be personalized by utilizing state information of computer-readable program instructions, so that electronic circuits including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs) execute computer-readable program instructions.

[0113] In this specification, aspects of the present invention are described with reference to flowcharts or block diagrams, or both, of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It is understood that each block in a flowchart or block diagram, or both, and any combination of blocks in a flowchart or block diagram, or both, can be implemented by computer-readable program instructions.

[0114] These computer-readable program instructions may be provided to a general-purpose computer, a dedicated computer, or a processor of another programmable data processing device to create a machine, such that instructions executed via the processor of a computer or other programmable data processing device generate means for implementing a specified function / operation in one or more blocks of a flowchart or block diagram, or both. Alternatively, these computer-readable program instructions may be stored in a computer-readable storage medium containing instructions, such that the storage medium contains a product containing instructions for implementing a specified mode of function / operation in one or more blocks of a flowchart or block diagram, or both, instructing a computer, a programmable data processing device, or other device, or a combination thereof, to function in a particular manner.

[0115] Furthermore, computer-readable program instructions may be loaded into a computer, another programmable data processing device, or another device to generate a computer implementation process in which instructions executed on a computer, another programmable device, or another device implement a specified function / operation in one or more blocks of a flowchart or block diagram, or both, and a series of operation steps may be executed on the computer, another programmable device, or another device.

[0116] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible embodiments of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or part of an instruction containing one or more executable instructions for implementing a particular logical function. In some alternative embodiments, the functions described in a block may be performed in an order different from the order shown in the drawings. For example, two consecutively shown blocks may actually be executed substantially simultaneously, depending on the functions involved, or in some cases in reverse order. It should also be noted that each block in a block diagram or flowchart, or both, and any combination of blocks in a block diagram or flowchart, or both, can be implemented by a dedicated hardware-based system that performs a particular function or operation, or a combination of dedicated hardware and computer instructions.

[0117] The descriptions of various embodiments of the present invention are presented for illustrative purposes only and are not intended to be exhaustive or limit to the disclosed embodiments. Many improvements and modifications will become apparent to those skilled in the art without departing from the scope of the described embodiments. The terminology used herein has been selected to best describe the principles of the embodiments, their practical applications, or the technical improvements of the technology found in the market, or to enable other those skilled in the art to understand the embodiments described herein.

Claims

1. A computer implementation method, In response to the interception of an initial transaction call from a client regarding the service, the verification of the token for the initial transaction regarding the service includes querying an authentication server and locally storing the validity period received for the token. In response to the interception of at least one consecutive call of the transaction relating to the service from the client, it is determined that the token for the at least one consecutive call is valid based on the locally stored validity period, Allowing the passing of at least one consecutive calls of the transaction relating to the service without querying the authentication server, Determining that the at least one consecutive call is the final call of the transaction, In response to the at least one consecutive call as the final call of the transaction, and if the locally stored validity period is still valid, the transaction is executed. Computer implementation methods including

2. The method according to claim 1, wherein the initial call and the subsequent calls of the transaction use the same token.

3. Based on the expiration of the validity period stored locally, it is determined that the token for the last consecutive call is invalid, To prevent the passing of the final consecutive call of the transaction relating to the said service, To reverse the aforementioned transaction, The computer implementation method according to claim 1, further comprising:

4. The computer implementation method according to claim 1, further comprising avoiding unauthorized reuse of the token by clearing the validity period of the token in response to the execution or rollback of the transaction.

5. The computer implementation method according to claim 1, wherein determining that the token for the at least one consecutive call is valid based on the locally stored validity period prevents the backend service computer system from querying the authentication server for verification of the token for the at least one consecutive call.

6. The computer implementation method according to claim 1, wherein determining that the token for at least one consecutive call is valid based on the locally stored validity period avoids the requirement for the backend service computer system to query the authentication server for verification of the token for at least one consecutive call.

7. The computer implementation method according to claim 1, wherein the transaction makes a change to at least one resource associated with the backend service computer system.

8. It is a system, Memory with computer-readable instructions, One or more processors for executing the computer-readable instruction, wherein the computer-readable instruction is In response to the interception of an initial transaction call from a client regarding the service, the verification of the token for the initial transaction regarding the service includes querying an authentication server and locally storing the validity period received for the token. In response to the interception of at least one consecutive call of the transaction relating to the service from the client, it is determined that the token for the at least one consecutive call is valid based on the locally stored validity period, Allowing the passing of at least one consecutive calls of the transaction relating to the service without querying the authentication server, Determining that the at least one consecutive call is the final call of the transaction, Execute the transaction in response to the at least one consecutive call as the final call of the transaction, provided that the locally stored validity period is still valid. Controlling the one or more processors to perform an operation including, A system equipped with these features.

9. The system according to claim 8, wherein the initial call and the subsequent calls of the transaction use the same token.

10. The aforementioned operation, Based on the expiration of the validity period stored locally, it is determined that the token for the last consecutive call is invalid, To prevent the passing of the final consecutive call of the transaction relating to the said service, To reverse the aforementioned transaction, The system according to claim 8, further comprising:

11. The system according to claim 8, further comprising the action of preventing unauthorized reuse of the token by clearing the validity period of the token in response to the execution or rollback of the transaction.

12. The system according to claim 8, wherein determining that the token for the at least one consecutive call is valid based on the locally stored validity period prevents the backend service computer system from querying the authentication server for verification of the token for the at least one consecutive call.

13. The system according to claim 8, wherein determining that the token for at least one consecutive call is valid based on the locally stored validity period avoids the need for the backend service computer system to query the authentication server for verification of the token for at least one consecutive call.

14. The system according to claim 8, wherein the transaction makes a change to at least one resource associated with the backend service computer system.

15. A computer implementation method, In response to the interception of a token call from a client involving an Application Programming Interface (API) key for a service transaction, the system queries the access decision engine to obtain the token list and access policy for the API key, which are then stored locally and associated together. In response to a call relating to the service having the API key and the interception of a token, it is determined that the call is granted access to the service based on the locally stored token list and access policy of the API key, To allow access to the resources of the call relating to the service without querying the access decision engine, Computer implementation methods including

16. The computer implementation method according to claim 15, further comprising determining, based on the token list and access policy of the API key stored locally, that subsequent calls relating to the service having the API key and another token are granted access to the service.

17. Computer implementation method according to claim 15, wherein determining that a call is granted access to the service based on the token list and access policy of the locally stored API key includes, without querying the access determination engine, verifying that the token is on the token list and verifying that the access policy permits access to the service by the API key.

18. The computer implementation method according to claim 15, further comprising monitoring API key expiration events.

19. The computer implementation method according to claim 18, further comprising preventing the separate use of the API key by invalidating the token list associated with the expired API key in response to the occurrence of the API key expiration event.

20. The computer implementation method according to claim 18, further comprising allowing the locally stored token list to continue to be used in determining access to the API key in response to the absence of the API key revocation event.

21. A computer program that causes one or more processors to perform the method described in any one of claims 15 to 20.

22. It is a system, Memory with computer-readable instructions, One or more processors for executing the computer-readable instructions, wherein the computer-readable instructions control the one or more processors to perform the method according to any one of claims 15 to 20, A system equipped with these features.

Images