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 in this specification relate to computer applications, and more specifically, relate to facilitating user authentication for desktop applications using a web-based authentication server.

Background Art

[0002] Security Assertion Markup Language (SAML) is an open standard for exchanging authentication data between entities. For example, SAML is often used to authenticate users in web applications associated with a service provider. A service provider is an entity that provides services such as utilities. A service provider is associated with a web application that can be used by a customer of the service provider to verify an account or by an employee to perform maintenance work. 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 an authentication service. Using SAML, a web application exchanges communications with an authentication server to authenticate a user of the web application. The advantage of being able to exchange messages with an authentication server using SAML is that the service provider does not need to implement its own authentication service, and furthermore, it is convenient for the user because the user can be authenticated with a plurality of web applications using a predetermined authentication server.

Summary of the Invention

[0003] In one example, a desktop application performs a method for authenticating a user. According to this 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 authentication server. The desktop application loads browser controls to navigate its internal browser to the web application, which then redirects the internal browser to the authentication server. The desktop application sends user authentication information to the authentication server via its internal browser to authenticate the desktop application's user. Within that internal browser, the desktop application receives a cookie containing an access token for the desktop application's user. The desktop application sends an authentication request containing the access token to the web application's associated web application programming interface (API). Based on the authentication instructions received from the web API, the desktop application grants access to its resources.

[0004] In other examples, a web application performs multiple modes of authentication for a user. According to this method, the web application receives a connection from an internal browser running in a desktop application on a client device. The web application redirects the desktop application's internal browser to an authentication server, acting as an intermediary between the desktop application and the authentication server. The web application receives an indication from the desktop application that the user has successfully authenticated the authentication server. In this way, the web application returns a cookie to the desktop application's internal browser containing an access token that verifies the authentication of the desktop application user. A web API associated with the web application receives an authentication setup request from the desktop application containing 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 both a web application and a desktop application. The web application is configured to act as an intermediary between the desktop application and an authentication server for authenticating users 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 browser controls to navigate its internal browser 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 its internal browser to authenticate users of the desktop application. In that internal browser, the desktop application receives a cookie containing an access token for users of the desktop application. The desktop application sends an authentication request containing the access token to the web API associated with the web application. Based on the authentication instructions received from the web API, the desktop application grants access to resources in the desktop application.

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

[0007] These and other features, aspects, and advantages of this disclosure will be better understood by reading the following detailed description with reference to the accompanying drawings. [Figure 1]This diagram shows an authentication system for authenticating a user to a desktop application, relating to some of the examples described herein. [Figure 2] This is a flowchart illustrating a method for authenticating a user to a desktop application, relating to some of the examples described herein. [Figure 3] This is a flowchart illustrating a method for authenticating a user to a desktop application in offline mode, relating to some of the examples described herein. [Figure 4] This is a diagram illustrating an example of a computing system capable of performing the specific operations described herein. [Modes for carrying out the invention]

[0008] While Security Evaluation Markup Language (SAML) offers convenience to both service providers and end users, a significant drawback of SAML is that its use is generally limited to web applications. Many web applications support SAML by incorporating the necessary configuration for communication in SAML into their code. In contrast, desktop applications are typically not designed to use SAML, so existing desktop applications that may use authentication providers for authentication need to 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 in this book use authentication providers to facilitate user authentication for desktop applications. For example, a desktop application can communicate with a web application using browser controls, and the web application can communicate with an authentication server on behalf of the desktop application using SAML. Furthermore, in some implementations, the web application programming interface (API) associated with the web application can generate a temporary password that enables user authentication in offline mode. As a result, the desktop application can authenticate users via SAML combined with an authentication server in both online and offline modes. A further advantage of some implementations is extensibility, as a desktop application can be configured to use a different authentication technology or a different authentication provider simply by being directed to another web application configured to facilitate the desired authentication.

[0010] Figure 1 is a diagram of an authentication system 100 relating 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 necessary, or as described herein, so that the desktop application 110 can authenticate users. The authentication system 100 may enable the desktop application 110 to authenticate users of the desktop application 110 by communicating with the authentication server 120 using SAML. In some examples, the desktop application is not configured to support SAML. However, the web application 140 can act as an intermediary between the desktop application 110 and the authentication server 120 to facilitate authentication.

[0011] The desktop application 110 may be installed on a client device 160, which is a computing device such as a desktop computer, notebook computer, tablet, or smartphone. To enable the desktop application 110 to run on the client device 160, the desktop application 110 may be a software program, or part of a software program, that can be executed by the processor of the client device 160. For example, the desktop application 110 is 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 the maintenance of utility meters. However, various other types of desktop applications 110 are also within the scope of this disclosure. The desktop application 110 may require user authentication so that the user cannot access the desktop application resources 170, such as data or services provided by the desktop application 110, until the user authenticates themselves to the desktop application 110.

[0013] In some examples, the desktop application 110 is configured to run a browser control 180 to provide the desktop application 110 with an internal browser 190. For example, the browser control 180 may provide controls such as navigation controls that enable the web browsing functionality of the internal browser 190 within the desktop application 110. In other words, the browser control 180 may 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 configuration necessary to support SAML. Therefore, in some examples, the internal browser 190 cannot communicate directly with the authentication server 120 to authenticate the 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 users by verifying their identity. More specifically, the authentication server 120 can authenticate that a user's identity matches the identity of a user associated with a user account on the authentication server 120, based on user authentication information entered by the user. The authentication server 120 may also be a server associated with an authentication provider. The authentication provider can verify the user's identity 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 on a computing unit or distributed across two or more computing units. For example, the authentication server 120 may be implemented as program code running on one or more processors of one or more computing units. In some examples, the authentication server 120 operates in the cloud and is accessible over the internet.

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

[0016] For example, the authentication data for a user's user account includes a user identifier and a password. The user identifier can uniquely identify the user. For example, the user identifier may be an email address, password, telephone number, Internet Protocol (IP) address, Media Access Control (MAC) address, or other data. The password may be stored in the data store 125 in an encrypted, hashed, or otherwise concealed 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 concealed representation of the user's biometric factors. When a user account is first established or updated, the authentication server 120 may receive the authentication data, such as by manual input by the user or administrator. The authentication server 120 may store this authentication data in the data store 125 and use it to authenticate users as described herein.

[0017] The authentication server 120 may be configured to communicate with applications using SAML. In some examples, the authentication server 120 cannot directly communicate for authentication purposes with certain desktop or web applications that do not support SAML. Furthermore, in some examples, the desktop application 110 described herein does not need to support SAML. The web application 140 may manage the authentication of users of the desktop application 110 by communicating with the desktop application 110 and further by communicating with the authentication server 120 using SAML. Although this disclosure repeatedly refers to the use of SAML in particular, other security communication protocols can be used in various examples. Therefore, the examples described herein are not limited to SAML as the security communication protocol of the authentication server 120, and rather, the references to SAML in particular herein are for illustrative purposes only.

[0018] The web application 140 may be configured to act as an intermediary between the desktop application 110 and the authentication server 120 in order 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 that is stored on a storage device and executable by one or more processors. The web application 140 may run on-premises, for example, at a site associated with a service provider associated with the desktop application 110, or it may run 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 for parsing and constructing SAML statements. In this way, 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 also act as an interface for the desktop application 110 to perform specific 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-premises, for example, at a site associated with a service provider associated with the desktop application 110, or it 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 one or more computing devices as the web application 140. However, in addition to or instead of this, 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 by other means.

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

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

[0022] Figure 2 is a flowchart of a method 200 for authenticating a user with respect to a desktop application 110 according to some examples described herein. In some examples, the components of the authentication system 100 execute this method 200 or a similar method when the desktop application 110 is launched on the client device 160. In Figure 2, the flowchart is divided into four vertical regions along the horizontal axis, and each region represents an operation performed by a corresponding component of the authentication system 100. However, the assignment of operations to specific components is provided for illustrative purposes only and does not limit the various implementations possible for the 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. Figure 2 depicts various processing operations that occur in a particular order, but this is not intended to be limiting. In certain alternative examples, the processing may be executed in a different order, some operations may be excluded or added, or some operations may be executed in parallel.

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

[0025] As shown in Figure 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. For this purpose, 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 settings can identify the web application 140 for the desktop application 110. In some examples, the authentication settings explicitly provide a location such as the Uniform Resource Locator (URL) or IP address of the web application 140 used for authentication. In addition to or instead of this, 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 settings indicate a security communication protocol such as SAML, and the desktop application 110 can map that security communication protocol to the location of the web application 140. Various implementations are possible and within the scope of the present disclosure.

[0027] In block 210, the desktop application 110 loads the browser control 180 and navigates the internal browser 190 of the desktop application 110 to the web application 140 identified in block 205. In block 215, the web application 140 may redirect the internal browser 190 of the desktop application 110 to the authentication server 120. In some examples, since the web application 140 includes program code indicating a location such as the URL or IP address of the authentication server 120, 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 to the authentication server 120 by the web application 140. Next, 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 their authentication information into the internal browser 190.

[0029] In block 230, the desktop application 110 sends user authentication information to the authentication server 120 via the internal browser 190. In 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 the authentication data for the user account stored in the authentication server 125. However, if the user authentication information does not match the authentication data stored in the data store 125, the authentication server 120 may resend the user authentication information prompt or indicate that authentication has 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. Next, in block 245, the web application 140 generates a cookie (e.g., a block of data) containing the access token and sends the cookie to the internal browser 190 of the desktop application. In some examples, the access token is encrypted to prevent it from being stolen and used by another user to access the desktop application 110. The access token may be, or contain, identification data that verifies authentication and uniquely identifies the session between the user and the desktop application 110. For example, the access token may contain a random string unique to the session. Traditionally, after user authentication to the web application, the web browser combines client-side communications with metadata containing the access token to verify the authenticity of such communications. However, in some examples, as further described below, the access token is utilized by the desktop application 110 without any further action by the internal browser 190 (e.g., after the internal browser 190 is closed).

[0031] In block 250, the desktop application 110 stores the cookie locally. In some examples, the desktop application 110 may then close the internal browser 190. In 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] In block 260, the web API 130 receives an authentication request containing an access token. The web API 130 may be configured to authenticate the access token, for example, by verifying the authenticity of the access token. Furthermore, the web API 130 may maintain or access a mapping of permissions for users for the desktop application 110. Given an access token containing a user identifier that identifies the user, the web API 130 authenticates the access token and determines the permissions associated with the user. In block 265, the web API 130 sends an authentication notice to the desktop application 110 indicating that the user has been authenticated with specific permissions. The authentication notice may indicate specific permissions applicable to the user with respect to the desktop application 110, such as resource 170 that the user is allowed to read and resource 170 that the user is allowed 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 to the user via email or other means, and the user has the temporary password. As will be described in more detail below, the temporary password allows the user to log in to the desktop application 110 in offline mode.

[0034] In block 280, the desktop application 110 receives an authentication notification and a temporary password display. The desktop application may store the temporary password display locally. 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 temporary password display on the secure storage device.

[0035] In block 285, the desktop application 110 enables the user to access resource 170 in accordance with the specific permissions indicated in the authentication notice received in block 280. For example, the desktop application 110 displays a user interface. The user interface allows the user to access resource 170 or perform other activities available through the desktop application 110 with the specific permissions provided. In some examples, this initiates a session between the user and the desktop application 110.

[0036] In general, in some examples, a session is a limited period during which a user interacts with the desktop application 110 without re-authentication. The desktop application may then terminate the session, for example, in response to the user logging out, or automatically after a certain period of inactivity. After the session ends, the user may be required to re-authenticate to access the resources 170 of the desktop application 110 again, and this re-authentication may be performed as described above or using a temporary password.

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

[0038] As mentioned above, the desktop application 110 can provide or restrict access to resources 170, such as specific data or services. In some cases, a user may need access to resources 170 in a location where the desktop application 110 cannot reach the web API 130 via the network 150. For example, the desktop application 110 may not always have network access. In one example, the client device 160 is a mobile device, and the user, a field technician, needs to use the desktop application 110 while out in the field. In this example, the resources 170 accessible to the desktop application 110 may be information about activities that the field technician is required to perform. However, the desktop application 110 may not always have network access available when operating in the field.

[0039] Some examples of desktop application 110 use the temporary passwords described above (see blocks 270-280) to facilitate user authentication in offline mode. Each temporary password may have an expiration date. As long as the expiration date has not yet arrived, the temporary password remains valid for authentication in offline mode. However, once the password expires, the temporary password becomes invalid and can no longer be used for authentication.

[0040] Figure 3 is a flowchart of method 300 for authenticating a user to a desktop application 110 in offline mode, relating to some examples described herein. In some examples, when the desktop application 110 is launched on the client device 160 and detects that the web API 130 is unreachable, the desktop application 110 performs method 300 or a similar method. In that case, the desktop application 110 may proceed to method 300 for authentication in 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 illustrative and non-limiting. Figure 3 depicts various processing operations occurring in a particular order, but this is not intended to be limiting. In particular alternative examples, the operations may be executed in a different order, some operations may be excluded or added, or some operations may be executed in parallel.

[0042] As shown in Figure 3, in block 305, the desktop application 110 prompts the user to enter user authentication information. For example, the desktop application presents the user with a user interface that includes input elements. In the input elements, the user types and submits user authentication information, or enters it by other means. In some examples, user authentication information includes a user identifier and a password. In block 310, the desktop application 110 receives the user authentication information entered by the user in response to the prompt.

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

[0044] However, if at least one valid temporary password is found for a user on the client device 160, in decision block 325, the desktop application 110 compares that temporary password with the password entered by the user as part of the user authentication information. 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 with 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 in block 330 because the received user authentication information is invalid. In this case, the desktop application 110 may indicate that authentication has failed through the user interface or the like. The desktop application 110 may restrict or prohibit access to the resources 170 available through the desktop application 110 until the user enters valid user authentication information. In some examples, the desktop application 110 may allow the user one or more additional attempts to provide valid user authentication information.

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

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

[0048] For example, Figure 4 shows an example of a computing system 400 that operates as a client device 160 and runs a desktop application 110. The example of the computing system 400 depicted 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. An example of the processor 402 includes 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 a suitable non-temporary computer-readable medium for storing data, program code, or both. The computer-readable medium may include electronic, optical, magnetic, or other storage devices that can provide computer-readable instructions or other program code to the processor. Non-limiting examples of computer-readable medium include magnetic disks, memory chips, read-only memory (ROM), random access memory (RAM), optical storage devices, magnetic tapes or other magnetic storage devices, or other media from which a processing device can read instructions.

[0050] In some examples, the arithmetic system 400 executes program code constituting 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 systems that perform one or more operations described herein. The program code may reside in the memory device 404 or a suitable computer-readable medium, or it may be executed by the processor 402 or another suitable processor. Although not shown in Figure 4, the memory device 404 of the same or a different arithmetic system 400 may contain program code for the web application 140 or the web API 130, or both.

[0051] The arithmetic system 400 may include one or more external or internal devices, such as input or output devices. For example, the arithmetic system 400 is shown with one or more input / output ("I / O") interfaces 408. One or more buses 406 are also included in the arithmetic system 400. The buses 406 connect one or more components of the arithmetic system 400 in a communicative manner.

[0052] An example of the computing system 400 includes a network interface device 410. The network interface device 410 includes one or more devices suitable for establishing wired or wireless data connections to one or more data networks, such as 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 the 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 network 150.

[0053] This specification provides numerous specific details to give a complete understanding of the claimed subject matter. However, those skilled in the art will understand that the claimed subject matter can be implemented without these specific details. In other examples, methods, apparatus, or systems that would be known to those skilled in the art are not described in detail so as not to obscure the claimed subject matter.

[0054] The features discussed herein are not limited to any particular hardware architecture or configuration. An arithmetic unit may include any suitable arrangement of components that provide results conditionally on one or more inputs. A suitable arithmetic unit includes a multipurpose microprocessor-based computer system that accesses stored software (i.e., computer-readable instructions stored in the memory of the computer system) that programs or configures the arithmetic unit from a general-purpose arithmetic unit to a dedicated arithmetic unit that implements one or more aspects of this subject. Any suitable programming, scripting, or other type of language or combination of languages ​​may be used in the software used to program or configure the arithmetic unit to implement the teachings contained herein.

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

[0056] The use of “conformed to” or “configured to” in this specification means an open and inclusive language that does not exclude devices adapted or configured to perform additional tasks or steps. Furthermore, the use of “based on” means that a process, step, calculation, or other operation “based on” one or more of the aforementioned conditions or values ​​may actually be based on additional conditions or values ​​beyond those stated above. The headings, lists, and numbering included herein are for illustrative purposes only and do not imply limitation.

[0057] While the subject matter has been described in detail with respect to its particular aspects, those skilled in the art will understand that, having attained the foregoing understanding, modifications, variations, and equivalents to such aspects can be readily produced. Therefore, it should be understood that this disclosure is presented for illustrative purposes, not limitation, and does not exclude modifications, variations, and / or additions to the subject matter that would be readily apparent to those skilled in the art.

Claims

1. A step of identifying a web application configured to act as an intermediary between the desktop application and the authentication server by a desktop application installed and running on the client device, The steps include: loading a browser control by the desktop application, navigating the desktop application's internal browser to the web application, and the web application redirecting the internal browser to the authentication server; The desktop application sends user authentication information to the authentication server via the internal browser for authenticating the user of the desktop application. The steps include: In the internal browser of the desktop application, receiving 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 the web application programming interface (API) associated with the web application. The steps include granting access to the desktop application's resources based on authentication instructions received from the web API, A method that includes this.

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

3. The steps include: terminating the session between the user and the desktop application; The desktop application includes the step of receiving the entered password, The steps include granting access to the resources of the desktop application based on comparing the entered password with the hash of the temporary password generated by the web API, The method according to claim 2, further comprising:

4. The aforementioned web application identification step is: The steps include requesting the web API to provide settings related to the authentication server in order to authenticate the user of the desktop application installed and running on the client device, The desktop application receives instructions from the web API for the web application acting as an intermediary between the desktop application and the authentication server. The method according to claim 1, further comprising:

5. The desktop application receives instructions for a security communication protocol for communicating with the authentication server. The steps include identifying that the web application has the capability to use the security communication protocol, The method according to claim 4, further comprising:

6. The desktop application receives a message indicating that Security Assertion Markup Language (SAML) is being used in communication with the authentication server. The steps include identifying that the web application has the ability to use SAML to communicate with the authentication server, The method according to claim 4, further comprising:

7. In a web application, the steps include receiving a connection from an internal browser running on the desktop application of a client device, The steps include: the web application redirects the internal browser of the desktop application to the authentication server, and the web application acts as an intermediary between the desktop application and the authentication server; The steps include: the web application receiving a notification in the desktop application indicating that the user has successfully authenticated to the authentication server; The steps include: the web application returning a cookie containing an access token to the internal browser of the desktop application to verify the authentication of the user of the desktop application; The steps include receiving an authentication request including the access token from the desktop application, A step of authenticating the user to the desktop application based on the access token, A method that includes this.

8. The steps include generating a temporary password for the offline mode of the desktop application, The steps include sending the hash of the temporary password to the desktop application to enable the user's offline authentication to the desktop application, The method according to claim 7, further comprising:

9. The steps include receiving an authentication setting request from the desktop application via a web application programming interface (API) associated with the web application, The steps include sending instructions from the web application to the desktop application in response to the authentication setting request, The method according to claim 7, further comprising:

10. The method according to claim 7, further comprising the step that the web application communicates with the authentication server using a security assertion markup language on behalf of the desktop application.

11. A web application configured to act as an intermediary between multiple desktop applications and an authentication server for authenticating users of the multiple desktop applications, Desktop applications and A system including, The aforementioned desktop application is The web application is identified as an intermediary between the desktop application and the authentication server, The browser control is loaded to navigate the internal browser of the desktop application to the web application, and the web application redirects the internal browser to the authentication server. The user authentication information for authenticating the user of the desktop application is sent to the authentication server via the internal browser. In the internal browser, a cookie containing an access token for the user of the desktop application is received. A request including the access token is sent to the web application programming interface (API) associated with the web application. Based on the authentication instructions received from the aforementioned web API, grant access to the resources of the desktop application. It is configured in such a way. system.

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

13. The aforementioned web API is A temporary password is generated to enable the user's offline authentication to the desktop application. Send the hash of the temporary password to the desktop application. The system according to claim 11, further configured as follows.

14. The aforementioned desktop application is The hash of the temporary password generated by the web API is received, The hash of the temporary password is stored on the client device running the desktop application, enabling the user to perform offline authentication for the desktop application. The system according to claim 13, further configured as follows.

15. The aforementioned desktop application is The session between the user and the desktop application is terminated. Receive the entered password, Based on comparing the entered password with the hash of the temporary password generated by the web API, access to the resource is permitted. The system according to claim 14, further configured as follows.

16. In order to identify the web application as an intermediary between the desktop application and the authentication server, the desktop application: The web API is requested to provide the settings related to the authentication server. The web application receives instructions from the web API. The system according to claim 11, further configured as follows.

17. The aforementioned desktop application is The system receives instructions for a security communication protocol to communicate with the authentication server. Identify that the web application has the capability to use the security communication protocol. The system according to claim 11, further configured as follows.

18. The aforementioned desktop application is Upon receiving instructions for a security communication protocol (SAML) to communicate with the aforementioned authentication server, Identify that the aforementioned web application has the ability to use SAML. The system according to claim 11, further configured as follows.

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

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

Images