The described embodiments set forth a technique for authenticating an application with an authorization server via an identity provider.
OAuth (Open Authorization) is an open standard for authorization that allows users to authorize third-party applications to access protected resources that are hosted by an identity provider (e.g., Google, Facebook, Twitter, etc.) without sharing their login credentials. Specifically, OAuth is a web-based authorization technique that involves the communication of an authorization code between the identity provider and the third-party application to provide the access to the protected resources. However, communication of the authorization code directly to the third-party application can cause security issues. For instance, malware installed on a client device (on which the third-party application operates) can obtain the authorization code that can then be used for malicious purposes, e.g., inappropriately gaining access to the protected resources. Therefore, there is a need for a technique for more-securely authenticating third-party applications via identity providers.
Representative embodiments set forth herein disclose various techniques for enabling an application operating on a client device to authenticate with an authentication server device by way of an identity provider. According to some embodiments, the authentication is performed without exposing a user's credentials (for the identity provider) to the application/authentication server device. As described in greater detail herein, the techniques involve the communication of an authorization code from a web browser operating on the client device to the authentication server device. The authorization code is associated with an authentication request issued by the web browser to the identity provider, where the authentication request includes login information that is known to the identity provider and is associated with the user of the application. In turn, the authentication server device generates an authorization identifier in response to a successful verification of the authentication request. The authorization identifier is communicated to the web browser, where, in turn, the web browser provides the authorization identifier to the application. The application can then utilize the authorization identifier to authenticate with the authentication server device. In this manner, the authentication server device facilitates the authorization process between the application and the identity provider without communicating the authorization code directly to the application, which can enhance overall security by strengthening the barrier against potential man-in-the-middle attacks.
This Summary is provided merely for purposes of summarizing some example embodiments so as to provide a basic understanding of some aspects of the subject matter described herein. Accordingly, it will be appreciated that the above-described features are merely examples and should not be construed to narrow the scope or spirit of the subject matter described herein in any way. Other features, aspects, and advantages of the subject matter described herein will become apparent from the following Detailed Description, Figures, and Claims.
Other aspects and advantages of the embodiments described herein will become apparent from the following detailed description taken in conjunction with the accompanying drawings that illustrate, by way of example, the principles of the described embodiments.
The included drawings are for illustrative purposes and serve only to provide examples of possible structures and arrangements for the disclosed inventive apparatuses and methods for providing wireless computing devices. These drawings in no way limit any changes in form and detail that may be made to the embodiments by one skilled in the art without departing from the spirit and scope of the embodiments. The embodiments will be readily understood by the following detailed description in conjunction with the accompanying drawings, wherein like reference numerals designate like structural elements.
Representative applications of apparatuses and methods according to the presently described embodiments are provided in this section. These examples are being provided solely to add context and aid in the understanding of the described embodiments. It will thus be apparent to one skilled in the art that the presently described embodiments can be practiced without some or all of these specific details. In other instances, well known process steps have not been described in detail in order to avoid unnecessarily obscuring the presently described embodiments. Other applications are possible, such that the following examples should not be taken as limiting.
The embodiments described herein set forth techniques for facilitating an authorization process between an application and an identity provider. In particular, the techniques involve redirecting an authorization code generated by the identity provider to an authentication server device rather than directly to the application. In turn, the authentication server device generates an authorization identifier based on the authorization code. The authorization identifier then is returned to the application and used by the application to authenticate with the authentication server device.
Accordingly, the techniques described herein provide a mechanism for authenticating the application operating on a client device with the authentication server device in a secure manner. A more detailed discussion of these techniques is set forth below and described in conjunction with
According to some embodiments, the client device 110, the authentication server device 120, and the identity provider 140 can communicate with one another via a network 130 (e.g., the Internet). The network 130 can include one or more of the Internet, an intranet, a PAN (Personal Area Network), a LAN (Local Area Network), a WAN (Wide Area Network), a MAN (Metropolitan Area Network), a wireless communication network, and other networks or combination of networks.
According to some embodiments, the authentication server device 120 can represent a computing device that is configured to facilitate the authorization process between the application 118 and the identity provider 140. A processor (or CPU) 122, in conjunction with the memory 124, can implement an OS (not illustrated in
According to some embodiments, the list of identity providers 140 and the associated client IDs are stored at the authentication server device 120. In some implementations, the authentication server device 120 communicates, at step 206, the retrieved list of identity providers 140 and the client IDs to the application 118.
At step 208, the list of identity providers 140 is presented to the application 118. According to some embodiments, the list of identity providers 140 can be presented in a graphical user interface (GUI) of the application 118. A user of the application 118 can then choose to authenticate with a particular identity provider 140 by selecting the particular identity provider 140 from the list presented in the GUI. At step 210, and in response to the selection of the particular identity provider 140 from the list, an authorization request is communicated from the application 118 to the authentication server device 120, where the authorization request represents a request to authenticate with the selected identity provider 140. At step 212, and in response to receiving the authorization request, the authentication server device 120 returns to the application 118: (1) a request ID associated with the authorization request, and (2) a login URL (Uniform Resource Locator) that enables the application 118 to interface with the selected identity provider 140 to perform an authorization process.
Referring now to
At step 216, the application 118, via the web browser 205, communicates an authentication request to the identity provider 140, where the authentication request includes login information (e.g., the user's credentials), the request ID (discussed above in conjunction with step 212), the client ID, and a redirect URL that points to the authentication server device 120. At step 218, and in response to the authentication request, the identity provider 140: (1) authenticates the login information, (2) generates an authorization code in response to a successful authentication, and (3) communicates the authorization code to the web browser 205 (executing on the client device 110). At step 220, the web browser 205 redirects the user to the authentication server device 120 based on the redirect URL. The web browser 205 communicates authorization information (including the authorization code and the request ID) to the authentication server device 120. In this manner, the authorization information is returned/redirected to the authentication server device 120 via the web browser 205 without exposing the authorization information to the application 118. In some implementations, the authorization information can be stored at the authentication server device 120.
At step 222, the authorization information is verified with the identity provider 140. In some implementations, the verification process involves verifying, by the identity provider 140, that the user's credentials are authentic. At step 224, in response to a successful verification, the authentication server device 120 generates an authorization identifier based on the request ID and/or the authorization code. In some implementations, the authorization identifier can include a random number, code, secret, and/or the like. The authorization identifier can be stored at the authentication server device 120. In some implementations, the authentication server device 120 can store the request ID, the authorization code, and the authorization identifier linked to the client ID. In some implementations, and in response to an unsuccessful verification, a value associated with the authorization identifier can be set to zero to provide an indication of the unsuccessful verification.
Referring to now
In some implementations, the web browser 205 can establish/access a corresponding process space in the memory 114. In this scenario, when the application 118 receiving the authorization identifier is not running with any elevated privileges, the contents of the corresponding process space in memory 114 (associated with the web browser 205) and communications of the web browser 205 are highly inaccessible to the application 118. In this manner, the authorization identifier can be securely communicated to the web browser 205 by the authentication server device 120 while reducing the likelihood of exposing the authorization identifier to the application 118.
At step 230, the application 118 communicates a login request to the authentication server device 120. According to some embodiments, the login request includes the request ID and the authorization identifier. In turn, at step 232, the authentication server device 120 verifies the login request. In some implementations, the verification process involves verifying that the request ID and the authorization identifier stored at the authentication server device 120 match the request ID and the authorization identifier included in the login request communicated by the application 118. Next, at step 234, and in response to a successful verification, the authentication server device 120 communicates a session key to the application 118. According to some embodiments, the session key can represent one or more encryption keys that can be used to enable the application 118 to securely access the database 126 of the authentication server device 120.
In some implementations, the authorization identifier generated by the authentication server device 120 is linked to the user/login information/client ID such that the authorization identifier can be used for subsequent login requests. With this approach, it is not necessary to re-generate the authorization identifier for each subsequent authorization/login request. According to some embodiments, the authorization identifier can be valid only for a pre-defined period of time to increase security. In some implementations, when the authentication server device 120 rejects the authorization identifier, the steps depicted in
Accordingly, the authorization process described in conjunction with
In some implementations, the authorization information, including the authorization code and the request ID, is verified with the identity provider 140, as previously described with respect to steps 222, 224, and 226 of
In some implementations, and as previously described with respect to step 230 and 232 of
In some implementations, and as previously described with respect to step 234 of
At step 404, the client device 110 launches the web browser 205 using the login URL received from the authentication server device 120. The web browser 205 displays the website of the identity provider 140, wherein the user can be prompted to provide their credentials (e.g., a user ID/password combination, etc.). In particular, as previously described with respect to step 216 of
The computing device 500 also includes the storage device 540, which can comprise a single disk or a plurality of disks (e.g., hard drives, spinning disks, magnetic storage disks, etc.), and includes a storage management module that manages one or more partitions within the storage device 540. In some embodiments, storage device 540 can include any type of non-volatile memory, flash memory, semiconductor (solid state) memory or the like. The computing device 500 can also include a Random Access Memory (RAM) 520 and a Read-Only Memory (ROM) 522. The ROM 522 can store programs, utilities or processes to be executed in a non-volatile manner. The RAM 520 can provide volatile data storage, and stores instructions related to the operation of the computing device 500.
The various aspects, embodiments, implementations or features of the described embodiments can be used separately or in any combination. Various aspects of the described embodiments can be implemented by software, hardware or a combination of hardware and software. The described embodiments can also be embodied as computer readable code on a computer readable medium. The computer readable medium is any data storage device that can store data that can thereafter be read by a computer system. Examples of the computer readable medium include read-only memory, random-access memory, CD-ROMs, DVDs, magnetic tape, hard disk drives, solid state drives, and optical data storage devices. The computer readable medium can also be distributed over network-coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.
The foregoing description, for purposes of explanation, used specific nomenclature to provide a thorough understanding of the described embodiments. However, it will be apparent to one skilled in the art that the specific details are not required in order to practice the described embodiments. Thus, the foregoing descriptions of specific embodiments are presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the described embodiments to the precise forms disclosed. It will be apparent to one of ordinary skill in the art that many modifications and variations are possible in view of the above teachings.