Binding web components to protect accessing of resources

Presented herein are systems and methods for binding web components to protect accessing of resources. A first server may receive, from a second server, a request to provide access to content for a first web component on a web application of a customer device. The first server may determine whether to issue an identifier to the customer device responsive to validating the request. The first server may generate, responsive to the determination, the identifier to bind the first web component with a second web component to permit access to the content for the first web component on the web application. The first server may transmit, to the second server, a response including the identifier and the content. The first server may communicate, via the second server, data associated with a user interaction with the content on the first web component bound with the second web component using the identifier.

TECHNICAL FIELD

This application generally relates to data security. In particular, the present application relates to binding web components to protect accessing of resources.

BACKGROUND

In a networked environment, a customer device (or end-user device) may receive a webpage from a web server. The webpage may contain primary content provided by a content publisher server, as well as one or more elements (e.g., document object model (DOM) elements) embedded into the webpage for supplemental content from a content provider server. Upon loading the webpage, the customer device may retrieve the primary content from the content publisher server and fetch supplemental content for the one or more elements from content provider servers. The embedding of the elements on the webpage, however, may expose the other web server to security vulnerabilities. The embedded elements may be unaware that that they are being loaded on a webpage that is managed by a server different from a server for the supplemental content. As a result, without visibility to the server for the primary content from the embedded element, such embedded elements and the contents therein can potentially be accessed by rogue entities and be exploited in improper ways.

SUMMARY

Disclosed herein are systems and methods for binding web components to protect from improper access to resources. In networked environments, an application (e.g., a web browser) running on a customer device may retrieve a webpage (e.g., in the form of a web application) from a content publisher server. The webpage may include a component (sometimes herein referred to as elements or objects, such as an inline frame element) embedded therein whose content are to be fetched from a content provider server. In retrieving the webpage, the browser on the customer device may request the content provider server to provide content to insert into the component of the webpage.

Allowing access to the content provider server for content to include into the webpage from the content publisher server may present security risks to the customer device. There may be various approaches to address some of these security vulnerabilities. For example, a cross-original resource sharing (CORS) protocol may be used by the web browser to send a pre-flight request to the content provider server to check whether the content provider server permits accessing from the webpage of the content publisher server. Such approaches, however, may only allow for limited control by the content provider server in controlling content once provided to the web browser and loaded into the component of the webpage. This problem may be exacerbated if the data provided to the web browser is. As such, these approach may allow potentially malicious actors to gain access to the resources of the content provider server through the webpage of the content publisher server.

To address these and other technical challenges, a web server providing content for embedded components on webpage may use an identifier to bind a web component (e.g., an inline frame) to a parent web component (e.g., a script element) on the webpage (e.g., defined using an HyperText Markup Language (HTML)). To load content into the web component of a webpage, the customer device may send a request to the content publisher server that had served the webpage. The content publisher server (also referred herein as a partner server) may serve as a proxy to facilitate communications between the customer device in accessing resources of the content provider server through a gateway. The gateway may reside along a communication path between the content publisher server and the content provider server.

Upon receipt of the request, the content publisher server may generate a token signed using an encryption key (e.g., a private key). The content publisher server may forward the request to the gateway, along with the generated token. The gateway may contain a configuration list of third-party servers and corresponding public certificates (e.g., including public encryption keys provided by third-party servers) that are allowed to access the web server. Using the configuration, the gateway may control access to the content provider server and enable secure communications between the content publisher server and the content provider server.

Upon receipt of the request, the gateway may validate the token by determining whether the encryption key (e.g., a public key) used to sign the token is configured in the list and the signature verification has succeeded. If the token is determined to be invalid, the gateway may provide an indication of failure to validate to the content publisher server. The indication of failure may be to signal that the token is invalid and that the content is not to be provided to the embedded component on the webpage on the customer device. On the other hand, if the token is valid, the gateway may send an indication of successful validation to the content provider server. When the validation of the token is successful, the content provider server may generate a binding identifier and return a response including the binding identifier to the content publisher server. The binding identifier may be used to bind the embedded web component with its parent web component to route interactions and data on the child web component to the content provider server.

With receipt of the response, the content publisher server may generate a new token (sometimes herein referred to as a partner token) including the binding identifier and an identifier for the customer device, among other parameters, encrypted using the encryption key. The other parameters may include, for example, an expiration time, issue time, and an identifier for the content publisher server. The content publisher server may also generate code challenge information. The code challenge information may include a unique random number corresponding to a code challenge verifier and a hash of the unique random number corresponding to a code challenge hash in accordance with a hash function corresponding code challenge method. The content publisher server may send the encrypted token along with the code challenge hash and method to the customer device.

When the token and the code challenge information are received, the customer device may use the parent web component to generate a context for the child web component of the webpage. The bound context may include the token, the code challenge information, a reference identifier for the parent web component (e.g., using postMessage( ) function), and an identifier for the customer device, among other parameters (sometimes herein referred to as claims). Upon the generation of the context, the customer device may send the bound context to the content provider server when launching the request to load the embedded web component. With receipt from the customer device, the content provider server may issue an access token including the parameters of the context. The content provider server may encrypt the access token using the encryption key, and send the access token along with the content and resources for the embedded web component to the customer device. Once loaded, communications through the embedded web component with the content provider server may be protected using the access token, which has the bound context as defined by the parameters.

Subsequently, the embedded web component on the webpage may be dismissed on the customer device. The dismissal of the embedded web component may trigger the context release procedure. Once interactions are completed between the embedded web component from the customer device with the content provider server, the customer device may dismiss the embedded web component by invoking the parent web component. From invoking, the customer device may generate an authorization code token from the parameters of the access token provided by the content provider server. The authorization code token may include the parameters of the access token along with the binding identifier. The customer device may send the authorization code token along with the stored partner token and code challenge information to the content provider server. Upon receipt, the content provider server may validate the authorization code token by determining whether the bounding identifier of the authorization code token matches the bounding identifier stored for the customer device. The content provider server may also validate the code challenge information to ascertain that the embedded web component was indeed dismissed from the bounded context. With the validation, the content provider server may send an acknowledgement along with additional content to the customer device.

In this manner, by providing a binding identifier to bind the embedded web component with the parent web component, the content accessed through the embedded web component may be controlled by the hosting content provider server thereby improving security. Once the context is bound to the parent web component on the webpage, this framework may allow for the customer device to securely and seamlessly access the sensitive data from the content provider server. Furthermore, the passage of the authorization code token from the dismissal of the embedded web component on the customer device to the content provider server may prevent further leakage of sensitive data onto the webpage once the interactions are complete on the web component. The scheme may thus improve data security and privacy while permitting accessing of the content from the content provider server different from the webpage provided by the content publisher server.

Aspects of present disclosure are directed to systems, methods, and non-transitory computer readable media for binding web components to protect resources accessed via web components. A first server may receive, from a second server, a request to provide access to content for a first web component on a web application of a customer device. The first server may determine whether to issue an identifier corresponding to the first web component to the customer device responsive to a validation of the request. The first server may generate, responsive to the determination, the identifier to bind the first web component with a second web component to permit access to the content for the first web component on the web application of the customer device. The second web component may be configured to receive content of the first web component. The first server may transmit, to the second server, a response including the identifier and the content. The first server may communicate, via the second server, data associated with a user interaction with the content presented on the first web component bound with the second web component using the identifier.

In one embodiment, the first server may receive, from the customer device via the second server, a context to bind the first web component with the second web component, the context including a first token generated by the second web component using the identifier. The first server may generate, responsive to validating the context, a second token using at least a portion of the context. The first server may transmit, to the second server, the second token to encrypt the communications of the data from the first web component.

In another embodiment, the first server may receive the context including (i) the first token and (ii) an information to permit communications between the first web component and the second web component. The first server may generate the second token to include at least a portion of the first token and the information.

In yet another embodiment, the first server may receive, from the customer device via the second server, an indication to unbind the first web component from the second web component responsive to a termination of the first web component. The indication may identify an authorization code token generated using the identifier. The first server may determine, responsive to validating the authorization code token of the indication, to unbind the first web component from the second web component.

In yet another embodiment, the first server may identify, from the authorization code token of the indication, the identifier. The first server may validate the authorization code token responsive to the identifier identified from the authorization code token matching the identifier transmitted in the response. In yet another embodiment, the first server may determine, responsive to failure to validate a second request, that the customer device is not to be issued with a second identifier corresponding to a third web component of a second customer device. The first server may transmit, to a third server, an indication to deny the third web component access to content of the first server, responsive to determining that the customer device is not to be issued with the second identifier.

In yet another embodiment, the first server may validate the request responsive to a gateway identifying the second server from which the request is received as permitted to access the first server. In yet another embodiment, the first server may receive the request access to content for an inline frame launched by the application the customer device responsive to accessing a webpage. In yet another embodiment, the first server may transmit the response to cause the second server to generate a token using the identifier to encrypt the communications of the data associated with the user interactions with the first web component. In yet another embodiment, the first server may generate the identifier referencing a binding of the first web component with the second web component.

DETAILED DESCRIPTION

Reference will now be made to the embodiments illustrated in the drawings, and specific language will be used here to describe the same. It will nevertheless be understood that no limitation of the scope of the disclosure is thereby intended. Alterations and further modifications of the features illustrated here, and additional applications of the principles as illustrated here, which would occur to a person skilled in the relevant art and having possession of this disclosure, are to be considered within the scope of the disclosure.

The present disclosure is directed to systems and methods for binding web components to protect accessing of resources in computer networked environments. A customer device may receive a webpage from a content publisher server, with a web component embedded on the webpage. To load content for the web component, the customer device may send a request to a content provider server via a gateway to provide the content. The request may be generated by a parent web component to the embedded web component. Upon receipt and validation of the request, the content provider server may generate and transmit a binding identifier for the web component to a parent web component on the webpage. The content publisher server may generate a token using the binding identifier along with other parameters, and send the token to the customer device. Using the token from the content publisher server, the customer device may in turn generate a context to bind the web component to the web component, and send the context to the content provider server. With receipt, the content provider server may generate an access token based on the context, and return the access token to the customer device. Using the access token, data from the embedded web component may be protected from outside entities, and may be communicated with the content publisher server. Although the example embodiments describe a web component provided by the content publisher server for the content provider server, it is intended that the systems and methods may be implemented in other environments involving a web server providing a web component to a partner server.

FIG.1depicts a block diagram of an environment100for binding web components to protect accessing of resources. The environment100may include at least one customer device105(sometimes herein referred to as a customer or a client device), at least one partner server110(sometimes herein referred to as a content publisher server or an access server), at least one application programming interface (API) gateway115(sometimes herein referred to as a gateway), and at least one web server120(sometimes herein referred to as a content provider server, resource server, or a web service), among others. The API gateway115and the web server120may be operated by or otherwise associated with a resource provider or an application host. The partner server110may be operated by or otherwise associated with a partner entity that is authorized to access or otherwise interface with the API gateway115and the web server120. The customer device105may be operated by or otherwise associated with an end-user attempting to access the resource provider or the application host via the partner server110. For example, the application host may be a service (e.g., account information retrieval, transaction, or loan application) provided by a banking institution. The end-user may be a customer attempting to access services provided by the banking institution via the host.

Embodiments may comprise additional or alternative components or omit certain components from those ofFIG.1and still fall within the scope of this disclosure. For example, the API gateway115and the web server120may be part of the same device. Various hardware and software components of one or more public or private networks may interconnect the various components of the environment100. Non-limiting examples of such networks may include Local Area Network (LAN), Wireless Local Area Network (WLAN), Metropolitan Area Network (MAN), Wide Area Network (WAN), and the Internet. The communication over the network may be performed in accordance with various communication protocols, such as Transmission Control Protocol and Internet Protocol (TCP/IP), User Datagram Protocol (UDP), and IEEE communication protocols, among others.

While loading a webpage, the customer device105detects an action to launch an inline frame on the webpage (125). The webpage may include one or more elements (sometimes herein referred to as web components) embedded therein, such as the inline frame to be loaded. The action may correspond to an invocation by the customer device105running a script (e.g., a JavaScript script element) corresponding an element that is a parent to the inline frame element on the webpage. Upon detecting the action, the customer device105may send a request to load the inline frame to the partner server110.

The partner server110forwards the request to launch the inline frame with a token (130). Upon receiving from the customer device105, the partner server110may generate the token to include in the request. In generating, the partner server110may encrypt or sign the token using an encryption key. The token may be, for example, packaged in accordance with a JavaScript Object Notation (JSON) web token (JWT) and may be encrypted using a public key received out-of-band by the partner server110from the API gateway115. With the generation, the partner server110may send the token along with the request to the API gateway115.

Upon receipt of the request, the API gateway115validate that the token by determining whether the token has been signed by the partner server110using the encryption key provided by the partner server110. The API gateway115may maintain a configuration of whitelisted servers, such as the partner server110, and use a public key certificate to validate encryption keys used to sign the tokens. When the validation of the token fails, the API gateway115may send a failure indication to the web server120(135). The web server120may in turn transmit an indication denial to the partner server110to specify that accessing of content for the inline frame is denied (140).

On the other hand, when the validation of the token succeeds, the API gateway115may send an indication of success and invoke the web server120to provide content for the inline frame (145). Upon receipt of the indication, the web server120may send the content for the inline frame along with a binding identifier to bind the inline frame with the parent script element to the partner server110(150). The partner server110in turn may generate a new token based on the binding identifier, along with other parameters, and pass the new token to the customer device105. Using the token, the customer device105may generate a context to bind the inline frame element with the parent script element, and may return the context to the web server120. With the passage of context, communications originating from user interactions with the inline frame element on the customer device105may be protected and exchanged with the web server120.

FIG.2depicts a block diagram of a system200for binding web components to protect accessing of resources. The system200may include at least one customer device202(sometimes referred to herein as a client device or customer), at least one access server204(sometimes referred to herein as a partner server or as a content publisher server), at least one gateway server206(sometimes referred to herein as a gateway), at least one resource server208(sometimes referred to herein as a resource service or content provider server), and one or more networks210, among others. The gateway server206may include at least one key maintainer212and at least one token validator214. The resource server208may include at least one request handler216, at least one identity generator218, at least one resource provider220, at least one binding handler222, and at least one database224. Embodiments may comprise additional or alternative components or omit certain components from those ofFIG.2, and still fall within the scope of this disclosure. For example, the gateway server206and the resource server208may be part of the same device.

Various hardware and software components of one or more public or private networks210may interconnect the various components of the system200. Non-limiting examples of such networks may include Local Area Network (LAN), Wireless Local Area Network (WLAN), Metropolitan Area Network (MAN), Wide Area Network (WAN), and the Internet. The communication over the network may be performed in accordance with various communication protocols, such as Transmission Control Protocol and Internet Protocol (TCP/IP), User Datagram Protocol (UDP), and IEEE communication protocols, among others.

The customer device202may be any computing device comprising one or more processors coupled with memory and software, and capable of performing the various processes and tasks described herein. The customer device202may be in communication with the access server204, the gateway server206, and the resource server208via the network210. Communications from the customer device202may be redirected via the network210from one component to another. For example, a request to access the resource server208may be first redirected to the access server204, then the gate server206, and then to the resource server208.

The access server204may be any computing device comprising one or more processors coupled with memory and software and capable of performing the various processes and tasks described herein. The access server204may be in communication with the customer device202, the gateway server206, and the resource server208via the network210. Although shown as a single access server204, the access server204may include any number of computing devices. The access server204may perform an initial authentication of the customer device202in accessing the gateway server206. From the initial authentication, the access server204may generate and issue an initial token for the customer device202.

The gateway server206may be any computing device comprising one or more processors coupled with memory and software and capable of performing the various processes and tasks described herein. The gateway server206may be in communication with the customer device202, the access server204, and the resource server208via the network230. Although shown as a single gateway server206, the gateway server206may include any number of computing devices. The gateway server206may control communications from the access server204and by extension the customer device202to the resource server208. Within the gateway server206, the key maintainer212may be or may include computer-readable machine code executable by the gateway server206may store and maintain encryption keys to be used to encrypt or sign tokens in requests. The token validator214may be or may include computer-readable machine code executable by the gateway server206to validate requests received via the network210

The resource server208may be any computing device comprising one or more processors coupled with memory and software, and capable of performing the various processes and tasks described herein. The resource server208may be in communication with the customer device202, the access server204, and the gateway server206via the network210, as well as the token database224. Although shown as a single resource server208, the resource server208may include any number of computing devices. The gateway server206may host, maintain, or otherwise include a resource. The resource may include an application, programs, processes, files, or data, among others. Access to the resource maintained by the gateway server206may be controlled by the access server204and the resource server208.

Within the resource server208, the request handler216may be or may include computer-readable machine code executable by the resource server208to parse and process requests validated by the gateway server206. The identity generator218may be or may include computer-readable machine code executable by the resource server208to create binding identifiers to be used to bind web components (sometimes herein referred to as elements or objects). The resource provider220may be or may include computer-readable machine code executable by the resource server208to provide content or resources requested by the customer device202when the access is granted to the customer device202. The binding handler222may be or may include computer-readable machine code executable by the resource server208to manage binding of the web components on the customer device202.

FIG.3depicts a block diagram of a system300for validating access requests to access resources. The system300may include at least one customer device302(sometimes referred to herein as a client device or customer), at least one access server304(sometimes referred to herein as a partner server as a content publisher server), at least one gateway server306(sometimes referred to herein as a gateway), and at least one resource server308(sometimes referred to herein as a resource service or content provider server), among others. The gateway server306may include at least one key maintainer312and at least one token validator314, among others. The resource server308may include at least one request handler316, among others.

Embodiments may comprise additional or alternative components or omit certain components from those ofFIG.3and still fall within the scope of this disclosure. Various hardware and software components of one or more public or private networks may interconnect the various components of the system300. Each component in system300(such as the customer device302, the access server304, the gateway server306and its sub-components, and the resource server308and its subcomponents) may be any computing device comprising one or more processors coupled with memory and software and capable of performing the various processes and tasks described herein.

The customer device302may have received at least one web application330from the access server304. The web application330may include at least one parent web component332(sometimes herein referred to as a parent element or parent object) and at least one embedded web component334(sometimes herein referred to as a child component, element, or object). In some embodiments, the parent web component332may correspond to the web application330itself. The web application330may be a webpage defined in accordance with a markup such as HyperText Markup Language (HTML), Extensible Markup Language (XML), JavaScript, or PHP, among others, or any combination thereof.

In the web application330, the parent web component332may correspond to a script element (e.g., an HTML script object) and the embedded web component334may correspond to an inline frame element (e.g., an HTML inline frame object). At least one of the parent web component332or the embedded web component334may correspond to a graphical user interface element on the webpage defining the web application330. In a hierarchy of the HTML document object model (DOM) tree defining the web application330, the parent web component332and the embedded web component334may have a parent-child relationship. While described herein primarily in terms of a HTML webpage, other scripts and settings may be used to implement the web application330and the associated functionalities with the web components332and334detailed herein.

The parent web component332may contain or include instructions to control, specify, or otherwise define the functionalities of embedded web component334. The instructions may have been configured in the web application330, and may be provided by the access server304. The instructions for the parent web component332of the web application330may be provided by the access server304. In some embodiments, the access server304may have received the instructions for the parent web component332from the gateway server306, the resource server308, or another associated entity. The content for the embedded web component334may be not provided by the access server304, and may initially not be loaded on the web application330. Instead, the content of the embedded web component334is to be retrieved by the customer device302from the resource server308. The retrieval of the content from the resource server308may be defined in part by the instructions included in the parent web component332. The parent web component332may retrieve, load, or otherwise receive the content for the embedded web component334.

When loading the web application330, the customer device302calls, runs, or otherwise invokes the instructions in parent web component332. In some embodiments, the customer device302may invoke the instruction in the parent web component332in response to detecting an interaction with the embedded web component334. From invoking, the customer device302may create, output, or otherwise generate at least one access request336to provide the customer device302access to content for the embedded web component334on the web application330. The access request336may be, for example, a HyperText Transfer Protocol (HTTP) request method, such as a GET or POST method, among others. The access request336may include an identifier corresponding to the customer device302, an instance of the web application330on the customer device302, or a user of the customer device302, among others. The access request336may identify the access server304as a destination of the access request336. In some embodiments, the access request336may identify the gateway server306or the resource server308as the destination. With the generation, the customer device302provides, sends, or otherwise transmits the access request336to the access server304.

Separately, the key generator312executing on the gateway server306may maintain and store at least one encryption key338for the access server304. The encryption key338may be used to encrypt and decrypt communications between the access server304and the gateway service306. The encryption key338may also be used to validate tokens provided by the access server304for accessing the resource server308through the gateway server306. The encryption key338may be generated in accordance with any asymmetric encryption algorithm. For example, the access server304may generate a public key and a private key in an accordance with an asymmetric cryptography (e.g., Rivest-Shamir-Adleman (RSA) algorithm). Upon generation, the access server304provides, sends, or otherwise transmits the public key as the encryption key338to the key maintainer312. The access server304may store and maintain the private key associated with the encryption key338. The key maintainer312in turn stores and maintains the public key as the encryption key338on the gateway server306. For example, the key generator312may store the public key and an identifier referencing the access server304on a list of trusted access servers.

In turn, the access server304retrieves, identifies, or otherwise receives the access request336from the customer device302. In some embodiments, the access server304may intercept the access request336from the customer device302and in route to the gateway server306or the resource server308. Upon receipt, the access server304may write, produce, or otherwise generate at least one request token340to insert or include into the access request336. The request token340may serve to authenticate the access server304with the gateway server306for communications between the customer device302and the resource server308through the access server304and the gateway server306. The request token340may be packaged or generated in accordance with a format, such as a JavaScript Object Notation (JSON) object (e.g., a JSON web token (JWT)).

To generate the request token340, the access server304may use at least a portion of the access request336or other parameters, such an identifier corresponding to the access server304or a communication session between the customer device302and the access server304. The request token340may identify or include a set of claims, such as: an expiration time specifying or defining a duration of time in which the request token340is valid; an issue time defining or identifying a time at which the request token340is created; the issuer identifier corresponding to the access server304; or the token identifier uniquely referencing the request token340; and an identifier corresponding to the customer device302, among others.

In some embodiments, the access server304may produce, create, or otherwise generate code challenge information to secure communications between the customer device302and the resource server308originating from the embedded web component334. The code challenge information may be used to specify or define a communication sequence to authenticate and secure communications between the customer device302and the resource server308via the access server304and the gateway server across the network. The code challenge information may identify or include a code challenge verifier, a code challenge hash, and a code challenge method. The code challenge verifier may be or include a value (e.g., a pseudo-random generated number or alphanumeric characters). The code challenge hash may be or include a hash of the value of the code challenge verifier, in accordance with a hash value specified by the code challenge method. The hash function used as the code challenge method may include, for example, a cryptographic hash function, such as a secure hash algorithm (SHA) such as SHA-1, SHA-2, and the like, a digital signature algorithm (DSA), or a message-digest algorithm (e.g., MD5), among others. The code challenge method may be specified or identified in the code challenge information. With the generation, the access server304may sign or encrypt the request token340(or the overall access request336) using the private key associated with the previously provided encryption key338. Upon signing, the access server304provides, sends, or transmits the access request336including the request token340to the gateway server306.

The token validator314executing on the gateway server306retrieves, identifies, or otherwise receives the access request336from the access server304. With receipt, the token validator314parses the access request336to extract or identify the contents therein, such as the request token340. The token validator314may decrypt the request token340using an encryption key associated with the encryption key338. For example, the encryption key338may be a public key, and the token validator314may decrypt the contents of the request token340(or the overall access request336) using a private key that was previously generated in conjunction with the public key. The token validator314may decrypt the request token340to extract the contents therein, such as the identifier corresponding to the access server304. The token validator314may identify the access server304corresponding to the identifier.

Upon decryption, the token validator314may identify or determine whether the access server304is one of a trusted list of access servers. Based on the determination, the token validator314may produce, output, or otherwise generate a validation result342to indicate the determination to the resource server308. The list may define or identify access server304whose access requests are to be trusted for further processing at the gateway server306. When the access server304is determined to be not any of the trusted set, the token validator314may identify or determine that the access server304is restricted from accessing the resource server308. The token validator314may also generate the validation result342to indicate that a failure to validate the access request336(or the request token340) from the access server304.

Otherwise, when the access server304is determined to be in the trusted set, the token validator314may identify or determine that the access server304is permitted to access the resource server308. The token validator314may also generate the validation result342to indicate successful validation of the access request336(or the request token340) from the access server304. In either case, with the generation, the token validator314provides, transmits, or otherwise sends the validation result342to the resource server308. In conjunction, the token validator314may provide, forward, or otherwise send the access request336from the access server304to the resource server308.

The request handler316executing on the resource server308may retrieve, identify, or otherwise receive the validation result342. The request handler316may also receive the access request336along with the validation result342from the access server304. Upon receipt, the request handler316may parse the access request336to extract or identify the contents therein. From parsing, the request handler316may extract or identify the identifier corresponding to the customer device302, the web application330, or the user. The request handler316may also identify the identifier corresponding to the access server304. The request handler316may also parse the validation result342to determine whether the validation of the access request336succeeded or failed. Based on the validation result342, the request handler316may determine whether the customer device302is to be issued a binding identifier corresponding to the embedded component334.

When the validation result342identifies the validation of the access request336as a failure, the request handler316may determine that the customer device302is not to be issued the binding identifier. Furthermore, the request handler316may provide, send, or otherwise transmit a response including an indication to deny the embedded web component334access content on the resource server308for the embedded web component334. The indication may be transmitted to the customer device302directly or indirectly via the gateway server306and the access server304. The process of requesting access to content for the embedded web component334may be attempted again, or terminated upon receipt of the denial indication. Otherwise, when the validation result342identifies the validation of the access request336as a success, the request handler316may determine that the customer device302is to be issued the binding identifier. Details of the functionality associated with the binding identifier is described below in conjunction withFIGS.4-6.

FIG.4depicts a block diagram of a system400for generating binding identifiers for web components in accessing resources. The system400may include at least one customer device402(sometimes referred to herein as a client device or customer), at least one access server404(sometimes referred to herein as a partner server or as a content publisher server), and at least one resource server408(sometimes referred to herein as a resource service or content provider server), among others. The customer device402may have received or receive at least one web application430from the access server404. The web application430may include at least one parent web component432(sometimes herein referred to as a parent element or parent object) and at least one embedded web component434(sometimes herein referred to as a child component, element, or object). The resource server408may include at least one identity generator418and at least one resource provider420, among others.

Embodiments may comprise additional or alternative components or omit certain components from those ofFIG.4and still fall within the scope of this disclosure. Various hardware and software components of one or more public or private networks may interconnect the various components of the system400. Each component in system400(such as the customer device402, the access server404, and the resource server408and its subcomponents) may be any computing device comprising one or more processors coupled with memory and software and capable of performing the various processes and tasks described herein.

The identity generator418executing on the resource server408produces, creates, or otherwise generates at least one binding identifier444. The binding identifier444may be to bind the embedded web component434with the parent web component432to permit access to the content for the embedded web component434on the web application430. The identity generator418may generate the binding identifier444, when the customer device402is to be issued the binding identifier444in response to validating an access request. The binding identity444may be a set of alphanumeric characters to uniquely reference the instance of the embedded web component434of the web application430on the customer device402. In some embodiments, the identity generator418may generate the binding identifier444using at least a portion of the access request, such as the identifier associated with the customer device402or the access server404, among others. With the generation, the identity generator418may store and maintain the binding identifier444on the database424. The identity generator418may store and maintain an association of the binding identifier444with the identifier of the customer device402or the access server404, or any other from the access request, among others.

The resource provider420executing on the resource server408retrieves, obtains, or otherwise identifies content446(sometimes herein referred to as initial content) to provide to the embedded web component434. The content446may identify or include data, such as additional instructions, an image, text, or multimedia, among others, to be inserted into the embedded web component434on the web application430. In some embodiments, the additional instructions of the content446may be executed by the parent web component432or in accordance with the instructions of the parent web component432. For example, the content446may include instructions and graphical user interface (GUI) elements for various services, such as account information retrieval, transaction, or loan application in an online bank application. Using the access request from the customer device402, the resource provider420may fetch or retrieve the content446from the database424(or another data source) for the embedded component434. For example, the resource provider420may identify which content446to provide based on a content identifier (e.g., a uniform resource locator (URL)) included by the script in the parent web component432in the access request. With the generation of the binding identifier444and retrieval of the content446, the resource provider420provides, sends, or otherwise transmits at least one response448to the access server404. The response448may identify or include the binding identifier444and the content446. In some embodiments, the response448may be provided by the resource provider420to the customer device402via the access server404.

The access server404in turn retrieves, identifies, or receives the response448from the resource server408. Upon receipt, the access server404may parse the response448to extract or identify the binding identifier444and the content446. With the identification, the access server404may generate at least one partner token450using at least a portion of the response448, such as the binding identifier444. The partner token450may also be used to encrypt or decrypt communications of data associated with the embedded web component434(e.g., user interactions) from the customer device402. The partner token450may be used to facilitate accessing of additional content for the embedded web component434on the customer device402from the resource server408. The access server404may generate the partner token450in accordance with a format, such as a JavaScript Object Notation (JSON) object (e.g., a JSON web token (JWT)), among others.

The partner token450may identify or include a set of claims (sometimes herein referred to as parameters or information), such as: the binding identifier444from the response448; an expiration time specifying or defining a duration of time in which the partner token450is valid; an issue time defining or identifying a time (e.g., a time stamp) at which the partner token450is created; an issuer identifier corresponding to the access server404; a token identifier uniquely referencing the partner token450(e.g., to protect from replay); and an identifier corresponding to the customer device402, among others. With the generation, the access server404may sign or encrypt the partner token450using the encryption key (e.g., a private key previously generated by the access server404).

In conjunction, the access server404may produce, create, or otherwise generate code challenge information to secure communications between the customer device402and the resource server408originating from the embedded web component434. The code challenge information may be used to specify or define a communication sequence to authenticate and secure communications between the customer device402and the resource server408via the access server404and the gateway server across the network. The code challenge information may identify or include a code challenge verifier, a code challenge hash, and a code challenge method. The code challenge verifier may be or include a value (e.g., a pseudo-random generated number or alphanumeric characters). The code challenge hash may be or include a hash of the value of the code challenge verifier, in accordance with a hash value specified by the code challenge method. The hash function used as the code challenge method may include, for example, a cryptographic hash function, such as a secure hash algorithm (SHA) such as SHA-1, SHA-2, and the like, a digital signature algorithm (DSA), or a message-digest algorithm (e.g., MD5), among others. The code challenge method may be specified or identifier in the code challenge information.

Upon generation, the access server404may store and maintain the partner token450and the code challenge information on the access server404(e.g., on a storage or a database accessible to the access server404). In some embodiments, the access server404may store an association of the partner token450and the code challenge information with the identifier associated with the customer device402. In conjunction, the access server404provides, sends, or otherwise transmits the content446to the customer device402. The access server404may transmit the partner token450and the code challenge information, along with the content446, to the customer device402.

The customer device402in turn retrieves, identifies, or otherwise receives the content446from the access server404. The customer device402may receive the partner token450and the code challenge information, along with the content446, from the access server404. Upon receipt, the customer device402may load, insert, or include the content446onto the embedded web component434. The loading of the content446may be in accordance with the instructions in the parent web component432. For example, the parent web component432while run by the customer device402, may receive the content446from the access server404, and may render graphics provided in the content446within the embedded web component434. The customer device402may continue to process the partner token450and the code challenge information as detailed herein below.

FIG.5depicts a block diagram of a system500for generating access tokens for providing access to resources via web components. The system500may include at least one customer device502(sometimes referred to herein as a client device or customer), at least one access server504(sometimes referred to herein as a partner server or as a content publisher server), and at least one resource server508(sometimes referred to herein as a resource service or content provider server), among others. The customer device502may have received or receive at least one web application530and at least one partner token550from the access server504. The web application530may include at least one parent web component532(sometimes herein referred to as a parent element or parent object) and at least one embedded web component534(sometimes herein referred to as a child component, element, or object). The resource server508may include at least one resource handler520and the binding handler522.

Embodiments may comprise additional or alternative components or omit certain components from those ofFIG.5and still fall within the scope of this disclosure. Various hardware and software components of one or more public or private networks may interconnect the various components of the system500. Each component in system500(such as the customer device502, the access server504, and the resource server508and its subcomponents) may be any computing device comprising one or more processors coupled with memory and software and capable of performing the various processes and tasks described herein.

The customer device502creates, produces, or otherwise generates at least one bound context552(sometimes herein referred to a component bound context, binding context, or generally as context). The customer device502may generate the bound context552using at least a portion of the partner token550, such as the binding identifier544from the resource server508. In some embodiments, the customer device502may use the code challenge information received from the access server504to generate the bound context552. The generation of the bound context552may be in accordance with the instructions in the parent web component532of the web application530. The bound context552may be to integrate or bind at least a portion of the functionalities embedded web component534to the parent web component532in the web application530. For instance, the bound context552may permit the parent web component532to receive data, events, or user interactions detected and passed from the embedded web component534.

The bound context552may identify or include at least a portion of the partner token550, such as: the binding identifier544; the expiration time specifying or defining a duration of time in which the partner token550is valid; an issue time defining or identifying a time at which the partner token550is created; the issuer identifier corresponding to the access server504; or the token identifier uniquely referencing the partner token550; and an identifier corresponding to the customer device502, among others. The bound context552may identify or include at least a portion of the code challenge information, such as: the code challenge verifier (e.g., random number or value), the code challenge hash (e.g., hash resultant of the verifier), and the code challenge method (e.g., the hash function used to calculate the hash), among others.

Continuing on, the bound context552may identify or include at least one registration information. The registration information may permit communications (e.g., passage of data) between the parent web component532and the embedded web component534. The registration information may identify or define communications between the parent web component532and the embedded web component534. With the registration information, the bound context552may enable data originating from the embedded web component534to be communicated with the parent web component532in route to the resource server508. For example, the register information may include data associated with an invocation of the HTML postMessage( ) function from the embedded web component534(e.g., inline frame element) to the parent web component532(e.g., script element). The bound context552may identify or include the identifier corresponding to the customer device502, the instance of the web application530, or the user (e.g., an account or user profile) of the web application530or the customer device502, among others.

With the generation, the customer device502may output, produce, or otherwise at least one binding request554(sometimes herein referred to as a query or request). The binding request554may identify or include the bound context552. The customer device502provides, sends, or otherwise transmits the binding request554including the bound context552to the resource server508via the access server504and the gateway server. When the binding request554is received at the access server504, the access server504may forward, send, or otherwise transmit the binding request554to the resource server508via the gateway server. The binding request554may be encrypted and decrypted using the encryption key previously received from the access server504to secure communications between the access server504and the gateway server to access the resource server508. In some embodiments, the gateway server between the access server504and the resource server508may perform validation on the binding request554as with the initial access request described above.

The binding handler522executing on the resource server508retrieves, identifies, or otherwise receives the binding request554from the customer device502via the access server504. Upon receipt, the binding handler522may process or parse the binding request554to extract or identify the context552therefrom. The binding handler522may validate the binding request554based on the contents of the context552. From the context552of the binding request554, the binding handler522may extract or identify the binding identifier544, among other parameters. The binding handler522may access the database524to find, retrieve, or identify the binding identifier544for the customer device502(e.g., using the identifier corresponding to the customer device502from the binding request554). The binding handler522may compare the binding identifier544identified from the binding request554with the binding identifier544from the database524for the customer device502.

If the binding identifiers do not match or correspond, the binding handler522may identify or determine that the context552is invalid. The binding handler522may limit or restrict accessing of resources for the embedded web component534. When the validation of the context552fails, the binding handler522may return, send, or otherwise transmit an indication of the failure to validate the context552of the binding request554to the customer device502. The indication may be transmitted through the gateway server and the access server504. The binding handler522may terminate the process of providing access to resources for the embedded web component534on the customer device502.

On other hand, if the binding identifiers match or correspond, the binding handler522may identify or determine that the context552is valid. When the validation of the context552is successful, the binding handler522outputs, creates, or otherwise generates at least one access token556(sometimes referred to herein as a customer access token, bearer token, or a token) using at least a portion of the context552. The access token556may be to finalize the binding of the embedded web component534with the parent web component532on the web application530. The access token556may also be used to encrypt or decrypt communications of data associated with the embedded web component534(e.g., user interactions) from the customer device502. The access token556may define the constraints and may generate the partner token550in accordance with a format, such as a JavaScript Object Notation (JSON) object (e.g., a JSON web token (JWT)), among others, for the communications of the data associated the embedded web component534, such as a time limit in which access to the resources for the embedded web component534hosted on the resource server508is permitted, among others. The binding handler522may generate the access token556in accordance with a format, such as a JavaScript Object Notation (JSON) object (e.g., a JSON web token (JWT)), among others.

The access token556may identify or include a set of claims (sometimes herein referred to as parameters or information). At least a portion of the claims for the access token556may identify or include at least a portion of the context552or at least a portion of the partner token550, among others. The set of claims for the access token556may identify or include any one of: the binding identifier544; the registration information of the bound context552(HTML postMessage( ) function); the expiration time specifying or defining a duration of time in which the access token556is valid; an issue time defining or identifying a time (e.g., a time stamp) at which the access token556is created; the issuer identifier corresponding to the resource server508; the token identifier uniquely referencing the access token556(e.g., to protect from replay); and the identifier corresponding to the customer device502, the instance of the web application530, or the user (e.g., the account or profile), among others. In some embodiments, the set of claims for the access token556may identify or include the partner token550itself, the bound context552, and the code challenge information, among others. The code challenge information may identify or include the code challenge verifier, the code challenge hash, and the code challenge method, among others, as discussed above. With the generation, the binding handler522may store and maintain the access token556on the database524. In some embodiments, the binding handler522may store and maintain an association between the access token556with the identifier corresponding to the customer device502on the database524.

In conjunction, the resource provider520executing on the resource server508retrieves, obtains, or otherwise identifies content558(sometimes herein referred to as additional content) to provide to the embedded web component534. The content558may identify or include data, such as additional instructions, an image, text, or multimedia, among others, to be inserted into the embedded web component534on the web application530. For example, the content558may include instructions and graphical user interface (GUI) elements for various services, such as account information retrieval, transaction, or loan application in an online bank application. In some embodiments, the additional instructions of the content558may be executed by the parent web component532or in accordance with the instructions of the parent web component532. The resource provider520may fetch or retrieve the content558from the database524(or another data source) for the embedded component534. For example, the resource provider520may identify which content558to provide based on a content identifier (e.g., a uniform resource locator (URL)) included by the script in the parent web component532in the initial access request.

With the generation of the access token556and retrieval of the content558, the resource provider520provides, sends, or otherwise transmits at least one response560to the access server504. The response560may identify or include the access token556and the content558, among others. The response560may identify or include a destination identifier corresponding to the customer device502(or the access server504) to which the response560is to be sent. In some embodiments, the response560may be provided by the resource provider520to the customer device502via the access server504and the gateway server. The communication through the access server504and the gateway server may be encrypted or decrypted using the token or encryption key. The access server504in turn retrieves, identifies, or receives the response560from the resource server508. Upon receipt, the access server504forwards, passes, or otherwise transmit the response560to the customer device502.

The customer device502retrieves, identifies, or receives the response560including the access token560and the content558from the resource server508. The response560may be received via the access server504or the gateway server, or both. Upon receipt, the customer device502may store and maintain the access token556and the content558(e.g., on a local storage). The customer device502may use the access token556to bind the embedded web component534with the parent web component532. In conjunction, the customer device502may also load or present the content558on the embedded component534within the web application530. The processing of the access token556and the presentation of the content558may be controlled or defined by the instruction in the parent embedded component534.

By binding the two web components, data associated with user interactions with the content558presented on the embedded web component534may be sent, conveyed, or otherwise passed to the parent web component532. The data may include invocations of a user interaction handler, requests from the customer device502in response to the user interaction, responses from the resource server508in response to corresponding requests, among others. For example, data associated with a screen touch detected via a screen touch event listener of the embedded web component534may be passed to a handler of the parent web component532. In addition, the customer device502may communicate the data associated with the user interactions from the embedded web component534through the parent web component532to the resource server508. Using the access token556, the customer device502and the resource server508may communicate with each other data associated with the embedded web component534. The communication through the embedded web component534may be performed in a secure and encrypted manner, thereby protecting any secure information entered through the embedded web component534.

FIG.6depicts a block diagram of a system600for releasing embedded web components for accessing resources. The system600may include at least one customer device602(sometimes referred to herein as a client device or customer), at least one access server604(sometimes referred to herein as a partner server as a content publisher server), and at least one resource server608(sometimes referred to herein as a resource service or content provider server), among others. The customer device602may have received or receive at least one web application630from the access server604. The web application630may include at least one parent web component632(sometimes herein referred to as a parent element or parent object) and at least one embedded web component634(sometimes herein referred to as a child component, element, or object). The embedded web component634may be loaded with the binding identifier644and the access token656. The resource server608may include at least one binding handler622.

Embodiments may comprise additional or alternative components or omit certain components from those ofFIG.6and still fall within the scope of this disclosure. Various hardware and software components of one or more public or private networks may interconnect the various components of the system600. Each component in system600(such as the customer device602, the access server604, and the resource server608and its subcomponents) may be any computing device comprising one or more processors coupled with memory and software and capable of performing the various processes and tasks described herein.

The customer device602may check or monitor for user interactions or communications corresponding to a completion of the embedded web component634. The monitoring for the user interactions or communications may be in accordance with the instructions in the embedded web component634(or the parent web component632). The customer device602may compare user interactions or communications with conditions for completion as specified by the embedded web component634. When the interactions or communications do not match the conditions, the customer device602may continue to monitor. Otherwise, when the interactions or communications match the conditions, the customer device602may determine the completion of the actions provided by the embedded web component634. For example, the customer device602may determine that actions provided by the embedded web component634are completed, upon receiving an acknowledgement of completion of a service (e.g., completion of account information retrieval or loan application) of the resource server608accessed through the embedded web component634. In some embodiments, the customer device602may determine that the embedded web component634is complete, when the access token656provided for the embedded web component634is no longer valid (e.g., from the expiration time).

The customer device602may initiate termination, dismissal, or otherwise releasing of the binding between the embedded web component634and the parent web component632. The initiation of the release by the customer device602may be in response to the detection of the completion of actions through the embedded web component634on the web application630. For instance, the customer device602may commence the release procedure, in response to acknowledgement of the completion of the services (e.g., completion of account information retrieval or loan application) of the resource server608accessed through the embedded web component634. The procedure to release the binding may be in accordance with the instructions in the embedded web component634in conjunction with the parent web component632. For example, upon detecting completion, the embedded web component634may call or invoke the release procedure defined by a handler the parent web component632.

From initiating, the customer device602may produce, output, or otherwise generate at least one authorization code token660using at least a portion of the access token656(e.g., the binding identifier644). The authorization code token660may be used to verify the unbinding of the embedded web component634from the parent web component632. The customer device602may generate the authorization code token660in accordance with a format, such as a JavaScript Object Notation (JSON) object (e.g., a JSON web token (JWT)), among others. The customer device602may generate the authorization code token660in accordance with the instructions in the parent web component632(or the embedded web component634). In some embodiments, the customer device602may fetch or retrieve the authorization code token660from the access token656.

The authorization code token660may identify or include a set of claims (sometimes herein referred to as parameters or information). At least a portion of the claims for the authorization code token660may identify or include at least a portion of the access token656, among others. The set of claims for the access token656may identify or include any one of: the binding identifier644; the expiration time specifying or defining a duration of time in which the authorization code token660is valid; an issue time defining or identifying a time (e.g., a time stamp) at which the authorization code token660is created; the issuer identifier corresponding to the customer device602; the token identifier uniquely referencing the authorization code token660(e.g., to protect from replay); and the identifier corresponding to the customer device602, the instance of the web application630, or the user (e.g., the account or profile), among others. In some embodiments, the set of claims for the authorization code token660may identify or include the access token656, the partner token, the bound context, and the code challenge information, among others. The code challenge information may identify or include the code challenge verifier, the code challenge hash, and the code challenge method, among others, as discussed above.

With the generation, the customer device602provides, sends, or otherwise transmits at least one release request662(sometimes herein referred to as an unbinding request or indication to unbind) to the resource server608. The release request662may identify or include the authorization code token660. The transmission of the release request662may be through the access server604and the gateway server. In some embodiments, the customer device602may transmit the release request662to the access server604. The access server604may in turn generate the authorization code token660in the manner as detailed above. With the generation, the access server604may insert or include the authorization code token660in the release request662, and may send the release request662to the resource server608.

The binding handler622executing on the resource server608retrieves, identifies, or otherwise receives the release request662from the customer device602. Upon receipt, the binding handler622may process or parse the release request662to extract or identify the authorization code token660therefrom. With the identification, the binding handler622may validate the authorization code token660based on the contents therein. From the authorization code token660, the binding handler622may extract or identify the binding identifier644, among other parameters. The binding handler622may access the database624to find, retrieve, or identify the binding identifier for the customer device602(e.g., using the identifier corresponding to the customer device602from the release request662). The binding handler622may compare the binding identifier644identified from the authorization code token660with the binding identifier from the database624for the customer device602.

If the binding identifiers do not match or correspond, the binding handler622may identify or determine that the authorization code token660is invalid. The binding handler622may also limit or restrict accessing of resources for the embedded web component634. When the validation of the authorization code token660fails, the binding handler622may return, send, or otherwise transmit an indication of the failure to validate the authorization code token660to the customer device602. The indication may be transmitted through the gateway server and the access server604. The binding handler622may terminate the process of providing access to resources for the embedded web component634on the customer device602. On other hand, if the binding identifiers match or correspond, the binding handler622may identify or determine that the authorization code token660is valid.

When the validation of the authorization code token660is successful, the binding handler622outputs, creates, or otherwise generates at least one release acknowledgement664(sometimes herein referred to as a release response or a response). The release acknowledgement664may be to indicate to the customer device602to finalize dismissal procedure of the embedded web component634. In conjunction, the resource provider620may retrieve, obtain, or otherwise identify content668to provide to the embedded web component634to indicate termination of the embedded web component634. The content668may identify or include data, such as additional instructions, an image, text, or multimedia, among others, to be inserted into the embedded web component634on the web application630. The resource provider620may fetch or retrieve the content668from the database524(or another data source) for the embedded component534. The binding handler622may insert or include the content668in the release acknowledgement664.

The resource handler620provides, sends, or otherwise transmits at least one release acknowledgement664to the access server604. The release acknowledgement664may identify or include the content668, among others. The release acknowledgement664may identify or include a destination identifier corresponding to the customer device602(or the access server604) to which the release acknowledgment664is to be sent. In some embodiments, the release acknowledgement664may be provided by the resource provider620to the customer device602via the access server604and the gateway server. The communication through the access server604and the gateway server may be encrypted or decrypted using the token or encryption key. The access server604in turn retrieves, identifies, or receives the release acknowledgement664from the resource server608. Upon receipt, the access server604forwards, passes, or otherwise transmits the release acknowledgement664to the customer device602.

The customer device602retrieves, identifies, or receives the release acknowledgement664including the content668from the resource server608. The release acknowledgement664may be received via the access server604or the gateway server, or both. Upon receipt, the customer device602may finalize the termination process of unbinding between the embedded web component634and the parent web component632. In conjunction, the customer device602may also load or present the content668on the embedded component634within the web application630. The processing of the release acknowledgement664and the presentation of the content668may be controlled or defined by the instruction in the parent embedded component634.

By passing the authorization code token660and finalizing the termination of the binding in this manner, the resource server608may prevent leakage of sensitive information through the embedded web component634once interactions are complete. The resource server608may also control accessing of the resources hosted thereon for services provided through the embedded web component634on the web application630. The scheme may thus improve data security and privacy from accessing of the content from the resource server608while permitting the user to remain on the web application630provided by the access server604.

FIGS.7A and7Bdepict communication diagrams of a process700of launching embedded web components to bind with parent web components. Embodiments may include additional, fewer, or different operations from those described in the method700. The method700may be performed by a server executing machine-readable software code, though it should be appreciated that the various operations may be performed by one or more computing devices and/or processors. The components and devices performing the process700may include a consumer device702, a web application704, a parent script element706, a partner server708, an inline frame element710, a gateway712, a validator714, and a web server718, among others. The web application704, the parent script element706, and the inline frame element710may be on the consumer device702.

At step720, the parent script element706generates a code challenge using a code challenge method. The code challenge may include a unique random number corresponding to a verifier and a hash value calculated in accordance with the code challenge method. At step722, the customer device702in conjunction with the web application704and the parent script element706may package to bind the inline frame element710and the parent script element706. At step724, the parent script element706may persist the code challenge verifier generated in accordance with the code challenge method. At step726, the consumer device702in conjunction with the web application704and the parent script element706may generate a request for a callback. At step728, in generating the request, the parent script element706may launch the inline frame element710with a partner token. The partner token may be generated by the partner server708, and may include a set of claims, such as an issuer identifier, a partner identifier, and a time-to-live (e.g., 30 seconds as depicted). At step730, the inline frame element710may send a request including the partner token, an identifier corresponding to the inline frame element710, code challenge information, and partner identifier, among other parameters to the gateway712. The request may identify a destination address (e.g., “www.example.com/partner/page.html”) to which the request is to be sent.

Continuing on, at step732, the gateway712may pass the request to the validator714. At step734, the validator714may validate the partner token from the partner server708. At step736, in validating, the partner token may be used to prove the inline frame element710was launched from an approved context corresponding to the parent script element706. At step738, the partner token may have failed to be validated. When validation has failed, at step740, the validator714may send an error message (e.g., HTTP 400 message) to the gateway712. At step742, the gateway712may forward the error message to the inline frame element710. On the other hand, when the validation is successful, at step744, the validator714may forward the request to the web server718. The request may include the destination identifier (e.g., “partner/html?” as depicted) to which the request is to be sent.

FIG.8A-Cdepict communication diagrams of a process800of generating access tokens for embedded web components. Embodiments may include additional, fewer, or different operations from those described in the method800. The method800may be performed by a server executing machine-readable software code, though it should be appreciated that the various operations may be performed by one or more computing devices and/or processors. The components and devices performing the process800may include a gateway802, a web server804, a resource server806, an authorizer808, and an authorization database810.

At step820, the web server804may take partner identifier from the partner token forwarded by the gateway802. At step822, the web server804may create a bearer token. The bearer token may include a set of public claims and a set of private claims. The set of public claims may include the issuer identifier, expiration time, issue time, and token identifier, among others. The set of private claims may include the partner identifier, customer device identifier, code challenge, and code challenge method, among others. At step824, the web server804may issue an identifier for an inline frame element of a web application. As step826, the web server804may send a request including the bearer token in the payload to the resource service806. The request may be in the form of an HTTP Post function, with a client identifier in the header.

Continuing on, at step828, the resource service806may forward the request including the bearer token in the payload to the inline frame authorizer808. At step830, the authorizer808may look up issuer identifiers to find a certificate to use for signature verification of the bearer token. At step832, the authorizer808may verify the bearer token using the signature. At step834, the authorizer808may generate a customer access token (CAT) based in part on the bearer token. The customer access token may include a set of public claims and a set of private claims. The set of public claims may include an issuer identifier, an issue time, and an expiration time, among others. The set of private claims may include partner identifier, a customer device identifier, code challenge, and a code challenge method, among others.

In addition, at step836, the authorizer808may check for a partner identifier or a customer identifier from the web server804or the resource server806. With the check, at step838, the authorizer808may persist a hash of the customer access token with metadata (e.g., the customer identifier, and partner identifier, among others) on the authorization database810. At step840, the authorizer808may send a response including the customer access token to the resource service806. The response may be in the format of a HTTP 200 OK response. At step842, the resource service806may forward the response to the web server804. The web server804may transmit the response to the customer device via the gateway802.

FIGS.9A-Cdepict flow diagrams of a method900of binding web components to protect accessing of resources. Embodiments may include additional, fewer, or different operations from those described in the method900. The method900may be performed by a server executing machine-readable software code, though it should be appreciated that the various operations may be performed by one or more computing devices and/or processors.

At step902, an access server send a request to access content to a resource server. The request may have originated from a customer device that loaded a web application including a parent web component and an embedded web component. The request may include a request token. The request token may identify a set of claims, such as an expiration time, a duration time, an issuer identifier, and a token identifier, among others. The request token may be signed or encrypted by the access server using an encryption key (e.g., a private key) generated by the access server. At step904, the resource server may receive the request to access from the access server. The resource server may parse the request to extract or identify the request token.

At step906, the resource server may determine whether the request to access is valid. To determine, the resource server may determine whether the token in the request was signed using the encryption key. The resource server may decrypt at least a portion of the token (e.g., an identifier corresponding to the access server) using the encryption key. Once decrypted, the resource server may determine whether the identifier is found on a list of trusted servers. If the identifier is determined to be not on the list, the resource server may determine that the request is invalid. If the identifier is determined to be on the list, the resource server may determine that the request is valid. In some embodiments, the gateway may perform the determination, and provide an indication of the validation results to the resource server.

At step908, when the request is determined to be invalid, the resource server may terminate the method. The resource server may return an indication of failing to validate to the access server. On the other hand, at step910, when the request is determined to be valid, the resource server may generate a binding identifier. The binding identifier may be used to bind the embedded web component with the parent web component to permit access to the resources for the embedded web component hosted on the resource server. At step912, the resource server may send a response including the binding identifier to the access server. At step914, the access server may receive the response from the resource server. At step916, the access server may provide the binding identifier in a partner token to the customer device to generate a context. The context may be to integrate or bind at least a portion of the functionalities of the embedded web component with the parent web component, such as to permit passage of data from user interactions from the embedded web component to the parent web component. The context may include a portion of a partner token, such as the binding identifier, expiration time, issue time, issuer identifier, registration information, and code challenge information, among others.

At step918, the access server may send the context to the resource server. At step920, the resource server may receive the context from the access server. Upon receipt, the resource server may parse the context to extract its contents, such as the binding identifier, among others. At step922, the resource server may determine whether the context is valid. To determine, the resource server may compare the binding identifier parsed from the context with the binding identifier stored for the customer device on a database. When the identifiers match, the resource server may determine that the context is valid. Otherwise when the identifiers do not match, the resource server may determine that the context is invalid.

At step924, if the context is determined to be invalid, the resource server may terminate, and may restrict access to the resource for the embedded web component. At step926, if the context is determined to be valid, the resource server may generate an access token. The access token may be used to finalize or confirm the binding of the embedded web component with the parent web component. The access token may include a set of claims, such as the binding identifier, the registration information, an expiration time, an issue time, an issue identifier, and code challenge information, among others. At step928, the resource server may transmit the token along with content for the embedded web component to the access server. At step930, the access server may receive the token along with the content from the resource server.

At step932, the access server may provide the token and the content to the customer device. The customer device may load the token and the content in accordance with the parent web component. The token may be used to bind the embedded web component with the parent web component. The content may be presented in the embedded web component. At steps934and936, the resource server and the access server may communicate data via the embedded web component. The data may be associated with the embedded web component and may include requests made in response to a user interaction with the embedded web component on the customer device and responses in response to such requests, among others. As the embedded web component is bound with the parent web component using the token, the data may be protected.

At step938, the access server may monitor the customer device for a dismissal of the embedded web component. In some embodiments, the customer device may monitor for the dismissal of the embedded web component. The dismissal may correspond to user interactions, communications, or any other conditions associated with a completion of the services provided through the embedded web component. The completion of services may in turn initiate the releasing of the binding of the embedded web component from the parent web component. When no conditions are satisfied, the access server may continue to monitor the customer device. When at least one condition is satisfied, the access server may determine that the embedded web component is dismissed.

At step940, if the embedded web component is determined to be dismissed, the access server may also send an indication of the dismissal to the resource server. The indication may include an authorization code token. The authorization code token may identify at least one of the access token, such as the binding identifier. At step942, the resource server may receive the indication from the access server. The access server may parse the indication to identify the binding identifier from the authorization code token. At step944, the resource server may determine whether the authorization code token is valid. To validate, the resource server may compare the binding identifier identified from the authorization code token with the binding identifier on the database. When the identifiers do not correspond, the resource server may determine that the authorization code token is invalid. When the identifiers correspond, the resource server may determine that the authorization code token is valid.

At step946, if the authorization code token is determined to be invalid, the resource server may terminate the process, and may restrict further access to the resources for the embedded web component. At step948, if the authorization code token is determined to be valid, the resource server may determine to unbind the embedded web component from the parent web component. With the determination, at step950, the resource server may send an indication to unbind from the access server. At step952, the access server may receive the indication from the resource server. The access server may provide the indication to the customer device, and the customer device may in turn conclude the unbinding of the embedded web component from the parent web component. At step954, the access server may end the process.

The foregoing method descriptions and the process flow diagrams are provided merely as illustrative examples and are not intended to require or imply that the steps of the various embodiments must be performed in the order presented. The steps in the foregoing embodiments may be performed in any order. Words such as “then,” “next,” etc. are not intended to limit the order of the steps; these words are simply used to guide the reader through the description of the methods. Although process flow diagrams may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, and the like. When a process corresponds to a function, the process termination may correspond to a return of the function to a calling function or a main function.