Client-server security enhancements using information accessed from access tokens

Abstract

A service computing system receives an API call, where an authorization token is included in the header of the API call, the contents of which contain an identifier. The identifier is also included as a parameter passed in with the API call. The service computing system parses the API call to obtain the authorization token, and the identifier included in the authorization token. It also obtains the identifier passed in as a parameter of the API call. The service computing system compares the identifier obtained from the authorization token with the identifier passed in as a parameter of the API call to determine if they match. If they do not match, the API call is processed as an unauthorized API call. A security system in the service computing system authorizes the API call based on the comparison.

Description

Background Technology

[0001] Computer systems are now widely used. Some of these computer systems are arranged in a client-server architecture. In such an architecture, the server provides services by exposing application programming interfaces (APIs) that can be called by client computing systems in order to gain access to resources maintained by the server.

[0002] This service is typically configured to maintain resources based on different tenants or organizations using them. Therefore, when a client computing system requests access to a resource, it calls the API exposed by the service, including either an organization identifier or a user identifier as one of the parameters in the API call. The tenant identifier identifies the organization or organization object corresponding to the resource to be accessed, and the user identifier identifies the user or user object corresponding to the resource to be accessed.

[0003] The above discussion is provided for general background information only and is not intended to help define the scope of the subject matter for which protection is sought. Summary of the Invention

[0004] The service computing system receives API calls, where the API call header includes an authorization token containing an identifier. This identifier is also included as a parameter passed with the API call. The service computing system parses the API call to obtain the authorization token and the identifier included in the authorization token. It also obtains the identifier passed as a parameter to the API call. The service computing system compares the identifier obtained from the authorization token with the identifier passed as a parameter to the API call to determine if they match. The security system in the service computing system authorizes the API call based on this comparison.

[0005] This summary is provided to introduce, in a simplified form, the selection of concepts further described below in the detailed description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to assist in determining the scope of the claimed subject matter. The claimed subject matter is not limited to implementations that address any or all of the shortcomings pointed out in the background art. Attached Figure Description

[0006] Figure 1 This is a block diagram of an example computing system architecture.

[0007] Figure 2 This is a block diagram that shows an example of an API interaction system in more detail.

[0008] Figure 3 This is a block diagram illustrating an example of a security system in more detail.

[0009] Figure 4 This is a flowchart illustrating an example of how a client computing system operates when making API calls.

[0010] Figure 5 This is a flowchart illustrating an example of how a service computing system authorizes API calls.

[0011] Figure 6 It shows the deployment in the cloud computing architecture. Figure 1 A block diagram of an example of the architecture shown.

[0012] Figure 7 This is a block diagram illustrating an example of a computing environment that can be used in the architecture shown in the previous figure. Detailed Implementation

[0013] As described above, in a client-server computing system architecture, the client computing system typically accesses server-level resources by making API calls using APIs exposed by the server. As an example, a first service located in the cloud can act as a client and interact with a second service located in the cloud by making API calls to an API exposed by that second service. In some current architectures, an API call is processed as long as it can be authenticated, and the parameters passed to the API are not checked. To increase security, in some current systems, API calls have headers in which the first service acting as the client computing system can place information. Therefore, in some current systems, the client computing system places an identifier in the header of the API call to identify the tenant or user whose resources will be accessed. The client also inserts this identifier as a parameter into the API call. In such a system, the server-side security system (the second service in this example) accesses the identifier in the header and compares it with the identifier passed as a parameter. If they match, the API call is authorized to continue.

[0014] However, this still presents security risks. For example, if a covert user gains access to a client DLL, that user can create an instance of the client. This client can then generate API calls that take an identifier that identifies the entity (such as an organization or user) as a parameter and also request access to the resources of that identified entity. The covert actor can also place the identifier in the header of the API call. Therefore, if a covert actor gains access to the client DLL, they can also gain access to the client's resources at the server level.

[0015] Therefore, this specification continues with systems where the client computing system obtains a signed authorization token, which includes an identifier, and this signed authorization token is placed in the header of the API call, also including the identifier as a parameter in the API call. When the server computing system receives the API call, it parses the header information to obtain the signed authorization token and ensures that the authorization token is authorized (it has not been altered). It then obtains the identifier from the authorization token and compares the obtained identifier with the identifier passed as a parameter. It authorizes the API call based on this comparison. In this way, even if a covert actor obtains the client DLL, it cannot enable the authorized API call to gain access to client resources because it will not be able to obtain the signed authorization token from the token issuer. Therefore, at the server level, the API call will be treated as an unauthorized API call.

[0016] Figure 1 This is a block diagram of an example computing system architecture 100, which further illustrates this. Figure 1 In the example shown, architecture 100 includes a service computing system 102 and multiple different client computing systems 104-106, which can access resources on the service computing system 102 via network 108. Network 108 can therefore be any of a wide variety of different types of networks, such as wide area networks, local area networks, near field communication networks, cellular networks, and a wide variety of other networks or combinations of networks.

[0017] In addition, Figure 1 In the example shown, service computing system 102 exposes application programming interface (API) 110 for interaction with client computing systems 104-106. Client computing systems 104-106 can make API calls to the exposed API 110 to gain access to service computing system 102 and its resources.

[0018] For the purposes of this specification, it is assumed that the client computing system 104 is a service that serves as a client (or can be used as a client) of the service computing system 102. For example, it can run within the same cloud service computing system 102.

[0019] Architecture 100 also illustrates that, in one example, client computing system 106 generates user interface 116 for user 118 to interact with. User 118 may be an administrator or another user who may wish to access resources on service computing system 102. User 118 illustratively interacts with user interface 116 to control and manipulate parts of client computing system 106 and service computing system 102.

[0020] As an example, suppose service computing system 102 is an email service computing system, and administrative user 118 wants to move a mailbox in service computing system 102. Administrative user 118 also assumes that a command can be run on computing system 106 to create a request for moving the identified mailbox. In that case, client computing system 104 can receive the request and invoke service computing system 102 (as a client of system 102) to request access to a resource (e.g., the mailbox). This can be achieved by making an access request call to API 110 exposed by system 102.

[0021] In addition, Figure 1 In the example shown, architecture 100 illustrates a token issuer service 120, which can issue tokens to client computing system 104 directly (if they are in the same cloud) or via network 108. In short, for example, client computing system 104 can obtain an authorization token from token issuer service 120. The request for the token generated by client computing system 104 can be limited by an identifier that corresponds to the user or organization on service computing system 102 that will be accessed. The authorization token issued by service 120 includes this identifier in the token's content. Continuing with the example above, this identifier could identify the tenant or user corresponding to the mailbox to be moved.

[0022] The client computing system 104 then generates an API call on API 110, which includes an authorization token in the API call header, as well as an identifier passed as a parameter with the API call. The service computing system 102 authorizes the API call by comparing the identifier in the token (retrieved from the API call header) with the identifier passed as a parameter with the API call. If they match, the API call proceeds. If they do not match, it is not authorized.

[0023] Before describing the operation of architecture 100 in more detail, a brief description of some items in architecture 100 and their operations will first be provided. Client computing systems 104-106 may be similar or different. In the example described herein, it is assumed that client computing system 104 is a service acting as a client of service computing system 102. Client computing system 106 is illustratively a computing system used by management users or other users requesting access to resources on computing system 102. Therefore, only client computing system 104 will be described in more detail.

[0024] exist Figure 1In the example shown, the client computing system 104 illustratively includes one or more processors or servers 122, a data storage unit 124, a communication system 126, an API interaction system 128, and may include a wide variety of other client system functions 132. The communication system 126 can be used to communicate with the token issuer service 120 and the service computing system 102 (using API 110) via network 108. Therefore, the communication system 126 can be any of a wide variety of different types of communication systems, depending on the specific type of network or combination of networks it intends to communicate with.

[0025] API interaction system 128 illustratively generates API calls for API 110. Thus, in one example, API interaction system 128 illustratively receives a request generated by user 118 indicating that user 118 wishes to obtain access to resources on service computing system 102. Therefore, it generates API calls to API 110 to obtain access to these resources. In doing so, it illustratively obtains an authorization token from token issuer service 120 and places it in the header of the API call. It also illustratively receives and processes responses to the API calls accordingly. This is described in more detail below. Other client system functions 132 may include a wide variety of other client computing system functions.

[0026] The token issuer service 120 illustratively includes one or more processors or servers 134, a data storage unit 136, a requester authentication system 138, a token generation system 140, and a communication system 142, and may include a wide variety of other token issuer functions 144. The communication system 142 illustratively communicates via a network 108. Therefore, it can be any of a wide variety of different types of communication systems or combinations of systems used for communication via the network 108.

[0027] Requester authentication system 138 illustratively authenticates requests for tokens. In one example, token issuer service 120 receives from service computing system 102 an instruction indicating that client computing system 104 is authorized to access certain resources on service computing system 102. Therefore, requester authentication system 138 shares a secret with client computing system 104. API interaction system 128 uses this secret when requesting an authorization token from token issuer service 120. Requester authentication system 138 also uses this secret to authenticate client computing system 104 as a system that can request authorization tokens from service 120.

[0028] Token generation system 140 generates authorization tokens. In one example, a request for an authorization token for accessing resources on service computing system 102 includes an identifier identifying the organization or user whose resources are being accessed. In that case, token generation system 140 generates the authorization token to include the identifier within the authorization token itself. As an example, system 140 may generate an authorization token to include three or more distinct parts. These may include a metadata part, a content (or claim) part, and a signature part. The content or claim part may contain the identifier. The signature part includes the signature. Once the token is signed, the authorized recipient of the token will be able to determine whether the token has been modified based on the signature.

[0029] exist Figure 1 In the example shown, the service computing system 102 includes one or more different servers 146, protected resources 148, a front-end system 150, a back-end system 152, a security system 154, and may include a wide variety of other service computing system functions 156. The front-end system 150 illustratively exposes API 110 that can receive API calls from the client computing system 104.

[0030] When a request to access protected resource 148 is received, frontend system 150 declaratively provides access to the API call to security system 154. In one example, security system 154 parses the API call to obtain an authorization token from the API call header. The authorization token itself is first authenticated. Using the signature on the authorization token, it is determined whether any content, metadata, or other information in the authorization token has been modified. If so, the call will fail because the authorization token has been modified. Assuming the authorization token itself is authenticated by security system 154, security system 154 then proceeds to determine whether the API call is authorized. Security system 154 obtains an identifier from the authorization token, and it also obtains the identifier passed as a parameter at the API call. It compares the two and determines whether the API call is authorized.

[0031] If the API call is authorized, it is passed to backend system 152, which grants access to the protected resource 148. If it is unauthorized, it is treated as an unauthorized API request by service computing system 102. This may include alerting security personnel, simply denying the requested access, and similar actions.

[0032] Figure 2This is a block diagram illustrating an example of an API interaction system 128 in more detail. The API interaction system 128 illustratively includes a token request logic unit 160, an API call generator 162 (which itself includes a token insertion logic unit 164, a parameter insertion logic unit 166, and may include other items 168), and a response processing logic unit 170, and may include other items 172. The token request logic unit 160 illustratively requests an access token from a token issuer service 120 and processes interactions with the token issuer service 120. Therefore, when an authorization token (or access token) is needed, it requests the token from the token issuer service 120 and provides that token to the API call generator 162. In the example shown herein, the API call generator 162 illustratively generates an API call, which may include headers and parameters, among other things. The token insertion logic unit 164 inserts the authorization token received from the token request logic unit 160 into the header of the API call. The parameter insertion logic unit 166 generates and inserts parameters based on the specific access request made in the API call. API call generator 162 can then provide API calls to communication system 126. Figure 1 As shown, in communication system 126 it is provided to API 110. When API 110 provides a response to an API call, response processing logic unit 170 receives the response and processes it as needed based on the executed access request.

[0033] Figure 3 This is a block diagram illustrating an example of security system 154 in more detail. Figure 3In the example shown, security system 154 illustratively includes an API call header parsing logic unit 174, a token processing logic unit 176, a parameter parsing logic unit 178, an identifier comparison logic unit 180, an unauthorized call handling logic unit 182, and a call authorization logic unit 184, and may include a variety of other items 186. The API call header parsing logic unit 174 illustratively parses the API call to identify an authorization token in the API call header. It provides the authorization token to the token processing logic unit 176. The token processing logic unit 176 illustratively processes the authorization token to determine whether the authorization token is genuine and authorized. For example, based on the signature in the authorization token, logic unit 176 can determine whether any part of the authorization token has been altered because it has been signed. If not, and the authorization token itself is genuine and authorized, then the token processing logic unit 176 illustratively identifies a specific identifier that the token request logic unit 160 uses to limit the scope of the authorization token request when it requests a token from the token issuer service 120. Recall that in one example, this identifier was included in the content portion of the authorization token. The parameter parsing logic unit 178 then parses the parameters in the API call to obtain the identifier that is passed as a parameter.

[0034] The identifier comparison logic unit 180 compares the identifier retrieved from the authorization token with the identifier retrieved from the parameters of the API call. It determines whether these identifiers are the same. If they are not the same, the unauthorized call processing logic unit 182 processes the API call as an unauthorized call. If so, the call authorization logic unit 184 instructs the API call processing to continue.

[0035] Figure 4 This is a flowchart illustrating an example of the operations of client computing system 104 and API interaction system 128 in requesting an authorization token and generating an API call using that authorization token. First, assume that a service (e.g., service computing system 102) is providing access to a protected resource (e.g., resource 148), and it exposes API 110 for interaction with client computing systems (in this example, client computing system 104). This is... Figure 4 Box 190 in the flowchart indicates this.

[0036] It is also assumed that the token issuer service 120 has shared the token request secret with the client computing system 104, and that the client computing system 104 has been approved by the service computing system 102 (to the token issuer service 120). This is by Figure 4 Box 192 in the flowchart indicates this.

[0037] In some cases, when client computing system 104 desires access to protected resource 148 on service computing system 102, token request logic unit 160 subsequently requests a resource access token from token issuer service 120. In doing so, it descriptively limits the scope of the access request with an identifier (which identifies the user or organization whose resource will be accessed). The request for the token and the limitation of the request scope by the identifier are determined by… Figure 4 Box 194 in the flowchart indicates that the identifier can be a tenant identifier, as indicated by box 191. It can be a user identifier as indicated by box 193, or another identifier as indicated by box 195.

[0038] The token is generated by the token generation system 140, which includes an identifier in the content portion of the token. It also signs the token and provides it back to the token request logic unit 160. Figure 4 Box 196 in the flowchart indicates receiving a resource access token from token issuer 120, where the identifier is part of the content (e.g., a statement) of the resource access token.

[0039] API call generator 164 then generates an API call to request access to a resource using API 110 exposed by service computing system 102. Token insertion logic unit 164 inserts a resource access token into the header of the API call. Parameter insertion logic unit 166 inserts an identifier as a parameter of the API call. API calls are generated in this way by... Figure 4 Box 198 in the flowchart indicates this.

[0040] Service computing system 102 then authenticates and authorizes the API call, and if authenticated and authorized, responds to the API call. Response processing logic unit 170 descriptively receives the requested access to the resource, as indicated by the response from service computing system 102. Receiving the requested access is handled by... Figure 4 The flowchart is indicated by box 200.

[0041] Figure 5 This is a flowchart illustrating an example of how security system 154 and service computing system 102 process API calls requesting access to protected resource 148. Front-end system 150 first receives a resource access request as an API call via API 110. This is handled by... Figure 5 Box 202 in the flowchart indicates this. The header parsing logic unit 174 then parses the API call header to obtain the resource access token inserted into the header by the token insertion logic unit 164 on the client computing system 104. Parsing the header to obtain the resource access token is... Figure 5 Box 204 in the flowchart indicates this.

[0042] The token processing logic unit 176 then verifies the token. For example, it can access the signature on the token to determine whether the token has been altered since it was issued by the token issuer service 120. Token verification is performed by... Figure 5 Box 206 in the flowchart indicates that if the token is invalid, as indicated in box 208, the API call will be treated as an unauthorized API call, as indicated in box 209.

[0043] However, if the token processing logic unit 176 does indeed verify the token at box 208, then the token processing logic unit 176 obtains the identifier from the content portion of the resource access token. This is determined by... Figure 5 Box 210 in the flowchart indicates this.

[0044] The parameter parsing logic unit 178 then obtains the identifier passed as a parameter in the API call. This is indicated by box 212. The identifier comparison logic unit 180 compares the identifier obtained from the token with the identifier passed as a parameter in the API call. This is indicated by box 214.

[0045] If the two identifiers do not match, as indicated in box 216, the unauthorized call handling logic unit 182 treats the API call as an unauthorized API call. This is also indicated in box 209.

[0046] However, if it is determined at box 216 that the two identifiers do indeed match, the authorization logic unit 184 continues to process the call as an authorized API call, thereby granting the requested access to the protected resource 148. This is by Figure 5 Box 218 in the flowchart indicates this.

[0047] Therefore, it can be seen that this specification greatly enhances the security of protected resources in a client-server architecture. By obtaining an authorization token, which includes an identifier provided by the requesting client through the token, and then having that client include the token in API calls, an unauthorized user cannot gain unauthorized access to protected resources, even if the unauthorized user wants to obtain the client's DLL. This significantly enhances security.

[0048] It will be noted that the foregoing discussion has described a wide variety of different systems, components, and / or logical units. It will be understood that such systems, components, and / or logical units can consist of hardware items (such as processors and associated memory, or other processing components, some of which are described below) that perform the functions associated with those systems, components, and / or logical units. Additionally, as described below, systems, components, and / or logical units can consist of software loaded into memory and subsequently executed by a processor, server, or other computing component. Systems, components, and / or logical units can also consist of different combinations of hardware, software, firmware, etc., some examples of which are described below. These are merely some examples of different structures that can be used to form the aforementioned systems, components, and / or logical units. Other structures may also be used.

[0049] This discussion also mentions processors and servers. In one example, processors and servers include computer processors with associated memory and timing circuitry (not shown separately). They are functional parts of the system or device to which they belong and are activated by and facilitate the function of other components or items in those systems.

[0050] Furthermore, numerous user interface displays have been discussed. They can take a wide variety of forms and have a wide variety of user-initiable input mechanisms placed on them. For example, user-initiable input mechanisms can be text boxes, checkboxes, icons, links, drop-down menus, search boxes, etc. They can also be initiated in a variety of ways. For example, they can be initiated using pointing and clicking devices (such as trackballs or mice). They can be initiated using hardware buttons, switches, joysticks or keyboards, thumb switches or thumb pads, etc. They can also be initiated using virtual keyboards or other virtual actuators. In addition, if the screen displaying them is a touch-sensitive screen, they can be initiated using touch gestures. Furthermore, if the device displaying them has a voice recognition component, they can be initiated using voice commands.

[0051] Various data storage units have already been discussed. It should be noted that they can be partitioned into multiple data storage units. All data storage units can be local to the system accessing them, all data storage units can be remote, or some can be local while others are remote. All these configurations are envisioned in this paper.

[0052] Additionally, the accompanying diagram shows multiple boxes, with functionality assigned to each box. It's important to note that fewer boxes can be used so that functionality is performed by fewer components. Conversely, more boxes can be used when functionality is distributed among more components.

[0053] Figure 6 yes Figure 1 The block diagram of architecture 100 shown herein is an example of a cloud computing architecture 500, except that its elements are situated within the cloud computing architecture. Cloud computing provides computing, software, data access, and storage services without requiring end users to be aware of the physical location or configuration of the system delivering the service. In various examples, cloud computing delivers services over a wide area network (such as the Internet) using appropriate protocols. For example, a cloud computing provider delivers an application over a wide area network, and it can be accessed via a web browser or any other computing component. The software or components of architecture 100, along with the corresponding data, may be stored on servers at a remote location. Computing resources in a cloud computing environment may be consolidated at a remote data center location, or they may be distributed. Cloud computing infrastructure can deliver services over a shared data center, even if they appear as a single access point to the user. Therefore, the components and functionalities described herein can be provided from a service provider located at a remote location using a cloud computing architecture. Alternatively, they may be provided from traditional servers, or they may be installed directly or otherwise on client devices.

[0054] This description aims to encompass both public and private cloud computing. Cloud computing (both public and private) offers a large, seamless aggregation of resources, along with reduced requirements for managing and configuring the underlying hardware infrastructure.

[0055] Public clouds are managed by a vendor and typically support multiple consumers using the same infrastructure. Furthermore, unlike private clouds, public clouds free end users from managing the hardware. Private clouds can be managed by the organization itself, and the infrastructure is usually not shared with other organizations. The organization will maintain the hardware to some extent, such as installation and maintenance.

[0056] exist Figure 6 In the example shown, some items are similar to Figure 1 The items shown are similar, and they are numbered similarly. Figure 6 Specifically, systems 102 and 104, as well as service 120, can all reside in cloud 502 (which can be public, private, or a combination of partially public and partially private). Therefore, user 118 accesses those systems via cloud 502 using user equipment and client computing system 106.

[0057] Figure 6 It also depicts another example of cloud architecture. Figure 6It is illustrated that some elements of architecture 100 may be located within cloud 502, while others may not. By way of example, token issuer service 120 and data storage unit 136 may be located outside of cloud 502 and accessed through cloud 502. Regardless of their location, they may be directly accessible by the system, accessible via a network (WAN or LAN), hosted as a service at a remote site, or provided as a service through the cloud or accessed by a connectivity service located in the cloud. All these architectures are envisioned in this document.

[0058] Also note that architecture 100 or parts thereof can be deployed on a wide variety of different devices. Some of those devices include servers, desktop computers, laptops, tablets, or other mobile devices such as handheld computers, mobile phones, smartphones, multimedia players, personal digital assistants, etc.

[0059] Figure 7 This is an example of a computing environment in which architecture 100 or a portion thereof (for example) can be deployed. Reference Figure 7 Example systems for implementing some embodiments include general-purpose computing devices in the form of a computer 810. Components of computer 810 may include, but are not limited to: a processing unit 820 (which may include the processor or server shown in the previous figure), system memory 830, and a system bus 821 that couples various system components, including the system memory, to the processing unit 820. System bus 821 may be any of several types of bus architectures, including a memory bus or memory controller, a peripheral bus, and a local bus using any of various bus architectures. By way of example and not limitation, these architectures include: Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus (also known as the Mezzanine bus). Figure 1 The described memory and program can be deployed in Figure 7 In the corresponding part.

[0060] Computer 810 typically includes a variety of computer-readable media. Computer-readable media can be any available medium accessible to computer 810, and includes both volatile and non-volatile media, removable and non-removable media. By way of example and not limitation, computer-readable media can include computer storage media and communication media. Computer storage media are distinct from and do not include modulated data signals or carrier waves. They include hardware storage media, which include information for storing computer-readable instructions, data structures, program modules, or other data, both volatile and non-volatile media implemented in any method or technology, removable and non-removable media. Computer storage media include, but are not limited to: RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic tape cassettes, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to computer 810. Communication media typically embody computer-readable instructions, data structures, program modules, or other data in a transmission mechanism, and includes any information transmission medium. The term "modulated data signal" means a signal having one or more of its set of characteristics or altered in a manner that encodes information in the signal. By way of example, and not limitation, communication media include wired media such as wired networks or direct-wire connections, and wireless media such as voice, RF, infrared, and other wireless media. Any combination of the foregoing should also be included within the scope of computer-readable media.

[0061] System memory 830 includes computer storage media in the form of volatile and / or non-volatile memory, such as read-only memory (ROM) 831 and random access memory (RAM) 832. A basic input / output system 833 (BIOS) containing basic routines that facilitate the transfer of information between components in computer 810 (such as at startup) is typically stored in ROM 831. RAM 832 typically contains data and / or program modules that are immediately accessible and / or currently in operation by processing unit 820. By way of example and not limitation, Figure 7 The operating system 834, application program 835, other program modules 836, and program data 837 are described.

[0062] Computer 810 may also include other removable / non-removable, volatile / non-volatile computer storage media. By way of example, Figure 7A hard disk drive 841 is depicted that reads from or writes to a non-removable, non-volatile magnetic medium, and an optical disk drive 855 that reads from or writes to a removable, non-volatile optical disk 856 (such as a CD-ROM or other optical media). Other removable / non-removable, volatile / non-volatile computer storage media that may be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital multifunction disks, digital video tapes, solid-state RAM, solid-state ROM, etc. The hard disk drive 841 is typically connected to the system bus 821 via a non-removable memory interface (such as interface 840), while the optical disk drive 855 is typically connected to the system bus 821 via a removable memory interface (such as interface 850).

[0063] Alternatively or additionally, the functions described herein may be performed at least in part by one or more hardware logic components. Illustrative types of hardware logic components that may be used, by way of example and not limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application-Specific Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (PLDs), etc.

[0064] In the discussion above and Figure 7 The driver and its associated computer storage media depicted provide the computer 810 with storage for computer-readable instructions, data structures, program modules, and other data. For example, in Figure 7 In this context, hard disk drive 841 is depicted as storing operating system 844, application programs 845, other program modules 846, and program data 847. Note: These components may be the same as or different from operating system 834, application programs 835, other program modules 836, and program data 837. Operating system 844, application programs 845, other program modules 846, and program data 847 are assigned different numbers here to indicate that they are at least different copies.

[0065] Users can input commands and information into computer 810 via input devices such as keyboard 862, microphone 863, and pointing devices 861 (such as mouse, trackball, or touchpad). Other input devices (not shown) may include joysticks, game controllers, satellite dish antennas, scanners, etc. These and other input devices are often connected to processing unit 820 via user input interface 860 coupled to the system bus, but may be connected via other interfaces and bus structures (such as parallel ports, game ports, or Universal Serial Bus (USB)). Visual display 891 or other types of display devices are also connected to system bus 821 via an interface (such as video interface 890). In addition to a monitor, the computer may also include other peripheral output devices such as speakers 897 and printers 896, which can be connected via output peripheral interface 895.

[0066] Computer 810 operates in a networked environment using logical connections to one or more remote computers (such as remote computer 880). Remote computer 880 may be a personal computer, handheld device, server, router, network PC, peer-to-peer device, or other public network node, and typically includes many or all of the elements described above for computer 810. Figure 7 The logical connections described include Local Area Networks (LANs) 871 and Wide Area Networks (WANs) 873, but may also include other networks. Such network connection environments are common in offices, enterprise-wide computer networks, intranets, and the Internet.

[0067] When used in a LAN network connection environment, computer 810 connects to LAN 871 via a network interface or adapter 870. When used in a WAN network connection environment, computer 810 typically includes a modem 872 or other means for establishing communication over a WAN 873 (such as the Internet). Modem 872 (which may be internal or external) may be connected to system bus 821 via user input interface 860 or other suitable mechanism. In a networked environment, program modules or portions thereof depicted for computer 810 may be stored in a remote memory storage device. This is by way of example and not limitation. Figure 7 Remote application 885 is shown as residing on remote computer 880. It will be understood that the network connection shown is exemplary and other means for establishing communication links between computers may be used.

[0068] It should also be noted that the different examples described in this article can be combined in different ways. That is, parts of one or more examples can be combined with parts of one or more other examples. All of these are envisioned in this article.

[0069] Example 1 is a computing system that includes:

[0070] processor;

[0071] A front-end system that exposes an Application Programming Interface (API) that receives access requests for accessing protected resources, the access requests having a header portion and a parameter portion; and

[0072] A security system that identifies a resource access token in the header portion of the access request and authorizes the access request based on information in the resource access token and information in the parameter portion of the resource access request.

[0073] Example 2 is a computing system according to any or all of the previous examples, wherein the security system includes:

[0074] The API header parsing logic unit is configured to parse the header portion to identify the resource access token.

[0075] Example 3 is a computing system according to any or all of the previous examples, wherein the resource access token has a content portion including a first identifier, and wherein the parameter portion of the access request has a second identifier.

[0076] Example 4 is a computing system according to any or all of the previous examples, wherein the security system includes:

[0077] A token processing logic unit is configured to: identify the first identifier in the content portion of the resource access token.

[0078] Example 5 is a computing system according to any or all of the preceding examples, wherein the security system includes:

[0079] A parameter parsing logic unit is configured to: identify the second identifier in the parameter portion of the access request.

[0080] Example 6 is a computing system according to any or all of the preceding examples, wherein the security system includes:

[0081] An identifier comparison logic unit is configured to: compare the first identifier with the second identifier and generate a comparison result indicating the comparison; and

[0082] An authorization logic unit is configured to determine whether the access request is an authorized access request based on the comparison result.

[0083] Example 7 is a computing system according to any or all of the previous examples, wherein the first identifier and the second identifier identify the user corresponding to the protected resource.

[0084] Example 8 is a computing system according to any or all of the previous examples, wherein the first identifier and the second identifier identify an organization corresponding to the protected resource.

[0085] Example 9 is a computing system according to any or all of the previous examples, wherein the resource access token has a signature portion having a signature, and wherein the token processing logic unit is configured to authenticate the resource access token based on the signature.

[0086] Example 10 is a client computing system that includes:

[0087] processor;

[0088] The token request logic unit obtains the access token from the token issuer;

[0089] An application programming interface (API) call generator that generates resource access request calls to the API to request access to a protected resource, the resource access request call including a set of parameters and including the access token in the header portion of the resource access request call; and

[0090] A communication system that transmits the resource access request call to the API.

[0091] Example 11 is a client computing system according to any or all of the previous examples, wherein the API call generator includes:

[0092] A token insertion logic unit is configured to insert the access token into the header portion of the resource access request invocation, wherein the access token includes a first identifier in the content portion of the access token.

[0093] Example 12 is a client computing system according to any or all of the previous examples, wherein the API call generator includes:

[0094] A parameter insertion logic unit is configured to insert a second identifier into the parameter set.

[0095] Example 13 is a client computing system according to any or all of the previous examples, wherein the first identifier and the second identifier identify a user corresponding to the protected resource.

[0096] Example 14 is a client computing system according to any or all of the previous examples, wherein the first identifier and the second identifier identify an organization corresponding to the protected resource.

[0097] Example 15 is a computer-implemented method that includes:

[0098] Publicly expose application programming interfaces (APIs);

[0099] The API receives access requests for accessing protected resources, and the access requests have a header section and a parameter section.

[0100] Identify the resource access token in the header portion of the access request; and

[0101] The access request is authorized based on the information in the resource access token and the information in the parameter portion of the resource access request.

[0102] Example 16 is any or all of the computer-implemented methods described in the preceding examples, wherein the resource access token includes:

[0103] The header portion is parsed to identify the resource access token.

[0104] Example 17 is any or all of the computer-implemented methods described in the preceding examples, wherein the authorization includes:

[0105] The content portion of the resource access token is parsed to identify the first identifier.

[0106] Example 18 is any or all of the computer-implemented methods described in the preceding examples, wherein the authorization includes:

[0107] The parameter portion of the access request is parsed to identify the second identifier.

[0108] Example 19 is any or all of the computer-implemented methods described in the preceding examples, wherein the authorization includes:

[0109] Compare the first identifier with the second identifier; and

[0110] Generate a comparison result that indicates the comparison.

[0111] Example 20 is any or all of the computer-implemented methods described in the preceding examples, wherein the authorization includes:

[0112] An authorization logic unit is configured to determine whether the access request is an authorized access request based on the comparison result.

[0113] Although the subject matter has been described in language specific to structural features and / or methodological actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are disclosed as examples of implementing the claims.

Claims

1. A computing system, comprising: processor; A front-end system that exposes an application programming interface (API) that receives access requests for accessing protected resources, the access requests having a header portion and a parameter portion; as well as The security system is configured as follows: Identify the resource access token in the header portion of the access request; Identify the first identifier in the content portion of the resource access token; Identify the second identifier in the parameter portion of the access request; Generate a comparison result indicating the comparison between the first identifier and the second identifier; and The access request is authorized based on the comparison result.

2. The computing system according to claim 1, wherein, The security system includes: The API header parsing logic unit is configured to parse the header portion to identify the resource access token.

3. The computing system according to claim 1, wherein, The computing system includes a service computing system, the front-end system receives the access request from the client computing system, and the resource access token is generated by a token issuer service.

4. The computing system according to claim 3, wherein, The security system is configured as follows: The token issuer service is provided with an indication that the client computing system is authorized to access the protected resource, wherein the token is generated by the token issuer service based on the indication, and the access request is authorized based on determining that the first identifier matches the second identifier.

5. The computing system according to claim 1, wherein, The first identifier and the second identifier identify the user corresponding to the protected resource.

6. The computing system according to claim 1, wherein, The first identifier and the second identifier identify the organization corresponding to the protected resource.

7. The computing system according to claim 1, wherein, The resource access token has a signature portion having a signature generated by a token issuer service, and wherein the security system is configured to: determine, based on the signature, whether the token has been altered since it was issued by the token issuer service, and to authenticate the resource access token based on the determination.

8. A computer-implemented method, comprising: Expose application programming interfaces (APIs); The API receives access requests for accessing protected resources, and the access requests have a header section and a parameter section. A resource access token is identified in the header portion of the access request, wherein the resource access token has a content portion including a first identifier, and the parameter portion of the access request has a second identifier; Generate a comparison result indicating the comparison between the first identifier and the second identifier; and The access request is authorized based on the comparison result.

9. The computer-implemented method according to claim 8, wherein, Identifying the resource access token includes parsing the header portion to identify the resource access token.

10. The computer-implemented method according to claim 9, further comprising: The content portion of the resource access token is parsed to identify the first identifier.

11. The computer-implemented method according to claim 10, further comprising: The parameter portion of the access request is parsed to identify the second identifier.

12. The computer-implemented method according to claim 11, wherein, Authorization includes: determining, based on the comparison result, that the access request is an authorized access request.

Images