Enabling SSO for embedded applications

Abstract

Techniques are disclosed for enabling a hub application to execute a token agent on behalf of an embedded application embedded in the hub application to restore an authentication state for the embedded application. An authentication login event is performed to authenticate the hub application with the account. As a result, the hub application receives a first access token from the token proxy platform, the first access token representing a restored authentication state with the account. And starting the embedded application. The hub application executes a token agent on behalf of the embedded application while avoiding execution of a subsequent authentication login event. The hub application sends the second access token to the embedded application.

Description

Background Art

[0001] WebView is a standard user interface (UI) element used by application developers who want to render web-based HTML, CSS, and JavaScript content in the context of a native (e.g., rich client or hub) application. Typically, WebView is rendered in-process and does not have access to the global shared system cookie container (cookie jar).

[0002] When a web app is launched within a WebView, there is no session state, cookies, or authentication tokens available in the Document Object Model (DOM) to enable a secure single sign-on (SSO) experience. Therefore, the user is often forced to log in again by entering his / her username or password.

[0003] The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is merely provided to illustrate one exemplary technology area where some embodiments described herein may be practiced. Summary of the Invention

[0004] Embodiments disclosed herein relate to systems, devices, and methods for enabling a hub application to execute a token proxy on behalf of an embedded application, thereby recovering the authentication state for the embedded application, which is embedded in the hub application.

[0005] Some embodiments perform an authentication login event to authenticate a hub application with an account. As a result of the hub application being authenticated, the hub application receives a first access token from a token broker platform, the first access token representing the restored authentication state of the account. The token broker platform operates as a central single sign-on (SSO) store for applications executing on the computer system.

[0006] These embodiments launch an embedded application from within an authenticated hub application.The embedded application is initially stateless, such that the embedded application is not authenticated with an account.

[0007] In avoiding performing subsequent authentication login events, these embodiments enable the hub application to perform token proxying on behalf of the embedded application to enable the embedded application to obtain a second access token, which also represents the recovered authentication state of the utilization account. The token proxy process includes the hub application receiving a request to obtain the second access token from the embedded application. The process also includes the hub application delegating the acquisition, retrieval or generation of the second access token to the token proxy platform by sending a request to the token proxy platform. The process includes the hub application receiving the second access token from the token proxy platform. The second access token is obtained based on the recovered authentication state currently existing for the account. The process also includes the hub application sending the second access token to the embedded application.

[0008] In some embodiments, the aforementioned request is received at a communication bridge that exists between the hub application and the embedded application. In such a scenario, a service or interface is provided as part of the communication bridge. The service enables the scripting language that is part of the embedded application to communicate with the native language that is part of the hub application.

[0009] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

[0010] Additional features and advantages will be set forth in the following description and, in part, will be apparent from the description, or may be learned by practice of the teachings herein. The features and advantages of the present invention may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. The features of the present invention will become more apparent from the following description and the appended claims, or may be learned by practice of the invention as set forth below. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] To illustrate the manner in which the foregoing and other advantages and features can be obtained, a more particular description of the subject matter briefly described above will be rendered by reference to specific embodiments thereof that are illustrated in the accompanying drawings. Understanding that these drawings depict only typical embodiments and are not to be considered limiting of scope, the embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

[0012] Figure 1 An example architecture involving native applications is shown.

[0013] Figure 2 An example architecture involving an embedded application embedded within a native application is shown.

[0014] Figure 3An example of a WebView is shown, which is an example of an embedded application.

[0015] Figure 4 Shows how WebView operates.

[0016] Figure 5 Shown is a process flow for authenticating an embedded application.

[0017] Figure 6 An improved architecture involving native and embedded applications is shown.

[0018] Figure 7 、 Figure 8 、 Figure 9 and Figure 10 Various improved process flows for authenticating embedded applications are shown.

[0019] Figure 11 The token brokering process is shown.

[0020] Figure 12 Shows how to embed different applications within other applications.

[0021] Figure 13A and Figure 13B Various flow diagrams of example methods for authenticating embedded applications are shown.

[0022] Figure 14 An example computer system is shown that can be configured to perform any of the disclosed operations. DETAILED DESCRIPTION

[0023] Embodiments disclosed herein relate to systems, devices, and methods for enabling a hub application to perform token proxying on behalf of an embedded application, thereby restoring the authentication state for the embedded application, which is embedded in the hub application. The embodiments beneficially address the so-called "double login" problem that exists for embedded applications. A "double login" occurs when a user must first log in to a rich client application (i.e., a hub or native application) and then log in again to any application hosted within the WebView of the application. It should be noted that the runtime of the disclosed embedded application does not have to be a WebView. For example, the embedded application can optionally be an application that does not include a user interface runtime, such as a headless browser or a JavaScript engine.

[0024] Some embodiments perform an authentication login event to authenticate the hub application with the account. As a result, the hub application receives a first access token from the token broker platform, which represents the restored authentication state with the account. These embodiments launch the embedded application. The embedded application is initially stateless.

[0025] These embodiments enable the hub application to perform token proxying on behalf of the embedded application while avoiding the need to perform subsequent authentication login events. The token proxying process includes the hub application receiving a request from the embedded application to obtain a second access token. The process also includes the hub application delegating the acquisition, retrieval, or generation of the second access token to the token proxy platform. The hub application receives the second access token from the token proxy platform. The second access token is obtained based on the restored authentication state currently existing for the account. The hub application sends the second access token to the embedded application.

[0026] In some embodiments, a communication bridge exists between the hub application and the embedded application. In such a scenario, a "service" or "interface" is provided as part of the communication bridge. In some embodiments, the "service" or "interface" can be a platform-specific application programming interface (API). The service enables a scripting language that is part of the embedded application to communicate with a native language that is part of the hub application. Examples of technology benefits, improvements, and real-world applications

[0027] The following section summarizes some example improvements and practical applications provided by the disclosed embodiments. However, it should be understood that these are only examples and the embodiments are not limited to only these improvements.

[0028] Typically, WebView is rendered in-process and does not have access to the global shared system cookie container. When a web app is launched within a WebView, there is no session state, cookies, or authentication tokens available to the Document Object Model (DOM) to implement a secure single sign-on (SSO) experience. Therefore, traditionally, the user is forced to log in again by entering his / her username or password. This can lead to problems requiring "double login." Examples would be helpful.

[0029] Imagine a user logged into Microsoft Teams and launches a third-party app from the Teams App Marketplace. The app is then loaded into a WebView component within the Teams process. Because this component lacks identity / SSO state, the user is required to log in to the third-party app to use it. This creates friction and a fragmented experience when the user navigates between the Teams first-party experience and the third-party app experience.

[0030] The disclosed embodiments provide various solutions to these problems, thereby eliminating friction perceived by users. The disclosed solutions enable token and device binding for SSO credentials for first-party and third-party applications hosted within another application. In other words, the disclosed protocols and techniques enable token proxying for hosted applications, thereby solving the "double login" problem. To this end, embodiments configure the host application (or alternatively, the system token proxy) to operate as an identity source that can provide SSO tokens to hosted applications.

[0031] Advantageously, embodiments may optionally employ two protocols. The first protocol is known as "single proxy," whereby a hosted application delegates to its direct host to provide a source of identity for the active user. The host application then obtains a token on behalf of the hosted application.

[0032] The second protocol is called "dual proxy", whereby the host delegates to an external identity source (such as an operating system or authentication server) to provide the identity source and obtain tokens on behalf of the hosted application. Dual proxy has the unique ability to ensure that the device identifier can be included in the SSO artifact generated for the hosted application. Dual proxy also allows various device security policies to be met. In some embodiments, the external identity source (e.g., an authentication service) is involved in all, most, or at least some of the token acquisition process because, in some cases, the external identity source is the entity that issues the token signed with the necessary keys. For example, in some implementations of the dual proxy protocol, the hub application delegates token acquisition to the operating system (OS), which then uses the trusted artifact it has for the user (which was previously obtained from the authentication server). The OS can then use this trusted artifact to obtain a new token on behalf of the hub (and ultimately on behalf of the embedded application).

[0033] In more detail, the disclosed embodiments also implement the acquisition of various device identifiers by embedded applications. In most embodiments, the device identifier is a generated value that is persisted to uniquely identify the device. For example, in most embodiments, the device identifier is a specific identity associated with one or more of a user identity or a device identity. In some embodiments, the device identifier may include an IMEI, a MAC address, or some other stable data value that is available across a registration or deregistration process. That is, scenarios in which the unique identifier is associated with a user identity or a device identity are preferred. For example, a MAC address may be associated with physical network hardware such as a NIC, which may be swapped out, thereby changing the MAC address. Because the unique identifier is persisted (e.g., possibly by an OS or platform agent), swapping physical network hardware does not change the device identifier.

[0034] In some cases, administrators for networks and organizations can put resource access policies around data. In order to access email data, the device may need to be registered and known to the tenant. In order to perform this registration process, a device identifier is used. It is worth noting that these device identifiers can be accessed by the operating system, which are generally not present in native applications or embedded applications. The device identifier is usually set by an authentication server. Optionally, the OS can include a key that the OS can use to prove its device identity to the authentication server. Through the proxy process outlined herein, an embodiment can provide a device identifier to an embedded application, thereby enabling the embedded application to call or operate on behalf of the unique name of the device. On some platforms, an embodiment relies on a system or platform agent to provide device identifiers. Typically, when a single agent is used, these identifiers may not be presented (for example, because the direct host of the embedded application does not own the data). Dual agents (for example, by delegating to a platform or system agent) often make device identifiers available.

[0035] In general, embodiments advantageously reduce the number of steps a user performs when interacting with an application, particularly with respect to the authentication process. This reduction improves the user's experience with the computer system. In addition, embodiments can intelligently reuse data (e.g., access tokens), thereby improving the efficiency of the computer system. As yet another benefit, embodiments can enable login state to flow from the operating system to any level of embedding with respect to embedded applications. Yet another advantage is that updates to authentication (e.g., AuthN) for embedded applications or native / hub applications can automatically ensure updates to other associated applications. For example, an agent can optionally associate tokens for two applications. As a result, an update to one token will also result in an update to the other token, thereby avoiding repeated prompts for re-authentication. Accordingly, these and many other benefits will now be described in more detail throughout the remainder of this disclosure. Example Architecture

[0036] Now turn your attention to Figure 1 , which shows an example architecture 100 that generally demonstrates how a "native" or "hub" application operates. As used herein, the phrase "native application" refers to an application written in a programming language designed for a specific platform or operating system (OS). Native applications also typically have a user interface (UI) whose framework is designed for the specific platform.

[0037] In other words, native apps are not generally considered cross-platform apps that run in a browser. Regarding the programming languages ​​of native apps, examples of such languages ​​include, but are not limited to, Java, C#, C++, Objective-C, and the like. These programming languages ​​are able to work with, or effectively work with, the device's OS platform.

[0038] Figure 1 An example of a native application is shown. Specifically, Figure 1 The device's OS 105 is shown. A browser 110 operates on OS 105 as an example of a native application. While browser 110 is an example of a native application, an application running in browser 110 is not an example of a native application; rather, the application is an example of a so-called "web application," details of which will be provided shortly. Other examples of native applications include, but are not limited to, Microsoft's Teams applications, Microsoft's Office suite applications, or any other downloaded application.

[0039] The browser 110 may include or interact with a rendering engine 115 to render content. Additionally, the browser 110 may interact with the native API of the OS via a native bridge 120. An example of a native bridge 120 may be an OS shell. A shell is typically considered the outermost layer of an OS. The shell is an interface that allows native applications to interact with the OS, allowing those applications to use device resources.

[0040] Using the native bridge 120 , the browser 110 can interact with the native API 125 . The native API 125 is a lower-level interface that applications can use to interact with the OS. The native API 125 can be accessed via the native bridge 120 .

[0041] Alternatively, the browser 110 can be authenticated with the OS by using a proxy platform 135. The proxy platform 135 operates as a central single sign-on (SSO) store for applications (e.g., native applications) executing on the device. In other words, the proxy platform 135 is a type of registration and authentication / credential service or mechanism that authenticates clients and / or applications.

[0042] Some platforms host token brokers (i.e., broker platforms) that act as a central SSO store for all user applications on a given device. At the protocol level, this capability is implemented through the Primary Refresh Token (PRT) protocol. The central authority in the PRT protocol is the Primary Refresh Token. This contrasts with a Refresh Token (RT), which can be used to obtain tokens for any application, and a RT, which is limited to a single application or, in some cases, a predefined set of applications.

[0043] Native applications request tokens from the token broker through an exposed API, typically specifying their application ID, the resource for which they need a token, and other environment-specific parameters. The token broker will then attempt to redeem its PRT for tokens on behalf of the requesting application. Additionally, on platforms that support package signing, the PRT protocol describes client authentication based on an identifier bound to the package.

[0044] The browser 110 can also communicate over a network to retrieve web content 135. The rendering engine 115 can be used to display the web content 135.

[0045] Figure 1 Presents technical solutions related to native applications, and Figure 2 The present invention provides a technical solution related to embedded applications hosted in or executed in WebView. Specifically, Figure 2 An example architecture 200 is shown including an OS 205 and native applications 210, which may optionally represent applications from Figure 1 browser 110 (or any other native application).

[0046] In this particular example, an embedded application is embedded in a native application 210; the embedded application is hosted or executed in a WebView 215. The WebView 215 is a type of embeddable browser that can be called by the native application 210 to display web content 220. In more detail, the WebView 215 can be considered as a portion of a browser engine that can optionally be embedded into the native application 210 so that the native application 210 can display highly dynamic information. In this case, the WebView 215 is a type of embeddable visual feature. Depending on the security posture selected by the hub, there may or may not be a trust separation between the hub application and the embedded application.

[0047] WebView 215 is one example of an embeddable runtime for an embedded application. The details provided later in this disclosure will generally focus more on embedded applications. At this point, an example may be helpful. Assume that a native application exists in the form of an email client. A user opens a ride-sharing extension in the context of that user's email client. The ride-sharing extension (e.g., with user permission) scans the contents of the currently open email and extracts the address. The ride-sharing extension then offers the user a ride booked to the address found in the user's email. In this scenario, the email is the native application and the ride-sharing extension is the embedded application. Traditionally, there has been no viable solution for developers to enable embedded applications to be authenticated without requiring the user to perform another login event.

[0048] These embedded applications can rely on identities to operate. To obtain this identity, embedded applications traditionally require additional login events. The disclosed embodiments propose a proxy protocol that enables devices to restore authentication and identity state to embedded applications by using a host application (e.g., a native application also called a "hub application") as the source of the identity or as an intermediary for obtaining the identity (such as by acting as a proxy on behalf of the extension or embedded application).

[0049] In the above example, the ride-sharing application may include tokens corresponding to the user, such as various access tokens, identity tokens, or even refresh tokens. Alternatively, the ride-sharing application has an understanding of where to obtain those tokens. In any case, embodiments allow the same set of tokens, or possibly sets of tokens, to be used by the embedded application based on the same authentication event.

[0050] return Figure 2 , the WebView 215 may include or interact with a rendering engine 225 to render the web content 220. In accordance with the disclosed principles (and as will be discussed in more detail later), a communication bridge 230 is included between the WebView 215 and the native application 210. The bridge 230 allows communications to be passed between the WebView 215 and the native application 210.

[0051] Architecture 200 also shows a native bridge 235, which represents the Figure 1 Thus, according to the disclosed embodiment, the architecture includes at least two bridges. These bridges include a bridge 230 that facilitates communication between the WebView 215 and the native application 210, and a native bridge 235 that facilitates communication between the native application 210 and the OS 205. The architecture 200 also shows a native API 240 and a proxy platform 245, which represent Figure 1 Native API 125 and proxy platform 130 .

[0052] Some native applications (e.g., native application 210) can act as hosts for multiple sub-applications (e.g., WebView 215). For such applications, it may not be desirable for the sub-applications to interact directly with the token proxy (e.g., proxy platform 245). This may be because the sub-applications are extracted from the execution environment, or, for platforms with package signing requirements, it may not be possible without forcing the sub-applications to couple themselves to the package metadata of their host. However, it is desirable to be able to easily authenticate these sub-applications without requiring additional logins.

[0053] Native applications 210 are typically associated with an account, such as a user account, a business account, a tenant account, or any other type of account. Typically, when a native application 210 is initialized, the native application 210 will request to be authenticated with the account. As a result, the user or other entity may have to log in to the account by presenting a set of credentials. If those credentials are valid, the native application 210 is authenticated with the account, and the login state 250 for the native application can be considered authenticated or restored using authentication 255.

[0054] When the WebView 215 is initialized, the WebView 215 is stateless 260, which means that the WebView 215 does not have a logged-in state 250 and it is not restored with authentication. Stateless also includes scenarios where no cookies are stored.

[0055] To authenticate a WebView 215, traditionally the user would have to submit user credentials a second time (e.g., the first time was when the native application 210 was authenticated). Requiring the user to repeatedly submit credentials can cause delays, user frustration, and other inconveniences to the user. The disclosed embodiments provide a seamless technique for authenticating a WebView or any other type of embedded application without requiring the user to submit user credentials a second or subsequent time. Instead, a single sign-on (SSO) event can be performed, and SSO can be used to authenticate not only native applications 210, but also embedded applications (e.g., WebView 215). Figure 3 and 4 Some additional details about WebView are provided. However, it should be noted that any type of embedded application embedded in a native application, or even any type of embedded application embedded in another embedded application, can be used. WebView is simply provided for example purposes only.

[0056] Figure 3 An example device is shown in the form of a tablet 300. Tablet 300 is displaying content from a native application 305. Tablet 300 is also displaying content from a WebView 310. In this example scenario, WebView 310 is an example of an embedded application embedded in native application 305.

[0057] Figure 4 It shows how a WebView 400 communicates over a network 410 using an address 405. The WebView 400 can retrieve content from a server 415 and then display the content on the device. Certification process flow

[0058] Figure 5An example of a process flow 500 is shown where the SSO option is not available for an embedded application 505. The process flow 500 involves the embedded application 505, a native application 510, a proxy platform 515, a network 520, and an authentication server 525 (which may implement a security token service). As previously described, the embedded application 505 is stateless 530.

[0059] When the native application 510 is first initialized, it will typically attempt to authenticate the native application 510 with an account. Figure 5 The authentication process of the native application is shown, with various actions above the dashed authenticated 535 line. The operations below the authenticated 535 line are actions for authenticating the embedded application 505 without enabling SSO.

[0060] Initially, the native application 510 submits an authentication request (AR) 540A to the proxy platform 515. The proxy platform 515 transmits the request (e.g., AR 540B) to the authentication server 525 via the network 520. The authentication server 525 verifies the request and attempts to authenticate the native application 510. In embodiments, the authentication is based on credentials provided by the user as part of the AR 540A, via multi-factor authentication, via passwordless authentication verification (which may be via communication with other devices), a multi-factor authentication response, or any combination thereof.

[0061] If the credentials are valid, the authentication server 525 returns an access token (AT) 545A to the proxy platform 515. The proxy platform 515 then transmits the AT 545B to the native application 510. The native application 510 can then use the received AT to authenticate and / or authorize with various APIs and other resources (e.g., as proof of allowed access).

[0062] The native application 510 can then trigger the launch 550 of the embedded application 505. As an example, assume that the native application 510 is Microsoft's TEAMS application, and the embedded application is an email scanning application that is a plug-in or extension for the TEAMS application. For example, the email scanning application can be tasked with scanning the user's emails and then automatically generating TEAMS calendar invitations for the scheduled meetings identified within the emails. In order to access these emails, the email scanning application will need to be authenticated. Traditionally, the user would be required to enter his / her credentials a second time (e.g., after initialization of the native application 510). Therefore, previous authentication techniques involving embedded applications cannot enable SSO, such as Figure 5 shown.

[0063] For example, when the embedded application 505 is started, it is stateless 530. As a result, the embedded application 505 is assigned the task of being authenticated. To this end, the embedded application 505 will submit an access request (AR) 555A to the proxy platform 515 (for example, assuming that the embedded application 505 can communicate directly with the proxy platform 515). The AR 555A will include the newly entered credentials. The proxy platform 515 will then send AR 555B to the authentication server 525. The authentication server 525 will attempt to authenticate the native application. In an embodiment, the authentication is based on the received credentials. Optionally, multi-factor authentication verified via non-password authentication can be used. Alternatively, a multi-factor authentication response or any combination of the above can also be used. An access token (AT) 560A is then generated. The AT 560A is accessed or retrieved by the proxy platform 515. That is, the AT 560A will be sent to the proxy platform 515, and then the proxy platform 515 will send the AT 560B to the embedded application 505. In this way, SSO 565 is not enabled for the embedded application 505. In some scenarios, the AR 555A does not include credentials, but rather the AR 555A includes an indication of the identity of the access token being requested. Improved architecture

[0064] The disclosed embodiments enable SSO even in scenarios involving both native and embedded applications. In particular, the embodiments enable a hub application (e.g., a native application) to perform token proxying on behalf of an embedded application embedded within the hub application, thereby recovering the authentication state for the embedded application. In other words, the embodiments effectively enable the embedded application to inherit the authentication state provided to the hub / native application.

[0065] Typically, there are three entities involved in the token broker protocol: a parent application or hub application, a child application (i.e., an embedded application, which may be an iframe within the hub), and a system token broker.

[0066] As a quick introduction, a sub-app sends a message to the hub app. The sub-app provides its client ID and the scopes for the desired token. The hub app assembles the sub-app's reply address based on its own client ID and the sub-app's origin. The hub app then sends a request to the system token broker with the sub-app's ID, the sub-app's reply address, and the scopes requested by the sub-app.

[0067] The system token proxy assembles the reply address by using the system token proxy prefix and the received request packet. The system token proxy combines these various parameters (including the reply address) into a request to the authentication server that hosts the token service. The token service verifies these parameters and returns an access token (AT) and optionally a refresh token (RT) for the sub-application to the token proxy. The system proxy passes the AT and optionally the RT to the hub application. Optionally, the hub application can cache the new RT. The hub application passes the AT to the sub-application. If a refresh token does not exist, a new access token can be requested. In some scenarios, token acquisition is facilitated by the OS. In such scenarios, the refresh token may not be provided to the application itself. Figure 6 An example architecture 600 that can be used to implement these various benefits and operations is shown. The action of requesting or refreshing a token by a hub or embedded application will typically result in a new refresh token being sent to the hub application. In this sense, both the hub and the embedded application can optionally play a role in supporting continued access to resources requested by the hub or embedded application without having to re-prompt the user to log in.

[0068] Architecture 600 shows many Figure 2 Here, Figure 2 The "native apps" have been renamed to hub apps 605, and Figure 2 The "WebView" has been renamed to embedded application 610. A bridge 615 exists between the embedded application 610 and the hub application 605. The bridge 615 represents Figure 2 The bridge 230 is configured to connect the CMOS device to the CMOS device.

[0069] In some embodiments, the embedded application 610 is a web application (e.g., a WebView application). The embedded application 610 can be considered to be extracted from the operating system (OS) of the computer system. Therefore, in some scenarios, the embedded application 610 is prevented from directly utilizing OS authentication.

[0070] Optionally, the web application is an application that uses one or more of Hypertext Markup Language (HTML), Cascading Style Sheets (CSS), or JavaScript. Optionally, the embedded application 610 can be a first-party extension application or a third-party extension application. A first-party extension application is an application that is controlled or managed by the same entity that owns the domain in which the hub application 605 is operating. A third-party extension application is an application that is not controlled by the same entity that owns the domain in which the hub application 605 is operating.

[0071] In accordance with the disclosed principles, embodiments configure bridge 615 to include a service 620 or interface. As used herein, the term "service" refers to an automated program that is tasked with performing different actions based on input. In some cases, service 620 can be a deterministic service that operates entirely given a set of inputs and without randomization factors. In other cases, service 620 can be or include a machine learning (ML) or artificial intelligence engine.

[0072] As used herein, references to any type of machine learning or artificial intelligence may include any type of machine learning algorithm or device, convolutional neural network(s), multi-layer neural network(s), recursive neural network(s), deep neural network(s), decision tree model(s) (e.g., decision trees, random forests, and gradient boosted trees), linear regression model(s), logistic regression model(s), support vector machines ("SVMs"), artificial intelligence device(s), or any other type of intelligent computing system. A machine learning algorithm may be trained using any amount of training data (and potentially later refined) to dynamically perform the disclosed operations.

[0073] Specifically, the communication bridge 615, and in particular the service 620, operates to translate operations implemented in the scripting language of the embedded application 610 into operations implemented in the native language of the hub application 610. In some examples, communicating through the communication bridge 615 involves adding an object to the global namespace for the embedded application 610. When the object is called, the object enables communication across the trust boundary between the native code of the embedded application 610 and the hub application 605.

[0074] The service 620 is provided as part of the communication bridge 615 between the hub application 605 and the embedded application 610. As described above, the service 620 enables the scripting language that is part of the embedded application 610 to communicate with the native language that is part of the hub application 605.

[0075] As previously described, the hub application 605 may be authenticated and therefore may have a restored logged-in state 625. However, when the embedded application 610 is launched from the hub application 605, the embedded application 610 is initially stateless 630. In accordance with the disclosed principles, embodiments allow various communications to occur through the bridge 615 and the native bridge such that a prior SSO 635 event (for the hub application 605) may be relied upon to also authenticate the embedded application 610.

[0076] As previously described, the proxy platform operates as a single SSO store 640 for applications executed on the OS of the device, including the hub application 605. The embodiment also configures the hub application 605 to execute a token proxy 645 on behalf of the embedded application 610. Therefore, the embodiment is able to take full advantage of the authentication login event 650 of the hub application 605 (wherein the hub application 605 is authenticated using an account 655) to authenticate the embedded application 610. Advantageously, the hub application can refresh its own token at will. The hub application can also refresh the embedded application's token based on a request from the embedded application or in response to a "keep fresh" policy specified on the hub application. Such a policy ensures that the embedded application's token will not expire. The embedded application can also request a refresh token for itself from the hub application. This request can conditionally result in a new refresh token also being obtained by the hub application for itself.

[0077] Specifically, as part of the authentication process, a first access token 660 is provided to the hub application 605. Later, a second access token is provided to the embedded application 610. This second access token represents an authentication state 665 for the embedded application 610, which is dependent on the authentication state of the hub application 605. Optionally, the second access token can be the same as the first access token, or alternatively, the second access token can be a copy of the first access token or a different instance of the first access token.

[0078] Some embodiments also restrict access tokens for embedded applications by removing certain permissions associated with the hub application's token. Some embodiments restrict access tokens for embedded applications by making the access token valid only for a predetermined list of sites associated with the embedded application. Some other restrictive effects include removing administrative privileges if those privileges exist in the hub application. In this sense, access tokens for embedded applications can be more restrictive than tokens provided to hub applications. Thus, embodiments can limit the scope of access granted by the bearer of the embedded token based on policy, user consent, or applicability.

[0079] Figure 7 、 Figure 8 、 Figure 9 and Figure 10 Further details are provided regarding the token proxy process.The token proxy process may include a single proxy or a dual proxy, as will be described in more detail below.

[0080] Figure 7 Shown are embedded applications 705, services 710 (e.g., from Figure 6 620 ), a hub application 715 , a proxy platform 720 , a network 725 , and an example proxy protocol 700 for an authentication server 730 . Figure 7The process outlined in occurs after the hub application 715 has been authenticated. In other words, Figure 7 The process outlined in Figure 5 The dashed line shown in the figure is after the certified 535 line.

[0081] By way of further illustration, an embodiment has performed an authentication login event to authenticate hub application 715 with an account. As a result of hub application 715 being authenticated, hub application 715 receives a first access token from token broker platform 720, the first access token representing the restored authentication state with the account. An embodiment has also launched embedded application 705 from within the authenticated hub application 715. Embedded application 705 is initially stateless, such that embedded application 705 is not authenticated with an account.

[0082] In case of avoiding to perform subsequent authentication login events, embodiments enable the hub application 715 to perform token proxying on behalf of the embedded application 705 to enable the embedded application 705 to obtain a second access token that also represents the restored authentication state of the utilization account. Figure 7 、 Figure 8 、 Figure 9 and Figure 10 Overview in.

[0083] In accordance with the disclosed principles, embedded application 705 relies on service 710 to send an access token (AT) request 735A to hub application 715, as shown in AT requests 735A and 735B. This communication uses Figure 6 Bridge 615 and service 620 are shown.

[0084] The hub application 715 optionally determines whether the proxy platform 720 is available. If the proxy platform 720 is available, the hub application 715 may choose to delegate the generation, retrieval, or acquisition of access tokens to the token proxy platform 720 by sending an AT request 735C to the proxy platform 720. This communication uses Figure 2 Described in Figure 6 When this delegation occurs, the dual proxy process described previously is triggered.

[0085] Optionally, the proxy platform 720 can query the operating system and inquire about the source of the request. The operating system can respond by notifying the proxy platform 720 of the source of the request. For example, the request may have a signature associated with it, where the signature is the signature of the embedded application and, optionally, the hub application. These signatures can be considered unique bundle IDs or cryptographically protected identifiers. In some scenarios, the OS does not have signatures for embedded applications. However, the OS may have signatures for hub applications, as hub applications are registered applications using an app store. The hub application has a value from the hub application to identify the embedded application. The hub application passes this value to the OS, which then sends it along with other request parameters to the authentication server for verification. In this sense, embodiments can perform various levels of verification by checking signatures on the request. In most scenarios, the proxy platform 720 does not actually authenticate the request because, in most scenarios, the proxy platform 720 does not include credential information. Therefore, the proxy platform 720 requests the authentication server to perform authentication. The cryptographically protected identifier indicates which application is involved in the access token or access token request, and the authentication server can use this information to perform authentication.

[0086] The proxy platform 720 transmits the AT request 735D to the authentication server 730 over the network 725. The AT request 735D may be authenticated by the authentication server 730 using the cryptographically protected identifier (mentioned above). That is, the authentication server 730 authenticates the AT request and generates an access token (AT) 740A, which is sent to the proxy platform 720. Furthermore, the cryptographically protected identifier may be used by the authentication server 730 to remove, add, or even modify claims or permissions from the generated AT 740A, which is related to the AT that is associated with the hub application. The proxy platform 720 then sends the AT 740B to the hub application 715 using the native bridge. The hub application then uses the native bridge from Figure 6 The bridge 615 sends AT 740C to the service 710 , and the service 710 provides AT 740D to the embedded application 705 .

[0087] The access token can be considered a type of bearer token. The embedded application can then use the access token to verify its authentication with various protected resources (such as various APIs, including REST APIs). The embedded application presents the access token and is then allowed to access the protected resource. In this way, the embodiment utilizes the login state of the hub application 715 and also uses the restored login state to allow authentication of the embedded application 705.

[0088] Figure 8 Shows something like Figure 7Another proxy protocol 800 of the proxy protocol 700 performs many of the same operations, so those repeated operations are no longer marked. Figure 7 and Figure 8 A significant difference between the two is that embodiments can optionally embed various device identifiers 805 into the access token provided to the embedded application. The device identifiers for the computer system (e.g., device identifiers 805) exist within the system OS. However, those device identifiers 805 are typically not present in embedded applications or hub applications. The OS has access to those device identifiers 805. For example, in some scenarios, the OS has a key that can be provided to the authentication server. The authentication server then issues a token with the device identifier.

[0089] In addition to the above example where the OS has the key, another example may include a device with a hardware cryptographic module that provides public key cryptographic services. These services protect the private key from direct access outside the module's security boundary while performing digital signatures using the private key on behalf of clients (e.g., an OS or application that can interact appropriately with the hardware module).

[0090] In other words, both the token broker platform and the hub application omit the device identifier 805. However, the access token can be recovered or populated with the device identifier 805. Typically, the device identifier 805 includes information used to uniquely identify the device. The access token can be configured to include various fields that can be populated with information. Some of these fields can be populated with the device identifier 805, which is obtained from the device OS and can be obtained from the OS by the broker platform. Figure 8 A dual agent process is also shown.

[0091] Figure 9 An example proxy protocol 900 is shown that is also similar to the previous proxy protocols. Common elements are not labeled.

[0092] In this example scenario, the proxy platform has already stored or otherwise cached an access token that can be used for the embedded application. Therefore, the proxy platform can optionally operate to authenticate the embedded application, rather than the proxy platform reaching the authentication server across the network. Alternatively, the proxy platform can access its cache to obtain the access token, as shown by accessing cache 905. Figure 9 The dual-agent process is also described in general.

[0093] Figure 10Yet another proxy protocol 1000 is shown. Here, the hub application operates as an authentication entity and has cached or otherwise stored an access token that can be used by the embedded application. For example, in response to receiving a request, the hub application can authenticate the embedded application based on determining that the embedded application is operating within the hub application. The hub application can then access its cache to obtain the access token, as shown in access cache 1005. However, in this example scenario, the resulting access token will not be populated with device identifiers 1010 because the hub application does not maintain those device identifiers 1010. As mentioned above, the OS maintains the device identifiers. Figure 10 A single-proxy process is described because the hub application does not delegate the authentication process to another entity.

[0094] Figure 11 An example of a token usage scenario 1100 is shown. The scenario shows a hub application 1105 and an embedded application 1110. The hub application 1105 has been provided with a first access token 1115A, and the embedded application 1110 has been provided with a second access token 1120B. Both access tokens represent a restored login state for a particular account. As a result of the hub application 1105 having previously authenticated, the second access token 1120B is obtained. Furthermore, the second access token 1120B is obtained without performing a secondary or subsequent login event.

[0095] The hub application 1105 can use its corresponding access token 1115A to access protected resources, such as REST API 1125 (i.e., in the form of a network call). Similarly, the embedded application 1110 can use its corresponding access token 1120B to access protected resources, such as REST API 1130. Typically, the API is not located locally on the device; instead, the application can make calls to a remote API across the network. Multiple embedded applications

[0096] Figure 12 A scenario involving a hub application 1200 and an embedded application 1205 embedded in the hub application 1200 is shown. A bridge 1210 is provided to facilitate communication between the hub application 1200 and the embedded application 1205. Figure 6 The service 1215 of the service 620 is configured as part of the bridge 1210 .

[0097] Recall that embodiments allow the embedded application 1205 to communicate with the hub application 1200 via the bridge 1210. Such communications may optionally include access token requests and even transmission of access tokens.

[0098] In some instances, the first embedded application embedded in hub application 1200 can itself host an embedded application. For example, embedded application 1220 is shown as embedded in embedded application 1205. Further, embedded application 1225 is shown as embedded in embedded application 1220. According to the disclosed principles, each embedded application, regardless of its level of embedding, can communicate directly with service 1215. That is, even if an embedded application is embedded in another application, both applications have the ability to communicate directly with service 1215. Therefore, service 1215 and bridge 1210 can operate in parallel to support any number of embedded applications. Example Method

[0099] The following discussion now relates to a number of methods and method actions that can be performed. Although method actions may be discussed in a particular order or shown in a flowchart as occurring in a particular order, this particular order is not required unless otherwise specified or because an action depends on another action being completed before the action is performed.

[0100] Now turn your attention to Figure 13A and Figure 13B , Figure 13A and Figure 13B Various flow charts are shown for an example method 1300 for enabling a hub application to execute a token proxy on behalf of an embedded application embedded in the hub application to recover the authentication state for the embedded application. Figure 6 Method 1300 is implemented within the architecture 600 of Figure 6 The hub application 605, embedded application 610, and proxy platform implement various portions of the method 1300. Alternatively, the method 1300 may be executed in a web execution environment (e.g., where the various components are available through a web interface) or an installed environment (e.g., where the various components are installed locally on the device).

[0101] Method 1300 includes an act of performing an authentication login event to authenticate the hub application with an account (such as, possibly, a tenant) (act 1305). As a result of the hub application being authenticated, the hub application receives a first access token from a token broker platform, the first access token representing the restored authentication state of the account. The token broker platform operates as a central single sign-on (SSO) store for applications executing on the computer system.

[0102] Action 1310 includes launching the embedded application from within the authenticated hub application. The embedded application is initially stateless. As a result, the embedded application is not authenticated with an account.

[0103] In case of avoiding to perform a subsequent authentication login event, action 1315 includes causing the hub application to perform token proxying on behalf of the embedded application to enable the embedded application to obtain a second access token (e.g., a bearer token) that also represents the restored authentication state of the utilization account. Optionally, the second access token can be the same as the first access token, such as being a duplicate or even an identical exact token. The token proxying process is performed on the embedded application. Figure 13B Overview in.

[0104] Figure 13B The illustrated action 1320 involves the hub application receiving a request from the embedded application to obtain a second access token. Figure 6 The bridge 615 receives the request to obtain the second access token. As previously described, the service is provided as part of the communication bridge, and the service enables the scripting language as part of the embedded application to communicate with the native language as part of the hub application.

[0105] In response to receiving a request from an embedded application to obtain a second access token, some embodiments cause the hub application to add information to the request. This information is account information, so that the token broker platform is informed of the account for which the second access token is being requested. Optionally, some embodiments cause the embedded application to obtain at least some account information from the hub application before sending the request. The embedded application can then include some of this information in its request to obtain the second access token.

[0106] Action 1325 involves delegating the generation, acquisition, or retrieval of a second access token to the token proxy platform by sending a request to the token proxy platform, which is part of the computer system's operating system. The process of the hub application delegating the generation, acquisition, or retrieval of a second access token to the token proxy platform by sending a request to the token proxy platform is referred to as a "dual proxy operation." Notably, the hub application also includes functionality for performing "single proxying." Single proxying involves the hub application generating, acquiring, retrieving, or accessing additional access tokens.

[0107] Typically, the token broker platform itself does not generate the second access token. Instead, the second access token is generated remotely from the token broker platform. For example, the authentication server mentioned previously can be the entity that generates the second access token. In some embodiments, the operating system can be used to proxy the token.

[0108] Action 1330 involves the hub application receiving a second access token from the token broker platform.The second access token is obtained based on the restored authentication state currently existing for the account.

[0109] Action 1335 involves the hub application sending a second access token to the embedded application. Optionally, method 1300 may include an action for the embedded application to access a protected resource using the second access token. In one example, the protected resource may be an application programming interface (API), and the API verifies the second access token. Once verified, the embedded application can utilize various program features available to it via the API.

[0110] In some embodiments, method 1300 may include additional actions. For example, method 1300 may include an action of determining that the second embedded application is embedded in the hub application. Another action involves subsequently determining that the token proxy platform is unavailable. Another action involves causing the hub application to generate, obtain, or retrieve a third access token (e.g., an example of a single proxy process). Yet another action involves sending the third access token to the second embedded application. The hub application may access an identity from the operating system of the computer system to generate, obtain, or retrieve the third access token.

[0111] In some embodiments, the token proxy process may include some additional actions. For example, the hub application may communicate with the token proxy platform, and the communication may involve parameters specifying both the hub application and the embedded application. The token proxy platform communicates with a remote service (e.g., an authentication server that is implementing a security token service) to obtain a second access token, wherein the communication between the token proxy platform and the remote service includes the transmission of parameters to the remote service that identify both the hub application and the embedded application. In some scenarios, the parameters may be: an identifier of the hub application, an identifier of the embedded application, an identifier of the restrictions imposed on the generated token, an indication of the policy to be implemented, an identifier of the user, device, or even an account. A first verification may be performed by the token proxy platform to verify the identity of the hub application. A second verification may be performed by the hub application to verify the identity of the embedded application. The identity of the embedded application is verified (e.g., typically by a token issuance service utilizing metadata provided by the hub) to ensure that the embedded application is not impersonating another application, thereby causing the hub application to attempt to authorize an embedded application token / access that it would not otherwise have. It is generally undesirable to require an embedded application to identify itself, as a bad actor / malicious application could assume a false identity, thereby gaining access to data or performing actions only available to a "real identity." Therefore, embodiments may advantageously perform the aforementioned verification to prevent such scenarios.

[0112] Thus, the disclosed embodiments advantageously resolve the dual login problem that exists for embedded applications. In doing so, significant benefits and advantages as described herein can be achieved. Example Computer / Computer System

[0113] Now turn your attention to Figure 14 , which illustrates an example computer system 1400 that may include and / or be used to perform any of the operations described herein. Computer system 1400 can take a variety of different forms. For example, computer system 1400 can be embodied as a tablet, desktop, laptop, mobile device, or standalone device, such as those described throughout this disclosure. Computer system 1400 can also be a distributed system that includes one or more connected computing components / devices in communication with computer system 1400. Computer system 1400 can implement any of the architectures described herein.

[0114] In its most basic configuration, computer system 1400 includes a variety of different components. Figure 14 Computer system 1400 is shown including a processor system 1405 including one or more processors (also referred to as "hardware processing units") and a memory system 1410.

[0115] With respect to the processor(s) of the processor system 1405, it should be understood that the functionality described herein may be performed, at least in part, by one or more hardware logic components (e.g., processor(s). For example, and without limitation, example types of hardware logic components / processors that may be used include: a field programmable gate array ("FPGA"), a program-specific or application-specific integrated circuit ("ASIC"), an application-specific standard product ("ASSP"), a system on a chip ("SOC"), a complex programmable logic device ("CPLD"), a central processing unit ("CPU"), a graphics processing unit ("GPU"), or any other type of programmable hardware.

[0116] As used herein, the terms “executable module,” “executable component,” “component,” “module,” “service,” “interface,” or “engine” may refer to a hardware processing unit or a software object, routine, or method that may be executed on the computer system 1400. The different components, modules, engines, and services described herein may be implemented as objects or processors executing on the computer system 1400 (e.g., as separate threads).

[0117] Storage system 1410 may include physical system memory, which may be volatile, non-volatile, or some combination of the two. The term "memory" may also be used herein to refer to non-volatile mass storage, such as physical storage media. If computer system 1400 is distributed, processing, memory, and / or storage capabilities may also be distributed.

[0118] Memory system 1410 is shown as including executable instructions 1415. Executable instructions 1415 represent instruction(s) executable by the processor of computer system 1400 to perform disclosed operations, such as those described in various methods.

[0119] The disclosed embodiments may include or utilize a special-purpose or general-purpose computer including computer hardware, such as, for example, one or more processors and system memory, as discussed in more detail below. The embodiments also include physical and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media can be any available media that can be accessed by a general-purpose or special-purpose computer system. Computer-readable media that store computer-executable instructions in the form of data are "physical computer storage media" or "hardware storage devices." Furthermore, computer-readable storage media, including physical computer storage media and hardware storage devices, exclude signals, carrier waves, and propagating signals. On the other hand, computer-readable media that carry computer-executable instructions are "transmission media" and include signals, carrier waves, and propagating signals. Thus, by way of example and not limitation, the present embodiments may include at least two distinctly different types of computer-readable media: computer storage media and transmission media.

[0120] Computer storage media (also called "hardware storage devices") are computer-readable hardware storage devices such as RAM, ROM, EEPROM, CD-ROM, RAM-based solid-state drives ("SSD"), flash memory, phase-change memory ("PCM") or other types of memory, or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other media that can be used to store desired program code means in the form of computer-executable instructions, data or data structures and that can be accessed by a general purpose or special purpose computer.

[0121] Computer system 1400 may also be connected (via wired or wireless connections) to external sensors (e.g., one or more remote cameras) or devices via network 1420. For example, computer system 1400 may communicate with any number of devices or cloud services to acquire or process data. In some cases, network 1420 may itself be a cloud network. Furthermore, computer system 1400 may also be connected to (multiple) remote / separate computer systems configured to perform any of the processing described with respect to computer system 1400, via one or more wired or wireless networks.

[0122] As in network 1420, a "network" is defined as one or more data links and / or data switches that implement the transmission of electronic data between computer systems, modules, and / or other electronic devices. When information is transmitted or provided to a computer via a network (hardwired, wireless, or a combination of hardwired and wireless), the computer appropriately considers the connection as a transmission medium. Computer system 1400 will include one or more communication channels for communicating with network 1420. Transmission media include networks that can be used to carry data or desired program code components in the form of computer executable instructions or in the form of data structures. In addition, these computer executable instructions can be accessed by general or special-purpose computers. The above combinations should also be included in the scope of computer-readable media.

[0123] In implementing various computer system components, program code components in the form of computer-executable instructions or data structures can be automatically transferred from a transmission medium to a computer storage medium (or vice versa). For example, computer-executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., a network interface card or "NIC") and then ultimately transferred to the computer system RAM and / or a less volatile computer storage medium at the computer system. Thus, it should be understood that computer storage media can be included in computer system components that also (or even primarily) utilize transmission media.

[0124] Computer-executable (or computer-interpretable) instructions include, for example, instructions that cause a general-purpose computer, a special-purpose computer, or a special-purpose processing device to perform a specific function or group of functions. Computer-executable instructions can be, for example, binary, intermediate format instructions such as assembly language, or even source code. Although the present technical solution has been described in language specific to structural features and / or method actions, it should be understood that the technical solution defined in the appended claims is not necessarily limited to the features or actions described above. On the contrary, the described features and actions are disclosed as example forms of implementing the claims.

[0125] Those skilled in the art will appreciate that these embodiments can be practiced in a network computing environment with many types of computer system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, pagers, routers, switches, etc. These embodiments can also be practiced in a distributed system environment, where local and remote computer systems linked (by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) over a network each perform tasks (e.g., cloud computing, cloud services, etc.). In a distributed system environment, program modules can be located in local and remote memory storage devices.

[0126] The present invention may be implemented in other specific forms without departing from the characteristics of the present invention. The described embodiments are to be considered in all respects as illustrative and non-restrictive. The scope of the present invention is therefore indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalents of the claims are intended to be embraced within their scope.

Claims

1. A computer system that enables a hub application to execute a token proxy on behalf of an embedded application to recover an authentication state for the embedded application, the embedded application being embedded in the hub application, the computer system comprising: Processor system; as well as a memory system comprising instructions executable by the processor system to cause the computer system to: performing an authentication login event to authenticate a hub application with the account, wherein, as a result of the hub application being authenticated, the hub application receives a first access token from a token broker platform, the first access token representing a recovered authentication state with the account, and wherein the token broker platform operates as a central single sign-on (SSO) store for applications executing on the computer system; launching the embedded application from within the authenticated hub application, wherein the embedded application is initially stateless such that the embedded application is not authenticated with the account; In a case where subsequent authentication login events are avoided, causing the hub application to execute a token broker on behalf of the embedded application to enable the embedded application to obtain a second access token, the second access token also representing the restored authentication state using the account, wherein the token broker comprises: The hub application receives a request from the embedded application to obtain the second access token; The hub application delegates the retrieval of the second access token to the token broker platform by sending the request to the token broker platform; the hub application receiving the second access token from the token broker platform, wherein the second access token is obtained based on the restored authentication state currently existing for the account; and The hub application sends the second access token to the embedded application.

2. The computer system of claim 1, wherein the embedded application is abstracted from an operating system (OS) of the computer system such that the embedded application is prevented from directly utilizing the OS authentication.

3. The computer system of claim 1 , wherein: The request to obtain the second access token is received on a communication bridge, the communication bridge existing between the hub application and the embedded application, and The communication bridge operates to convert operations implemented in the scripting language of the embedded application to operations implemented in the native language of the hub application. 4 . The computer system of claim 1 , wherein execution of the instructions further causes the computer system to cause the embedded application to access a protected resource using the second access token. The computer system of claim 1 , wherein the embedded application is one of a first-party extension application or a third-party extension application.

6. The computer system of claim 1, wherein the embedded application is a web application that uses one or more of: Hypertext Markup Language (HTML), Cascading Style Sheets (CSS), or JavaScript. The computer system of claim 1 , wherein the embedded application is a WebView application.

8. A computer system according to claim 1, wherein a device identifier for the computer system exists within an operating system (OS) of the computer system, wherein both the token proxy platform and the hub application omit the device identifier, and wherein the second access token is recovered using the device identifier obtained from the OS.

9. The computer system of claim 1, wherein execution of the instructions further causes the computer system to access a protected resource using the second access token, wherein the protected resource is an application programming interface (API), and wherein the API validates the second access token.

10. The computer system of claim 1 , wherein the hub application delegates retrieval of the second access token to the token proxy platform by sending the request to the token proxy platform, the delegation operating as a dual proxy operation; and The hub application further comprises functionality for performing a single proxy, the single proxy comprising the hub application retrieving additional access tokens.

11. A method for enabling a hub application to execute a token proxy on behalf of an embedded application to recover an authentication state for the embedded application, the embedded application being embedded in the hub application, the method comprising: performing an authentication login event to authenticate a hub application with the account, wherein, as a result of the hub application being authenticated, the hub application receives a first access token from a token broker platform, the first access token representing a recovered authentication state with the account, and wherein the token broker platform operates as a central single sign-on (SSO) store for the hub application; launching the embedded application from within the authenticated hub application, wherein the embedded application is initially stateless such that the embedded application is not authenticated with the account; In a case where subsequent authentication login events are avoided, causing the hub application to execute a token broker on behalf of the embedded application to enable the embedded application to obtain a second access token, the second access token also representing the restored authentication state using the account, wherein the token broker comprises: The hub application receives a request from the embedded application to obtain the second access token; The hub application delegates the retrieval of the second access token to the token broker platform by sending the request to the token broker platform; the hub application receiving the second access token from the token broker platform, wherein the second access token is obtained based on the restored authentication state currently existing for the account; and The hub application sends the second access token to the embedded application.

12. The method of claim 11, wherein the method is executed in a web execution context or in an installed context.

13. The method of claim 11 , wherein a service is provided as part of a communication bridge between the hub application and the embedded application, and wherein the service enables a scripting language that is part of the embedded application to communicate with a native language that is part of the hub application.

14. The method of claim 11, wherein the token broker platform is part of an operating system (OS) of a computer system implementing the method.

15. The method according to claim 11, further comprising: determining that a second embedded application is embedded in the hub application; Thereafter, determining that the token broker platform is unavailable; causing the hub application to retrieve a third access token; as well as The third access token is sent to the second embedded application, wherein the hub application accesses an identity from an operating system (OS) of a computer system implementing the method to retrieve the third access token.

16. A method for enabling a hub application to execute a token proxy on behalf of an embedded application, thereby restoring an authentication state for the embedded application, the embedded application being embedded in the hub application, the method comprising: performing an authentication login event to authenticate a hub application with the account, wherein, as a result of the hub application being authenticated, the hub application receives a first access token from a token broker platform, the first access token representing a recovered authentication state with the account, and wherein the token broker platform operates as a central single sign-on (SSO) store for the hub application; launching the embedded application from within the authenticated hub application, wherein the embedded application is initially stateless such that the embedded application is not authenticated with the account; In a case where subsequent authentication login events are avoided, causing the hub application to execute a token broker on behalf of the embedded application to enable the embedded application to obtain a second access token, the second access token also representing the restored authentication state using the account, wherein the token broker comprises: the hub application receiving a request from the embedded application to obtain the second access token, wherein the request is received over a communication bridge that exists between the hub application and the embedded application, wherein a service is provisioned as part of the communication bridge, and wherein the service enables a scripting language that is part of the embedded application to communicate with a native language that is part of the hub application; The hub application delegates the retrieval of the second access token to the token broker platform by sending the request to the token broker platform; the hub application receiving the second access token from the token broker platform, wherein the second access token is obtained based on the restored authentication state currently existing for the account; and The hub application sends the second access token to the embedded application.

17. The method according to claim 16, wherein In response to receiving the request to obtain the second access token from the embedded application, the hub application adds information to the request, wherein the information is information about the account so that the token proxy platform is informed of which account the second access token is being requested. The method of claim 16 , wherein the second access token is generated remotely from the token broker platform.

19. The method of claim 18, wherein the token broker further comprises: The hub application communicates with the token broker platform, the communication involving parameters specifying both the hub application and the embedded application; the token broker platform communicating with a remote service to obtain the second access token, wherein the communication between the token broker platform and the remote service includes transmitting the parameter to the remote service, the parameter identifying both the hub application and the embedded application; and Wherein a first verification is performed by the token proxy platform to verify the identity of the hub application, and a second verification is performed by the hub application to verify the identity of the embedded application.

20. The method of claim 16, wherein the second access token is a bearer token.

Images