Web-based authentication for desktop applications

Abstract

In one example, the system includes a web application and a desktop application. The web application acts as an intermediary between the desktop application and an authentication server. The desktop application loads a browser control to navigate an internal browser of the desktop application to the web application, and the web application redirects the internal browser to the authentication server. The desktop application sends user authentication information to the authentication server via the internal browser for authenticating a user of the desktop application. The desktop application receives a cookie in the internal browser that includes an access token for the user of the desktop application. The desktop application sends an authentication request including the access token to a web application programming interface (API) associated with the web application. The desktop application grants access to resources of the desktop application based on the authentication indication received from the web API.

Description

[Technical field]

[0001] Some examples described herein relate to computer applications, and more specifically, to facilitating authentication of users to desktop applications using a web-based authentication server. [Background technology]

[0002] Security Assertion Markup Language (SAML) is an open standard for exchanging authentication data between entities. For example, SAML is often used to authenticate a user in a web application associated with a service provider. A service provider is an entity that provides a service, such as a utility. A service provider is associated with a web application that the service provider's customers can use to verify accounts or employees can use to perform maintenance tasks. When a web application requires user authentication, the web application can communicate with an authentication server of an authentication provider. An authentication provider is an entity that provides authentication services. Using SAML, a web application exchanges communication with an authentication server to authenticate users of the web application. The advantage of using SAML and exchanging messages with an authentication server is that a service provider does not need to implement its own authentication service, and further, it is convenient for users because a given authentication server can be used to authenticate users in multiple web applications. Summary of the Invention

[0003] In one example, a desktop application performs aspects of a method for authenticating a user, whereby while installed and running on a client device, the desktop application identifies a web application configured to act as an intermediary between the desktop application and an authentication server. The desktop application loads a browser control to navigate an internal browser of the desktop application to the web application, which redirects the internal browser to the authentication server. The desktop application, via the internal browser, sends user authentication information to the authentication server for authenticating a user of the desktop application. In the internal browser, the desktop application receives a cookie containing an access token for the user of the desktop application. The desktop application sends an authentication request, including the access token, to a web application programming interface (API) associated with the web application. Based on the authentication indication received from the web API, the desktop application grants access to resources of the desktop application.

[0004] In another example, a web application performs aspects of a method for authenticating a user. According to the method, the web application receives a connection from an internal browser executed in a desktop application on a client device. The web application redirects the internal browser of the desktop application to an authentication server, the web application acting as an intermediary between the desktop application and the authentication server. The web application receives an indication in the desktop application of successful authentication of the user to the authentication server. In this manner, the web application returns a cookie to the internal browser of the desktop application that includes an access token that confirms authentication of the user of the desktop application. A web API associated with the web application receives an authentication setup request from the desktop application that includes the access token, and the web API authenticates the user to the desktop application based on the access token.

[0005] In yet another example, a system configured to authenticate a user to a desktop application includes a web application and the desktop application. The web application is configured to act as an intermediary between the desktop application and an authentication server for authenticating a user of the desktop application. The desktop application identifies the web application as an intermediary between the desktop application and the authentication server. The desktop application loads a browser control to navigate an internal browser of the desktop application to the web application, and the web application redirects the internal browser to the authentication server. The desktop application sends user authentication information to the authentication server via the internal browser for authenticating a user of the desktop application. In the internal browser, the desktop application receives a cookie including an access token for the user of the desktop application. The desktop application sends an authentication request including the access token to a web API associated with the web application. The desktop application grants access to a resource of the desktop application based on the authentication indication received from the web API.

[0006] These exemplary aspects and features are not described to limit or define the described subject matter, but are provided to provide examples to aid in understanding the concepts described herein. Other aspects, advantages, and features of the presently described subject matter will become apparent after consideration of the entire application. [Brief description of the drawings]

[0007] These and other features, aspects, and advantages of the present disclosure will become better understood from the following detailed description when taken in conjunction with the accompanying drawings. [Figure 1]FIG. 2 is a diagram of an authentication system for authenticating a user to a desktop application according to some examples described herein. [Diagram 2] FIG. 2 is a flow diagram of a method for authenticating a user to a desktop application according to some examples described herein. [Diagram 3] FIG. 2 is a flow diagram of a method for authenticating a user to a desktop application in an offline mode according to some examples described herein. [Figure 4] FIG. 1 illustrates an example of a computing system capable of performing certain operations described herein. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] Although the Security Assessment Markup Language (SAML) offers convenience for both service providers and end users, a significant drawback of SAML is that it is generally limited to use in web applications. Many web applications support SAML by building the necessary configuration into their code to communicate in SAML. In contrast, desktop applications are not typically designed to use SAML, so existing desktop applications that may use an authentication provider for authentication must be updated with the appropriate configuration to use SAML. Without such configuration, many desktop applications are severely limited in terms of authentication options.

[0009] However, some examples described herein use an authentication provider to facilitate authentication of a user to a desktop application. For example, the desktop application may communicate with a web application using a browser control, and the web application may communicate with an authentication server on behalf of the desktop application using SAML. Additionally, in some implementations, a web application programming interface (API) associated with the web application may generate a temporary password that allows authentication of the user in offline mode. As a result, the desktop application may authenticate the user via SAML in combination with an authentication server in both online and offline modes. A further advantage of some implementations is extensibility, where the desktop application may be configured to use different authentication technologies or different authentication providers, simply by being directed to another web application configured to facilitate the desired authentication.

[0010] FIG. 1 is a diagram of an authentication system 100 according to some examples described herein. The authentication system 100 includes a desktop application 110, an authentication server 120, a web API 130, and a web application 140 associated with the web API 130, each of which is connected to a network 150. The desktop application 110, the authentication server 120, the web API 130, and the web application 140 may communicate with each other as needed or as described herein to enable the desktop application 110 to authenticate users. The authentication system 100 may communicate with the authentication server 120 using SAML to enable the desktop application 110 to authenticate users of the desktop application 110. In some examples, the desktop application is not configured to support SAML. However, the web application 140 may act as an intermediary between the desktop application 110 and the authentication server 120 to facilitate the authentication.

[0011] The desktop application 110 may be installed on a client device 160, which may be a computing device such as a desktop computer, a notebook computer, a tablet, or a smartphone. The desktop application 110 may be a software program, or a portion of a software program, executable by a processor of the client device 160 such that the desktop application 110 runs on the client device 160. For example, the desktop application 110 may be a thick client application.

[0012] In some embodiments, the desktop application 110 is associated with a service provider. For example, the service provider is a utility provider and the desktop application 110 is a program used by the utility provider's field technicians to manage and track maintenance of utility meters. However, various other types of desktop applications 110 are within the scope of this disclosure. The desktop application 110 may require user authentication so that the desktop application's resources 170, such as data or services provided by the desktop application 110, are inaccessible to the user until the user authenticates himself or herself to the desktop application 110.

[0013] In some examples, the desktop application 110 is configured to execute a browser control 180 to provide an internal browser 190 to the desktop application 110. For example, the browser control 180 can provide controls such as navigation controls that enable web browsing functionality of the internal browser 190 within the desktop application 110. In other words, the browser control 180 can be a browser wrapper for the desktop application 110. Because the internal browser 190 is part of the desktop application 110, in some examples, the internal browser 190 does not have the necessary configuration to support SAML. Thus, in some examples, the internal browser 190 cannot directly communicate with the authentication server 120 to authenticate a user. However, as described herein, the internal browser 190 can communicate with the web application 140 to facilitate user authentication.

[0014] The authentication server 120 may be configured to authenticate a user by verifying the identity of the user. More specifically, the authentication server 120 may authenticate that the identity of the user matches the identity of the user associated with a user account on the authentication server 120 based on the user authentication information entered by the user. The authentication server 120 may be a server associated with an authentication provider. The authentication provider may verify the identity of the user through the authentication server 120 and authenticate the user for various applications. These applications may be web applications, desktop applications, or a combination of both. The authentication server 120 may be implemented as hardware, software, or a combination of both. The authentication server 120 may be implemented in a computing device or distributed across two or more computing devices. For example, the authentication server 120 may be implemented as program code running on one or more processors of one or more computing devices. In some examples, the authentication server 120 operates in the cloud and is accessible via the Internet.

[0015] Data store 125 includes or may have information about users who have user accounts on authentication server 120. Data store 125 may be one or more databases, database tables, text files, or other storage objects stored in a storage device of authentication server 120. For example, each user account may be represented as a row in a table in data store 125. In some examples, the user accounts include user data for the respective users, including authentication data used to authenticate the users associated with the user accounts.

[0016] For example, the authentication data for a user's user account includes a user identifier and a password. The user identifier may uniquely identify the user. For example, the user identifier may be an email address, a password, a phone number, an Internet Protocol (IP) address, a Media Access Control (MAC) address, or other data. The password may be stored in the data store 125 in an encrypted, hashed, or otherwise obscured form. In some examples, such as when the authentication server 120 supports biometric data, the authentication data for a user account may additionally or alternatively include a hashed or otherwise obscured representation of the user's biometric factors. When a user account is initially established or updated, the authentication server 120 may receive authentication data, such as by manual entry by a user or administrator. The authentication server 120 may persist this authentication data in the data store 125 and use it to authenticate the user as described herein.

[0017] The authentication server 120 may be configured to communicate with the application using SAML. In some examples, the authentication server 120 may not be able to directly communicate for authentication purposes with a particular desktop application or web application that does not support SAML. Furthermore, in some examples, the desktop application 110 described herein need not support SAML. The web application 140 may manage authentication of a user of the desktop application 110 by communicating with the desktop application 110 and further communicating with the authentication server 120 using SAML. Although this disclosure makes repeated references to the use of SAML specifically, in various examples, other security communication protocols may be used. Thus, the examples described herein are not limited to SAML as a security communication protocol for the authentication server 120, and rather, references herein to SAML specifically are made for purposes of illustration only.

[0018] The web application 140 may be configured to act as an intermediary between the desktop application 110 and the authentication server 120 to authenticate users of the desktop application 110. In some examples, the web application 140 is implemented as hardware, software, or a combination of both. For example, the web application 140 is implemented as program code stored on a storage device and executable by one or more processors. The web application 140 may operate on-premise, e.g., at a site associated with a service provider associated with the desktop application 110, or may operate in the cloud. In some examples, the web application 140 is configured to communicate with the authentication server 120 using SAML. For example, the program code of the web application 140 includes instructions to parse and construct SAML statements. In this manner, the web application 140 is configured to exchange messages with the authentication server 120 for authentication purposes.

[0019] In some examples, the web API 130 is an application programming interface exposed to the desktop application 110. The web API 130 may operate as an interface through which the desktop application 110 performs certain interactions with the web application 140 or other resources on the web. In some examples, the web API 130 is implemented as hardware, software, or a combination of both. The web API 130 may operate on-premise, for example at a site associated with a service provider associated with the desktop application 110, or may operate in the cloud. In some examples, the web API 130 is integrated with the web application 140 or the web API 130 runs on the same computing device or devices as the web application 140. However, in addition or instead, the web API 130 may run on a device separate from the web application 140 and communicate with the web application 140 via the network 150 or other means.

[0020] In some examples, each of the web application 140, the web API 130, and the authentication server 120 can facilitate authentication of multiple desktop applications. In that case, each desktop application configured to use the authentication system 100 described herein can access the web API 130 and the web application 140 and may perform operations similar to those performed by the desktop application 110 described herein. Thus, although the present disclosure repeatedly refers, in the singular, to operations involving the desktop application 110, the authentication system 100 can authenticate users of the various desktop applications 110, and such authentication may occur in parallel such that the web application 140, the web API 130, and the authentication server 120 can facilitate authentication of multiple desktop applications 110 at a given time.

[0021] In some examples, desktop application 110, web application 140, web API 130, and authentication server 120 communicate with each other via network 150. Network 150 may be a combination of one or more local area networks or wide area networks using wired communication systems, wireless communication systems, or a combination thereof. Each of client device 160, web application 140, web API 130, and authentication server 120 may directly or indirectly access network 150 via a respective network interface device.

[0022] 2 is a flow diagram of a method 200 for authenticating a user to a desktop application 110 according to some examples described herein. In some examples, components of authentication system 100 perform this method 200 or a similar method when desktop application 110 launches on client device 160. In FIG. 2, the flow diagram is divided into four vertical regions along the horizontal axis, with each region representing an operation performed by a corresponding component of authentication system 100. However, the assignment of operations to specific components is provided for illustrative purposes only and does not limit the various possible implementations of authentication system 100.

[0023] The method 200 shown in Figure 2 may be implemented in software executed by one or more processors of a computer system, in hardware, or in a combination of software and hardware. The method 200 shown in Figure 2 and described below is intended to be exemplary and non-limiting. Although Figure 2 depicts various process operations occurring in a particular order, this is not intended to be limiting. In certain alternatives, the processes may be performed in a different order, some operations may be eliminated or added, or some operations may be performed in parallel.

[0024] Before block 205, the desktop application 110 may determine whether the web API 130, which is necessary for online authentication in some examples, is reachable. For example, the desktop application 110 may not be able to reach the web API 130 when the client device 160 on which the desktop application 110 is running is not connected to the network 150, or when the desktop application 110 does not have network access otherwise. If the desktop application 110 is not able to reach the web API 130, the desktop application may perform the method 300 for authentication in an offline mode, such as the method 300 described in FIG. 3. However, if the desktop application 110 is able to reach the web API 130, the desktop application 110 may perform the method 200 in an online mode.

[0025] 2, in block 205, the desktop application 110 identifies a web application 140 configured to act as an intermediary between the desktop application 110 and the authentication server 120. To this end, the desktop application 110 may request authentication settings necessary for authentication. For example, the desktop application 110 may request such authentication settings from the web API 130. In response to the request, the web API 130 may return the authentication settings.

[0026] The authentication configuration can identify the web application 140 to the desktop application 110. In some examples, the authentication configuration explicitly provides a location, such as a uniform resource locator (URL) or IP address, of the web application 140 to be used for authentication. Additionally or alternatively, in some examples, the desktop application 110 maintains a mapping of security communication protocols to web applications, and the desktop application 110 knows the location of such web applications. In that case, the authentication configuration can indicate a security communication protocol, such as SAML, and the desktop application 110 can map the security communication protocol to the location of the web application 140. Various implementations are possible and are within the scope of this disclosure.

[0027] In block 210, the desktop application 110 loads the browser control 180 to navigate the desktop application's 110 internal browser 190 to the web application 140 identified in block 205. In block 215, the web application 140 may redirect the desktop application's 110 internal browser 190 to the authentication server 120. In some examples, the web application 140 includes program code that indicates the location, such as a URL or IP address, of the authentication server 120 so that the web application 140 can redirect the internal browser 190 to that location.

[0028] In block 220, the authentication server 120 receives a connection from the internal browser 190 of the desktop application 110. Specifically, the connection may be the result of the internal browser 190 being redirected by the web application 140 to the authentication server 120. Then, in block 225, the authentication server 120 sends a prompt to the internal browser 190 of the desktop application 110 to provide user authentication information. In some examples, the prompt is displayed to the user via the internal browser of the desktop application 110, and the user enters the user's authentication information into the internal browser 190.

[0029] At block 230, the desktop application 110, via the internal browser 190, sends the user authentication information to the authentication server 120. At block 235, the authentication server 120 receives the user authentication information and verifies the user's identity. More specifically, the authentication server 120 may verify that the received user authentication information matches authentication data for the user account stored in the data store 125 of the authentication server 120. However, if the user authentication information does not match the authentication data stored in the data store 125, the authentication server 120 may re-prompt for the user authentication information or indicate that the authentication failed.

[0030] If the user authentication information is valid (i.e., matches the authentication data of the user account), in block 240, the authentication server 120 redirects the internal browser 190 to the web application 140. Then, in block 245, the web application 140 generates a cookie (e.g., a block of data) that includes the access token and sends the cookie to the desktop application's internal browser 190. In some examples, the access token is encrypted so that the access token cannot be stolen and used to access the desktop application 110 by another user. The access token may be or include identification data that verifies the authentication and uniquely identifies a session between the user and the desktop application 110. For example, the access token may include a random string that is unique to the session. Traditionally, after authenticating a user to a web application, the web browser combines communications from the client side with metadata, including the access token, to verify the authenticity of such communications. However, in some examples, as described further below, the access token is utilized by the desktop application 110 without any additional interaction of the internal browser 190 (e.g., after the internal browser 190 is closed).

[0031] At block 250, the desktop application 110 saves the cookie locally. In some examples, the desktop application 110 may then close the internal browser 190. At block 255, the desktop application 110 sends an authentication request to the web API 130. In some examples, the desktop application 110 sends an access token, which may be encrypted, to the web API 130 as part of the authentication request.

[0032] At block 260, the web API 130 receives the authentication request including the access token. The web API 130 may be configured to authenticate the access token, for example, by verifying the authenticity of the access token. Additionally, the web API 130 may maintain or have access to a mapping of permissions to users for the desktop application 110. Given the access token including a user identifier that identifies the user, the web API 130 authenticates the access token and determines the permissions associated with the user. At block 265, the web API 130 sends an authentication notification to the desktop application 110 indicating that the user has been authenticated with the particular permissions. The authentication notification may indicate the particular permissions applicable to the user with respect to the desktop application 110, such as resources 170 that the user is authorized to read and resources 170 that the user is authorized to write.

[0033] In block 270, the web API 130 generates a temporary password for the user of the desktop application 110 and sends a representation of the temporary password, such as a hash of the temporary password, to the desktop application. In block 275, the web API 130 sends the temporary password, such as by email, to the user so that the user has the temporary password. As described in more detail below, the temporary password allows the user to log into the desktop application 110 in offline mode.

[0034] At block 280, the desktop application 110 receives the authentication notification and the representation of the temporary password. The desktop application may locally store the representation of the temporary password. In some examples, the client device 160 includes a secure storage device, such as an encrypted drive, and the desktop application 110 causes the client device 160 to store the representation of the temporary password in the secure storage device.

[0035] In block 285, the desktop application 110 allows the user to access the resource 170 according to the specific permissions indicated in the authentication notification received in block 280. For example, the desktop application 110 displays a user interface that allows the user to access the resource 170 or perform other activities available via the desktop application 110 with the specific permissions provided, which in some examples initiates a session between the user and the desktop application 110.

[0036] Generally, in some instances, a session is a limited period of time during which a user interacts with the desktop application 110 without re-authenticating. The desktop application may then terminate the session, for example, in response to the user logging out or automatically after a period of user inactivity. After the session ends, the user may need to re-authenticate to access resources 170 of the desktop application 110 again, either as described above or using a temporary password.

[0037] In some examples, the aforementioned communications occurring between desktop application 110, web API 130, and web application 140 may be transparent to the user. For example, the user opens desktop application 110, sees a prompt for user credentials, enters the user credentials, receives an email with a temporary password for offline login, and is granted access to resource 170. The user need not be aware of the various other actions involved in method 200 of authentication.

[0038] As mentioned above, the desktop application 110 can provide or restrict access to resources 170, such as certain data or services. In some cases, a user may need access to resources 170 where the desktop application 110 cannot reach the web API 130 over the network 150. For example, the desktop application 110 may not always have access to a network. In one example, the client device 160 is a mobile device and the user, a field technician, requires use of the desktop application 110 when out in the field. In this example, the resource 170 accessible to the desktop application 110 may be information regarding an activity required to be performed by the field technician. However, network access may not always be available to the desktop application 110 when operating in the field.

[0039] Some examples of desktop application 110 utilize temporary passwords, as described above with reference to blocks 270-280, to facilitate user authentication in offline mode. Each temporary password may be associated with an expiration time. Before the expiration time, the temporary password remains valid for authentication in offline mode. However, once the password expiration time is reached, the temporary password expires and becomes invalid and can no longer be used for authentication.

[0040] 3 is a flow diagram of a method 300 for authenticating a user to a desktop application 110 in an offline mode, according to some examples described herein. In some examples, the desktop application 110 executes this method 300 or a similar method when the desktop application 110 launches on the client device 160 and detects that the web API 130 is unreachable. The desktop application 110 may then proceed to this method 300 for authentication in an offline mode.

[0041] The method 300 shown in Figure 3 may be implemented in software executed by one or more processors of a computer system, in hardware, or in a combination of software and hardware. The method 300 shown in Figure 3 and described below is intended to be exemplary and non-limiting. Although Figure 3 depicts various process operations occurring in a particular order, this is not intended to be limiting. In certain alternatives, the processes may be performed in a different order, some operations may be eliminated or added, or some operations may be performed in parallel.

[0042] 3, in block 305, the desktop application 110 prompts the user for user credentials. For example, the desktop application presents the user with a user interface that includes an input element in which the user types and submits or otherwise enters the user credentials. In some examples, the user credentials include a user identifier and a password. In block 310, the desktop application 110 receives the user credentials entered by the user in response to the prompt.

[0043] In decision block 315, the desktop application 110 determines whether a temporary password associated with the user (e.g., associated with the entered user identifier) ​​is stored on the client device 160 and is valid for offline authentication. For example, if the temporary password has not yet expired, the temporary password may be considered valid, and after expiration, the temporary password may be considered invalid. If no such valid temporary password is found, the authentication fails in block 320. The desktop application 110 may present a notification, such as via a user interface, that authentication in offline mode is unavailable or has failed. In that case, the desktop application 110 may limit or prohibit access to resources 170 available via the desktop application 110.

[0044] However, if at least one valid temporary password is found for the user on the client device 160, then in decision block 325 the desktop application 110 compares the temporary password to the password entered by the user as part of the user credentials. As mentioned above, the client device 160 may store a hash of the temporary password rather than the temporary password itself. In that case, the desktop application 110 may hash the password received in block 310 and compare the hash to the hash of the temporary password to determine whether the received password and the temporary password match.

[0045] If the received password does not match the temporary password, authentication fails at block 330 because the received user credentials are invalid. In this case, the desktop application 110 may indicate, such as via a user interface, that authentication failed. The desktop application 110 may limit or prohibit access to resources 170 available via the desktop application 110 until the user enters valid user credentials. In some examples, the desktop application 110 may allow the user one or more additional attempts to provide valid user credentials.

[0046] However, if the password received in block 310 matches the temporary password associated with the user, then in block 335 the desktop application 110 considers the user to be authenticated and may then allow the user to use the desktop application 110 to access resources 170 or perform other activities.

[0047] Figure 4 is a diagram of an example computing system 400 capable of performing certain operations described herein. For example, a computing system 400 similar to that shown in Figure 4 may be a client device 160 configured to run a desktop application 110, the computing system 400 may run a web application 140 and a web API 130, or the computing system 400 may be or run an authentication server 120. A variety of suitable computing systems or computing systems may be used to perform the operations described herein.

[0048] 4 illustrates an example computing system 400 operating as a client device 160 and executing desktop application 110. The illustrated example computing system 400 includes a processor 402 communicatively coupled to one or more memory devices 404. The processor 402 executes computer-executable program code stored in the memory devices 404. Examples of the processor 402 include a microprocessor, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other suitable processing device. The processor 402 may include one or more processing units.

[0049] The storage device 404 includes suitable non-transitory computer readable media for storing data, program code, or both. The computer readable media may include electronic, optical, magnetic, or other storage devices capable of providing computer readable instructions or other program code to a processor. Non-limiting examples of computer readable media include magnetic disks, memory chips, read only memory (ROM), random access memory (RAM), optical storage devices, magnetic tape or other magnetic storage devices, or other media from which a processor can read instructions.

[0050] In some examples, the computing system 400 executes program code that configures the processor 402 to perform one or more operations described herein. The program code includes, for example, instructions for implementing the desktop application 110 or other suitable system that performs one or more operations described herein. The program code may reside in the memory device 404 or a suitable computer-readable medium and may be executed by the processor 402 or another suitable processor. Although not shown in FIG. 4, the memory device 404 of the same or a different computing system 400 may include program code for the web application 140 or the web API 130, or both.

[0051] Computing system 400 may include one or more external or internal devices, such as input devices or output devices. For example, computing system 400 is shown with one or more input / output ("I / O") interfaces 408. One or more buses 406 are also included in computing system 400. Bus 406 communicatively couples one or more components of computing system 400.

[0052] An example of a computing system 400 includes a network interface device 410. The network interface device 410 includes one or more devices suitable for establishing a wired or wireless data connection to one or more data networks, such as the network 150. Non-limiting examples of the network interface device 410 include an Ethernet network adapter or a Wireless Fidelity (WiFi) card. The computing system 400 can use the network interface device 410 to communicate with one or more other computing devices over a data network. For example, a computing system 400 running a desktop application 110 can use the network interface device 410 to communicate with a web application 140 and a web API 130 over the network 150.

[0053] Numerous specific details have been set forth herein to provide a thorough understanding of the claimed subject matter. However, those skilled in the art will understand that the claimed subject matter may be practiced without these specific details. In other instances, methods, apparatus, or systems that would be known to those skilled in the art have not been described in detail so as not to obscure the claimed subject matter.

[0054] The features discussed herein are not limited to a particular hardware architecture or configuration. A computing device may include any suitable arrangement of components that provide a result conditional on one or more inputs. Suitable computing devices include general-purpose microprocessor-based computer systems that access stored software (i.e., computer-readable instructions stored on the computer system's memory) that programs or configures the computing system from a general-purpose computing device to a special-purpose computing device that implements one or more aspects of the present subject matter. In the software used to program or configure a computing device, any suitable programming, scripting, or other type of language or combination of languages ​​may be used to implement the teachings contained herein.

[0055] Aspects of the methods disclosed herein may be implemented in the operation of such a computing device. For example, the blocks may be reordered, combined, and / or divided into sub-blocks. Certain blocks or processes may be performed in parallel.

[0056] The use of "adapted to" or "configured to" herein means open and inclusive language that does not exclude devices adapted or configured to perform additional tasks or steps. Additionally, the use of "based on" means open and inclusive in that a process, step, calculation, or other operation "based on" one or more of the aforementioned conditions or values ​​may in fact be based on additional conditions or values ​​beyond those previously stated. The headings, lists, and numbering contained herein are for ease of description only and are not meant to be limiting.

[0057] Although the present subject matter has been described in detail with respect to certain embodiments thereof, it will be appreciated that those skilled in the art, upon gaining the foregoing understanding, may readily produce modifications, variations, and equivalents to such embodiments. Accordingly, it should be understood that the present disclosure has been presented for purposes of illustration and not limitation, and is not intended to exclude the inclusion of modifications, variations, and / or additions to the present subject matter as would be readily apparent to one of ordinary skill in the art.

Claims

1. identifying, by a desktop application installed and executed on a client device, a web application configured to act as an intermediary between said desktop application and an authentication server; loading, by the desktop application, a browser control to navigate an internal browser of the desktop application to the web application, the web application redirecting the internal browser to the authentication server; sending, by the desktop application via the internal browser, user authentication information to the authentication server for authenticating a user of the desktop application; receiving, at the internal browser of the desktop application, a cookie that includes an access token for the user of the desktop application; sending, by the desktop application, an authentication request including the access token to a web application programming interface (API) associated with the web application; granting access to resources of the desktop application based on an authorization indication received from the web API; The method includes:

2. receiving, by the desktop application, a hash of the temporary password generated by the web API; storing a hash of the temporary password on the client device to enable offline authentication of the user to the desktop application; The method of claim 1 further comprising:

3. terminating the session between the user and the desktop application; receiving an entered password in the desktop application; granting the desktop application access to the resource based on matching the entered password with a hash of the temporary password generated by the web API; The method of claim 2 further comprising:

4. The step of identifying a web application includes: requesting the web API to provide relevant settings to the authentication server for authenticating the user of a desktop application installed and executed on the client device; receiving, by the desktop application, from the web API, an indication of the web application acting as an intermediary between the desktop application and the authentication server; The method of claim 1 further comprising:

5. receiving, by the desktop application, an indication of a security communication protocol for communicating with the authentication server; identifying the web application as having the capability to use the secure communication protocol; The method of claim 4 further comprising:

6. receiving, by the desktop application, an indication that Security Assertion Markup Language (SAML) is being used to communicate with the authentication server; identifying the web application as having the capability to use SAML to communicate with the authentication server; The method of claim 4 further comprising:

7. receiving, in a web application, a connection from an internal browser executed in a desktop application on a client device; redirecting, by the web application, the internal browser of the desktop application to an authentication server, the web application acting as an intermediary between the desktop application and the authentication server; receiving, by the web application, an indication of successful authentication of the user at the desktop application to the authentication server; returning, by the web application, a cookie to the internal browser of the desktop application, the cookie including an access token confirming authentication of the user of the desktop application; receiving an authentication request from the desktop application, the authentication request including the access token; authenticating the user to the desktop application based on the access token; The method includes:

8. generating a temporary password for an offline mode of the desktop application; sending a hash of the temporary password to the desktop application to enable offline authentication of the user to the desktop application; The method of claim 7 further comprising:

9. receiving an authentication configuration request from the desktop application via a web application programming interface (API) associated with the web application; sending an indication of the web application to the desktop application in response to the authentication configuration request; The method of claim 7 further comprising:

10. The method of claim 7 , further comprising the step of the web application communicating with the authentication server on behalf of the desktop application using a Security Assertion Markup Language.

11. a web application configured to act as an intermediary between a plurality of desktop applications and an authentication server for authenticating users of the plurality of desktop applications; Desktop applications and A system comprising: The desktop application includes: Identifying the web application as an intermediary between the desktop application and the authentication server; Loading a browser control to navigate the desktop application's internal browser to the web application, which redirects the internal browser to the authentication server; Sending user authentication information to the authentication server via the internal browser for authenticating a user of the desktop application; receiving, at the internal browser, a cookie including an access token for the user of the desktop application; Sending an authentication request, including the access token, to a web application programming interface (API) associated with the web application; granting access to resources of the desktop application based on an indication of authentication received from the web API; It was configured as follows: system.

12. the web application is further configured to facilitate authentication of the user to a second desktop application; the second desktop application is different from the desktop application; The system of claim 11.

13. The web API includes: generating a temporary password to enable offline authentication of the user to the desktop application; Sending the hash of the temporary password to the desktop application The system of claim 11 further configured to:

14. The desktop application includes: receiving a hash of the temporary password generated by the web API; Storing a hash of the temporary password on a client device executing the desktop application to enable offline authentication of the user to the desktop application. The system of claim 13 further configured to:

15. The desktop application includes: terminating the session between the user and the desktop application; Receives the entered password, granting access to the resource based on matching the entered password with a hash of the temporary password generated by the web API; The system of claim 14 further configured to:

16. To identify the web application as an intermediary between the desktop application and the authentication server, the desktop application: Requesting the web API to provide settings associated with the authentication server; Receive instructions for the web application from the web API. The system of claim 11 further configured to:

17. The desktop application includes: receiving instructions for a security communication protocol for communicating with the authentication server; Identifying the web application as having the capability to use the secure communication protocol The system of claim 11 further configured to:

18. The desktop application includes: receiving instructions in a security communications protocol (SAML) for communicating with the authentication server; Identifying the web application as having the ability to use SAML The system of claim 11 further configured to:

19. 20. The system of claim 18, wherein the web application is further configured to communicate with the authentication server on behalf of the desktop application using SAML.

20. 20. The system of claim 19, wherein the desktop application does not have the ability to communicate with SAML.

Images