WO2023172250A1

WO2023172250A1 - Apparatus and method of a distributed single sign-on mechanism

Info

Publication number: WO2023172250A1
Application number: PCT/US2022/019341
Authority: WO
Inventors: Jinlin Xu; Xiaofeng Li; Yiwei ZHAO
Original assignee: Innopeak Technology, Inc.
Priority date: 2022-03-08
Filing date: 2022-03-08
Publication date: 2023-09-14

Abstract

According to one aspect of the present disclosure, a method for distributed single sign-on (DSSO), implemented by a first computing device of a DSSO environment is provided. The method may include receiving a request for one or more first tokens from a second computing device. The one or more first tokens may be associated with a user application of the second computing device. The method may include determining whether the user application of the second computing device is associated with the DSSO environment based on DSSO policy information. The method may include, in response to determining that the user application of the second computing device is associated with the DSSO environment, obtaining the one or more first tokens. The method may include sending the one or more first tokens to the second computing device to cause the user application of the second computing device to be logged in.

Description

APPARATUS AND METHOD OF A DISTRIBUTED SINGLE SIGN-ON MECHANISM

BACKGROUND

[0001] Embodiments of the present disclosure relate to apparatus and method for wireless communication.

[0002] Single sign-on (SSO) is an authentication method that enables users to securely authenticate with multiple applications and websites using a single set of credentials. SSO works based upon a trust relationship set up between a resource provider and an identity provider, such as an identity provider. This trust relationship is often based upon a certificate that is exchanged between the identity provider and the resource provider. This certificate can be used to sign identity information sent from the identity provider to the resource provider so that the resource provider knows it is coming from a trusted source. In SSO, this identity data takes the form of tokens that include identifying information for a user, such as a user’s email address or a username, for example.

SUMMARY

[0003] According to one aspect of the present disclosure, a method for distributed single sign-on (DSSO), implemented by a first computing device of a DSSO environment is provided. The method may include receiving a request for one or more first tokens from a second computing device. The one or more first tokens may be associated with a user application of the second computing device. The method may include determining whether the user application of the second computing device is associated with the DSSO environment based on DSSO policy information. The method may include, in response to determining that the user application of the second computing device is associated with the DSSO environment, obtaining the one or more first tokens. The method may include sending the one or more first tokens to the second computing device to cause the user application of the second computing device to be logged in.

[0004] According to another aspect of the present disclosure, an apparatus for a first computing device of a DSSO environment is provided. The apparatus may include one or more processors. The apparatus may include memory having instructions stored thereon, which when executed by the one or more processors cause the processors to perform receiving a request for one or more first tokens from a second computing device. The one or more first tokens may be associated with a user application of the second computing device. The apparatus may include memory having instructions stored thereon, which when executed by the one or more processors cause the processors to perform determining whether the user application of the second computing device is associated with the DSSO environment based on DSSO policy information. The apparatus may include memory having instructions stored thereon, which when executed by the one or more processors cause the processors to perform, in response to determining that the user application of the second computing device is associated with the DSSO environment, obtaining the one or more first tokens. The apparatus may include memory having instructions stored thereon, which when executed by the one or more processors cause the processors to perform sending the one or more first tokens to the second computing device to cause the user application of the second computing device to be logged in.

[0005] According to yet another aspect of the present disclosure, a non-transitory computer-readable medium of a first computing device of a DSSO environment is provided. The non-transitory computer-readable medium having instructions stored thereon, which when executed by one or more processors cause the one or more processors to perform receiving a request for one or more first tokens from a second computing device. The one or more first tokens may be associated with a user application of the second computing device. The non-transitory computer-readable medium having instructions stored thereon, which when executed by one or more processors cause the one or more processors to perform determining whether the user application of the second computing device is associated with the DSSO environment based on DSSO policy information. The non-transitory computer-readable medium having instructions stored thereon, which when executed by one or more processors cause the one or more processors to perform, in response to determining that the user application of the second computing device is associated with the DSSO environment, obtaining the one or more first tokens. The non-transitory computer-readable medium having instructions stored thereon, which when executed by one or more processors cause the one or more processors to perform sending the one or more first tokens to the second computing device to cause the user application of the second computing device to be logged in.

[0006] These illustrative embodiments are mentioned not to limit or define the present disclosure, but to provide examples to aid understanding thereof. Additional embodiments are discussed in the Detailed Description, and further description is provided there. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate embodiments of the present disclosure and, together with the description, further serve to explain the principles of the present disclosure and to enable a person skilled in the pertinent art to make and use the present disclosure.

[0008] FIG. 1A illustrates an exemplary distributed single sign-on (DSSO) environment, according to some embodiments of the present disclosure.

[0009] FIG. IB illustrates an exemplary DSSO architecture, according to some embodiments of the present disclosure.

[0010] FIG. 1C illustrates various DSSO user interfaces (UIs), according to some embodiments of the present disclosure.

[0011] FIG. 2 illustrates a data flow for a first exemplary DSSO mechanism, according to some embodiments of the present disclosure.

[0012] FIG. 3 illustrates a data flow for a second exemplary DSSO mechanism, according to some embodiments of the present disclosure.

[0013] FIG. 4 illustrates a data flow for a third exemplary DSSO mechanism, according to some embodiments of the present disclosure.

[0014] FIG. 5 illustrates a data flow for a fourth exemplary DSSO mechanism, according to some embodiments of the present disclosure.

[0015] FIG. 6 illustrates a flow chart of a first exemplary method of wireless communication, according to some embodiments of the present disclosure.

[0016] FIG. 7 illustrates a flow chart of a second exemplary method of wireless communication, according to some embodiments of the present disclosure.

[0017] FIG. 8 is a block diagram illustrating an example of a computer system useful for implementing various embodiments set forth in the disclosure.

[0018] FIG. 9A illustrates an example data flow for an SSO mechanism.

[0019] FIG. 9B illustrates an example authorization mechanism for SSO access to a user application.

[0020] Embodiments of the present disclosure will be described with reference to the accompanying drawings. DETAILED DESCRIPTION

[0021] Although specific configurations and arrangements are discussed, it should be understood that this is done for illustrative purposes only. A person skilled in the pertinent art will recognize that other configurations and arrangements can be used without departing from the spirit and scope of the present disclosure. It will be apparent to a person skilled in the pertinent art that the present disclosure can also be employed in a variety of other applications.

[0022] It is noted that references in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” “some embodiments,” “certain embodiments,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it would be within the knowledge of a person skilled in the pertinent art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0023] In general, terminology may be understood at least in part from usage in context. For example, the term “one or more” as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures or characteristics in a plural sense. Similarly, terms, such as “a,” “an,” or “the,” again, may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term “based on” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for existence of additional factors not necessarily expressly described, again, depending at least in part on context.

[0024] As mentioned above, SSO is an authentication and authorization procedure that enables users to securely sign in to multiple independent software systems (e.g., applications and websites) using a one set of credentials (e.g., username and password). First the user is authenticated based on login credentials for one application before it is determined if the user is authorized for SSO for a related application. SSO works based upon a trust relationship set up between an application, which is associated with a resource provider, and an identity provider. This trust relationship may be based on a certificate that is exchanged between the identity provider and the resource provider. This certificate can be used to sign identity information that may be sent from the identity provider to the service provider so that the service provider knows it is coming from a trusted source. In SSO, this identity information takes the form of tokens which contain identifying bits of information about the user, e.g., such as the user’s email address, username, password, etc. When a first SSO application is logged in and the user interacts with a second SSO application on the same device, the identify provider may send tokens to the second SSO application without requesting login credentials. The second SSO application may send the tokens to the resource provider for access to restricted resources. The resource provider may authorize the second SSO application for access to the restricted resources based on the tokens. An example SSO data flow 900 is illustrated in FIG. 9A.

[0025] Referring to FIG. 9A, user device 902 is configured to SSO so that a single set of credentials may be input for access to first user application 904 and second user application 906. First user application 904 and second user application 906 are both associated with the same identity provider 910. For instance, first user application 904 may be Facebook™ and second user application 906 may be Whatsapp™. In the example depicted in FIG. 9A, the user is logged into first user application 904, which means that identity provider 910 has already authenticated the user’s credentials. To initiate an SSO mechanism when the user interacts with second user application 906, second user application 906 sends (at 901) an authorization request to browser 908, which sends (at 903) an authentication message to identity provider 910. Identity provider 910 may determine whether the user has been authenticated in connection with first user application 904. Although not depicted in FIG. 9A, when the user has not been authenticated, or when the user has not authorized SSO, identity provider 910 may instruct browser 908 to display a login user interface.

[0026] However, in the example shown in FIG. 9A, the user is authorized for SSO. Therefore, identity provider 910 sends (at 905) an authorization code to browser 908, which forwards (at 907) the authorization code to second user application 906. Second user application 906 returns (at 909) the authorization code to identity provider 910, which authenticates second user application 906 based on the authorization code. Once authenticated, identity provider 910 sends (at 911) tokens to second user application 906. Then, second user application 906 sends (at 913) an access request message that includes the tokens to resource server 912, which grants access to its restricted resources. A pictorial illustration of SSO access 901 to a user application is shown in FIG. 9B.

[0027] Referring to FIG. 9B, user device 902 may include first user application 904 and second user application 906. When access to first user application 904 is desired, the user may enter login credentials by interacting with a login UI 914. Once authenticated, the user is granted access to the restricted resources via first user application 904. If SSO is enabled, the user may access second user application 906 by interacting with its icon, and without re-entering user credentials. While SSO improves the quality of the user-experience in some scenarios, the SSO mechanism of FIGs. 9A and 9B cannot be used across devices, which negatively impacts the user’s experience when switching from one device to another.

[0028] Thus, there exists an unmet need for a distributed SSO (DSSO) mechanism to enable SSO services for applications located on different devices but that share the same identity provider.

[0029] To overcome these and other challenges, the present disclosure provides an exemplary DSSO mechanism that enables SSO services across different devices. According to the present disclosure, when a user is successfully logged into a remote application on a remote device, the user may access a user application on a second device without re-entering login credentials at the user device. This may be achieved by an exemplary authorization agent located on both devices. During a DSSO procedure, the authorization agent at the user device may send a request for tokens to the authorization agent at the remote device when a user attempts to access a user application. The authorization agent at the user device may facilitate the acquisition of tokens from the remote device when the remote application is logged in. Then, the tokens may be sent to the authorization agent at the user device, which forwards them to the user application. Using the tokens received from the remote device, the user may access restricted resources via the user application without re-entering login credentials at the user device. Thus, the exemplary DSSO mechanism described herein may enable access to restricted resources in a simplified but secure manner when a user changes devices, which achieves an improves user-experience. Additional details of the exemplary DSSO mechanism are provided below in connection with FIGs. 1 A-8.

[0030] FIG. 1A illustrates an exemplary DSSO environment 100, according to some embodiments of the present disclosure. FIG. IB illustrates an exemplary DSSO architecture 101, according to some embodiments of the present disclosure. FIG. 1C illustrates DSSO configuration UIs 103, according to some embodiments of the present disclosure. FIGs. 1 A, IB, and 1C will be described together.

[0031] Referring to FIG. 1 A, the exemplary DSSO environment may include a user device 102 and a remote device 104. User device 102 and remote device 104 may be associated with the same user (e.g., Smith). For instance, user device 102 may be Smith’s smartphone, while remote device 104 may be Smith’s tablet device.

[0032] Moreover, user device 102 may include one or more user applications, such as first user application 110-1 and second user application 110-2. Remote device 104 may include one or more remote applications, such as remote application 112. In the non-limiting example of FIG. 1A, first user application 110-1 is an ABC messenger application, second user application 110-2 is an ABC mail application, and remote application 112 is the ABC mail application. By way of example, first user application 110-1 may be a Google™ Messages application, second user application 110-2 may a Gmail™ application, and remote application 112 may also be the Gmail™ application. In this example, Gmail™ and Google Messages™ share the same identity provider, and hence, may share the same login credentials for Smith. However, first user application 110-1, second user application 110-2, remote application 112 are not limited to the examples of FIG. 1 A. Instead, these applications may include any application associated with the same identity provider. Also the user’s login credentials may be different for the different applications so long as the identity provider can verify the user using one or more sets of login credentials it stores for Smith. [0033] Still referring to FIG. 1 A, when Smith interacts with the ABC mail application icon on remote device 104, an authentication procedure may be performed to verify Smith’s identity prior to granting access to restricted resources, which in this example are e-mails. Once authenticated, remote application 112 may receive one or more tokens from the authentication server, which enables Smith to access restricted resources of the resource provider.

[0034] A login UI 114 may be displayed if remote application 112 is not presently logged in. When login UI 114 is displayed, Smith may enter his login credentials. The login credentials may be sent to an identity provider, which uses them to verify Smith’ s identity. On the other hand, if remote application 112 is already logged in, Smith may access his e-mail account via remote application 112 without re-entering his login credentials. Because the example applications of user device 102 and remote device 104 are associated with the same identity provider, the tokens received by remote application 112 may be sent to one or more of the first user application 110-1 and/or the second user application 110-2 when Smith attempts to access one of these applications. The tokens may be received based on one of the exemplary DSSO mechanisms described below in connection with FIGs. 2-5, or other DSSO mechanisms.

[0035] Various DSSO operations may be performed between user device 102, remote device 104, and an identity provider before user device 102 provides remote device 104 with tokens. Depending on Smith’s configuration settings, a DSSO policy confirmation UI 116 may be displayed on remote device 104 before user device 102 is provided with the tokens to access restricted resources.

[0036] Referring to FIG. IB, an exemplary DSSO architecture 101 is depicted with user device 102, remote device 104, an identity provider 150, and resource provider 160. User device 102 may include user application 110, system browser application 118a (also referred to herein as a “browser”), a user communication component 120a, and a user authorization agent 122a. Remote device 104 may include remote application 112, system browser application 118b, remote communication component 120b, and a remote authorization agent 122b.

[0037] Each system browser application 118a, 118b may be configured to access internet services, such as restricted resources at resource provider 160, via the cloud 140. User communication component 120a and remote communication component 120b may be configured to communicate with one another using any known communication protocol and/or technique, such as Wi-Fi, near-field communication (NFC), Bluetooth™, short-range communication, peer-to-peer communication, cellular communication, among others.

[0038] In some embodiments, remote application 112 and/or remote authorization agent 122b may communicate with identity provider 150 and/or resource provider 160 (or vice versa) via system browser application 118b. However, in some other embodiments, remote application 112 and/or remote authorization agent 122b may communicate with identity provider 150 and/or resource provider 160 (or vice versa) directly. Thus, in the following example embodiments, communications facilitated via system browser application 118b are not limited thereto, and may be implemented via a direct communication link. Conversely, in the following example embodiments, communications facilitated via a direct communication link are not limited thereto, and may be implemented via system browser application 118b.

[0039] User authorization agent 122a and remote authorization agent 122b may be configured to implement the exemplary DSSO mechanism for user application 110 and remote application 112. Each authorization agent may be configured to manage and enforce a DSSO protection policy configured by the user, manage a list of SSO applications that share unique credentials, manage a list of connected devices, and/or provide a getTokens() mechanism (see FIGs. 2-5) to get tokens from other devices, just to name a few. Still referring to FIG. IB, the exemplary DSSO mechanism may include a protection mechanism through which remote device 104 may request tokens 130. A user may set a DSSO policy at user device 102 using user authorization agent 122a and/or remote device 104 using the remote authorization agent 122b.

[0040] Moreover, each of user application 110 and remote application 112 may include an application authorization (appAuth) software developer kit (sdk) and a DSSO sdk. The AppAuth sdk may be a client sdk for native applications that performs authentication using OAuth 2.0 and OpenlD Connect. It may use a system browser application as an authentication layer to provide a login UI. In some embodiments, rather than AppAuth sdk, each of user application 110 and remote application 112 may include an Android AccountManager, which uses an authenticator application (not shown) provided by the authorization provider to display a login UI. DSSO sdk may provide application programming interfaces (APIs) for an application and enable application access to an authorization agent (e.g., gettokens()). The DSSO sdk may include a build-in server to implement the gettokens() function.

[0041] Referring to FIG. 1C, a global -based policy UI 170 may be displayed based on user interaction with an authorization agent icon. Global-based policy UI 170 may enable DSSO policy management by a user for one or more devices specific to the user’s account. In some embodiments, a device-based policy UI 180 may be displayed, which enable a user to authorize token exchange between specific devices, applications, and/or software systems. A list of the devices, applications, and/or software system for which the user has authorized token exchange may be referred to as DSSO policy information. The DSSO policy information may be maintained by the remote authorization agent 122b or elsewhere at remote device 104. The auto-configure function associated with device-based policy UI 180 enables DSSO token receipt after the subsequent authorization by the identity provider. For example, the device-based policy UI 180 may enable the user to select a “confirm once policy,” a “confirm every time policy,” or a “default policy.” The confirm once policy causes the display of a DSSO policy confirmation UI 116 the first time remote authorization agent 122b requests tokens from user authorization agent 122a. When the “confirm every time policy” is selected, DSSO policy confirmation UI 116 is displayed every time remote authorization agent 122b requests tokens from user authorization agent 122a. DSSO policy confirmation UI 116 may not be displayed when the default policy is set. Instead, the default policy enables user authorization agent 122a to send tokens to remote authorization agent 122b without user confirmation. Various data flows associated with the exemplary DSSO mechanism are described below in connection with FIGs. 2-5.

[0042] FIG. 2 illustrates a data flow associated with a first exemplary DSSO mechanism 200, according to some embodiments of the present disclosure. First exemplary DSSO mechanism 200 may be performed when the same application is installed on both user device 102 and remote device 104, when remote application 112 is authorized and logged in (e.g., has valid tokens), and user application 110 is not logged in.

[0043] Referring to FIG. 2, first exemplary DSSO mechanism 200 may begin when a user interacts with user application 110. Based on the interaction, user application 110 may determine that the user wishes to access restricted resources via user application 110. User application 110 may send a gettokens() message 201 to user authorization agent 122a. User authorization agent 122a may send a first tokens request 203 to remote authorization agent 122b. Tokens request 203 may include information associated with user application 110. For example, tokens request 203 may indicate a grant type, scope, client id, client secret, packageName, app signed certificate, etc. Grant type may indicate the request for tokens. Scope may indicate the scope of the request. Client id may include identification information associated with user device 102, user application 110, and/or user authorization agent 122a. Client secret may include security information that proves the tokens request 203 is from user device 102.

[0044] Still referring to FIG. 2, remote authorization agent 122b may perform (at 250) a DSSO determination before tokens are sent to user application 110 and/or user device 102. The DSSO determination may be made using the information included in the first tokens request 203 and DSSO policy information maintained by remote authorization agent 122b (or elsewhere at remote device 104). As mentioned above in connection with FIG. 1C, the DSSO policy information may include the list of devices, applications, and/or software systems for which the user has enabled external token exchange. Remote authorization agent 122b may determine whether DSSO is enabled for user device 102/remote device 104 and/or user application 110/remote application 112 by comparing the information included in first tokens request 203 with the DSSO policy information. By way of example and not limitation, the packageName and/or app signed certificate may uniquely identify user application 110. Once user application 110 is identified, remote authorization agent 122b may determine whether it has been authorized for external token exchange with remote device 104 and/or remote application 112 based on the DSSO policy information. When it is determined that user application 110 and/or user device 102 is/are not authorized for DSSO, remote authorization agent 122b may terminate operations associated with DSSO for the first tokens request 203 for security reasons. Otherwise, when user application 110 and/or user device 102 is/are authorized for DSSO, remote authorization agent 122b may generate a getapptokens() message 205, which is sent to remote application 112. [0045] In response to the getapptokens() message 205, remote application 112 may respond with tokens 130. If the DSSO policy set by the user is either the “confirm every time policy” or the “confirm once policy,” DSSO policy confirmation UI 116 may be displayed at remote device 104 prior to sending tokens 130 to user authorization agent 122a. If the user confirms DSSO authorization when the UI is display, or if the DSSO policy is the “default policy,” remote authorization agent 122b forwards the tokens 130 to user authorization agent 122a. Tokens 130 may then be forwarded to user application 110. Using tokens 130 received from user authorization agent 122a, user application 110 may access restricted resources at resource provider 160 (not shown in FIG. 2) without requesting user credentials at user device 102.

[0046] In some embodiments, tokens 130 may include information in the following format(s): “ HTTP/ 1.1 200 OK Content-Type: application/json Cache-Control: no-store Pragma: no-cache { “id token” "eyJhbGciOiJSUzIlNHsImtpZCI6IjFlOWdkazcifQ. ewoglmlzc... ; ” “refresh token; ” “8xLOxBtZp8; ” “access token; ” “SlAV32hkKG, ” “token type; ” “Bearer; ” “expires in” : 3600, scope=openid email }.

[0047] As seen above, “access token” information may include the opaque string the application will use to communicate with resource provider 160 and request data or perform actions with resource provider 160 on user behalf. “Refresh token” information may be used to obtain a renewed access token. “Id token” information may be a security token granted by identity provider 150 that contains information about a user. This information tells the application that the user is authenticated and may also provide information such as a username. The value of “id token” information is base64 encoded and may include one or more of the following formats: “{ “iss”: “https://server.example.com”, // resource provider domain; and/or “sub”: “24400320”, // the identifier of the authenticated user - account; “aud”: “s6BhdRkqt3,”// the client ID of the user application which has requested the ID token. Moreover, each application may include its own client identification (ID) that indicates information, such as: “exp”: 1311281970, // expiration Time; “iaf ’: 1311280970, // when the token issued; an “auth_time”: 1311280969, // when the user is authenticated }.

[0048] FIG. 3 illustrates a data flow associated with a second exemplary DSSO mechanism 300, according to some embodiments of the present disclosure. Second exemplary DSSO mechanism 300 may be performed when the same application is installed on both user device 102 and remote device 104, when remote application 112 is authorized and logged in but its tokens have expired, and user application 110 is not logged in. Referring to FIG. 3, second exemplary DSSO mechanism 300 may begin when a user interacts with user application 110. Based on the interaction, user device 102 may determine that the user wishes to access restricted resources via user application 110, and send a gettokens() message (not shown) to user authorization agent 122a. Upon receipt of the gettokens() message, user authorization agent 122a may send a token request 301 to remote authorization agent 122b.

[0049] Still referring to FIG. 3, remote authorization agent 122b may perform (at 350) a DSSO determination before tokens are sent to user application 110 and/or user device 102. The DSSO determination may be made using the information included in the token request 301 and DSSO policy information maintained by remote authorization agent 122b (or elsewhere at remote device 104). As mentioned above in connection with FIG. 1C, the DSSO policy information may include the list of devices, applications, and/or software systems for which the user has enabled external token exchange. Remote authorization agent 122b may determine whether DSSO is enabled for user device 102/remote device 104 and/or user application 110/remote application 112 by comparing the information included in token request 301 with the DSSO policy information. By way of example and not limitation, the packageName and/or app signed certificate may uniquely identify user application 110. Once user application 110 is identified, remote authorization agent 122b may determine whether user application 110 (or user device 102) has been authorized for external token exchange with remote device 104 and/or remote application 112 based on the DSSO policy information. When it is determined that user application 110 and/or user device 102 is/are not authorized for DSSO, remote authorization agent 122b may terminate operations associated with DSSO for the token request 301 for security reasons. Otherwise, when user application 110 and/or user device 102 is/are authorized for DSSO, remote authorization agent 122b may generate a getapptokens() message 303, which is sent to remote application 112.

[0050] In this example scenario, remote application 112 may determine that its tokens have expired, and hence, need to be refreshed. Thus, remote application 112 may send a refreshtokens() message 305 to identity provider 150. Refreshtokens() message 305 may be sent via system browser application 118b or directly to identity provider 150.

[0051] Still referring to FIG. 3, identity provider 150 may determine that remote application 112 has been authorized and that its tokens have expired. Hence, identity provider 150 may send refreshed tokens 130 to remote application 112. The refreshed tokens 130 may be sent via system browser application 118b or directly to remote application 112. Once received, remote application 112 may send the refreshed tokens 130 to remote authorization agent 122b. If the DSSO policy set by the user is either the “confirm every time policy” or the “confirm once policy,” a DSSO policy confirmation UI 116 may be displayed at remote device 104 prior to sending tokens 130 to user authorization agent 122a. If the user confirms DSSO authorization when DSSO policy confirmation UI 116 is displayed, or if the DSSO policy is the “default policy,” remote authorization agent 122b forwards the tokens 130 to user authorization agent 122a. Although not shown, user authorization agent 122a may forward tokens 130 to the user application 110, which may use the tokens to access restricted resources at resource provider 160.

[0052] FIG. 4 illustrates a data flow associated with a third exemplary DSSO mechanism 400, according to some embodiments of the present disclosure. Third exemplary DSSO mechanism 400 may be performed when the same application is installed on both user device 102 and remote device 104, when remote application 112 is not logged in but a related SSO application at remote device 104 is logged in, and user application 110 is not logged in. Referring to FIG. 4, third exemplary DSSO mechanism 400 may begin when a user interacts with user application 110 (not shown). Based on the interaction, user device 102 may determine that the user wishes to access restricted resources via user application 110, and sends a gettokens() message (not shown) to user authorization agent 122a. Upon receipt of the gettokens() message, user authorization agent 122a may send a token request 401 to remote authorization agent 122b.

[0053] When the token request 401 is received, remote authorization agent 122b may perform (at 450) a DSSO determination before tokens are sent to user application 110 and/or user device 102. The DSSO determination may be made using the information included in the token request 401 and DSSO policy information maintained by remote authorization agent 122b (or elsewhere at remote device 104). As mentioned above in connection with FIG. 1C, the DSSO policy information may include the list of devices, applications, and/or software systems for which the user has enabled external token exchange. Remote authorization agent 122b may determine whether DSSO is enabled for user device 102/remote device 104 and/or user application 110/remote application 112 by comparing the information included in token request 401 with the DSSO policy information. By way of example and not limitation, the packageName and/or app signed certificate may uniquely identify user application 110. Once user application 110 is identified, remote authorization agent 122b may determine whether user application 110 (or user device 102) has been authorized for external token exchange with remote device 104 and/or remote application 112 based on the DSSO policy information. When it is determined that user application 110 and/or user device 102 is/are not authorized for DSSO, remote authorization agent 122b may terminate operations associated with DSSO for the token request 401 for security reasons. Otherwise, when user application 110 and/or user device 102 is/are authorized for DSSO, remote authorization agent 122b may generate a getapptokens() message 403, which is sent to remote application 112.

[0054] In this example scenario, remote authorization agent 122b may determine that remote application 112 is not logged in, but SSO is configured for another remote application at remote device 104. Thus, remote application 112 may send an authorization message 405 to system browser application 118b, in some embodiments. Here, system browser application 118b may forward the authorization message 405 to identity provider 150. However, in some embodiments, remote application 112 may send authorization message 405 directly to identity provider 150.

[0055] Still referring to FIG. 4, identity provider 150 may determine that remote device 104 is configured for SSO and that an application related to remote application 112 is logged in. Thus, identity provider 150 may send an authorization code 407 to the system browser application 118b, which forwards the authorization code 407 to remote application 112. Additionally and/or alternatively, identity provider 150 may send authorization code 407 directly to remote application 112. In either scenario, remote application 112 may return the authorization code 407 to the identity provider 150. When the authorization code 407 is returned, identity provider 150 may send tokens 130 to remote application 112, which forwards them to remote authorization agent 122b. If the DSSO policy set by the user is either the “confirm every time policy” or the “confirm once policy,” a DSSO policy confirmation UI 116 may be displayed at remote device 104 prior to sending tokens 130 to user authorization agent 122a. If the user confirms DSSO authorization when the DSSO policy confirmation UI 116 is displayed, or if the DSSO policy is the “default policy,” remote authorization agent 122b forwards the tokens 130 to user authorization agent 122a. User authorization agent 122a may forward tokens 130 to user application 110. User application 110 may access restricted resources at resource provider 160 using tokens 130.

[0056] FIG. 5 illustrates a data flow associated with a fourth exemplary DSSO mechanism 500, according to some embodiments of the present disclosure. Fourth exemplary DSSO mechanism 500 may be performed when user application 110 is installed on user device 102, a corresponding remote application 112 is not installed on remote device 104, the user has not logged into a corresponding web application at remote device 104, and user application 110 is not logged in. [0057] Referring to FIG. 5, fourth exemplary DSSO mechanism 500 may begin when a user interacts with user application 110 (not shown). Based on the interaction, user device 102 may determine that the user wishes to access restricted resources via user application 110, and sends a gettokens() message (not shown) to user authorization agent 122a. Upon receipt of the gettokens() message, user authorization agent 122a may send a token request 501 to remote authorization agent 122b.

[0058] Still referring to FIG. 5, remote authorization agent 122b may perform (at 550) a DSSO determination before tokens are sent to user application 110 and/or user device 102. The DSSO determination may be made using the information included in the token request 501 and DSSO policy information maintained by remote authorization agent 122b (or elsewhere at remote device 104). As mentioned above in connection with FIG. 1C, the DSSO policy information may include the list of devices, applications, and/or software systems for which the user has enabled external token exchange. Remote authorization agent 122b may determine whether DSSO is enabled for user device 102/remote device 104 and/or user application 110/remote application 112 by comparing the information included in token request 501 with the DSSO policy information. By way of example and not limitation, the packageName and/or app signed certificate may uniquely identify user application 110. Once user application 110 is identified, remote authorization agent 122b may determine whether user application 110 (or user device 102) has been authorized for external token exchange with remote device 104 and/or remote application 112 based on the DSSO policy information. When it is determined that user application 110 and/or user device 102 is/are not authorized for DSSO, remote authorization agent 122b may terminate operations associated with DSSO for the token request 501 for security reasons. Otherwise, when user application 110 and/or user device 102 is/are authorized for DSSO, remote authorization agent 122b may determine whether remote application 112 is installed at remote device 104.

[0059] In the example depicted in FIG. 5, remote authorization agent 122b may determine that remote application 112 is not installed, and thus, generates an authorization request 503 based on information included in the tokens request 501. For example, authorization request 503 may include information such as, e.g., “POST /auth/O2/token HTTP/1.1 ” “Host: www.example.com0 “Content-Type: application, ^/x-www-form-urlencoded;charset=UTF-8C

“grant type=client credentials&scope= openid & client id= (CLIENT ID) &client seer et= (CLIENT SECRET) 0 etc. Authorization request 503 may be sent to system browser application 118b, which sends an authentication message 505 to identity provider 150.

[0060] Still referring to FIG. 5, identity provider 150 may determine that the user has not logged in to the web application, and instructs system browser application 118b to display a login UI 507. The user may input login credentials 509 using login UI 507, which is displayed on remote device 104. System browser application 118b may send the login credentials 509 to the identity provider 150. If the login credentials are verified, identity provider 150 may send an authorization code 511 to system browser application 118b, which sends them to remote authorization agent 122b. Additionally and/or alternatively, identity provider 150 may send authorization code 511 directly to remote authorization agent 122b. Remote authorization agent 122b may return authorization code 511 to identity provider 150 either directly or via system browser application 118b. If the authorization code 511 is verified, identity provider 150 sends tokens 130 to remote authorization agent 122b. If the DSSO policy set by the user is either the “confirm every time policy” or the “confirm once policy,” a DSSO policy confirmation UI 116 may be displayed at remote device 104 prior to sending tokens 130 to user authorization agent 122a. If the user confirms DSSO authorization when the DSSO policy confirmation UI 116 is displayed, or if the DSSO policy is the “default policy,” remote authorization agent 122b forwards the tokens 130 to user authorization agent 122a. User authorization agent 122a may send tokens 130 to user application 110 (not shown), which may use them to access restricted resources at resource provider 160 (not shown).

[0061] An example use case for fourth exemplary DSSO mechanism 500 is when a user is staying at a hotel and wishes to access her Netflix™ account via the Netflix™ application (user application) installed on the smart TV in her room. The Netflix™ application (remote application) is not installed on her phone, and she doesn’t wish to input her login credentials into the smart TV for security and privacy reasons. Thus, by displaying the login UI on her phone rather than the smart TV, she is protected from potential malware on an unfamiliar device. Moreover, the input system on her phone may be more user-friendly than that of the smart TV.

[0062] FIG. 6 illustrates a flow chart of a first exemplary method 600 of wireless communication of a remote device, according to some embodiments of the present disclosure. First exemplary method 600 may be performed by a computing device (e.g., a first computing device) e.g., such as remote device 104, remote application 112, system browser application 118b, remote communication component 120b, remote authorization agent 122b, and/or computing system 800. First exemplary method 600 may include steps 602-610 as described below. It is to be appreciated that some of the steps may be optional, and some of the steps may be performed simultaneously, or in a different order than shown in FIG. 6.

[0063] Referring to FIG. 6, at 602, the computing device may receive, from a user authorization agent of a user device, a first request for one or more first tokens for a user application associated with an identity provider. For example, referring to FIG. 2, remote authorization agent 122b may receive a first tokens request 203 from user authorization agent 122a. Tokens request 203 may include information associated with user application 110. For example, tokens request 203 may indicate a grant type, scope, client id, client secret, etc. Grant type may indicate the request for tokens. Scope may indicate the scope of the request. Client id may include identification information associated with user device 102, user application 110, and/or user authorization agent 122a. Client secret may include security information that proves the tokens request 203 is from user device 102.

[0064] At 604, computing device may determine whether one or more of the user application and/or the user device are authorized for DSSO. For example, referring to FIG. 2, remote authorization agent 122b may perform (at 250) a DSSO determination before tokens are sent to user application 110 and/or user device 102. The DSSO determination may be made using the information included in the first tokens request 203 and DSSO policy information maintained by remote authorization agent 122b (or elsewhere at remote device 104). As mentioned above in connection with FIG. 1C, the DSSO policy information may include the list of devices, applications, and/or software systems for which the user has enabled external token exchange. Remote authorization agent 122b may determine whether DSSO is enabled for user device 102/remote device 104 and/or user application 110/remote application 112 by comparing the information included in first tokens request 203 with the DSSO policy information. By way of example and not limitation, the packageName and/or app signed certificate may uniquely identify user application 110. Once user application 110 is identified, remote authorization agent 122b may determine whether it has been authorized for external token exchange with remote device 104 and/or remote application 112 based on the DSSO policy information. When it is determined that user application 110 and/or user device 102 is/are not authorized for DSSO, remote authorization agent 122b may terminate operations associated with DSSO for the first tokens request 203 for security reasons. Otherwise, when user application 110 and/or user device 102 is/are authorized for DSSO, remote authorization agent 122b may generate a getapptokens() message 205, which is sent to remote application 112. [0065] At 606, computing device may generate and send a second request for the one or more first tokens to a remote application. For example, referring to FIG. 2, remote authorization agent 122b may generate and send a getapptokens() message 205 to remote application 112.

[0066] At 608, the computing device may receive the one or more first tokens from the remote application in response to the remote application being logged in. For example, referring to FIG. 2, in response to the getapptokens() message 205, remote application 112 may send tokens 130 to remote authorization agent 122b.

[0067] At 610, the computing device may send the one or more first tokens to the second authorization agent of the user device. For example, referring to FIG. 2, if the DSSO policy set by the user is either the “confirm every time policy” or the “confirm once policy,” DSSO policy confirmation UI 116 may be displayed at remote device 104 prior to sending tokens 130 to user authorization agent 122a. If the user confirms DSSO authorization when the UI is displayed, or if the DSSO policy is the “default policy,” remote authorization agent 122b forwards the tokens 130 to user authorization agent 122a. Otherwise, remote authorization agent 122b may forward tokens 130 to user authorization agent 122a without displaying DSSO policy confirmation UI 116 if not required by the DSSO policy.

[0068] FIG. 7 illustrates a flow chart of a second exemplary method 700 of wireless communication of a user device, according to some embodiments of the present disclosure. Second exemplary method 700 may be performed by a computing device (e.g., a second computing device), e.g., such as user device 102, user application 110, system browser application 118a, user communication component 120a, user authorization agent 122a, and/or computing system 800. Second exemplary method 700 may include steps 702-708 as described below. It is to be appreciated that some of the steps may be optional, and some of the steps may be performed simultaneously, or in a different order than shown in FIG. 7.

[0069] Referring to FIG. 7, at 702, the computing device may receive a first request (e.g., gettokens() message 201) for one or more tokens from a user application. For example, referring to FIG. 2, user authorization agent 122a may receive a gettokens() message 201 from user application 110 in response to a user interaction with a user application icon displayed on user device 102.

[0070] At 704, the computing device may send a second request (e.g., first tokens request 203) for the one or more tokens to a second authorization agent of a remote device of the DSSO environment. For example, referring to FIG. 2, user authorization agent 122a may send a first tokens request 203 to remote authorization agent 122b. Tokens request 203 may include information associated with user application 110. For example, tokens request 203 may indicate a grant type, scope, client id, client secret, etc. Grant type may indicate the request for tokens. Scope may indicate the scope of the request. Client id may include identification information associated with user device 102, user application 110, and/or user authorization agent 122a. Client secret may include security information that proves the tokens request 203 is from user device 102.

[0071] At 706, the computing device may receive the one or more tokens from the second authorization agent. For example, referring to FIG. 2, if the DSSO policy set by the user is either the “confirm every time policy” or the “confirm once policy,” DSSO policy confirmation UI 116 may be displayed at remote device 104 prior to user authorization agent 122a receiving tokens 130. If the user confirms DSSO authorization when the UI is display, or if the DSSO policy is the “default policy,” remote authorization agent 122b forwards the tokens 130 to user authorization agent 122a.

[0072] At 708, the computing device may send the one or more tokens to the user application. For example, referring to FIG. 2, user authorization agent 122a may send tokens 130 to user application 110. Using tokens 130 received from user authorization agent 122a, user application 110 may access restricted resources at resource provider 160 (not shown in FIG. 2) without requesting user credentials at user device 102.

[0073] Various embodiments can be implemented, for example, using one or more computer systems, such as computer system 800 shown in FIG. 8. One or more computer system 800 can be used, for example, to implement the exemplary DSSO mechanisms 200, 300, 400, 500 of FIGs. 2-5, method 600 of FIG. 6, and/or method 700 of FIG. 7. For example, computer system 800 can perform any of the above-described operations associated with DSSO, according to various embodiments. Computer system 800 can be any computer capable of performing the functions described herein.

[0074] Computer system 800 can be any well-known computer capable of performing the functions described herein. Computer system 800 includes one or more processors (also called central processing units, or CPUs), such as a processor 804. Processor 804 is connected to a communication infrastructure 806 (e.g., a bus). One or more processors 804 may each be a graphics processing unit (GPU). In an embodiment, a GPU is a processor that is a specialized electronic circuit designed to process mathematically intensive applications. The GPU may have a parallel structure that is efficient for parallel processing of large blocks of data, such as mathematically intensive data common to computer graphics applications, images, videos, etc.

[0075] Computer system 800 also includes user input/output device(s) 803, such as monitors, keyboards, pointing devices, etc., that communicate with communication infrastructure 806 through user input/output interface(s) 802.

[0076] Computer system 800 also includes a main or primary memory 808, such as random access memory (RAM). Main memory 808 may include one or more levels of cache. Main memory 808 has stored therein control logic (i.e., computer software) and/or data. Computer system 800 may also include one or more secondary storage devices or memory 810. Secondary memory 810 may include, for example, a hard disk drive 812 and/or a removable storage device or drive 814. Removable storage drive 814 may be a floppy disk drive, a magnetic tape drive, a compact disk drive, an optical storage device, tape backup device, and/or any other storage device/drive. Removable storage drive 814 may interact with a removable storage unit 818. Removable storage unit 818 includes a computer usable or readable storage device having stored thereon computer software (control logic) and/or data. Removable storage unit 818 may be a floppy disk, magnetic tape, compact disk, DVD, optical storage disk, and/ any other computer data storage device. Removable storage drive 814 reads from and/or writes to removable storage unit 818 in a well- known manner.

[0077] According to an exemplary embodiment, secondary memory 810 may include other means, instrumentalities or other approaches for allowing computer programs and/or other instructions and/or data to be accessed by computer system 800. Such means, instrumentalities or other approaches may include, for example, a removable storage unit 822 and an interface 820. Examples of the removable storage unit 822 and the interface 820 may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, and/or any other removable storage unit and associated interface.

[0078] Computer system 800 may further include a communication or network interface 824. Communication interface 824 enables computer system 800 to communicate and interact with any combination of remote devices, remote networks, remote entities, etc. (individually and collectively referenced as 828). For example, communication interface 824 may allow computer system 800 to communicate with remote devices 828 over communication path 826, which may be wired and/or wireless, and which may include any combination of local area networks (LANs), wide area networks (WANs), the Internet, etc. Control logic and/or data may be transmitted to and from computer system 800 via communication path 826.

[0079] In an embodiment, a tangible apparatus or article of manufacture comprising a tangible computer useable or readable medium having control logic (software) stored thereon is also referred to herein as a computer program product or program storage device. This includes, but is not limited to, computer system 800, main memory 808, secondary memory 810, and removable storage units 818 and 822, as well as tangible articles of manufacture embodying any combination of the foregoing. Such control logic, when executed by one or more data processing devices (such as computer system 800), causes such data processing devices to operate as described herein.

[0080] Based on the teachings contained in this disclosure, it will be apparent to persons skilled in the relevant art(s) how to make and use embodiments of the present disclosure using data processing devices, computer systems and/or computer architectures other than that shown in FIG. 8. For example, embodiments may operate with software, hardware, and/or operating system implementations other than those described herein.

[0081] In various aspects of the present disclosure, the functions described herein may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or encoded as instructions or code on a non-transitory computer-readable medium. Computer-readable media includes computer storage media. Storage media may be any available media that can be accessed by a first computing device, such as remote device 104 of FIGs. 1 A, IB, 2, 3, 4, and 5 or computer system 800 of FIG. 8. By way of example, and not limitation, such computer-readable media can include random-access memory (RAM), read-only memory (ROM), EEPROM, compact disc read-only memory (CD-ROM) or other optical disk storage, hard disk drive (HDD), such as magnetic disk storage or other magnetic storage devices, Flash drive, solid state drive (SSD), or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a processing system, such as a mobile device or a computer. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), and floppy disk where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. [0082] According to one aspect of the present disclosure, a method for DSSO, implemented by a first computing device of a DSSO environment is provided. The method may include receiving a request for one or more first tokens from a second computing device. The one or more first tokens may be associated with a user application of the second computing device. The method may include determining whether the user application of the second computing device is associated with the DSSO environment based on DSSO policy information. The method may include, in response to determining that the user application of the second computing device is associated with the DSSO environment, obtaining the one or more first tokens. The method may include sending the one or more first tokens to the second computing device to cause the user application of the second computing device to be logged in.

[0083] In some embodiments, the method may include, in response to a configuration setting requiring user confirmation prior to sending the one or more first tokens to the second computing device, displaying a user confirmation request on a user interface of the first computing device.

[0084] In some embodiments, the method may include, in response to determining that one or more second tokens have expired, sending a token refresh request to an identity provider. In some embodiments, the method may include receiving, from the identity provider, the one or more first tokens in response to the token refresh request.

[0085] In some embodiments, the method may include, in response to determining that a remote application of the first computing device that is related to the user application of the second computing device is not logged in and that a related SSO application of the first computing device is logged in, sending an authorization request to an identity provider. In some embodiments, the remote application and the user application may be a same application type. In some embodiments, receiving an authorization code from the identity provider in response to the authorization request. In some embodiments, the method may include returning the authorization code to the identity provider. In some embodiments, the obtaining the one or more first tokens may include, in response to the authorization code being authenticated by the identity provider, receiving the one or more first tokens from the identity provider.

[0086] In some embodiments, the method may include, in response to determining that the first computing device does not include a remote application that is a same application type as the user application of the second computing device and that an SSO application of the first computing device associated with an identity provider is not logged in, sending an authorization request associated the user application to the identity provider. In some embodiments, the method may include displaying a login user interface associated with the identity provider on a user interface of the first computing device. In some embodiments, the method may include receiving a set of credentials based on an interaction with the login user interface. In some embodiments, the method may include sending the set of credentials to the identity provider.

[0087] In some embodiments, the method may include, in response to the set of credentials being authenticated by the identity provider, receiving an authorization code from the identity provider. In some embodiments, the method may include returning the authorization code to the identity provider. In some embodiments, the obtaining the one or more first tokens may include, in response to the authorization code being authenticated by the identity provider, receiving the one or more first tokens from the identity provider when the authorization code is authenticated by the identity provider.

[0088] In some embodiments, the method may include, in response to determining that the first computing device does not include a remote application that is a same application type as the user application of the second computing device and that an SSO application associated with an identity provider is logged in, sending an authorization request to the identity provider. In some embodiments, the method may include receiving an authorization code from the identity provider. In some embodiments, the method may include returning the authorization code to the identity provider. In some embodiments, the obtaining the first one or more tokens may include, in response to the authorization code being authenticated by the identity provider, receiving the one or more first tokens from the identity provider when the authorization code is authenticated by the identity provider.

[0089] In some embodiments, the method may include receiving the DSSO policy information based on input to a user interface. In some embodiments, the method may include maintaining the DSSO policy information. In some embodiments, the DSSO policy information may indicate a set of applications associated with the DSSO environment.

[0090] According to another aspect of the present disclosure, an apparatus for a first computing device of a DSSO environment is provided. The apparatus may include one or more processors. The apparatus may include memory having instructions stored thereon, which when executed by the one or more processors cause the processors to perform receiving a request for one or more first tokens from a second computing device. The one or more first tokens may be associated with a user application of the second computing device. The apparatus may include memory having instructions stored thereon, which when executed by the one or more processors cause the processors to perform determining whether the user application of the second computing device is associated with the DSSO environment based on DSSO policy information. The apparatus may include memory having instructions stored thereon, which when executed by the one or more processors cause the processors to perform, in response to determining that the user application of the second computing device is associated with the DSSO environment, obtaining the one or more first tokens. The apparatus may include memory having instructions stored thereon, which when executed by the one or more processors cause the processors to perform sending the one or more first tokens to the second computing device to cause the user application of the second computing device to be logged in.

[0091] In some embodiments, the memory having instructions stored thereon, which when executed by the one or more processors further cause the processors to perform, in response to a configuration setting requiring user confirmation prior to sending the one or more first tokens to the second computing device, displaying a user confirmation request on a user interface of the first computing device.

[0092] In some embodiments, the memory having instructions stored thereon, which when executed by the one or more processors further cause the processors to perform, in response to determining that one or more second tokens have expired, sending a token refresh request to an identity provider. In some embodiments, the memory having instructions stored thereon, which when executed by the one or more processors further cause the processors to perform receiving, from the identity provider, the one or more first tokens in response to the token refresh request.

[0093] In some embodiments, the memory having instructions stored thereon, which when executed by the one or more processors further cause the processors to perform, in response to determining that a remote application of the first computing device that is related to the user application of the second computing device is not logged in and that a related SSO application of the first computing device is logged in, sending an authorization request to an identity provider. In some embodiments, the remote application and the user application may be a same application type. In some embodiments, the memory having instructions stored thereon, which when executed by the one or more processors further cause the processors to perform receiving an authorization code from the identity provider in response to the authorization request. In some embodiments, the memory having instructions stored thereon, which when executed by the one or more processors further cause the processors to perform returning the authorization code to the identity provider. In some embodiments, the obtaining the one or more first tokens may include, in response to the authorization code being authenticated by the identity provider, receiving the one or more first tokens from the identity provider.

[0094] In some embodiments, the memory having instructions stored thereon, which when executed by the one or more processors further cause the processors to perform, in response to determining that the first computing device does not include a remote application that is a same application type as the user application of the second computing device and that an SSO application of the first computing device associated with an identity provider is not logged in, sending an authorization request associated the user application to the identity provider. In some embodiments, the memory having instructions stored thereon, which when executed by the one or more processors further cause the processors to perform displaying a login user interface associated with the identity provider on a user interface of the first computing device. In some embodiments, the memory having instructions stored thereon, which when executed by the one or more processors further cause the processors to perform receiving a set of credentials based on an interaction with the login user interface. In some embodiments, the memory having instructions stored thereon, which when executed by the one or more processors further cause the processors to perform sending the set of credentials to the identity provider.

[0095] In some embodiments, the memory having instructions stored thereon, which when executed by the one or more processors further cause the processors to perform, in response to the set of credentials being authenticated by the identity provider, receiving an authorization code from the identity provider. In some embodiments, the memory having instructions stored thereon, which when executed by the one or more processors further cause the processors to perform returning the authorization code to the identity provider. In some embodiments, the obtaining the one or more first tokens may include, in response to the authorization code being authenticated by the identity provider, receiving the one or more first tokens from the identity provider when the authorization code is authenticated by the identity provider.

[0096] In some embodiments, the memory having instructions stored thereon, which when executed by the one or more processors further cause the processors to perform, in response to determining that the first computing device does not include a remote application that is a same application type as the user application of the second computing device and that an SSO application associated with an identity provider is logged in, sending an authorization request to the identity provider. In some embodiments, the memory having instructions stored thereon, which when executed by the one or more processors further cause the processors to perform receiving an authorization code from the identity provider. In some embodiments, the memory having instructions stored thereon, which when executed by the one or more processors further cause the processors to perform returning the authorization code to the identity provider. In some embodiments, the obtaining the first one or more tokens may include, in response to the authorization code being authenticated by the identity provider, receiving the one or more first tokens from the identity provider when the authorization code is authenticated by the identity provider.

[0097] In some embodiments, the memory having instructions stored thereon, which when executed by the one or more processors further cause the processors to perform receiving the DSSO policy information based on input to a user interface. In some embodiments, the memory having instructions stored thereon, which when executed by the one or more processors further cause the processors to perform maintaining the DSSO policy information. In some embodiments, the DSSO policy information may indicate a set of applications associated with the DSSO environment.

[0098] According to yet another aspect of the present disclosure, a non-transitory computer-readable medium of a first computing device of a DSSO environment is provided. The non-transitory computer-readable medium having instructions stored thereon, which when executed by one or more processors cause the one or more processors to perform receiving a request for one or more first tokens from a second computing device. The one or more first tokens may be associated with a user application of the second computing device. The non-transitory computer-readable medium having instructions stored thereon, which when executed by one or more processors cause the one or more processors to perform determining whether the user application of the second computing device is associated with the DSSO environment based on DSSO policy information. The non-transitory computer-readable medium having instructions stored thereon, which when executed by one or more processors cause the one or more processors to perform, in response to determining that the user application of the second computing device is associated with the DSSO environment, obtaining the one or more first tokens. The non-transitory computer-readable medium having instructions stored thereon, which when executed by one or more processors cause the one or more processors to perform sending the one or more first tokens to the second computing device to cause the user application of the second computing device to be logged in.

[0099] In some embodiments, the instructions, which when executed by the one or more processors further cause the one or more processors to perform, in response to a configuration setting requiring user confirmation prior to sending the one or more first tokens to the second computing device, displaying a user confirmation request on a user interface of the first computing device.

[0100] In some embodiments, the instructions, which when executed by the one or more processors further cause the one or more processors to perform, in response to determining that one or more second tokens have expired, sending a token refresh request to an identity provider. In some embodiments, the instructions, which when executed by the one or more processors further cause the one or more processors to perform receiving, from the identity provider, the one or more first tokens in response to the token refresh request.

[0101] In some embodiments, the instructions, which when executed by the one or more processors further cause the one or more processors to perform, in response to determining that a remote application of the first computing device that is related to the user application of the second computing device is not logged in and that a related SSO application of the first computing device is logged in, sending an authorization request to an identity provider. In some embodiments, the remote application and the user application may be a same application type. In some embodiments, the instructions, which when executed by the one or more processors further cause the one or more processors to perform receiving an authorization code from the identity provider in response to the authorization request. In some embodiments, the instructions, which when executed by the one or more processors further cause the one or more processors to perform returning the authorization code to the identity provider. In some embodiments, the obtaining the one or more first tokens may include, in response to the authorization code being authenticated by the identity provider, receiving the one or more first tokens from the identity provider.

[0102] The foregoing description of the specific embodiments will so reveal the general nature of the present disclosure that others can, by applying knowledge within the skill of the art, readily modify and/or adapt for various applications such specific embodiments, without undue experimentation, without departing from the general concept of the present disclosure. Therefore, such adaptations and modifications are intended to be within the meaning and range of equivalents of the disclosed embodiments, based on the teaching and guidance presented herein. It is to be understood that the phraseology or terminology herein is for the purpose of description and not of limitation, such that the terminology or phraseology of the present specification is to be interpreted by the skilled artisan in light of the teachings and guidance.

[0103] Embodiments of the present disclosure have been described above with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed.

[0104] The Summary and Abstract sections may set forth one or more but not all exemplary embodiments of the present disclosure as contemplated by the inventor(s), and thus, are not intended to limit the present disclosure and the appended claims in any way.

[0105] Various functional blocks, modules, and steps are disclosed above. The particular arrangements provided are illustrative and without limitation. Accordingly, the functional blocks, modules, and steps may be re-ordered or combined in different ways than in the examples provided above. Likewise, certain embodiments include only a subset of the functional blocks, modules, and steps, and any such subset is permitted.

[0106] The breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims

WHAT IS CLAIMED IS:

1. A method for distributed single sign-on (DSSO), implemented by a first computing device of a DSSO environment, the method comprising: receiving a request for one or more first tokens from a second computing device, the one or more first tokens being associated with a user application of the second computing device; determining whether the user application of the second computing device is associated with the DSSO environment based on DSSO policy information; in response to determining that the user application of the second computing device is associated with the DSSO environment, obtaining the one or more first tokens; and sending the one or more first tokens to the second computing device to cause the user application of the second computing device to be logged in.

2. The method of claim 1, further comprising: in response to a configuration setting requiring user confirmation prior to sending the one or more first tokens to the second computing device, displaying a user confirmation request on a user interface of the first computing device.

3. The method of claim 1, further comprising: in response to determining that one or more second tokens have expired, sending a token refresh request to an identity provider; and receiving, from the identity provider, the one or more first tokens in response to the token refresh request.

4. The method of claim 1, further comprising: in response to determining that a remote application of the first computing device that is related to the user application of the second computing device is not logged in and that a related single sign-on (SSO) application of the first computing device is logged in, sending an authorization request to an identity provider, the remote application and the user application being a same application type; receiving an authorization code from the identity provider in response to the authorization request; and returning the authorization code to the identity provider, wherein the obtaining the one or more first tokens comprises: in response to the authorization code being authenticated by the identity provider, receiving the one or more first tokens from the identity provider.

5. The method of claim 1, further comprising: in response to determining that the first computing device does not include a remote application that is a same application type as the user application of the second computing device and that a single sign-on (SSO) application of the first computing device associated with an identity provider is not logged in, sending an authorization request associated the user application to the identity provider; displaying a login user interface associated with the identity provider on a user interface of the first computing device; receiving a set of credentials based on an interaction with the login user interface; and sending the set of credentials to the identity provider.

6. The method of claim 5, further comprising: in response to the set of credentials being authenticated by the identity provider, receiving an authorization code from the identity provider; and returning the authorization code to the identity provider, wherein the obtaining the one or more first tokens comprises: in response to the authorization code being authenticated by the identity provider, receiving the one or more first tokens from the identity provider when the authorization code is authenticated by the identity provider.

7. The method of claim 1, further comprising: in response to determining that the first computing device does not include a remote application that is a same application type as the user application of the second computing device and that a single sign-on (SSO) application associated with an identity provider is logged in, sending an authorization request to the identity provider; receiving an authorization code from the identity provider; and returning the authorization code to the identity provider, wherein the obtaining the first one or more tokens comprises: in response to the authorization code being authenticated by the identity provider, receiving the one or more first tokens from the identity provider when the authorization code is authenticated by the identity provider.

8. The method of claim 1, further comprising: receiving the DSSO policy information based on input to a user interface; and maintaining the DSSO policy information, wherein the DSSO policy information indicates a set of applications associated with the DSSO environment.

9. An apparatus for a first computing device of a distributed single sign-on (DSSO) environment, comprising: one or more processors; and memory having instructions stored thereon, which when executed by the one or more processors cause the processors to perform: receiving a request for one or more first tokens from a second computing device, the one or more first tokens being associated with a user application of the second computing device; determining whether the user application of the second computing device is associated with the DSSO environment based on DSSO policy information; in response to determining that the user application of the second computing device is associated with the DSSO environment, obtaining the one or more first tokens; and sending the one or more first tokens to the second computing device to cause the user application of the second computing device to be logged in.

10. The apparatus of claim 9, wherein the memory having instructions stored thereon, which when executed by the one or more processors further cause the processors to perform: in response to a configuration setting requiring user confirmation prior to sending the one or more first tokens to the second computing device, displaying a user confirmation request on a user interface of the first computing device.

11. The apparatus of claim 9, wherein the memory having instructions stored thereon, which when executed by the one or more processors further cause the processors to perform: in response to determining that one or more second tokens have expired, sending a token refresh request to an identity provider; and receiving, from the identity provider, the one or more first tokens in response to the token refresh request.

12. The apparatus of claim 9, wherein the memory having instructions stored thereon, which when executed by the one or more processors further cause the processors to perform: in response to determining that a remote application of the first computing device that is related to the user application of the second computing device is not logged in and that a related single sign-on (SSO) application of the first computing device is logged in, sending an authorization request to an identity provider, the remote application and the user application being a same application type; receiving an authorization code from the identity provider in response to the authorization request; and returning the authorization code to the identity provider, wherein the obtaining the one or more first tokens comprises: in response to the authorization code being authenticated by the identity provider, receiving the one or more first tokens from the identity provider.

13. The apparatus of claim 9, wherein the memory having instructions stored thereon, which when executed by the one or more processors further cause the processors to perform: in response to determining that the first computing device does not include a remote application that is a same application type as the user application of the second computing device and that a single sign-on (SSO) application of the first computing device associated with an identity provider is not logged in, sending an authorization request associated the user application to the identity provider; displaying a login user interface associated with the identity provider on a user interface of the first computing device; receiving a set of credentials based on an interaction with the login user interface; and sending the set of credentials to the identity provider.

14. The apparatus of claim 13, wherein the memory having instructions stored thereon, which when executed by the one or more processors further cause the processors to perform: in response to the set of credentials being authenticated by the identity provider, receiving an authorization code from the identity provider; and returning the authorization code to the identity provider, wherein the obtaining the one or more first tokens comprises: in response to the authorization code being authenticated by the identity provider, receiving the one or more first tokens from the identity provider when the authorization code is authenticated by the identity provider.

15. The apparatus of claim 9, wherein the memory having instructions stored thereon, which when executed by the one or more processors further cause the processors to perform: in response to determining that the first computing device does not include a remote application that is a same application type as the user application of the second computing device and that a single sign-on (SSO) application associated with an identity provider is logged in, sending an authorization request to the identity provider; receiving an authorization code from the identity provider; and returning the authorization code to the identity provider, wherein the obtaining the first one or more tokens comprises: in response to the authorization code being authenticated by the identity provider, receiving the one or more first tokens from the identity provider when the authorization code is authenticated by the identity provider.

16. The apparatus of claim 9, wherein the memory having instructions stored thereon, which when executed by the one or more processors further cause the processors to perform: receiving the DSSO policy information based on input to a user interface; and maintaining the DSSO policy information, wherein the DSSO policy information indicates a set of applications associated with the DSSO environment.

17. A non-transitory computer-readable medium of a first computing device of a distributed single sign-on (DSSO) environment, the non-transitory computer-readable medium having instructions stored thereon, which when executed by one or more processors cause the one or more processors to perform: receiving a request for one or more first tokens from a second computing device, the one or more first tokens being associated with a user application of the second computing device; determining whether the user application of the second computing device is associated with the DSSO environment based on DSSO policy information; in response to determining that the user application of the second computing device is associated with the DSSO environment, obtaining the one or more first tokens; and sending the one or more first tokens to the second computing device to cause the user application of the second computing device to be logged in.

18. The non-transitory computer-readable medium of claim 17, wherein the instructions, which when executed by the one or more processors further cause the one or more processors to perform: in response to a configuration setting requiring user confirmation prior to sending the one or more first tokens to the second computing device, displaying a user confirmation request on a user interface of the first computing device.

19. The non-transitory computer-readable medium of claim 17, wherein the instructions, which when executed by the one or more processors further cause the one or more processors to perform: in response to determining that one or more second tokens have expired, sending a token refresh request to an identity provider; and receiving, from the identity provider, the one or more first tokens in response to the token refresh request.

20. The non-transitory computer-readable medium of claim 17, wherein the instructions, which when executed by the one or more processors further cause the one or more processors to perform: in response to determining that a remote application of the first computing device that is related to the user application of the second computing device is not logged in and that a related single sign-on (SSO) application of the first computing device is logged in, sending an authorization request to an identity provider, the remote application and the user application being a same application type; receiving an authorization code from the identity provider in response to the authorization request; and returning the authorization code to the identity provider, wherein the obtaining the one or more first tokens comprises: in response to the authorization code being authenticated by the identity provider, receiving the one or more first tokens from the identity provider.