Web encryption for web messages and application programming interfaces

Systems and methods for providing access to online content while also securing user confidential information are presented. User confidential information (e.g., user phone number or e-mail address) may be used to authenticate and authorize a client device to access online resources, such as microservices exposed via application programming interfaces (APIs). With the techniques described herein, such user confidential information is protected both in transit over a network connection and while at rest in storage on the client device. This is achieved through the use of an encrypted access token (e.g., a JSON Web Encryption (JWE) token) including the user confidential information in an encrypted form. The client device receives such encrypted access token from an identity provider (IDP) and passes it to a resource server API to access the microservices associated with the API, without the client device decrypting the user confidential information contained therein.

FIELD OF THE DISCLOSURE

The present disclosure relates to securing confidential information used in authorizing user access to web-based services through application programming interfaces (APIs) using a token-based approach.

BACKGROUND

Existing techniques for providing access to online resources typically involve authenticating and authorizing user access based upon user credentials. Online resources include services or microservices that permit a user to interact with a secure server to submit information to the server, retrieve information from the server, edit information stored on the server, or perform data processes based upon user-submitted information. Such resources are typically exposed to external users via APIs. Depending upon the scope of the services, such APIs may be secured to protect against unauthorized access or damage to the data resources caused by accidental or malicious misuse of the APIs. Thus, user credentials are used (either directly or indirectly) to protect the data resources exposed to client devices associated with users. In some situations, the user credentials may be stored in cookies or tokens stored on a client device to allow the user access to the resources for a period of time without needing to obtain the user credentials from the user each time the resources are accessed. Such user credentials typically include a unique user identifier (user ID). For simplicity and interconnection, many systems use confidential information (e.g., a phone number or e-mail address) as a user ID.

As data privacy concerns have grown in recent years, however, there has been an increasing need for techniques to provide access to online resources without exposing user confidential information. When user confidential information is used as a unique user ID, such confidential information is exposed to attacks while in transit over a communication network connection between the client device as part of a message. The confidential information is also exposed to attacks while at rest in storage on the client device. For example, software bugs or malicious applications may expose information stored on the client device to malicious actors. Since many legacy systems are configured with user IDs based upon confidential information, new techniques to protect such user confidential information are needed.

SUMMARY

The present invention solves the problem of securing confidential information used to access online resources. To solve this problem, the techniques disclosed herein use encrypted access tokens to maintain data confidentiality and integrity both while in transit and at rest on a client device. The disclosure herein generally relates to systems, methods, and non-transitory computer-readable media storing instructions for securing confidential data used in accessing online resources. The systems, methods, and instructions disclosed herein may be implemented by client devices, identity provider servers, resource services, or combinations thereof.

The techniques described herein may include a method for securing confidential data used in accessing online resources, comprising: authenticating a user account for use by a client application of a client device based upon user credentials associated with the user account by communication between the client device and an identity provider (IDP) via a communication network; sending a token request message including an indication of authentication of the user account from the client application to the IDP; receiving at the client application an encrypted access token having a payload including a user identifier that is encrypted as part of the encrypted access token from the IDP; sending a resource request including the encrypted access token from the client application to a resource server via the communication network; and receiving at the client application a resource request response based upon the encrypted access token from the resource server.

The user identifier included in the encrypted access token may comprise a phone number associated with the user account. The client device may lack a key to decrypt the payload of the encrypted access token. The encrypted access token may be a JavaScript Object Notation (JSON) Web Encryption (JWE) token generated by the IDP or another type of encrypted token. Additionally or alternatively, the encrypted access token may be bound to a user session of the user account in the client application. In some embodiments, the encrypted access token may be stored in a memory of the client device, such that sending the encrypted access token to the resource server includes accessing the encrypted access token from the memory. In further embodiments, the method may include generating a proof-of-possession (PoP) token including an indication of a resource associated with the resource server, which PoP token is signed by a private key of the client application, in which case sending the resource request includes sending the PoP token to the resource server.

Systems or computer-readable media storing instructions for implementing all or part of the methods described above may also be provided in some aspects. Such systems or computer-readable media may include executable instructions to cause one or more processors to implement part or all of the methods described above. Additional or alternative features described herein below may be included in some aspects.

DETAILED DESCRIPTION

The systems, methods, and techniques described herein solve the problem of securing user confidential information used to access online resources. To solve this problem, the techniques disclosed herein use encrypted access tokens to maintain data confidentiality and integrity both while in transit over a communication network connection and at rest in storage on a client device. Unlike existing techniques, the user confidential information is not exposed during storage on the client device, even in situations where the client device has been compromised. Additionally, the techniques disclosed herein may be used by first-party client applications associated with the identity provider (IDP), as well as third-party client applications. Additional, fewer, or alternative aspects may be included in various embodiments, as described herein.

FIG.1illustrates a block diagram of an exemplary secure resource access technique100for provisioning and using encrypted access tokens to access secure online resources. The secure resource access technique100may be implemented to provide access to remote resources through application programming interfaces (APIs) or services in a secure manner, while maintaining the security and confidentiality of user account information needed to access some such resources. As illustrated, a client application110obtains an encrypted access token from an identity provider (IDP)120, which encrypted access token protects the payload by remaining encrypted even when stored or used by the client application110. Thus, any user confidential data included in the encrypted access token (e.g., user phone number or e-mail address) remains secure against attacks, even if the device running the client application110is compromised.

To obtain the encrypted access token, the client application110sends a token request101to the IDP120. The token request101includes an indication of authentication or authorization, such as a code previously received from the IDP120based upon account credentials provided to the IDP120. The token request101may also include information to enable the IDP120to generate an encrypted access token that is bound to the client application110(or to an application session or user session associated with the client application110). In response to a valid token request101, the IDP120generates and returns an encrypted access token102to the client application110, which includes an encrypted payload that may safely contain user confidential information. The encrypted access token may be a JavaScript Object Notation (JSON) Web Encryption (JWE) token or other type of encrypted token, as discussed elsewhere herein. Upon receiving the encrypted access token102from the IDP120, the client application110may use the encrypted access token to obtain access to secure resources of a resource server via a resource API or service130. A copy of the encrypted access token102received from the IDP120may also be stored by the client application110for further use in accessing secure resources.

To access a secure resource, the client application110sends a resource request103that includes a copy of the encrypted access token to a resource API or service130associated with the resource. The resource request103may further include parameters corresponding to the resource request, such as information identifying the client application110or the resource. Upon receiving the resource request103, the resource API or service130verifies the resource request103is authorized based upon the encrypted access token included in the resource request103. To validate the encrypted access token received in the resource request103, the resource API or service130may decrypt the encrypted access token using a public or private key, which may be available to the resource API or service130as part of the same system as the IDP120. Thus, the IDP120and the resource APIs or services130may be operated by the same entity and may share data (e.g., cryptographic keys) in a secure manner using internal networks without exposing such data to external networks. After validation, the resource API or sever130may provide a resource request response104to the client application110, such as by providing requested data (e.g., account data or media content) or by providing a confirmation that one or more actions associated with the resource request have been performed (e.g., confirmation that account data has been updated). Thus, the client application110uses the encrypted access token obtained from the IDP120to obtain access to the secure resources via a resource API or service130without exposing user confidential data to malicious or accidental disclosure.

FIG.2illustrates a block diagram of an exemplary resource security system200, comprising a client device202, an identity provider204, and a resource server206. These components of the resource security system200are communicatively connected via a network208. The resource security system200provides an example of an environment in which the techniques described herein may be implemented to provide secure access to online resources using encrypted access tokens. Although only one of each of the client device202, identity provider (IDP)204, resource server206, and network208(along with each of their constituent components) is illustrated for simplicity, alternative embodiments may include multiple such components. Additional, fewer, or alternative components or configurations may be implemented in various embodiments.

The client device202is a computing device associated with a user to interact with the IDP204and the resource server206via the network208, such as a smartphone, a workstation computer, a tablet computer, a smart device (e.g., a smart speaker, a personal digital assistant device, or an Internet-of-Things (IoT) connected device or component), or other type of computing device capable of receiving and processing electronic information through an electronic communication network. Thus, the client device202includes a controller210to receive, store, process, generate, and output data. The controller210includes a memory212storing processor-executable instructions in a non-transitory medium, one or more processors214configured to execute computer-readable instructions, a random access memory (RAM)216for temporary memory, and an input/output (I/O) circuit218. The components of the controller210may be interconnected via an address/data bus or other means. It should be appreciated that although only one processor214is depicted, the controller210may include multiple processors214in some embodiments. Similarly, the controller210may include multiple RAMs216and multiple memories212. Although the I/O circuit218is likewise depicted as a single block, the I/O circuit218may include a number of different I/O circuits, which may be configured for specific I/O operations. The processor214may include one or more processors of any known or hereafter developed type, including general-purpose processors or special-purpose processors. Similarly, the controller210may implement the RAM216and memory212as semiconductor memories, magnetically readable memories, optically readable memories, or any other type of memory.

To implement functionality of the resource security system200, the memory212of the client device2020may store various applications, routines, software modules, and data. Thus, memory212includes a client application224(e.g., a web browser or special-purpose application) enabling the user to interact with the resources of the resource server206, such as to request media content or to access and update user account data. A user agent222is also provided in the memory212to handle authentication and authorization of a user account via communication with the IDP204, such as by receiving and sending user account credentials (e.g., user name and password) to the IDP204. Depending upon resource and development considerations, the user agent222may be a separate software module or may be part of the client application224. Upon receiving an encrypted access token226from the IDP204, the client device202also stores the token226in the memory212for use in accessing resources of the resource server206.

To provide network connectivity over the network208, the client device202further includes a communication unit220capable of sending and receiving data via wired or wireless communication links to the network208. The communication unit220may include hardware and software components (e.g., encoding modules, decoding modules, and antennas) to transmit messages based up data received from the controller210or to provide received messages to the controller210. The communication unit220may transmit and receive wired or wireless communications with external devices via the network208, using any suitable wireless communication protocol network, such as a wireless telephony network (e.g., GSM, CDMA, LTE, 5G, etc.), a Wi-Fi network (802.11 standards), a WiMAX network, etc. Furthermore, the communication unit220may provide input signals to the controller210via the I/O circuit218. The controller210of the client device202may further be configured to communicate data through the communication unit220using any suitable data protocol.

The IDP204comprises computing components configured to authenticate and authorize the client device202to access external resources based upon an association of the client device202with a user account. Thus, the IDP204comprises a computing device (e.g., one or more servers) configured to communicate via the network208, as well as to receive, store, process, generate, access, and output data Like the client device202, the IDP204includes a controller230that stores and processes electronic data and a communication interface240that communicates with external computing devices (e.g., client devices202or resource servers206) via the network208. Similar to the controller210, the controller230receives, processes, produces, transmits, and stores data. The controller230includes a memory232, a processor234, a RAM236, and an I/O circuit238, each configured and operating analogously to the corresponding components of the controller210described above. The IDP204also includes a communication interface240configured to send and receive communications between the IDP204and external computing devices via a data network connection with the network208. Similar to the communication unit220, the communication interface240may include software and hardware components configured to enable communication using standard or specialized communication protocols, via wired or wireless communication connections.

To implement functionality of the resource security system200, the memory232of the IDP204may store various applications, routines, software modules, and data. Thus, memory232includes an authentication application242and the token application244. The authentication application242may obtain user account credentials from the client device202and authenticate the user account on the client device202. Upon authentication, the token application244may generate an encrypted access token associated with the user account and send the encrypted access token to the client device202. Additionally, in some embodiments, the memory232of the IDP204may store further instructions for one or more encryption or decryption filters246. Such filters246may be used to encrypt or decrypt payload content to generate or use the encrypted access token to provide access to secured external resources based upon user account credentials or related information. In some such embodiments, an encryption filter246may encrypt the payload using a public key associated with a particular resource.

The resource server206comprises computing components configured to provide access to secured external resources to the client device202, based upon verification of user account authorization. Thus, the resource server206comprises one or more servers configured to communicate via the network208, as well as to receive, store, process, generate, access, and output data. Like the client device202, the resource server includes a controller260that stores and processes electronic data and a communication interface270that communicates with external computing devices (e.g., client devices202or IDP204) via the network208. Similar to the controller210, the controller260receives, processes, produces, transmits, and stores data. The controller260includes a memory262, a processor264, a RAM266, and an I/O circuit268, each configured and operating analogously to the corresponding components of the controller210described above. The resource server206also includes a communication interface270configured to send and receive communications between the resource server206and external computing devices via a data network connection with the network208. Similar to the communication unit220, the communication interface270may include software and hardware components configured to enable communication using standard or specialized communication protocols, via wired or wireless communication connections.

The memory262of the resource server206may store various applications, routines, software modules, and data to control access to resources stored on or accessed through the resource server206. Thus, the memory262may store one or more APIs or services272for exposing resource access to client devices202via the network208. The APIs or services272may be configured to verify user account authorization based upon an encrypted access token provided by the client device202prior to providing access to the resources. In some embodiments, the resource server206may decrypt encrypted access tokens using one or more decryption filters276stored in the memory262. Such decryption filters276may access a private key of the resource server206to decrypt the payload content of an encrypted access token to verify user account authorization to access resources stored on or controlled by the resource server206. Each decryption filter276may correspond to one or more of the APIs or services272. The memory262may also store one or more resources274accessible via the APIs or services272, which resources may include data and/or application logic. For example, such resources274may include streaming media content, user account details, account creation application logic, or other types of data or functions. In some embodiments, the resource server206may access one or more resources stored in additional networked memories, databases, or data stores (not shown) via the network208or via additional communication connections (not shown).

FIG.3illustrates a sequence diagram of an exemplary secure resource access process300according to certain embodiments. Parts of the exemplary resource access process300may be implemented by communicating messages via the network208, while communication between the user agent222and the client application224may occur within the client device202. Additional or alternative aspects may be included in some embodiments.

The secure resource access process300begins with an initiate authorization request302from the client application224to the user agent222. Such initiate authorization request302may be sent in response to a user action to log in to a system or to access secured resources (e.g., resources274of the resource server206). Upon receiving the initiate authorization request302, the user agent222obtains user credentials by accessing stored user credentials or otherwise receiving the user credentials from the user (line304). For example, the user agent222may present a login screen or window to enable receiving or accessing the user credentials from the user (e.g., by receiving a user name, password, personal identification number, security question response, or biometric identification data). Upon receiving the user credentials, the user agent222sends the user credentials to the IDP204in a user credential message306, which may be transmitted in an encrypted message or over a secure connection (e.g., using transport layer security).

The IDP204validates the user credentials received from the user agent222(line308), which may include verifying the integrity of the received message and extracting or decrypting the user credentials from the received message. If the user credentials cannot be validated due to error or invalid credentials, the process may terminate. When the user credentials are validated, the IDS204generates and returns an authorization code by transmitting an authorization code message to the user agent222. The authorization code message310may be transmitted in an encrypted message or over a secure connection. Upon receiving the authorization code message310, the user agent222extracts the authorization code and provides an authorization code response312to the client application224. The client application224is thus authenticated or authorized on the client device202.

Upon receiving the authorization code response312, the client application224proceeds to obtain an encrypted access token to enable access secure resources from one or more resource servers206. To obtain such encrypted access token, the client application224sends a token request message314to the IDP204, which may be transmitted in an encrypted message or over a secure connection. The token request message314includes the authorization code and may further include a client identifier to bind the encrypted access token to the client device202or to the client application224. In some embodiments, a session identifier may also be included to bind the encrypted access token to a session. Upon receiving the token request message314, the IDP204validates the authorization code and generates an encrypted access token. In some embodiments, the encrypted access token includes user confidential data, such as personally identifiable information used as a user identifier (e.g., user phone number or e-mail address). The encrypted access token may be generated as a JavaScript Object Notation (JSON) Web Encryption (JWE) token or other type of encrypted token, as discussed elsewhere herein. The IDP204then sends an encrypted access token message318containing the encrypted access token to the client application224. Although the encrypted access token message318may be transmitted in an encrypted message or over a secure connection, transport security is not required because the encrypted access token is itself secure. Thus, interception or modification of the encrypted access token would not compromise the security of the system resources or any user confidential data included in the token. Upon receiving the encrypted access token message318, the client application224may store the encrypted access token in the memory212of the client device202(i.e., as an encrypted access token226). The encrypted access token may thus be stored for repeated use in accessing secure resources from one or more resource servers206over a duration of time, which time duration may be determined by an expiration parameter of the encrypted access token.

To access resources from a resource server206, such as upon request by the user of the client device202, the client application224generates a resource request message using the stored encrypted access token (line322). The resource request message may include the encrypted access token. In some embodiments, generating the resource request message may include generating a proof-of-possession token to be included in the resource request message. However composed, the resource request message324is sent from the client application224to the resource server206to request access to secure resources (e.g., to access a resource274via an API or service272of the resource server206). When the resource server206receives the resource request message324via an API or service272, it validates the encrypted access token to verify user authorization to access the requested resource274(line326). In some embodiments, such validation may include decrypting the payload of the encrypted access token via a decryption filter276. Alternatively, the resource server206may communicate with the IPD204to provide the encrypted access token to the IDP204for decryption and verification by a decryption filter246of the IDP204. After validation, the resource server206grants access to the requested resource274to the client application224. In some embodiments, granting access to the resource may include sending a resource request response message328to the client application224. Such resource request response message328may include data, files, or other content requested by the client application224. Additionally or alternatively, granting access to the resource may include performing a function at the resource server206based upon the resource request message324(e.g., adding, deleting, updating, processing, or storing data in the memory262based upon the resource request message324). After the resource server206performs an action in response to the resource request message324after validating the encrypted access token, the secure resource access process300may end.

FIG.4illustrates a flow diagram of an exemplary secure resource access method400for accessing secure resources using an encrypted access token. The secure resource access method400may be implemented by components of the client device202in communication via the network208with the IDP204and the resource server206. Various aspects of the method may be performed by software applications, routines, or modules running on the client device202, such as the user agent222and the client application224.

The secure resource access method400begins with authentication or authorization of the user account at the client device202(block402). The client device202then obtains an encrypted access token from the IDP204(block404) and stores the received encrypted access token (block406). To access the secure resources from the resource server206, in some embodiments, the client device202generates a proof-of-possession (PoP) token (block408). A resource request message is generated (block410) and sent from the client device202to the resource server206(block412). After the resource server206verifies user authorization, the resource request is processed by the resource server206. In some embodiments, the client device414receives a response to the resource request message from the resource server206(block414). The client device416may further generate and send additional resource request messages (and receive additional responses, as applicable) using the stored encrypted access token until no further resource requests remain (block416). When no further resource requests remain, the method ends. Additional or alternative aspects may be included in some embodiments.

At block402, the user agent222of the client device202authenticates or authorizes the user account for use by a client application224of the client device202. Whether the user account is authorized for particular access or only authenticated will depend upon parameters and configuration of the resource security system200, based upon the security requirements and the scope of use of the encrypted access token. When authorizing the user account for a particular level of access (e.g., access to a limited set of resources, such as access to view but not edit billing information), the IDP204may Authentication or authorization may include obtaining user credentials, sending the user credentials in a secure message to the IDP204for validation, and receiving an authorization code from the IDP204in a secure response. The user agent222may further provide the authorization code to the client application224of the client device202for use in obtaining the encrypted access token.

At block404, the client application224obtains an encrypted access token from the IDP204via the network208. To obtain the encrypted access token, the client application224sends a token request message including an indication of authentication of the user account (e.g., the authorization code received from the user agent222) to the IDP206. The token request message may also include an identifier of one or more of the client device202, the client application224, or a user session or application session within the client application224. Thus, the IDP204may generate the encrypted access token such that the encrypted access token is bound to the client device202, the client application224, of the user session or application session. In some embodiments, the encrypted access token has a payload including a user identifier that is encrypted as part of the encrypted access token. Such user identifier may include user confidential data, such as personally identifiable information used as a user identifier (e.g., user phone number or e-mail address). For example, the user identifier may comprise a phone number (e.g., an international mobile subscriber identity (IMSI) or a mobile subscription identification number (MSIN)) of the user account, which may also server as the user account number for a mobile telecommunications subscriber. Such a user identifier is secured through encryption as part of the encrypted access token, thereby protecting user confidential data.

Although any type of encrypted token may be used as the encrypted access token, the IDP204generates the encrypted access token as a JavaScript Object Notation (JSON) Web Encryption (JWE) token in some embodiments. A JWE token comprises five portions: a JWE header, a JWE encrypted key, a JWE initialization vector, a JWE ciphertext (i.e., an encrypted payload corresponding to a plaintext payload containing the user identifier), and a JWE authentication tag. Each of these five portions may be encoded using Base64 or Base64 for URL encoding (or other binary-to-text encoding schemes) to obtain the string of characters that represents the JWE token. Generating a JWE token comprises multiple steps, some of which may be performed in various orders. The process of generating the JWE begins with randomly generating a content encryption key for use in encrypting the plaintext payload. The JWE encrypted key may then be generated by encrypting the content encryption key with a public key and text-encoding the resulting encrypted key (e.g., using Base64URL encoding). Likewise, an initialization vector may be randomly generated and text-encoded to produce the JWE initialization vector. The JWE header may next be generated by generating and text-encoding a header containing parameters regarding the JWE token, such as encryption algorithm identifiers or certificate indicators. The indicated algorithm and parameters may then be used to generate the JWE ciphertext by encrypting the plaintext payload containing the user identifier (and any additional data in the payload) using the content encryption key and the initialization vector previously generated, then text-encoding the resulting encrypted payload. An authentication tag may be generated to ensure the integrity of the token and text-encoded to obtain the JWE authentication tag. The JWE token may then be generated by assembling these five portions into a compact string, which portions may be separated by periods. Once generated by the IDP204, the encrypted access token is sent to and received by the client application224of the client device202via the network208.

At block406, the client application224stores the received encrypted access token in the memory212of the client device202(e.g., as the encrypted access token226) for further use. When the encrypted access token is bound to a session (e.g., a user session or application session), it may be stored for use during the session or until earlier expired. In some embodiments, the encrypted access token is further secured during storage by failing to provide the client device202with a key to decrypt the token. Thus, the payload of the encrypted access token (including any user confidential data) is secured while stored in the memory212of the client device202because the client device202lacks a key to decrypt the payload of the encrypted access token. In further embodiments, the encrypted access token may be refreshed periodically by automatically obtaining a new encrypted access token prior to expiration of the previous encrypted access token. In this manner, the encrypted access token may be further secured without imposing an additional burden on the user of frequently providing the user account credentials.

At block408, in some embodiments, the client application224generates a proof-of-possession (PoP) token for use in requesting secure resources from a resource server206. The PoP token may be generated to include one or more indications of parameters or requests to a resource server206(e.g., as a query, array, string, XML file, or JSON object providing parameters in a format accepted by a target API or service272of a target resource server206). The PoP token may be bound to the client application224, an application session, or a user session, and the PoP token may be signed by a private key associated with the client application274or a user account. The PoP token may be generated by the client application224to include the parameters for the resource request, as well as headers and other items in a format expected by the target API or sever272to which the resource request message will be sent. Thus, the PoP token may be a hash of a message including headers, an identifier of the target API or service272(e.g., a URL corresponding to the address of the API or service), and resource request parameters, which hashed message may then be signed by the client application224(e.g., using a private key) to prevent modification or reuse by an intercepting third party.

At block410, the client application224generates a resource request message to send to the resource server206. The resource request message includes the encrypted access token and an indication of the resource requested or the action requested from the resource server206. The encrypted access token226may be accessed from the memory212of the client device202. Indications of requested resources or actions may be explicit (e.g., specifically identified in the resource request message) or implicit (e.g., at least partially indicated by the API or service272to which the resource request message is addressed). In some embodiments, the PoP token may be used to provide the indication of one or more requested resources or actions, such as through a payload that includes such indication (e.g., a string, query, or other data parameters accepted by the API or service272of the resource server206to specify resources or actions). Thus, the resource request message may include both an encrypted access token to indicate the client application224had permission (through an authenticated or authorized user account) to access the resource and a PoP token to indicate the resource or action requested (or parameters associated with such request).

At block412, the client application224sends the resource request message to an API or server272of the resource server206via the network208. The resource request message may be sent via a secure communication protocol (e.g., using TLS), but encryption of the encrypted access token and PoP token may be used to provide stronger security. Upon receiving the resource request message, the resource server206may verify user account access permissions using the encrypted access token, then parse the resource request to perform a corresponding action (e.g., providing content, processing data, or generating and sending a response). In some embodiments, verifying access may include decrypting the payload of the encrypted access token at the resource server206. In further embodiments, the resource server206may communicate with the IDP204via the network208to authorize the resource request by sending the encrypted access token to the IDP204for validation. In some embodiments, the resource server206may further verify a user account indicated by a user identifier in the encrypted access token is authorized to access the resource requested, which may be determined based upon both the user identifier and an indication of the resource or action requested by the resource request message (either as part of a PoP token or otherwise explicitly or implicitly indicated by the resource request message). Upon determining the resource request is valid (i.e., the client application224is authorized to access the requested resource), the resource server206performs the resource request. In some embodiments, performing the resource request includes sending a resource response to the client application224of the client application via the network208.

At block414, in some embodiments, the client application224receives a resource request response from the resource server206based upon the resource request message. The resource request response may include content from the resource server206or may simply confirm receipt and performance of the resource request indicated in the resource request message. Upon receiving a response, the client application224may present an indication of the response to the user of the client device202.

At block416, the client application224determines whether there is another resource request to send to the same or a different resource server206. The client application224may wait for another resource request until the encrypted access token is no longer valid, such as by reaching an expiration time or termination of a bound session. When a new resource request is identified, the client application proceeds to generate and send a resource request message corresponding to the new resource request, according to blocks408-414above, then determines whether there is a further resource request when returning to block416. When no further resource requests are identified or available (e.g., upon expiration or revocation of the encrypted access token), the secure resource access method400ends.

To the extent that any term recited in the claims at the end of this disclosure is referred to in this disclosure in a manner consistent with a single meaning, that is done for the sake of clarity only so as to not confuse the reader, and it is not intended that such claim term be limited, by implication or otherwise, to that single meaning. Finally, unless a claim element is defined by reciting the word “means” and a function without the recital of any structure, it is not intended that the scope of any claim element be interpreted based upon the application of 35 U.S.C. § 112(f).