Web-based authentication for desktop applications

In one implementation, a system includes a web application and a desktop application, where the web application acts as an intermediary between the desktop application and an identity 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 identity server. The desktop application submits, via the internal browser, user credentials to authenticate a user of the desktop application to the identity server. The desktop application receives, at the internal browser, a cookie including an access token for the user of the desktop application. The desktop application transmits, to a web application programming interface (API) associated with the web application, an authentication request including the access token. The desktop application grants access to a resource of the desktop application based on an indication of authentication received from the web API.

TECHNICAL FIELD

Some implementations described herein relate to computer applications and, more specifically, to facilitating authentication of users to desktop applications using a web-based identity server.

BACKGROUND

Security Assertion Markup Language (SAML) is an open standard for exchanging authentication data between entities. For instance, SAML is often used to authenticate users to web applications associated with service providers. A service provider is an entity that provides a service, such as a utility. A service provider can be associated with a web application, such as one useable by a customer of the service provider to check an account or useable by an employee to perform maintenance tasks. If the web application requires user authentication, then the web application can communicate with an identity server of an identity provider. An identity provider is an entity that provides an authentication service. Using SAML, the web application exchanges communications with the identity server to authenticate a user of the web application. A benefit of using SAML, and thus being able to exchange messages with the identity server, is that the service provider need not implement its own authentication service, and additionally, a given identity server can be used to authenticate users to multiple web applications, which is convenient for users.

SUMMARY

In one implementation, a desktop application performs aspects of a method for authenticating a user. According to the method, 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 identity 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 identity server. The desktop application submits, via the internal browser, user credentials to authenticate a user of the desktop application to the identity server. At its internal browser, the desktop application receives a cookie including an access token for the user of the desktop application. The desktop application transmits, to a web application programming interface (API) associated with the web application, an authentication request including the access token. Based on an indication of authentication received from the web API, the desktop application grants access to a resource of the desktop application.

In another implementation, 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 running in a desktop application of a client device. The web application redirects the internal browser of the desktop application to an identity server, and the web application acts as an intermediary between the desktop application and the identity server. The web application receives an indication of successful authentication to the identity server of a user at the desktop application. As such, the web application returns, to the internal browser of the desktop application, a cookie including an access token confirming authorization of the user at the desktop application. A web API associated with the web application receives, from the desktop application, an authentication request comprising the access token, and the web API authenticates the user to the desktop application, based on the access token.

In yet another implementation, a system configured to authenticate users to desktop applications includes a web application and a desktop application. The web application is configured to act as an intermediary between desktop applications and an identity server for authenticating users of the desktop applications. The desktop application identifies the web application as the intermediary between the desktop application and the identity 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 identity server. The desktop application submits, via the internal browser, user credentials to authenticate a user of the desktop application to the identity server. The desktop application receives, at the internal browser, a cookie including an access token for the user of the desktop application. The desktop application transmits, to a web API associated with the web application, an authentication request including the access token. The desktop application grants access to a resource of the desktop application based on an indication of authentication received from the web API.

These illustrative aspects and features are mentioned not to limit or define the presently described subject matter, but to provide examples to aid understanding of the concepts described in this application. Other aspects, advantages, and features of the presently described subject matter will become apparent after review of the entire application.

DETAILED DESCRIPTION

Although Security Assessment Markup Language (SAML) provides convenience for both service providers and end users, a significant drawback of SAML is that it is typically limited to use with web applications. Many web applications support SAML by incorporating, into their code, configurations required for communications in SAML. In contrast, desktop applications are not typically designed to use SAML, so each existing desktop application that could potentially use an identity provider for authentication would need to be updated with proper configurations in order to utilize SAML. Without such configurations, many desktop applications are severely limited in terms of their authentication options.

Some implementations described herein, however, facilitate authentication of users to desktop applications using an identity provider. For instance, a desktop application can utilize a browser control to communicate with a web application, such that the web application communicates with an identity server, using SAML, on behalf of the desktop application. Further, in some implementations, a web application programming interface (API) associated with the web application can generate a temporary password to enable authentication of the user in offline mode. As a result, the desktop application can authenticate a user, through SAML in combination with an identity server, in both online mode and offline mode. A further benefit of some implementations is extensibility, in that the desktop application could be configured to use a different authentication technique or a different identity provider simply by being directed to a different web application configured to facilitate the authentication desired.

FIG.1is a diagram of an authentication system100, according to some implementations described herein. The authentication system100may include a desktop application110, an identity server120, a web API130, and a web application140associated with the web API130, each of which may be connected to a network150. The desktop application110, the identity server120, the web API130, and the web application140may communicate with one another as needed or as described herein to enable the desktop application110to authenticate a user. The authentication system100may enable the desktop application110to authenticate a user of the desktop application110, through the use of SAML to communicate with an identity server120. In some implementations, the desktop application is not configured to support SAML. However, the web application140may act as an intermediary between the desktop application110and the identity server120to facilitate the authentication.

The desktop application110may be installed on a client device160, which may be a computing device such as a desktop computer, notebook computer, tablet, or smartphone. The desktop application110may be a software program, or portion of a software program, executable by a processor of the client device160such that the desktop application110runs on the client device160. For instance, the desktop application110is a thick client application.

In some implementations, the desktop application110is associated with a service provider. For instance, the service provider is a utility provider, and the desktop application110is a program used by field technicians of the utility provider to manage and track maintenance of utility meters. However, various other types of desktop applications110are within the scope of this disclosure. The desktop application110may require user authentication such that a resource170of the desktop application, such as data or a service provided by the desktop application110, is not accessible to a user until the user authenticates himself to the desktop application110.

In some implementations, the desktop application110is configured to execute a browser control180to provide an internal browser190in the desktop application110. For instance, the browser control180may provide controls, such as navigation controls, that enable web browsing functionality of the internal browser190in the desktop application110. In other words, the browser control180may be a browser wrapper for the desktop application110. Because the internal browser190is part of the desktop application110, in some implementations, the internal browser190does not have the configurations needed to support SAML. Thus, in some implementations, the internal browser190is not capable of communicating directly with the identity server120to authenticate a user. However, as described herein, the internal browser190can communicate with the web application140to facilitate user authentication.

The identity server120may be configured to authenticate users by verifying the identities of users. More specifically, the identity server120can authenticate that a user's identity, based on user credentials entered by the user, matches the identity of a user associated with a user account on the identity server120. The identity server120may be a server associated with an identity provider. Through the identity server120, the identity provider may confirm the identity of users and may thus authenticate users to various applications. Those applications may be web applications, desktop applications, or a combination of both. The identity server120may be implemented as hardware, software, or a combination of both. The identity server120may be implemented on a computing device or distributed across two or more computing devices. For instance, the identity server120may be implemented as program code executed on one or more processors of one or more computing devices. In some implementations, the identity server120operates in a cloud and is accessible over the internet.

The identity server120may include or have access to a datastore125, which maintains information about users having user accounts with the identity server120. The datastore125may be one or more databases, database tables, text files, or other storage objects stored in a storage device of the identity server120. For instance, each user account may be represented as a table row in the datastore125. In some implementations, a user account includes user data related to a respective user, where that user data includes authentication data used to authenticate the user associated with the user account.

For instance, the authentication data in a user account of a user may include a user identifier and a password. The user identifier may uniquely identify the user; for instance, the user identifier is an email address, password, phone number, Internet Protocol (IP) address, media access control (MAC) address, or other data. The password may be stored in the datastore125in a form that is encrypted, hashed, or otherwise concealed. In some implementations, such as if the identity server120supports biometric data, the authentication data in the user account may additionally or alternatively include a representation of a biometric factor, which may be hashed or otherwise concealed, of the user. When the user account is initially established or updated, the identity server120may receive the authentication data, such as through manual entry by the user or an administrator. The identity server120may then maintain this authentication data in the datastore125for use in authenticating the user as described herein.

The identity server120may be configured to communicate with applications using SAML. In some implementations, the identity server120is not capable of communicating directly for authentication purposes with certain desktop applications or web applications that do not support SAML. Further, in some implementations, the desktop application110described herein need not support SAML. The web application140may manage authentication of users for the desktop application110by communicating with the desktop application110and, further, by using SAML to communicate with the identity server120. Although this disclosure refers repeatedly to the use of SAML in particular, various implementations could use some other security communication protocol. Thus, the implementations described herein are not limited to SAML as the security communication protocol of the identity server120, but rather, references herein to SAML in particular are made for illustrative purposes only.

The web application140may be configured to act as an intermediary between the desktop application110and the identity server120to authenticate users for the desktop application110. In some implementations, the web application140is implemented as hardware, software, or a combination of both. For instance, the web application140is implemented as program code stored on a storage device and executable by one or more processors. The web application140may run on-premises, such as at a site associated with a service provider associated with the desktop application110, or may operate in a cloud. In some implementations, the web application140is configured to communicate with the identity server120using SAML. For instance, the program code of the web application140includes instructions for parsing and constructing SAML statements. As such, the web application140is configured to exchange messages with the identity server120for authentication purposes.

In some implementations, the web API130is an application programming interface exposed to the desktop application110. The web API130may behave as an interface for the desktop application110to perform certain interactions with the web application140or with other resources on the web. In some implementations, the web API130is implemented as hardware, software, or a combination of both. The web API130may run on-premises, such as at a site associated with a service provider associated with the desktop application110, or may operate in a cloud. In some implementations, the web API130is integrated with the web application140, or the web API130executes on the same one or more computing devices as does the web application140. Additionally or alternatively, however, the web API130may run on a distinct device from the web application140and may communicate with the web application140over the network150or via other means.

In some implementations, each of the web application140, the web API130, and the identity server120may facilitate authentication for multiple desktop applications. In that case, each desktop application configured to use the authentication system100as described herein may have access to the web API130and the web application140and may perform operations similar to those described as performed by the desktop application110described herein. Thus, although this disclosure refers repeatedly to operations involving the desktop application110, in the singular, the authentication system100may authenticate users for various desktop applications110, and such authentications may occur in parallel such that the web application140, the web API130, and the identity server120can facilitate authentication for multiple desktop applications110at a given time.

In some implementations, the desktop application110, the web application140, the web API130, and the identity server120communicate with one another over the network150. The network150may be a combination of one or more local area networks or wide area networks, using wired communications systems, wireless communication systems, or a combination thereof. Each of the client device160, the web application140, the web API130, and the identity server120may have direct or indirect access to the network150via a respective network interface device.

FIG.2is a flow diagram of a method200of authenticating a user to the desktop application110, according to some implementations described herein. In some implementations, components of the authentication system100perform this method200or similar when the desktop application110starts up on the client device160. InFIG.2, the flow diagram is sectioned across the horizontal axis into four vertical areas, each of which represents operations performed by a corresponding component of the authentication system100. However, the assignment of operations to certain components is provided for illustrative purposes only and does not limit the various possible implementations of the authentication system100.

The method200depicted inFIG.2may be implemented in software executed by one or more processors of a computer system, implemented in hardware, or implemented in a combination of software and hardware. The method200presented inFIG.2and described below is intended to be illustrative and non-limiting. AlthoughFIG.2depicts various processing operations occurring in a particular sequence or order, this is not intended to be limiting. In certain alternative examples, the processing may be performed in a different order, operations may be excluded or added, or some operations may be performed in parallel.

Prior to block205, the desktop application110may determine whether it can reach the web API130, which is required for online authentication in some implementations. For instance, the desktop application110may be unable to reach the web API130if the client device160on which the desktop application110runs is not connected to the network150or, otherwise, if the desktop application110does not have network access. If the desktop application110cannot reach the web API130, then the desktop application may execute a method300for authentication in offline mode, such as the method300described inFIG.3. However, if the desktop application110can reach the web API130, then the desktop application110may proceed with this method200in online mode.

As shown inFIG.2, at block205, the desktop application110identifies a web application140configured to act as an intermediary between the desktop application110and an identity server120. To this end, the desktop application110may request authentication settings needed for authentication; for instance, the desktop application110may request such authentication settings from the web API130. In response to the request, the web API130may return the authentication settings.

The authentication settings may identify the web application140to the desktop application110. In some examples, the authentication settings explicitly provide a location, such as a uniform resource locator (URL) or IP address, of the web application140to be used for authentication. Additionally or alternatively, in some examples, the desktop application110maintains a mapping of security communication protocols to web applications, and the desktop application110knows the locations of such web applications. In that case, the authentication settings may indicate a security communication protocol, such as SAML, and the desktop application110may map that security communication protocol to a location of the web application140. Various implementations are possible and are within the scope of this disclosure.

At block210, the desktop application110loads a browser control180to navigate an internal browser190of the desktop application110to the web application140identified at block205. At block215, the web application140may redirect the internal browser190of the desktop application110to the identity server120. In some implementations, the web application140includes program code indicating a location, such as an URL or IP address, of the identity server120, and thus, the web application140can redirect the internal browser190to that location.

At block220, the identity server120receives a connection from the internal browser190of the desktop application110. Specifically, the connection may be a result of the internal browser190having been redirected to the identity server120by the web application140. Thus, at block225, the identity server120transmits to the internal browser190of the desktop application110a prompt to provide user credentials. In some implementations, the prompt is displayed via the internal browser of the desktop application110to a user, and the user enters the user's credentials into the internal browser190.

At block230, the desktop application110, via the internal browser190, transmits the user credentials to the identity server120. At block235, the identity server120receives the user credentials and confirms the user's identity. More specifically, the identity server120may confirm that the user credentials received match those in authentication data of a user account stored in the datastore125of the identity server120. However, if the user credentials do not match authentication data stored in the datastore125, the identity server120may once again transmit a prompt for user credentials or may indicate that authentication has failed.

If the user credentials are valid (i.e., matching authentication data of a user account), then at block240, the identity server120redirects the internal browser190back to the web application140. Then at block245, the web application140generates a cookie (e.g., a block of data) including an access token and transmits that cookie to the internal browser190of the desktop application. In some implementations, the access token is encrypted to ensure that the access token cannot be stolen and used by a different user to access the desktop application110. The access token may be or include identifying data that confirms authentication and uniquely identifies a session between the user and the desktop application110. For instance, the access token may include a random string unique to the session. Conventionally, after authentication of a user to a web application, the web browser would couple communications from the client side with metadata including the access token, to confirm the authenticity of such communications. In some implementations, however, the access token is utilized by the desktop application110without additional operations of the internal browser190(e.g., after the internal browser190is closed) as described further below.

At block250, the desktop application110stores the cookie locally. In some implementations, the desktop application110may then close the internal browser190. At block255, the desktop application110transmits an authentication request to the web API130. In some implementations, the desktop application110transmits the access token, which may be encrypted, to the web API130as part of the authentication request.

At block260, the web API130receives the authentication request, including the access token. The web API130may be configured to authenticate access tokens, such as by verifying the authenticity of access tokens. Further, the web API130may maintain, or have access to, a mapping of users to permissions for the desktop application110. Given the access token, which may include a user identifier that identifies the user, the web API130may thus authenticate the access token and determine permissions associated the user. At block265, the web API130transmits to the desktop application110an authentication notification indicating that the user is authenticated with specific permissions. The authentication notification may indicate the specific permissions applicable to the user with respect to the desktop application110, such as which resources170the user is allowed to read and which resources170the user is allowed to write.

At block270, the web API130generates a temporary password for the user of the desktop application110and transmits a representation of the temporary password, such as a hash of the temporary password, to the desktop application. At block275, the web API130also sends the temporary password to the user, such as via email, so the user has the temporary password. As described in more detail below, the temporary password may enable the user to log into the desktop application110in offline mode.

At block280, the desktop application110receives the authentication notification and the representation of the temporary password. The desktop application110may store the representation of the temporary password locally. In some implementations, the client device160includes a secure storage device, such as an encrypted drive, and the desktop application110causes the client device160to store the representation of the temporary password on the secure storage device.

At block285, the desktop application110allows the user access to the resource170according to the specific permissions indicated in the authentication notification received at block280. For instance, the desktop application110displays a user interface through which the user can access the resource170or perform other activities available through the desktop application110with the specific permissions provided. In some implementations, this begins a session between the user and the desktop application110.

Generally, in some implementations, the session is a limited period of time during which the user interacts with the desktop application110without having to re-authenticate. Later, the desktop application110may terminate the session, for instance, responsive to the user logging out or automatically after a period of inactivity of the user reaches a certain time length. After termination of the session, the user may need to re-authenticate to again access the resource170of the desktop application110, and that re-authentication can be done as described above or using the temporary password.

In some implementations, the communications described above that occur among the desktop application110, the web API130, and the web application140may be transparent to the user. For instance, the user opens the desktop application110, sees the prompt for user credentials, enters the user credentials, receives an email indicating the temporary password for offline login, and is permitted access to the resource170. The user need not be aware of the various other operations involved in the method200of authentication.

As discussed above, the desktop application110can provide or restrict access to a resource170, such as certain data or services. In some cases, a user may require access to that resource170in a place where the desktop application110cannot reach the web API130over the network150. For instance, the desktop application110may not have network access at all times. In one example, the client device160is a mobile device, and a user who is a field technician requires use of the desktop application110when out in the field. In this example, the resource170accessible to the desktop application110could be information about activities required to be performed by the field technician. However, network access may not always be available to the desktop application110when operated in the field.

Some implementations of the desktop application110utilize the temporary password, discussed above with reference to blocks270-280, to facilitate user authentication in an offline mode. Each temporary password may be associated with an expiration time. Before the expiration time arrives, the temporary password remains valid for authentication in offline mode. However, when the expiration time for a password arrives, the temporary password expires, thus becoming invalid, and can no longer be used for authentication.

FIG.3is a flow diagram of a method300of authenticating a user to the desktop application110in offline mode, according to some implementations described herein. In some implantations, the desktop application110performs this method300or similar when the desktop application110starts up on the client device160and detects that the web API130is unreachable. In that case, the desktop application110may proceed to this method300for authentication in offline mode.

The method300depicted inFIG.3may be implemented in software executed by one or more processors of a computer system, implemented in hardware, or implemented in a combination of software and hardware. The method300presented inFIG.3and described below is intended to be illustrative and non-limiting. AlthoughFIG.3depicts various processing operations occurring in a particular sequence or order, this is not intended to be limiting. In certain alternative examples, the processing may be performed in a different order, operations may be excluded or added, or some operations may be performed in parallel.

As shown inFIG.3, at block305, the desktop application110prompts a user for user credentials. For instance, the desktop application110presents to the user a user interface, which includes input elements where the user can type and submit, or otherwise enter, the user credentials. In some examples, the user credentials include a user identifier and a password. At block310, the desktop application110receives the user credentials entered by the user in response to the prompt.

At decision block315, the desktop application110determines whether any temporary password associated with the user (e.g., associated with the entered user identifier) is stored on the client device160and valid for offline authentication. For instance, a temporary password could be deemed valid if the temporary password has not yet expired, and a temporary password could be deemed invalid after its expiration. If no such valid temporary password is found, then at block320, authentication fails. The desktop application110may present a notification, such as via the user interface, that authentication in offline mode is not available or has failed. In that case, the desktop application110may restrict or disallow access to the resource170available through the desktop application110.

However, if at least one temporary password that is valid is found for the user on the client device160, then at decision block325, the desktop application110compares that temporary password to the password entered by the user as part of the user credentials. As discussed above, the client device160may maintain a hash of the temporary password, rather than the temporary password itself. In that case, the desktop application110may hash the password received at block310and may compare the hash to the hash of the temporary password to determine whether the password received and the temporary password match.

If the password received does not match the temporary password, then at block330, authentication fails because the user credentials received are invalid. In that case, the desktop application110may indicate, such as via the user interface, that authentication has failed. The desktop application110may restrict or disallow access to the resource170available through the desktop application110until the user enters valid user credentials. In some implementations, the desktop application110may allow the user one or more additional attempts to provide valid user credentials.

However, if the password received at block310matches the temporary password associated with the user, then at block335, the desktop application110deems the user to be authentic. As such, the desktop application may allow the user to use the desktop application110to access the resource170or to perform other activities.

FIG.4is a diagram of an example of a computing system400that can perform certain operations described herein. For instance, a computing system400similar to that shown inFIG.4can be a client device160configured to run the desktop application110, the computing system400can run the web application140and the web API130, or the computing system400can be or can execute the identity server120. Various suitable computing systems or groups of computing systems can be used for performing the operations described herein.

For example,FIG.4shows an example of a computing system400that acts as the client device160and executes the desktop application110. The depicted example of the computing system400includes a processor402communicatively coupled to one or more memory devices404. The processor402executes computer-executable program code stored in a memory device404. Examples of the processor402include a microprocessor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or another suitable processing device. The processor402can include one or more processing devices.

The memory device404includes a suitable non-transitory computer-readable medium for storing data, program code, or both. A computer-readable medium can include an electronic, optical, magnetic, or other storage device capable of providing a processor with computer-readable instructions or other program code. Non-limiting examples of a computer-readable medium include a magnetic disk, memory chip, read-only memory (ROM), random-access memory (RAM), optical storage, magnetic tape or other magnetic storage, or another medium from which a processing device can read instructions.

In some implementations, the computing system400executes program code that configures the processor402to perform one or more of the operations described herein. The program code includes, for example, instructions for implementing the desktop application110or other suitable systems that perform one or more operations described herein. The program code may be resident in the memory device404or a suitable computer-readable medium and may be executed by the processor402or other suitable processor. Although not shown inFIG.4, a memory device404of the same or a different computing system400may include program code for the web application140or the web API130, or both.

The computing system400may include one or more external or internal devices, such as input or output devices. For example, the computing system400is shown with one or more input/output (“I/O”) interfaces408. One or more buses406are also included in the computing system400. The bus406communicatively couples one or more components of the computing system400.

An implementation of the computing system400includes a network interface device410. The network interface device410includes one or more devices suitable for establishing a wired or wireless data connection to one or more data networks, such as the network150. Non-limiting examples of the network interface device410include an Ethernet network adapter or a Wireless Fidelity (WiFi) card. The computing system400is able to communicate with one or more other computing devices via a data network using the network interface device410. For example, the computing system400running the desktop application110can use the network interface device410to communicate with the web application140and the web API130over the network150.

The features discussed herein are not limited to any particular hardware architecture or configuration. A computing device can include any suitable arrangement of components that provide a result conditioned on one or more inputs. Suitable computing devices include multipurpose microprocessor-based computer systems accessing stored software (i.e., computer-readable instructions stored on a memory of the computer system) that programs or configures the computing system from a general-purpose computing apparatus to a specialized computing apparatus implementing one or more aspects of the present subject matter. Any suitable programming, scripting, or other type of language or combinations of languages may be used to implement the teachings contained herein in software to be used in programming or configuring a computing device.