Securing remote authentication

Abstract

The present disclosure relates to securing remote authentication. A secure session between a first user entity and an identity provider is authenticated using a second user entity. The method receives a request for a session from an entity claiming to be the first user entity. The method further includes sending an authentication context from the request, and wherein the authentication context for the request reaches the second user entity. The method further includes receiving an indication that the authentication context has been verified. As a result, the method further includes authenticating the secure session between the first user entity and the identity provider or approving a secure transaction.

Description

[0001] This application is a divisional application of an invention patent application with an international application date of March 23, 2017, which entered the Chinese national stage on September 27, 2018, with Chinese national application number 201780020563.9 and invention name “Protecting Remote Authentication”. Background Art

[0002] Computers and computing systems have impacted nearly every aspect of modern life. Computers are often involved in work, play, healthcare, transportation, entertainment, home management, and more.

[0003] In addition, computing system functionality can be enhanced by the ability of computing systems to interconnect to other computing systems via network connections. These connections allow computing systems to access services at other computing systems and to receive application data from other computing systems quickly and efficiently.

[0004] In some examples, the device may log in to a server or other identity provider to obtain services at the server. For example, this may be accomplished using remote login. Remote login involves logging into a primary entity (e.g., application, device, etc.) using a previously provided secondary entity (e.g., smart card, phone, application, browser, device, etc.). However, such remote login schemes may be subject to phishing attacks for one-time tokens / approvals of previously provided secondary entities. In these cases, a user who intends to authenticate remotely may be tricked into authenticating the attacker's authentication request by utilizing the user's secondary entity to authenticate the attacker.

[0005] The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is provided merely to illustrate one exemplary technology area in which some embodiments described herein may be practiced. Summary of the invention

[0006] One embodiment illustrated herein includes a method that can be practiced in a computing environment. The method includes an action for authenticating a secure session between a first user entity and an identity provider using a second user entity. The method receives a request for a session from an entity claiming to be the first user entity. The method also includes sending an authentication context from the request, and wherein the authentication context of the request reaches the second user entity. The method also includes receiving an indication that the authentication context has been verified. As a result, the method also includes authenticating a secure session between the first user entity and the identity provider or approving a secure transaction.

[0007] This summary is provided to introduce some concepts in a simplified form, which are further described in the detailed description below. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

[0008] Additional features and advantages will be set forth in the following description, and in part will be apparent from the description, or may be learned by practice of the teachings herein. The features and advantages of the invention may be realized and obtained by means of the devices and combinations particularly pointed out in the appended claims. Features of the invention will become more apparent from the following description and the appended claims, or may be learned by practice of the invention as described below. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] In order to describe the manner in which the above-recited and other advantages and features may be obtained, a more particular description of the subject matter briefly described above will be rendered by reference to specific embodiments illustrated in the accompanying drawings. Understanding that these drawings depict only typical embodiments and are therefore not to be considered limiting of its scope, the embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

[0010] Figure 1 An example environment is shown in which a primary entity may use a secondary entity to establish a secure connection with an identity provider;

[0011] Figure 2 Another example environment is shown in which a primary entity may use a secondary entity to establish a secure connection with an identity provider;

[0012] Figure 3 Another example environment is shown in which a primary entity may use a secondary entity to establish a secure connection with an identity provider;

[0013] Figure 4 Another example environment is shown in which a primary entity may use a secondary entity to establish a secure connection with an identity provider;

[0014] Figure 5 Another example environment is shown in which a primary entity may use a secondary entity to establish a secure connection with an identity provider;

[0015] Figure 6 Another example environment is shown in which a primary entity may use a secondary entity to establish a secure connection with an identity provider;

[0016] Figure 7 Another example environment is shown in which a primary entity may use a secondary entity to establish a secure connection with an identity provider;

[0017] Figure 8Another example environment is shown in which a primary entity may use a secondary entity to establish a secure connection with an identity provider;

[0018] Fig. 9 A method of authenticating a secure session between a first user entity and an identity provider using a second user entity is shown; and

[0019] Fig.10 Another method of authenticating a secure session between a first user entity and an identity provider using a second user entity is shown. DETAILED DESCRIPTION

[0020] Some embodiments herein can hinder man-in-the-middle attacks in remote login scenarios by providing authentication context to a user (or a user's device) by an identity provider (e.g., at a server). For example, in one embodiment, an existing channel between an identity provider and an auxiliary entity can be used to provide authentication context about an authentication request from a primary entity to a server. In doing so, the identity provider can show the user the possible differences between the primary entity and the identity provider in the hope of helping to prevent phishing in remote authentication requests. In these cases, the user can be shown the observations seen by the logged-in identity provider, such as the location of the primary entity, the type of device of the primary entity, the type of authentication scheme, etc. In this case, if the primary entity is compromised, the auxiliary entity is used as a means of communicating with the user. In these cases, a channel with an auxiliary entity will allow the identity provider to convey to the user a message that cannot be modified by an attacker who has compromised the primary entity. In particular, the identity provider may be able to detect modifications by comparing the authentication context from the primary entity with the authentication context approved at the auxiliary entity.

[0021] Reference now Figure 1 , shows an example. Figure 1, a user 102 initiates a device-to-device login flow on a primary entity 104 (e.g., a device or application such as a computer, phone, etc.), where a man-in-the-middle attacker 106 may be present. The authentication stack on the primary entity 104 issues a request 108 to initialize the login to an identity provider 110 (e.g., a service at a server). The authentication stack at the primary entity 104 receives a random number 112 and an authentication context 114 (which may be, for example, a location), both of which are passed to a secondary entity 116 (e.g., a device such as a smartphone) for signing by the secondary entity 116. On the secondary entity 116, the user is presented with the authentication context 114 (e.g., the location is displayed to the user on the secondary entity 116), sees that the authentication context 114 is valid, and unlocks the local credential with a local gesture on the secondary entity 116. For example, the user 102 may select a button in the user interface of the secondary entity 116 that indicates that the displayed location is indeed the physical location of the primary entity 104. The secondary entity 116 signs the nonce 112 and the authentication context 114 and sends the resulting token 118 to the primary entity 104 for the primary entity to use as a credential to authenticate with the identity provider 110. The identity provider 110 verifies that the location in the signed token 118 is the same location as the primary entity 104. The man-in-the-middle attacker 106 has access to the token 118, but cannot play it from a different location.

[0022] Man-in-the-middle attacker 106 cannot use token 118 from their remote location because the location in token 118 cannot be changed. If man-in-the-middle attacker 106 modifies the location provided to auxiliary entity 116, user 102 will be able to see that the location in authentication context 114 is not expected and cancel the request at auxiliary entity 116.

[0023] Figure 2Another example is shown in FIG. 1 . In this example, a user 102 initializes a remote login session on a web browser 120 with an identity provider 110 by sending a remote authentication request 108 to log in to the user's trusted secondary entity 116. The identity provider 120 causes the web browser 120 to display a QR code 122 (which has a session identifier and location embedded in the data of the QR code 122) for approval by the secondary entity 116. At the secondary entity 116, the user 102 scans the QR code 122 and is presented with an option, such as an option on the screen of the secondary entity 116, to approve the remote login based on the location information embedded as the authentication context in the QR code 122 to approve the remote authentication request 108. The user 102 verifies that the location is appropriate (e.g., the user is using the primary entity 104 at the location indicated in the authentication context) and enters their local credentials 124 and a local gesture at the secondary entity 116 to approve the remote authentication request 108 to prove that it is from the user 102. The auxiliary entity 116 then presents the local credentials 124 along with the location 114 to the identity provider 110 to verify the remote authentication request 108. The identity provider 110 compares the location of the remote authentication request 108 with the location provided by the auxiliary entity 116 to ensure that it matches the user-approved location provided by the auxiliary entity. The identity provider 110 is then able to authenticate the remote session.

[0024] The location in this case helps prevent man-in-the-middle attacks between the browser 120 and the identity provider 110. If a man-in-the-middle attack occurs in this case and the user 102 is presented with the attacker's QR code, the user 102 will be able to deny the authentication request because the location does not match what is expected. A more sophisticated attacker may attempt to change the location presented in the QR code—that is, modify the QR code to contain the user's actual location and the attacker's session identifier. In this case, the identity provider 110 will block the authentication request because the attacker's location will be different from the location 114 approved by the trusted second entity 116.

[0025] Reference now Figure 3, which shows another example. In this example, a user attempts to initialize a remote connection session in which a man-in-the-middle attacker intercepts a remote authentication request 108 from a primary entity 104. A man-in-the-middle attacker 106 uses the session identifier from the remote authentication request 108 to create a malicious remote authentication request 108'. Using the malicious remote authentication request 108', a remote connection session is created for the attacker 106. The user 102 at the primary entity is presented with the attacker's session identifier 126 for the remote connection request. The user 102 unknowingly proceeds to a web page 120 to log into the remote authentication session on a trusted secondary entity 116, and enters the attacker session identifier 126 to complete the process. Because the site uses SSL, the process appears to be secure to the user; however, the user enters their username and password (or local credentials) and is presented with the location of the session 126. The user 102 sees that the location is different than expected and rejects the session.

[0026] A variation of this embodiment may bypass user approval if the identity provider 110 detects that the location of the primary entity 104 is very close to the location of the secondary entity 116, or that the primary entity 104 is in a familiar location. Alternatively or additionally, the identity provider may detect that the primary entity 104 and the secondary entity 116 have similar IP addresses, indicating that they are connected at a common location.

[0027] Reference now Figure 4 , another example is shown. In this example, a user 102 wants to purchase an application from an identity provider 110 (or an entity associated with the identity provider) through an application store 128 on an entity 104 (e.g., a device) running malware 130. After clicking to purchase in the application store 128, the malware 130 runs and attempts to trick the user 102 into purchasing a malicious application. The user enters a password into the application store 128 as part of the purchase process, and a notification 132 is sent from the identity provider 110 to the auxiliary entity 116 to request approval to purchase the application. The auxiliary entity 116 displays to the user 102 that the application the user is purchasing is a malicious application, and allows the user 102 to then use the auxiliary entity 116 to deny the purchase. In this case, the malware 130 cannot modify the notification 132 sent to the trusted second entity 116. In this way, the user 102 can be securely notified and asked to approve the application being purchased.

[0028] Thus, embodiments may leverage an existing channel between a secondary entity 116 (such as a device or application) and the identity provider 110 in a remote login flow to protect the remote authentication request of the first entity as a means of securely communicating with the user. By displaying the authentication context details (location, device type, entity type, transaction type, etc.) observed by the login server to the user when requesting login approval, embodiments may use the user to help observe differences in remote logins to protect remote authentication requests.

[0029] Embodiments may include an identity provider observation associated with a primary entity as part of a signed token from a secondary entity regarding remote login user approval to allow the identity provider to verify approval of the login from the primary entity.

[0030] Embodiments may use a channel with a secondary entity to automatically verify observations about a primary entity and prompt the user on the secondary entity if there is an inconsistency.

[0031] Embodiments may notify a user's secondary entity (e.g., using a push notification) of the necessary login observation data to enable the user to securely approve the request at the secondary entity as a means of securely communicating to the user in the event that the primary entity is compromised.

[0032] Although using Figures 1 to 4 to illustrate a detailed example, but Figures 5 to 8 The following examples are presented to illustrate the more general principles that may be implemented in various embodiments of the invention.

[0033] Reference now Figure 5 , showing the general process flow. Figure 5 In the example shown, the first entity 104 sends a request as shown in 501 to the identity provider 110. In response to the request, the identity provider 110 sends the authentication context as shown in 502 and the random number as shown in 503 to the first entity 104. The first entity 104 sends the authentication context as shown in 504 and the random number as shown in 505 to the secondary entity 116. The information can be provided to the secondary entity 116 in one or more of a variety of different ways. For example, the information can be provided between the primary entity 104 and the secondary entity 116 using a network connection, device sharing, near field communication, a wireless connection, the user simply typing the information displayed on the primary entity 104 into the secondary entity 116, and the like.

[0034] The auxiliary entity 116 can perform various actions for authenticating the authentication context. For example, as previously described, the authentication context can be location information. The location information can be displayed to the user at the auxiliary entity 116. Then, the user (or the auxiliary entity 116 itself) can verify that the location information corresponds to the location of the main entity 104. In an alternative example, the authentication context can be an IP address. The auxiliary entity 116 can display the IP address in the authentication context to the user. If the user is able to determine the IP address of the main entity 104, the user can confirm that the IP address of the main entity 104 matches the IP address displayed by the auxiliary entity 116 from the authentication context. This can be implemented in many different ways. For example, in one embodiment, the main entity 104 can be configured to automatically display the IP address of the main entity 104 as part of the authentication process with the identity provider 110. However, if malware is installed on the main entity 104, the malware can spoof the IP address of the malicious entity and display the spoofed IP address at the main entity 104. Therefore, in an alternative, more secure example, the primary entity 104 may communicate with the secondary entity 116 and, as part of its communications, provide the secondary entity 116 with the IP address of the primary entity 104. The secondary entity 116 may then display to the user the IP address sent from the primary entity 104 as well as the IP address contained in the authentication context. The user may then compare the information displayed on the secondary entity 116 to determine whether the IP address of the primary entity 104 matches the IP address contained in the authentication context.

[0035] Once the authentication context has been verified at the secondary entity 116, the secondary entity 116 may sign the authentication context and the nonce and send the signed authentication context and nonce to the primary entity 104 as shown at 506. The primary entity 104 may then send the signed authentication context and nonce to the identity provider 110 as shown at 508. The identity provider 110 may verify the signature using standard cryptographic techniques. Additionally or alternatively, the identity provider 110 may verify that the authentication context sent from the identity provider 110 to the primary entity 104 at 502 matches the authentication context received back from the secondary entity 116 by the primary entity at 508. If all verifications pass, the identity provider 110 may then provide the primary entity 104 with a token as shown at 510, which the primary entity 104 may then use in an authenticated session with the identity provider 110.

[0036] Reference now Figure 6 , an alternative example embodiment is shown. Figure 6The primary entity 104 is shown sending a request as shown at 601 to the identity provider 110. The identity provider 110 responds to the request by sending an authentication context as shown at 602 and a random number as shown at 603 to the primary entity 104. The primary entity 104 provides the authentication context as shown at 604 to the secondary entity 116. The primary entity 104 also provides the random number as shown at 605 to the secondary entity 116. This information can be provided to the secondary entity 116 in one or more different ways. For example, the information can be provided between the primary entity 104 and the secondary entity 116 using a network connection, device sharing, near field communication, a wireless connection, a user simply typing information displayed on the primary entity 104 into the secondary entity 116, and the like.

[0037] and Figure 5 As in the examples shown in , the secondary entity can use the authentication context to perform various verification actions. For example, as shown above, the authentication context can include location information of the primary entity 104. The location information can be displayed at the secondary entity 116, and the user can be allowed to verify the location information on the secondary entity 116. Other examples of authentication context can be verified as shown above and in the examples shown below.

[0038] If the authentication context can be properly verified, the secondary entity 116 will sign the authentication context and the nonce and send the signed authentication context and nonce to the identity provider 110, as shown at 606. The identity provider 110 can verify the signature using standard encryption techniques. Additionally or alternatively, the identity provider 110 can verify that the authentication context sent from the identity provider 110 to the primary entity 104 at 602 matches the authentication context received back from the secondary entity 116 at 608. If all verifications pass, the identity provider 110 can provide the primary entity 104 with an appropriate token and, as shown at 607, allow the primary entity 104 to communicate in a secure session with the identity provider 110.

[0039] Reference now Figure 7 , shows another alternative example. Figure 7 In the example shown, the primary entity 104 sends a request as shown at 701 to the identity provider 110. In addition, as shown at 702, the primary entity 104 sends a session identifier corresponding to the request to the secondary entity 116. The information can be provided to the secondary entity 116 in one or more of a variety of different ways. For example, the information can be provided between the primary entity 104 and the secondary entity 116 using a network connection, device sharing, near field communication, a wireless connection, the user simply typing the information displayed on the primary entity 104 into the secondary entity 116, and the like.

[0040] As shown at 703, the secondary entity 116 uses the session identifier in communications with the identity provider. The identity provider 110 receives the session identifier from the secondary entity 116 and in response sends an authentication context as shown at 704 and a random number as shown at 705. Again, the secondary entity 116 can perform various actions to verify the authentication context. For example, if the authentication context includes location information of the primary entity 104, the location information can be displayed at the secondary entity 116 so that the user can verify that the location information in the authentication context actually corresponds to the location of the primary entity 104. If the authentication context can be correctly verified at the secondary entity 116, the authentication context and random number are signed, and the signed authentication and random number are sent back from the secondary entity 116 to the identity provider 110, as shown at 706. The identity provider 110 can verify the signature using standard cryptographic techniques. Additionally or alternatively, the identity provider 110 can verify that the authentication context sent from the identity provider 110 at 704 matches the authentication context received back at the identity provider 110 at 706. In alternative or additional embodiments, a password, biometric, one-time code, or other credential may be entered at the secondary entity 116 and returned to the identity provider 110. The authentication may be verified at the identity provider 110. In any of the illustrated examples, if all verifications pass, the identity provider 110 may then provide the primary entity 104 with an appropriate token, as shown at 707, so that the primary entity 104 may engage in a secure connection with the identity provider 110.

[0041] Reference now Figure 8, yet another example embodiment is shown. In this example, the primary entity 104 sends a request as shown at 801 to the identity provider 110. In this particular example, the secondary entity 116 may have previously registered with the identity provider 110 to receive alerts when various actions are performed between the primary entity 104 and the identity provider 110. Therefore, in this example, as shown at 802 and 803, as a result of the secondary entity 116 previously registering with the identity provider 110 to receive notifications when the primary entity 104 attempts to request a secure connection with the identity provider 110, the authentication context and random number are automatically sent to the secondary entity 116. Once the secondary entity 116 receives the random number and the authentication context, the secondary entity 116 can perform various verification actions as shown above (and in further examples below) to verify the authentication context. Once the authentication context is verified, the authentication context and random number can be signed by the secondary entity 116, and the signed authentication context and random number can be sent to the identity provider 110, as shown at 804. The identity provider 110 can verify the signature using standard encryption techniques. Additionally or alternatively, the identity provider 110 may verify that the authentication context sent from the identity provider at 802 matches the authentication context received back at the identity provider 110 at 804. In alternative or additional embodiments, a password, biometric, one-time code, or other credential may be entered at the secondary entity 116 and returned to the identity provider 110. The authentication may be verified at the identity provider 110. In any illustrated examples, the identity provider 110 then provides the primary entity 104 with an appropriate token as shown at 805 to allow the primary entity 104 to participate in a secure connection with the identity provider 110. Embodiments may also be used to protect a second authentication factor. For example, in Figure 8 In the example, the initial request shown at 801 may include a first credential (a credential that a man-in-the-middle attacker can intercept). However, if two credentials are required to establish a session, the authentication context may be a second credential that can be protected in the manner described above.

[0042] Various details are now shown. For example, various different information can be used alone or together as authentication context. In particular, authentication context can generally be information related to a secure session between a main entity 104 and an identity provider 110. For example, authentication context can be location information of the main entity 104. Such location information can be based on the IP address of the main entity 104. In an alternative example, authentication context information can be only the IP address of the main entity 104. In another alternative example, authentication context can be information about the main entity 104, such as the device type of the main entity 104 or some other distinguishing features that can be transmitted during authentication and can be verified by checking the main entity 104. In another alternative example, authentication context can be authentication process flow state information. For example, authentication context can include information indicating what action a user is trying to perform. For example, authentication context can indicate that a user is trying to log in to a specific e-commerce website or other website. Authentication context can even have finer granularity, such as indicating that a user is about to purchase a specific product or that a user is requesting some other asset. In some embodiments, the token provided by the identity provider 110 may only be applicable to the action indicated in the authentication context. Thus, for example, if a user confirms that the authentication context is being used to purchase a specific book from a specific retailer, a malicious individual will not be able to use the issued token to purchase a different book from a different retailer.

[0043] The authentication context may be verified by the auxiliary entity 116 using various verification actions. For example, in some embodiments, the auxiliary entity 116 may display the authentication context to the user and receive user input confirming that the authentication context is accurate. In an alternative example, the auxiliary entity 116 may receive the authentication context and compare the authentication context with known information. For example, the auxiliary entity 116 may receive an authentication context indicating that the main entity 104 has a specific IP address from the identity provider 110. In addition, in ordinary communication with the main entity 104, the auxiliary entity 116 may receive IP information directly from the main entity 104. The auxiliary entity 116 may automatically compare the IP address received directly from the main entity 104 with the IP address contained in the authentication context to determine whether they match within a predetermined standard. If the IP address received from the main entity 104 matches the IP address in the authentication context, the auxiliary entity 116 may allow the authentication to proceed, and if the IP address received directly from the main entity 104 does not match the IP address in the authentication context received from the identity provider 110, the authentication may be stopped.

[0044] In other examples, the identity provider 110 may receive an authentication context, such as an IP address, from the primary entity 104 or the secondary entity 116, but may receive an asserted IP address outside of the authentication context that may be compared to determine whether a man-in-the-middle attacker is likely attempting to hijack the secure connection between the primary entity 104 and the identity provider 110.

[0045] The following discussion now relates to many methods and method actions that can be performed. Although method actions may be discussed in a particular order or shown in a flowchart as occurring in a particular order, a particular order is not required unless specifically stated or required because an action depends on another action being completed before the action is performed.

[0046] Reference now Fig. 9 , method 900 is shown. Method 900 can be practiced in a computing environment. Method 900 includes actions for authenticating a secure session between a first user entity and an identity provider using a second user entity. The method includes receiving a session request from an entity claiming to be the first user entity (action 902). For example, Figure 1 Request 108 is shown received by identity provider 110 from primary entity 104. Figure 3 In the illustrated alternative example, identity provider 110 receives request 108 ′ from man-in-the-middle attacker 106 purporting to be primary entity 104 .

[0047] Method 900 also includes sending the authentication context from the request, and wherein the authentication context of the request reaches the second user entity (action 904). Figure 1 As shown, the authentication context 114 is sent to the primary entity 104, which then sends the authentication context 114 to the secondary entity 116. Figure 2 In the alternative example shown, the authentication context is sent directly to the auxiliary entity 116 .

[0048] Method 900 also includes receiving an indication that the authentication context has been verified (act 906). Figure 4 As shown, the authentication context is signed by the secondary entity 116, and the signed authentication context is passed to the primary entity 104, which then passes the signed authentication context back to the identity provider 110. Figure 6 In the illustrated alternative example, the authentication context is signed at the auxiliary entity 116 , and the signed authentication context is passed directly from the auxiliary entity 116 to the identity provider 110 .

[0049] As a result, method 900 also includes authenticating the secure session between the first user entity and the identity provider or approving the secure transaction (action 908). Figure 5 ,6 , 7, and 8 each show a token being passed from the identity provider 110 back to the host entity 104, which the host entity 104 and the identity provider 110 can use in establishing and maintaining a secure session. Part of establishing a secure connection and / or verifying the authentication context can include the identity provider verifying that both the authentication context and the indication that the context has been verified have not been tampered with by the first entity or a middleman. For example, the identity provider 110 can verify that the authentication context sent by the identity provider 110 matches the signed authentication context received back at the identity provider.

[0050] The method 900 may be practiced wherein the authentication context includes a location of the first user entity. Figure 1 As shown, the location of the primary entity 104 can be displayed on the screen of the secondary entity 116 to allow the user 102 to verify the location of the primary entity 104. The location of the primary entity 104 can be determined based on an IP address sent from the primary entity 104 to the identity provider 110, where the identity provider can then use the IP address to determine the location of the primary entity 104.

[0051] The method 900 may be practiced wherein the authentication context includes an IP address of the first user entity. Figure 1 As shown, the secondary entity 116 can display the IP address of the primary entity 104. The user 102 can then verify that the IP address of the primary entity 104 matches the IP address displayed by the secondary entity 116.

[0052] The method 900 may be practiced wherein the authentication context includes process flow information regarding authentication between the first user entity and the identity provider. Figure 1 As shown, the authentication context 114 may include an indication of the purpose of the authentication by the primary entity 104 to the identity provider 110. For example, the primary entity 104 may be attempting to complete the purchase of a product from an e-commerce site using the identity provider 110. The secondary entity 116 may display an indication to the user 102 that the authentication context 104 indicates that a session between the primary entity 104 and the identity provider 110 is attempting to complete. The user 102 may then verify that they are indeed attempting to perform the action indicated in the authentication context 114 displayed at the secondary entity 116.

[0053] The method 900 may be practiced where the requested authentication context reaches the second user entity for verification at the second user entity by being sent directly to the second user entity by the identity provider. Figure 7 and 8 An example is shown where the authentication context is sent directly to the auxiliary entity 116 .

[0054] Some such embodiments of method 900 may be practiced where the authentication context is automatically sent to the second user entity as a result of receiving a request for a session as a result of the second user entity subscribing to receive notifications. For example, primary entity 104 and secondary entity 116 may subscribe to identity provider 110. When a request is received at identity provider 110 from primary entity 104, identity provider 110 may automatically send the authentication context of secondary entity 116.

[0055] The method 900 may be practiced where the requested authentication context reaches the second user entity to be verified at the second user entity by being sent directly by the identity provider to the first user entity and then the first user entity sends the authentication context to the second user entity. Figure 5 and 6 An example is shown in which an authentication context is received at a primary entity 104 and then sent from the primary entity 104 to a secondary entity 116. The primary entity 104 may send the authentication context from the primary entity 104 to the secondary entity 116 using a variety of functions, such as near field communication, displaying a QR code, wireless connection, network connection, providing data to a user so that the user can enter the data into the secondary entity 116, etc.

[0056] The method 900 may be practiced where receiving an indication that the authentication context has been verified at the second user entity includes receiving the authentication context signed by the second user entity. Figure 5 , 6 , 7 and 8 show the case where the authentication context is signed by the auxiliary entity 116 and the signed authentication context is returned to the identity provider 110 .

[0057] The method 900 may be practiced where the authentication context is verified at a second user entity by receiving user input indicating that the authentication context is valid. For example, the authentication context may be displayed at the secondary entity 116 so that the user 102 may verify that the authentication context is valid with respect to the primary entity 104. For example, the user 102 may use the secondary entity 116 to indicate that the location displayed as the authentication context is correct for the primary entity 104, that the IP address displayed as the authentication context is correct for the primary entity 104, or that the financial transaction indicated in the authentication context is consistent with the financial transaction that the user 102 is attempting to perform.

[0058] The method 900 may be practiced where authenticating a secure session between the first user entity and the identity provider or approving a secure transaction includes sending one or more tokens from the identity provider to the first user entity. Figure 5 , 6 , 7 and 8 show the token delivered from the identity provider 110 to the host entity 104.

[0059] Reference now Fig.10 , a method 1000 is shown. The method can be practiced in a computing environment. The method includes actions for authenticating a secure session between a first user entity and an identity provider using a second user entity. Note that an entity can be a device, a virtual device, an application, etc.

[0060] Method 1000 includes a user using a first entity to request a secure session with identity provider 110, wherein the request is associated with an authentication context of the first entity (act 1002). Figure 1 As shown, user 102 may use primary entity 104 to send a request 108 to identity provider 110 requesting a secure session between primary entity 104 and identity provider 110. Authentication context 114 may be, for example, a location, an IP address, a device type corresponding to primary entity 104, a user agent of primary entity 104, an action attempted to be performed using the secure session, and the like.

[0061] Method 1000 also includes the user receiving the authentication context of the first entity from the second entity (act 1004 ). For example, user 102 may receive authentication context 114 by viewing the authentication context on secondary device 116 .

[0062] Method 1000 also includes the user confirming that the authentication contexts from the first entity and the second entity match according to some predetermined criteria (act 1006 ).For example, user 102 may interact with auxiliary entity 116 to verify displayed authentication context 114 .

[0063] The method 1000 may be practiced where the second entity receives the authentication context of the first entity from the first entity. For example, the user 102 may view the authentication context 114 at the primary entity 104 as a result of the authentication context being sent directly from the identity provider 110 to the primary entity 104. Alternatively, the user 102 may receive the authentication context 114 at the primary entity 104 as a result of the authentication context being sent to the secondary entity 116 and then to the primary entity 104.

[0064] Method 1000 may be practiced where a second entity receives an authentication context from identity provider 110. For example, auxiliary entity 116 may receive authentication context 114 from an identity provider, such as in Figure 7 In the example shown.

[0065] The method 1000 may be practiced where the authentication context is signed by the second entity. For example, the secondary entity 116 may sign the authentication context, as shown in the various figures.

[0066] The method 1000 may be practiced where the authentication context is received by the second entity using one or more of near field communication, Bluetooth, scanning a QR code, Wi-Fi, a peer connection, ZigBee, a network connection, and the like.

[0067] The method 1000 may be practiced where the authentication context is received from the identity provider 110 to the second entity via one or more of an established notification channel, SMS messaging, a secure authenticated connection, and the like.

[0068] In addition, the method can be implemented by a computer system including one or more processors and a computer-readable medium such as a computer memory. In particular, the computer memory can store computer-executable instructions that cause various functions such as the actions recorded in the embodiments to be performed when executed by one or more processors.

[0069] Embodiments of the present invention may include or utilize a special or general-purpose computer including computer hardware, as discussed in more detail below. Embodiments within the scope of the present invention also include physical and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media can be any available media that can be accessed by a general or special-purpose computer system. The computer-readable medium that stores computer-executable instructions is a physical storage medium. The computer-readable medium that carries computer-executable instructions is a transmission medium. Therefore, by way of example and not limitation, embodiments of the present invention may include at least two distinct computer-readable media: a physical computer-readable storage medium and a transmission computer-readable medium.

[0070] Physical computer-readable storage media include RAM, ROM, EEPROM, CD-ROM or other optical disk storage (such as CD, DVD, etc.), magnetic disk storage or other magnetic storage devices, or any other media that can be used to store desired program code means in the form of computer-executable instructions or data structures and can be accessed by a general or special purpose computer.

[0071] A "network" is defined as one or more data links capable of transmitting electronic data between computer systems and / or modules and / or other electronic devices. When information is transmitted or provided to a computer via a network or other communication connection (hardwired, wireless, or a combination of hardwired or wireless), the computer correctly views the connection as a transmission medium. Transmission media may include networks and / or data links that can be used to carry desired program code devices in the form of computer executable instructions or data structures and that can be accessed by general or special computers. Combinations of the above are also included within the scope of computer-readable media.

[0072] Furthermore, upon reaching various computer system components, program code means in the form of computer executable instructions or data structures may be automatically transferred from a transmission computer readable medium to a physical computer readable storage medium (or vice versa). For example, computer executable instructions or data structures received over a network or data link may be buffered in RAM within a network interface module (e.g., a "NIC") and then ultimately transferred to computer system RAM and / or to a less volatile computer readable physical storage medium in the computer system. Thus, a computer readable physical storage medium may be included in a computer system component that also (or even primarily) utilizes a transmission medium.

[0073] Computer executable instructions include, for example, instructions and data that cause a general-purpose computer, a special-purpose computer, or a special-purpose processing device to perform a specific function or group of functions. Computer executable instructions can be, for example, binary files, intermediate format instructions such as assembly language, or even source code. Although the subject matter is described in a language specific to structural features and / or method actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the features or actions described above. On the contrary, the described features and actions are disclosed as example forms of implementing the claims.

[0074] Those skilled in the art will appreciate that the present invention can be practiced in a network computing environment with many types of computer system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, pagers, routers, switches, etc. The present invention can also be practiced in a distributed system environment, in which local and remote computer systems linked by a network (by a hardwired data link, a wireless data link, or by a combination of a hardwired and wireless data link) all perform tasks. In a distributed system environment, program modules can be located in both local and remote memory storage devices.

[0075] Alternatively or additionally, the functions described herein may be performed at least in part by one or more hardware logic components. For example, and not limitation, illustrative types of hardware logic components that may be used include field programmable gate arrays (FPGAs), program-specific integrated circuits (ASICs), program-specific standard products (ASSPs), systems on chips (SOCs), complex programmable logic devices (CPLDs), and the like.

[0076] The present invention may be implemented in other specific forms without departing from the spirit or features of the present invention. The described embodiments should be considered in all respects as merely illustrative and not restrictive. Therefore, the scope of the present invention is indicated by the appended claims rather than the preceding description. All changes within the meaning and equivalent range of the claims are included within their scope.

Claims

1. A method for authenticating a secure session between a first entity of a user and an identity provider in a computing environment by using a second entity of the user, the method comprising: At a first entity of the user, sending a request for a secure session to an identity provider; receiving, at a second entity of the user, an authentication context based on the request, wherein the authentication context is prepared by the identity provider; verifying at the second entity of the user that the received authentication context corresponds to the first entity of the user, wherein the verification comprises: bypassing user approval for the verification when an Internet Protocol (IP) address of the first entity of the user is detected to share certain similar characteristics with an IP address of the second entity of the user; Based on the verification, the second entity authenticates the authentication context; receiving, at the identity provider, the authenticated authentication context; and As a result, the identity provider authenticates a secure session or approves a secure transaction between the first entity of the user and the identity provider. 2 . The method of claim 1 , wherein the second entity receives the authentication context from the first entity. 3 . The method of claim 1 , wherein the authentication context comprises one of: a location of the first entity of the user, or the IP address of the first entity of the user.

4. The method of claim 1, wherein the authentication context is received by the second entity using one or more of: near field communication, Bluetooth, scanning a QR code, Wi-Fi, Ethernet, ZigBee, or a peer-to-peer connection. The method of claim 1 , wherein the second entity receives the authentication context from the identity provider.

6. The method of claim 1, wherein the authentication context comprises a location of the first entity, and the location is received at the second entity from the identity provider via one or more of: an established notification channel, SMS, or a secure authenticated connection.

7. The method of claim 1, wherein the authentication context comprises at least one of: the IP address of the first entity, the location of the first entity, or process flow information regarding authentication between the first entity and the identity provider.

8. The method of claim 1, wherein the authentication context is included in a push notification pushed to the second entity.

9. A computer system comprising: one or more processors; as well as One or more computer-readable hardware storage devices having computer-executable instructions stored thereon, the computer-executable instructions being executable by the one or more processors to cause the computer system to authenticate a secure session between a first entity of the user and an identity provider by using the computer system as a second entity of the user to perform at least the following operations: in response to a request for a secure session being sent from the first entity of the user to the identity provider, receiving an authentication context based on the request, wherein the authentication context is prepared by the identity provider; verifying that the received authentication context corresponds to the first entity of the user, wherein verifying that the received authentication context corresponds to the first entity of the user comprises: bypassing user approval for the authentication when an Internet Protocol (IP) address of the first entity of the user is detected to share certain similar characteristics with an IP address of the second entity of the user; authenticating the authentication context based on the verification; and The authenticated authentication context is sent to the identity provider.

10. The computer system of claim 9, wherein the computer system receives the authentication context from the first entity.

11. The computer system of claim 9, wherein the authentication context comprises one of: a location of the first entity of the user, or the IP address of the first entity of the user.

12. The computer system of claim 9, wherein the authentication context is received by the computer system using one or more of: near field communication, Bluetooth, scanning a QR code, Wi-Fi, Ethernet, ZigBee, or a peer-to-peer connection.

13. The computer system of claim 9, wherein authenticating the authentication context comprises signing the authentication context at the second entity.

14. A method of authenticating a secure session between a first entity of a user and an identity provider using a second entity of the user, the method comprising: At a first entity of the user, sending a request for a secure session to an identity provider; receiving, at a second entity of the user, an authentication context based on the request, wherein the authentication context is prepared by the identity provider; verifying at the second entity of the user that the received authentication context corresponds to the first entity of the user, wherein the verification comprises: bypassing user approval for the verification when an Internet Protocol (IP) address of the first entity of the user is detected to share certain similar characteristics with an IP address of the second entity of the user; Based on the verification, the second entity signs the authentication context to authenticate the authentication context; receiving, at the identity provider, the authenticated authentication context; and As a result, the identity provider authenticates a secure session or approves a secure transaction between the first entity of the user and the identity provider.

15. The method of claim 14, wherein the authentication context comprises one of: a location of the first entity of the user, or the IP address of the first entity of the user.

16. The method of claim 14, wherein the authentication context is received by the second entity using one or more of: near field communication, Bluetooth, scanning a QR code, Wi-Fi, Ethernet, ZigBee, or a peer-to-peer connection.

17. The method of claim 14, wherein the authentication context comprises at least one of: the IP address of the first entity, the location of the first entity, or process flow information regarding authentication between the first entity and the identity provider.

18. The method of claim 14, wherein the authentication context is included in a push notification pushed to the second entity.

19. The method of claim 14, wherein the first entity is a phone, and wherein the second entity is a web browser executing on a device other than the phone.

Images