Method and system for securing vpn communications

Abstract

Methods and systems for authenticating a client device for access to a resource server using an access token include generating a session key for a communication session between the device and the resource server, deriving a random number from the session key, and sending a request to an identity platform to authenticate the device for access to the resource server, where the request includes the random number. Upon confirmation of the authentication, the methods and systems can include receiving an access token from the identity platform, the access token including information confirming the authentication of the device, and sending the access token to the resource server to support access to the resource server, where the access token includes the random number.

Description

Technical Field

[0001] This disclosure generally relates to securely connecting to a Virtual Private Network (VPN), and more specifically, to methods and systems for securing VPN tunnels using token-based authentication. Background Technology

[0002] VPNs are typically used to enable users to transfer data from their devices across shared or public networks to a private network as if their devices were directly connected to the private network. This allows applications running on the VPN to benefit from the security and management of the private network. To ensure security and proper authentication, VPN servers typically perform authentication functions to authorize users to access the VPN server. This can require the VPN server to expend significant memory and processor resources on authentication functions. Sometimes, in addition to being an authorized user, other conditions must be met to access the VPN server. Some of these conditions may be related to the device's state. To ensure these conditions are met, the VPN server can query devices to verify one or more of the device's state. However, the process of querying various devices to verify their state can require considerable bandwidth and processor resources.

[0003] Therefore, there is a need for improved methods and systems for authenticating VPN users and / or protecting VPN tunnels. Summary of the Invention

[0004] To address these and other issues, in a general sense, this paper describes a device having a processor and memory communicating with the processor, wherein the memory stores executable instructions that, when executed by the processor, cause the device to perform multiple functions. These functions may include generating a session key for a communication session between the device and a resource server, obtaining a random number from the session key, sending a request to an identity platform to authenticate the device for access to the resource server, the request including the random number, receiving an access token from the identity platform after authentication confirmation, the access token including information confirming the device's authentication, and sending the access token to the resource server to support access to the resource server, wherein the access token includes the random number.

[0005] In another general aspect, this application describes a method for generating an access token for providing access to a resource server. The method may include receiving a request from a device to provide an access token to the device for accessing the resource server, the request including a random number derived from a session key generated for a communication session between the device and the resource server; determining whether the device is authorized to access the resource server; in response to determining that the device is authorized to access the resource server, generating an access token that includes the random number in the access token; and sending the access token to the device.

[0006] In other general aspects, this application describes a non-transient computer-readable medium having stored instructions that, when executed, cause a programmable device to generate a session key for a communication session between the programmable device and a resource server, obtain a random number from the session key, send a request to an identity platform to authenticate the programmable device for accessing the resource server, the request including the random number, and, upon confirmation of authentication, receive an access token from the identity platform, the access token including information confirming the authentication of the programmable device, and send the access token to the resource server to support access to the resource server, wherein the access token includes the random number.

[0007] This summary is provided to present, in a simplified form, the selection of concepts further described in the detailed description below. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that address any or all of the shortcomings pointed out in any part of this disclosure. Attached Figure Description

[0008] The accompanying drawings depict one or more implementations of this teaching, and are by way of example only and not limitation. In the drawings, the same reference numerals refer to the same or similar elements. Furthermore, it should be understood that the drawings are not necessarily drawn to scale.

[0009] Figure 1 Example systems on which various aspects of this disclosure can be implemented are described.

[0010] Figures 2A to 2B A simplified example layout for providing access tokens to authenticate client devices is depicted.

[0011] Figure 3 This is a flowchart depicting an example method for requesting and receiving access tokens to authenticate a client device to a resource server.

[0012] Figure 4 This is a flowchart describing an example method for generating access tokens used to authenticate client devices to access a resource server.

[0013] Figure 5 This is a block diagram illustrating an example software architecture, the parts of which can be used in conjunction with various hardware architectures described herein.

[0014] Figure 6 This is a block diagram illustrating the components of an example machine configured to read instructions from a machine-readable medium and execute any of the features described herein. Detailed Implementation

[0015] In the detailed description below, many specific details are illustrated by way of examples to provide a thorough understanding of the relevant teachings. It will be apparent to those skilled in the art, after reading this description, that the various aspects can be practiced without such details. In other cases, to avoid unnecessarily obscuring aspects of the teachings, well-known methods, processes, components, and / or circuits have been described at a relatively high level without detail.

[0016] VPN tunnels are typically used to securely and privately connect personal client devices to external networks. However, to use a VPN service, a user must first provide authentication information that ensures they have authorization to access the VPN. Traditionally, the VPN server performs the authentication and authorization process itself. This can involve multiple data exchanges with the client device and / or a remote authentication service such as Remote Authentication Dial-In User Service (RADIUS). This process typically requires the use of memory, processor, and / or bandwidth resources.

[0017] In addition to requiring a client device associated with an authorized user, some services (e.g., VPN services) may expect certain conditions to be met to allow continued access to the service. In some cases, these conditions relate to the device's state, such as having a specific operating system, not being jailbroken, etc. In this disclosure, these conditions are referred to as conditional access policies. To ensure that conditional access policies are met, VPN servers typically query devices to identify their latest state. This is performed after the user is authenticated. However, device state can change during a session. To be able to detect changes in device state, VPN servers typically query each device for the entire duration of the session to ensure that the policy continues to be met. This can require significant hardware and / or software resources. Due to the amount of resources required to query each client device to ensure that conditional access policies are met, most VPN servers query each device only occasionally (e.g., once per hour). This naturally leads to a slow response to changes in device state, as there can be a period of time between a device state change and the VPN server identifying the changed state. Furthermore, having the VPN server verify compliance with conditional access policies can result in a degraded end-user experience. Therefore, having the VPN server itself verify compliance with conditional access policies could not only require significant bandwidth, memory, and processor resources, but could also result in slow response to changes in state, poor performance, and / or a degraded user experience.

[0018] To address these technical challenges and more, this description provides a technical solution for efficiently authenticating resource server users by leveraging tokens issued by an identity platform. The identity platform used for user authentication can be decoupled from the resource server (e.g., a VPN server). The identity platform performs the necessary authentication process and issues an access token to the user once authenticated. The access token may include information identifying the user and verifying that the token was issued by the appropriate identity platform. The access token can then be sent to a resource client (e.g., a VPN client), which can use the token to access the resource server. In this way, the user authentication process is performed by an entity outside the resource server, thereby reducing the amount of processor, memory, and bandwidth resources used by the resource server. Furthermore, by using tokens, the authentication process becomes simpler and more efficient.

[0019] In some implementations, the process of ensuring that conditional access policies are met when access to a resource server is permitted can be performed as part of the authentication process. The authentication process may involve an identity platform and / or verification platform verifying the conditional access policies before issuing an access token. In one implementation, the access token may include an instruction specifying that the device conforms to the conditional access policies. Therefore, this technical solution provides an improved method for authenticating resource server users and ensuring that the user's client devices conform to conditional access policies. This improved method increases efficiency and saves computing resources.

[0020] Tokens used to access Transport Layer Security (TLS) sessions are vulnerable to replay attacks. For example, a token from a client device can be deduced and used by different devices to access a VPN server. To prevent this, this description provides a technical solution for some implementations to enhance the security features provided by the access token by adding a cipher indication (e.g., a random number) to it. To create the cipher indication, a session master key can first be generated for each session. The session master key can then be manipulated to generate a cipher indication associated with a specific session. This may involve generating a hash of the session master key. In this way, the cipher indication can be calculated independently by both the client and the resource server and cannot be deduced by an external attacker. As a result, attempts to use the access token outside the channel will fail because the cipher indication calculated by the resource server will not match the cipher indication in the deduced token. Therefore, this technical solution provides an effective mechanism to provide additional security when performing authentication processes remotely.

[0021] As those skilled in the art will understand upon reading this disclosure, the benefits and advantages provided by such technical solutions may include, but are not limited to, solutions to technical problems related to inefficient authorization for resource server users and inefficient verification of compliance with conditional access policies. Furthermore, the benefits and advantages provided by such technical solutions include providing additional security by effectively preventing unauthorized use of access tokens. The benefits provided by such solutions include improved resource server efficiency, enhanced user experience, and increased security.

[0022] Figure 1 An example system 100 is illustrated on which aspects of this disclosure may be implemented. System 100 may include a resource server 110, which may be a VPN server capable of facilitating VPN communication between client device 120 and a public network or the Internet 150. Resource server 110 may be operable to establish a tunnel (e.g., a VPN tunnel) between resource client 140 and resource server 110. Data transmitted through this tunnel may be encrypted to provide privacy and / or security. Thus, resource server 110 can provide secure and private communication between client devices (such as client device 120) and the Internet 150. Resource server 110 may operate as a shared resource server accessible by various computer client devices (such as client device 120).

[0023] Network 130 can be a wired or wireless (multiple) network, or a combination of wired and wireless networks, connecting one or more components of system 100. Client device 120 can be any type of device capable of receiving input from a user and communicating with network 130 to send and receive data. Such client devices can include personal or handheld computing devices with or connected to input and output elements. For example, client device 120 can be one of the following: mobile phone; smartphone; tablet computer; flatbed truck; smartwatch; wearable computer; personal computer; desktop computer; laptop computer; gaming device / computer; television; fat client; thin client; browser-based client, etc. This list is for illustrative purposes only and should not be considered limiting. The internal hardware structure of the client device is as follows: Figure 5 and Figure 6 It will be discussed in more detail.

[0024] In some implementations, client device 120 includes resource client 140 (e.g., a VPN client). Resource client 140 may be an application (e.g., a software program) installed on client device 120 to establish and manage connections between resource client 140 and resource server 110. Therefore, resource client 140 may be provided to provide access to resources (e.g., VPN services) of resource server 110. For example, a VPN client is typically provided on client device 120 to establish a VPN connection with a VPN server and manage VPN tunnels used for VPN communication with the VPN server. In some implementations, resource client 140 operates automatically in the background. Alternatively and / or additionally, resource client 140 may provide one or more user interfaces (UIs) that enable users to interact with and / or configure resource client 140.

[0025] To ensure that users are authorized to use resource server 110 and / or to verify that client device 120 is communicating with the correct resource server 110, authentication is required before a tunnel for communication can be established. To avoid the need for resource server 110 to perform authentication operations itself, the technical solutions described in this application provide a token-based authentication mechanism, where the token is generated by an entity independent of resource server 110. In some implementations, this is achieved by utilizing identity platform 160. Identity platform 160 may be an application (e.g., a software program) that provides client authentication, identity, and / or access management. Identity platform 160 may include authentication server 170, security token server 180, and / or one or more application programming interfaces (APIs) for managing user identity and authorization. In some implementations, identity platform 160 also includes a web interface (not shown) to enable administrators and / or users to interact with identity platform 160.

[0026] Identity platform 160 can assist client device 120 in adding identity and access management functionality to resource client 140. Therefore, identity platform 160 can receive requests from resource client 140 to authenticate client device 120 for access to resource server 110. In response, identity platform 160 can perform authentication operations to authenticate client device 120. In some implementations, authenticating client device 120 may involve communicating with authentication server 170. Authentication server 170 can provide one or more UIs that allow users to interact with authentication server 170 to provide authentication information. For example, authentication server 170 can provide one or more UIs to allow users to provide log information (e.g., username, password, etc.). Once authentication information (e.g., log information, device identification information, etc.) is received, authentication server 170 can determine whether the user is authorized to access resource server 110. This can be done by comparing the received authentication information with authentication information stored in user data storage (e.g., user authentication database) to confirm that the received information matches the stored information. Once the user and / or client device 120 is authenticated, the authentication server 170 can send authentication data to the identity platform 160. The identity platform 160 can then generate an access token. In some implementations, the access token is generated by the security token server 180. Alternatively, the authentication server 170 can generate the access token itself and send it to the identity platform 160. In such an implementation, the identity platform 160 can be responsible for communicating with the authentication server 170 and / or storing and managing the access tokens. The identity platform 160 can send the access token to the resource client 140 for communication with the resource server 110. In some implementations, the identity platform 160 is stored on a server and can be accessed by one or more client devices via network 130. Alternatively and / or additionally, the identity platform 160 can be stored and / or operated from the client device 120.

[0027] In some implementations, in addition to providing identity and access management functions, identity platform 160 verifies compliance with conditional access policies. For example, when resource server 110 requests compliance with certain conditional access policies, these policies can be transmitted to identity platform 160. Identity platform 160 can then query client device 120 or a device management provider (not shown) managing client device 120 for the status related to the conditional access policies. In response to receiving the status, identity platform 160 can check the status to confirm compliance. For example, identity platform 160 can request client device 120 to provide information about the latest operating system used by client device 120. In response, client device 120 can identify and send information identifying the latest operating system to identity platform 160. Identity platform 160 can compare the identified operating system with the conditional access policies to determine whether the identified operating system complies with the requirements. Therefore, instead of resource server 110 having to perform post-authentication compliance verification, identity platform 160 can directly cooperate with client device 120 and / or the client device's device management provider to obtain the latest device status. Once compliance is confirmed, the identity platform 160 can include an indication that the device complies with the access policy in the access token.

[0028] Once authentication confirmation is received from authentication server 170, identity platform 160 can generate an access token. Alternatively, authentication server 170 can generate its own access token and send it to identity platform 160. In such an implementation, identity platform 160 can be responsible for communicating with authentication server 170 and / or storing and managing access tokens.

[0029] Figure 2A A simplified example arrangement of a data stream used to provide access tokens for authenticating client devices is shown. As illustrated, data stream 200A can begin when client device 120 sends an access request to resource client 140. For example, this can be initiated by a user of client device 120 launching resource client 140. Alternatively, it can occur when a user utilizes the UI functionality provided by resource client 140 to request access to resource server 110. In another implementation, the process can be started in the background without direct user intervention. For example, it can be started when a web browser is opened.

[0030] Once an access request is received, resource client 140 can send an authentication request to identity platform 160. Once it is confirmed that the user is authorized to access resource server 110, identity platform 160 can send an access token to resource client 140. The access token may include information confirming that the user is authenticated and authorized to access resource server 110. Furthermore, when compliance with a conditional access policy is required, the access token may contain information confirming that client device 120 meets the conditional access policy requirements. For example, if client device 120 meets the conditional access policy requirements, the flags included in the access token can be checked. In some implementations, the access token may include one or more claims. One of these claims may provide an indication that the user is authenticated and authorized to access resource server 110 (e.g., the client device is an authorized device). Another of these claims may provide an indication that client device 120 complies with the conditional access policy requirements.

[0031] This access token can then be sent by resource client 140 to resource server 110. If necessary, resource server 110 can examine the access token to ensure that it includes information verifying that user / client device 120 is authorized to access resource server 110 and complies with any conditional access policies. If the access token includes the required information (e.g., a required statement), resource server 110 can grant access to protected resources (e.g., providing a protected tunnel for secure and / or private communication with the Internet).

[0032] Using access tokens to authenticate and verify compliance with conditional access policies improves system efficiency and can also enhance user experience. However, access tokens are vulnerable to replay attacks, where attackers can spoof and replay the token. To prevent this, in some implementations, a random number obtained by the client device 120 can be included in the access token. The random number, as used herein, can refer to a published random number or a pseudo-random number to ensure that communication cannot be reused in a replay appendage. The random number can also be obtained independently by the resource server 110 to ensure authenticity. However, since the random number is not directly sent by the client device 120 or the resource server 110, it cannot be inferred by an external attacker.

[0033] Figure 2B A simplified example arrangement of a data stream for providing an access token including a random number is shown. As shown, data stream 200B can begin when client device 120 sends an access request to resource client 140. This can be related to the above regarding... Figure 2A The process can be initiated in a similar manner as discussed. For example, the process can be initiated by a user of client device 120 that starts resource client 140.

[0034] Once the access request is received, resource client 140 can initiate a key exchange operation with resource server 110. The key exchange operation may include first sending a request to resource server 110 to initiate communication. As part of the communication initiation request, resource client 140 may securely send a portion of the encrypted session key to resource server 110. In response, resource server 110 may send a different portion of the encrypted session key to resource client 140. In some implementations, this is performed via a Diffie-Hellman key exchange operation. The key exchange may involve perfect forward secrecy, where even if the key is included, only a small portion of the key may be exposed. In this way, resource server 110 may have a portion of the key, while resource client 140 may have a different portion of the key. After the exchange, both resource server 110 and resource client 140 may have both portions of the key, which can constitute the complete key. These two separate portions can then be used by resource server 110 and resource client 140 to separately generate the complete key. In this way, only resource server 110 and resource client 140 can have the complete key. This complete key is referred to as the master session key in this document.

[0035] In some implementations, the master session key can include information about the active communication session. This is because a communication session (e.g., a TLS session) involves state generated on both sides of the session (e.g., on the client and server). This state can be included in the exchanged key, making the key bound to the active communication session. In this way, even if the master session key is leaked, different devices will not be able to successfully replay the token because the session information contained in the master session key will be incorrect.

[0036] Following key exchange communication, resource client 140 can create a master session key based on the information exchanged with resource server 110. Once the master session key is generated, resource client 140 can obtain a random number from it. In some implementations, the random number is a hash of the master session key. This provides an added layer of security, preventing the master session key from being spoofed during communication. The generated random number can only be used in the current session because it contains information that associates the random number with the current session.

[0037] Once a random number is generated, an authentication request can be sent from resource client 140 to identity platform 160 to provide an access token. This request may include the random number. Upon receipt, identity platform 160 can include the random number in its generated access token. In some implementations, the random number may be included as one of one or more indicators included in the access token. The resulting access token with the random number is then sent to resource client 140.

[0038] Once received, resource client 140 can send an access token including a random number to resource server 110 to initiate communication. In response, resource server 110 can create a random number derived from its generated master session key and compare that random number with the random number included in the access token. If the random number provided in the access token matches the random number generated by resource server 110, resource server 110 determines that the access token is a valid access token from an authorized user. This proves that the token has not been replayed outside the original session. As a result, resource server 110 can securely provide access to resources (e.g., VPN tunneling). This improves security and can prevent external attacks when the access token is used.

[0039] Figure 3 This is a flowchart describing an example method 300 for requesting and receiving access tokens to authenticate a client device's access to a resource server. In some implementations, the steps of method 300 are handled by the resource client (such as...). Figure 1 The resource client 140) executes. At 305, method 300 can begin by receiving a request to access the resource server. This can be initiated when a request to start the resource client is received. Alternatively, it may occur when a user's request to access the resource server and / or access the network using UI features provided by the resource client is received.

[0040] Once the request to access the resource server is received, at 310, method 300 can proceed to sending a request for authentication. This can be achieved, for example, by the resource client sending an authentication request to the identity platform. In an implementation where a random number is used to enhance security, the random number can be sent as part of the authentication request. The identity platform can then perform the authentication operations required to authenticate the client device / user. Once the identity platform confirms that the client device / user is authorized to access the resource server, it can send an access token to the resource client. Therefore, at 315, method 300 can receive the access token. The access token can be received from the identity platform and may include information confirming authentication and / or compliance with conditional access policies. Furthermore, the access token may include a random number derived from the master session key of the current session. After receiving the access token, method 300 can proceed to sending the access token to the resource server at 320. This allows the resource server to verify whether the client device / user is authorized to access the resource server without having to perform the authentication process itself.

[0041] Figure 4 This is a flowchart describing an example method 400 for generating access tokens used to authenticate client devices accessing a resource server. In some implementations, method 400 may be provided by an identity platform (such as...) Figure 1Identity platform 160) and / or authentication server (such as Figure 1 The authentication server (170) in the network performs this operation. At 405, method 400 can begin by receiving a request to provide an access token. This can occur when a resource client (such as a VPN client) sends a request for an access token to the resource server to authenticate the client device. The request can be received over the network and can include information identifying the resource client and / or the client device from which the request is received. In some implementations, the request may also include a random number derived from the master session key for the current session included in the access token.

[0042] Upon receiving the request, method 400 can proceed at 410 to determine whether a valid access token is available for the client device identified in the request. This may occur, for example, when a request for an access token is received and an access token is generated for the client device within the most recent predetermined time period (e.g., the last hour). For example, there may be a time limit associated with the token, and the token may be determined to be invalid when that time limit expires. In some examples, the access token may be valid for only one hour. In other examples, the access token may be valid for 24 hours. Other configurations are also possible. For example, the validity of the access token may depend on parameters other than time or on a different parameter than time. In implementations that use random numbers to enhance security, a random number can be added to the valid access token once a valid access token is identified. This is because the random number is associated with the active session, so even if a valid access token is available, it may not have the correct random number.

[0043] When it is determined that a valid access token is available to the client device (Yes at 410), method 400 may proceed to step 425 to determine whether compliance with the conditional access policy is required, as discussed further below. However, when it is determined that a valid access token is not available to the client device (No at 410), method 400 may proceed to step 415 to determine whether the client device has been authenticated. This may involve determining whether a valid authorization license has been generated and / or received for the client device. In some implementations, once the authentication information provided by the user and / or other identity information received from the resource client (e.g., device identity information) is checked against an authentication database to ensure that the user is authorized to use the resource server, this may require the user to be a registered user of the resource server and / or to be using an authorized network (e.g., an authorized WiFi network). In some implementations, the authorization license may expire after a predetermined period of time to prevent the possibility of unauthorized use.

[0044] When it is determined that the client device / user is authenticated (e.g., valid authentication permission is available) (Yes at 415), method 400 can proceed to generating an access token at 420. In some implementations, the access token is generated and manipulated in a manner similar to OAuth and / or OpenID connection tokens. Therefore, the token can be a security token generated and used to enable access. The access token may include identification information about the client device and / or user. For example, the access token may include username and / or password information. Furthermore, the access token may include verification evidence indicating that the access token was issued by an identity platform. For example, the access token may include a cryptographic signature as evidence that it was generated by an appropriate identity platform. Additionally, the access token may include a random number obtained from the master session key of the current session to be included in the access token.

[0045] However, if it is determined that the client device / user has not yet been authenticated (e.g., a valid authentication license is unavailable) (No at 415), method 400 can proceed at 445 to retrieve authentication information for the client device / user. This process may include sending an authentication request to an authentication server, where the request includes information identifying the resource client and / or client device. If the identification information is unavailable or insufficient to authenticate the client device / user, the authentication server can provide a UI that allows the user to enter identification information (such as a username and / or password). Alternatively, the identification information can be retrieved via identity federation. Once received, the identification information can be provided to an identity platform. In some implementations, the process of providing a UI to receive and verify the identification information is performed by the identity platform.

[0046] After retrieving the identification information, method 400 can proceed at 450 to check the information against the relative authentication database to determine whether the user is authorized to use the resource server. This can be performed by the authentication server. If the client device / user is identified as authorized (yes at 450), method 400 can proceed to step 420 to generate an access token, as described above. However, when it is determined that the client device / user is not authorized (no at 450), method 400 can proceed at 455 to notify the resource client that the client device / user is not an authorized user. In response, the resource client can display a notification to the user informing them that the provided authentication information is incorrect, and can allow the user to enter alternative identification information.

[0047] After the access token is generated, at 425, method 400 may proceed to determine whether the resource server requires compliance with a conditional access policy. The conditional access policy may include compliance with specific device states, such as not being a jailbroken device, having a specific operating system, or being a managed device. These may be access policies set by an administrator (e.g., a VPN administrator) as prerequisites for utilizing the resource server. When it is determined that compliance with the conditional access policy is not required, method 400 may proceed to step 440 to send the generated access token to the resource client. However, if it is determined that the client device is required to comply with the conditional access policy (yes at 425), method 400 may proceed at 430 to determine whether the conditional access policy is satisfied. This may involve querying the resource client and / or the client device's device management provider to determine one or more device states. The device states can then be sent to the identity platform to determine whether the client device meets the requirements.

[0048] When it is determined that the device is compliant (yes at 430), method 400 can proceed to 435 to include device compliance verification in the access token. This information can be provided as an indication within the token. When device compliance is verified and compliance verification information is included in the access token, at 440, method 400 can proceed to send the access token to the resource client. In an alternative implementation, compliance verification may not be included in the access token. Instead, compliance with the conditional access policy can be verified before the access token is generated. In such an implementation, the access token can be generated after verifying that the client device meets the conditional access requirements. As a result, the generation of the access token itself can be an indication of compliance with the conditional access policy.

[0049] However, if it is determined that the device does not meet the conditional access requirements, method 400 may proceed to step 455 to provide a notification to the resource client. This may include sending a notification message informing the user that authentication cannot be granted because the device does not meet one or more conditional access policy requirements. In response, the resource client may display a notification to the user informing them of the conditional access policy requirements.

[0050] Therefore, in different implementations, technical solutions can be provided to enable the use of access tokens generated by an independent identity platform to authorize client devices to access resource servers (such as VPN servers) and / or verify compliance with conditional access policies of the resource servers. To achieve this, the technical solution can utilize an identity platform that communicates with the resource client and / or the client device management provider to authenticate users and ensure that the client devices comply with conditional access policies. In this way, verification of compliance with conditional access policies can be integrated into the authentication process. The identity platform can generate and send access tokens that can be used for secure communication with the resource server. Furthermore, the token may include a random number of the master session key associated with the active session to enhance security. This increases system efficiency for the resource server while improving the user experience and increasing security.

[0051] Figure 5 This is a block diagram 500 illustrating a software architecture 502, the parts of which can be used in conjunction with various hardware architectures described herein, which can implement any of the features described above. Figure 5 This is a non-limiting example of a software architecture, and it should be understood that many other architectures can be implemented to facilitate the functionality described herein. Software architecture 502 can execute on hardware such as client devices, local application providers, web servers, server clusters, external services, and other servers. A representative hardware layer 504 includes a processing unit 506 and associated executable instructions 508. Executable instructions 508 represent executable instructions of software architecture 502, including implementations of the methods, modules, etc., described herein.

[0052] Hardware layer 504 also includes memory / storage device 510, which includes executable instructions 508 and accompanying data. Hardware layer 504 may also include other hardware modules 512. Instructions 508 stored by processing unit 506 may be a portion of instructions 518 stored by memory / storage device 510.

[0053] The example software architecture 502 can be conceptualized as layers, each providing various functionalities. For example, software architecture 502 may include layers and components such as an operating system (OS) 514, libraries 516, a framework 518, applications 520, and a presentation layer 544. Operationally, applications 520 and / or other components within a layer can invoke API calls 524 to other layers and receive corresponding results 526. The layers shown are representative in nature; other software architectures may include additional or different layers. For example, some mobile or dedicated operating systems may not provide a framework 518.

[0054] OS 514 can manage hardware resources and provide public services. OS 514 may include, for example, a kernel 528, services 530, and drivers 532. Kernel 528 can act as an abstraction layer between hardware layer 504 and other software layers. For example, kernel 528 may be responsible for memory management, processor management (e.g., scheduling), component management, networking, security settings, etc. Services 530 may provide other public services to other software layers. Drivers 532 may be responsible for controlling the underlying hardware layer 504 or interfacing with the underlying hardware layer. For example, drivers 532 may include display drivers, camera drivers, memory / storage drivers, peripheral device drivers (e.g., via Universal Serial Bus (USB)), network and / or wireless communication drivers, audio drivers, etc., depending on the hardware and / or software configuration.

[0055] Library 516 may provide common infrastructure that can be used by application 520 and / or other components and / or layers. Library 516 typically provides functionality for use by other software modules to perform tasks, rather than directly interacting with OS 514. Library 516 may include system libraries 534 (e.g., the C standard library), which provide functions such as memory allocation, string manipulation, and file operations. Furthermore, library 516 may include API libraries 536, such as media libraries (e.g., those supporting the rendering and manipulation of image, sound, and / or video data formats), graphics libraries (e.g., OpenGL libraries for rendering 2D and 3D graphics on a display), database libraries (e.g., SQLite or other relational database functions), and web libraries (e.g., WebKit, which provides web browsing functionality). Library 516 may also include various other libraries 538 to provide numerous functionalities for application 520 and other software modules.

[0056] Framework 518 (sometimes also called middleware) provides a higher level of common infrastructure that can be used by Application 520 and / or other software modules. For example, Framework 518 can provide various graphical user interface (GUI) functions, advanced resource management, or advanced location services. Framework 518 can also provide a wide range of other APIs for Application 520 and / or other software modules.

[0057] Application 520 includes built-in application 540 and / or third-party application 542. Examples of built-in applications 540 may include, but are not limited to, contact applications, browser applications, location applications, media applications, messaging applications, and / or game applications. Third-party applications 542 may include any application developed by an entity other than the provider of a particular system. Application 520 may use the functionality available via OS 514, library 516, framework 518, and presentation layer 544 to create a user interface for interaction with the user.

[0058] Some software architectures use virtual machines, such as virtual machine 548. Virtual machine 548 provides an execution environment where applications / modules can run as if on a hardware machine (such as a physical machine). Figure 6 The virtual machine 548 can be run on a machine 600, for example, in the same way. The virtual machine 548 can be hosted by a host OS (e.g., OS 514) or a hypervisor, and can have a virtual machine monitor 546 that manages the operation of the virtual machine 548 and its interoperability with the host operating system. A software architecture different from the software architecture 502 outside the virtual machine can execute within the virtual machine 548 (such as OS 550, libraries 552, frameworks 554, applications 556, and / or presentation layers 558).

[0059] Figure 6 This is a block diagram illustrating components of an example machine 600 configured to read instructions from a machine-readable medium (e.g., a machine-readable storage medium) and perform any of the features described herein. The example machine 600 is in the form of a computer system (e.g., a programmable device) within which instructions 616 (e.g., in the form of a software component) for causing the machine 600 to perform any of the features described herein can be executed. Thus, instructions 616 can be used to implement the methods or components described herein. Instructions 616 cause an unprogrammed and / or unconfigured machine 600 to operate as a specific machine configured to implement the described features. Machine 600 can be configured to operate as a standalone device or can be coupled (e.g., networked) to other machines. In a networked deployment, machine 600 can operate as a server machine or client machine in a server-client network environment, or as a node in a peer-to-peer or distributed network environment. Machine 600 can be implemented as, for example, a server computer, client computer, personal computer (PC), tablet computer, laptop computer, netbook, set-top box (STB), gaming and / or entertainment system, smartphone, mobile device, wearable device (e.g., smartwatch), and Internet of Things (IoT) device. Furthermore, although only a single machine 600 is shown, the term "machine" includes a collection of machines that individually or jointly execute instruction 616.

[0060] Machine 600 may include processor 610, memory 630, and I / O components 650, which may be communicatively coupled via, for example, bus 602. Bus 602 may include multiple buses coupling the various components of machine 600 via various bus technologies and protocols. In examples, processor 610 (including, for example, a central processing unit (CPU), graphics processing unit (GPU), digital signal processor (DSP), ASIC, or suitable combinations thereof) may include one or more processors 612a to 612n, which can execute instructions 616 and process data. In some examples, one or more processors 610 may execute instructions provided or identified by one or more other processors 610. The term "processor" includes a multi-core processor, which includes cores capable of executing instructions simultaneously. Although Figure 6 Multiple processors are shown, but machine 600 may include a single processor with a single core, a single processor with multiple cores (e.g., a multi-core processor), a multi-core processor with a single core per processor, a multi-core processor with multiple cores per processor, or any combination thereof. In some examples, machine 600 may include multiple processors distributed among multiple machines.

[0061] Memory / storage device 630 may include main memory 632, static memory 634 or other memory and storage unit 636, both of which can access processor 610, such as via bus 602. Storage unit 636 and memories 632, 634 store instructions 616 that implement any one or more of the functions described herein. Memory / storage device 630 may also store temporary, intermediate and / or long-term data for processor 610. During its execution, instructions 616 may also reside wholly or partially within memories 632, 634, storage unit 636, at least one of processor 610 (e.g., within a command buffer or cache memory), at least one of I / O components 650, or any suitable combination thereof. Thus, memories 632, 634, storage unit 636, the memory in processor 610 and the memory in I / O components 650 are examples of machine-readable media.

[0062] As used herein, "machine-readable medium" refers to a device capable of temporarily or permanently storing instructions and data that cause machine 600 to operate in a particular manner. The term "machine-readable medium" as used herein does not include transient electrical or electromagnetic signals themselves (such as those on a carrier wave propagating through a medium); therefore, the term "machine-readable medium" can be considered tangible and non-transient. Non-limiting examples of non-transient, tangible machine-readable media may include, but are not limited to, non-volatile memory (such as flash or read-only memory (ROM)), volatile memory (such as static random access memory (RAM) or dynamic RAM), buffer memory, cache, optical storage media, magnetic storage media and devices, network-accessible or cloud storage, other types of storage, and / or any suitable combination thereof. The term "machine-readable medium" applies to a single medium or a combination of media for storing instructions (e.g., instruction 616) that, when executed by one or more processors 610 of machine 600, cause machine 600 to perform one or more features described herein. Therefore, "machine-readable media" can refer to a single storage device, as well as a "cloud-based" storage system or storage network that includes multiple storage devices or equipment.

[0063] I / O component 650 may include a wide variety of hardware components suitable for receiving input, providing output, generating output, transmitting information, exchanging information, capturing measurements, and so on. The specific I / O component 650 included in a particular machine will depend on the type and / or function of the machine. For example, mobile devices (such as mobile phones) may include touch input devices, while terminalless servers or IoT devices may not include such touch input devices. Figure 6 The specific examples of I / O components shown are by no means limiting, and other types of components may be included in machine 600. The grouping of I / O components 650 is only for the simplicity of this discussion, and the grouping is by no means limiting. In various examples, I / O components 650 may include user output components 652 and user input components 654. User output components 652 may include, for example, visual components (e.g., liquid crystal displays (LCDs) or projectors) for displaying information, auditory components (e.g., speakers), haptic components (e.g., vibration motors or force feedback devices), and / or other signal generators. User input components 654 may include, for example, alphanumeric input components (e.g., keyboards or touchscreens), pointing components (e.g., mouse devices, touchpads, or other pointing tools) and / or haptic input components (e.g., physical buttons or touchscreens that provide position and / or force or touch gestures of touch) configured to receive various user inputs (such as user commands and / or selections).

[0064] In some examples, among numerous other sensor components, I / O component 650 may include biometric component 656, motion component 658, environmental component 660, and / or positioning component 662. Biometric component 656 may include, for example, components for detecting body expressions (e.g., facial expressions, vocal expressions, hand or body gestures, or eye tracking), measuring biosignals (e.g., heart rate or brain waves), and identifying a person (e.g., via voice-based, retina-based, and / or face-based identification). Positioning component 662 may include, for example, a position sensor (e.g., a Global Positioning System (GPS) receiver), an altitude sensor (e.g., a barometric pressure sensor from which altitude can be obtained), and / or an orientation sensor (e.g., a magnetometer). Motion component 658 may include motion sensors (such as acceleration and rotation sensors). Environmental component 660 may include, for example, a lighting sensor, an auditory sensor, and / or a temperature sensor.

[0065] I / O component 650 may include communication component 664, which implements various technologies operable to couple machine 600 to network(s)670 and / or device(s)680 via corresponding communication couplers 672 and 682. Communication component 664 may include one or more network interface components or other suitable devices interface with network(s)670. Communication component 664 may include components, for example, adapted to provide wired communication, wireless communication, cellular communication, near field communication (NFC), Bluetooth communication, Wi-Fi, and / or communication via other modes. Device(s)680 may include other machines or various peripheral devices (e.g., via USB coupling).

[0066] In some examples, communication component 664 may detect identifiers or include components suitable for detecting identifiers. For example, communication component 664 may include a radio frequency identification (RFID) tag reader, an NFC detector, an optical sensor (e.g., a one-dimensional or multi-dimensional barcode or other optical code), and / or an acoustic detector (e.g., a microphone for identifying audio signals of tags). In some examples, location information may be determined based on information from communication component 664, such as, but not limited to, geographic location via Internet Protocol (IP) address, location via Wi-Fi, cellular, NFC, Bluetooth, or other wireless station identification and / or signal triangulation.

[0067] Although various embodiments have been described, the description is intended to be exemplary and not restrictive, and it should be understood that further embodiments and implementations within the scope of the embodiments are possible. While many possible combinations of features are shown in the drawings and discussed in this detailed description, many other combinations of the disclosed features are also possible. Any feature of any embodiment may be used in combination with or substituted for any other feature or element in any other embodiment, unless specifically limited. Therefore, it should be understood that any feature shown and / or discussed in this disclosure can be implemented together in any suitable combination. Thus, the embodiments are not limited except as provided in the appended claims and their equivalents. Furthermore, various modifications and changes may be made within the scope of the appended claims.

[0068] Typically, the functions described in this article (e.g., Figures 1-4 The features shown herein can be implemented using software, firmware, hardware (e.g., fixed logic, finite state machines, and / or other circuitry), or a combination of these implementations. In the case of a software implementation, the program code performs a specified task when executed on a processor (e.g., one or more CPUs). The program code can be stored in one or more machine-readable storage devices. The features of the techniques described herein are system-independent, meaning that these techniques can be implemented on a variety of computing systems with various processors. For example, an implementation may include entities (e.g., software) that cause hardware to perform operations, such as processor function blocks, etc. For example, a hardware device may include a machine-readable medium that can be configured to hold instructions that cause the hardware device (including an operating system running thereon and associated hardware) to perform operations. Thus, the instructions can be used to configure the operating system and associated hardware to perform operations, thereby configuring or otherwise adapting the hardware device to perform the functions described above. The instructions can be provided by the machine-readable medium to the hardware elements executing the instructions in various different configurations.

[0069] Further features, characteristics, and advantages of the invention will be described below by way of the following:

[0070] Project 1. A device comprising:

[0071] Processor; and

[0072] A memory that communicates with the processor stores executable instructions that, when executed by the processor, cause the device to perform the following functions:

[0073] Generate a session key for communication between the device and the resource server;

[0074] Obtain a random number from the session key;

[0075] Send a request to the identity platform to authenticate the device for accessing the resource server; the request includes a random number.

[0076] After authentication is confirmed, an access token is received from the identity platform. The access token includes information confirming the device's authentication; and

[0077] Send an access token to the resource server to enable access to the resource server.

[0078] The access token includes a random number.

[0079] Project 2. Based on the equipment in Project 1, where the resource server is a Virtual Private Network (VPN).

[0080] Item 3. Based on the device in Item 1 or 2, wherein the access token includes information identifying the device.

[0081] Item 4. A device according to any of the preceding items, wherein the access token includes information confirming that the device is an authorized device.

[0082] Project 5. A device according to any of the preceding projects, wherein the access token includes information confirming that the device complies with one or more conditional access policies of the resource server.

[0083] Project 6. A device according to any of the preceding projects, wherein the executable instructions, when executed by a processor, also cause the device to perform the following functions:

[0084] Send the first part of the session key to the resource server;

[0085] Receive the second part of the session key from the resource server;

[0086] Generate a session key from the first and second parts of the session key; and

[0087] Send a random number to the identity platform.

[0088] Item 7. The device according to any of the preceding items, wherein the random number is obtained from the session key by hashing the session key.

[0089] Item 8. A method for generating an access token for providing access to a resource server, the method comprising:

[0090] The device receives a request to provide an access token to the device for accessing the resource server. The request includes a random number derived from a session key generated for the communication session between the device and the resource server.

[0091] Determine whether the device is authorized to access the resource server;

[0092] In response to determining that the device is authorized to access the resource server, an access token is generated;

[0093] Include random numbers in the access token; and

[0094] Send an access token to the device.

[0095] Project 9. Based on the method of Project 8, it also includes:

[0096] Determine whether the resource server requires compliance with one or more conditional access policies;

[0097] When determining whether a resource server requires compliance with one or more conditional access policies, verify that the device complies with one or more conditional access policies, and

[0098] The access token will include information that confirms that the device complies with one or more conditional access policies.

[0099] Project 10. According to the method of Project 9, wherein verifying that the device conforms to one or more conditional access policies includes:

[0100] Send a request to the device or at least one of the device management providers for the device to provide one or more device states related to one or more conditional access policies;

[0101] Receive the status of one or more devices; and

[0102] Compare one or more device states with one or more conditional access policies to verify whether one or more device states comply with one or more conditional access policies.

[0103] Item 11. The method of any one of Items 8-10, wherein the access token includes information identifying the device.

[0104] Item 12. The method of any one of Items 8-11, wherein the access token includes information confirming that the device is an authorized device.

[0105] Project 13. According to the method of any one of Projects 8-12, it also includes:

[0106] Upon receiving a request from the device, determine whether a valid access token for the device is available; and

[0107] In response to determining that a valid access token for the device is available, a valid access token is sent to the device.

[0108] Item 14. A non-transitory computer-readable medium having stored instructions thereon, which, when executed, cause a programmable device to:

[0109] Generate a session key for communication between the programmable device and the resource server;

[0110] Obtain a random number from the session key;

[0111] Send a request to the identity platform to authenticate the programmable device for accessing the resource server; the request includes a random number.

[0112] After authentication is confirmed, an access token is received from the identity platform. This access token includes information confirming the authentication of the programmable device; and

[0113] Send an access token to the resource server to enable access to the resource server.

[0114] The access token includes a random number.

[0115] Item 15. Non-transient computer-readable media according to Item 14, wherein the resource server is a Virtual Private Network (VPN).

[0116] Item 16. A non-transient computer-readable medium according to Item 14 or Item 15, wherein the access token includes information identifying the programmable device.

[0117] Item 17. A non-transient computer-readable medium according to any one of items 14-16, wherein the access token includes information confirming that the programmable device is an authorized device.

[0118] Item 18. A non-transient computer-readable medium according to any one of items 14-17, wherein the access token includes information confirming that the programmable device complies with one or more conditional access policies of the resource server.

[0119] Item 19. A non-transient computer-readable medium according to any one of items 14-18, wherein the instructions further enable a programmable device to:

[0120] Send the first part of the session key to the resource server;

[0121] Receive the second part of the session key from the resource server;

[0122] Generate a second key from the first and second parts of the session key;

[0123] Obtain a random number from the session key; and

[0124] Send a random number to the identity platform.

[0125] Item 20. A non-transient computer-readable medium according to any one of items 14-19, wherein the random number is obtained from the session key item by hashing the session key.

[0126] While what is considered the best model and / or other examples has been described above, it should be understood that various modifications can be made therein, and the subject matter disclosed herein can be implemented in various forms and examples, and these teachings can be applied in many applications, only some of which are described herein. The following claims are intended to claim protection for any and all applications, modifications, and variations that fall within the true scope of this teaching.

[0127] Unless otherwise stated, all measurements, values, ratings, positions, amplitudes, dimensions, and other specifications set forth in this specification (including the following claims) are approximate and not precise. They are intended to have a reasonable range consistent with the functions they address and the conventions of the field to which they belong.

[0128] The scope of protection is limited only by the following claims. When interpreted in accordance with this specification and the subsequent examination history, this scope is intended and should be interpreted as consistent with the general meaning of the language used in the claims and covers all structural and functional equivalents. Nevertheless, no claim is intended to cover, nor should it be interpreted in, any subject matter that does not meet the requirements of Sections 101, 102, or 103 of the Patent Act. Any unintentional coverage of such subject matter is hereby denied.

[0129] Except as stated above, nothing stated or described is intended or should not be construed as offering to the public any component, step, feature, object, benefit, advantage or equivalent, whether or not it is stated in the claims.

[0130] It should be understood that the terms and expressions used herein have the general meanings assigned to them in their respective fields of investigation and research, unless otherwise specified herein.

[0131] Terms such as "first" and "second" may be used solely to distinguish one entity or action from another without necessarily requiring or implying any actual relationship or order between such entities or actions. The terms "comprising," "including," and any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements may include not only those elements but also other elements not expressly listed or inherent to such a process, method, article, or apparatus. Unless otherwise limited, an element beginning with "a" or "an" does not exclude the presence of other identical elements in the process, method, article, or apparatus that constitute that element.

[0132] The abstract of this disclosure is provided to allow the reader to quickly identify the nature of the disclosed technology. It is understood that this abstract is not intended to interpret or limit the scope or meaning of the claims. Furthermore, as can be seen from the foregoing detailed description, various features have been combined in various examples for the purpose of simplifying the disclosure. The approach of this disclosure should not be construed as reflecting an intention in any claim to claim more features than expressly stated in the claims. Rather, as reflected in the following claims, the inventive subject matter lies in all features less than those in a single disclosed example. Therefore, the following claims are incorporated herein by reference, each claiming as a separately claimed subject matter.

Claims

1. An apparatus comprising: processor; as well as A memory communicating with the processor, the memory storing executable instructions, which, when executed by the processor, cause the device to perform the following steps: Using the resource client application installed on the device, a master session key is generated for the communication session between the device and the resource server; Using the resource client application installed on the device, a random number is obtained from the generated master session key by generating a hash of the master session key; After obtaining the random number, the device sends the random number to the identity platform in an authentication request, which is used to authenticate the device for accessing the resource server; Receive an access token from the identity platform, the access token including the random number and including information confirming the authentication of the device; Send the access token to the resource server; as well as After sending the access token to the resource server, access to the resource server is received.

2. The device according to claim 1, wherein the resource server is a Virtual Private Network (VPN).

3. The device of claim 1, wherein the access token includes information identifying the device.

4. The device of claim 1, wherein the access token includes information confirming that the device is an authorized device.

5. The device of claim 1, wherein the access token includes information confirming that the device complies with one or more conditional access policies of the resource server.

6. The device of claim 1, wherein the executable instructions, when executed by the processor, further cause the device to perform the following steps: Send the first part of the master session key to the resource server; Receive the second part of the master session key from the resource server; and The master session key is generated from the first part and the second part of the master session key, and the random number sent to the identity platform is obtained from the master session key.

7. The device of claim 1, wherein the random number is obtained from the session key by generating a hash of the session key.

8. A method performed by an identity platform for generating an access token for providing access to a resource server, the method comprising: The device receives an authentication request for providing an access token used by the device when accessing the resource server for a communication session between the device and the resource server. The authentication request includes a random number obtained using a resource client application installed on the device. The random number is obtained from a master session key by using the resource client application installed on the device to generate a hash of the master session key. Determine whether the device is authorized to access the resource server; In response to determining that the device is authorized to access the resource server, the access token is generated by including the random number in the access token; as well as Send the access token to the device.

9. The method according to claim 8, further comprising: Determine whether the resource server requires compliance with one or more conditional access policies; When determining whether the resource server requires compliance with the one or more conditional access policies, verify that the device complies with the one or more conditional access policies, and Information that confirms the device complies with one or more conditional access policies will be included in the access token.

10. The method of claim 9, wherein verifying that the device conforms to the one or more conditional access policies comprises: Send a request to the device or at least one of the device management providers for the device to provide one or more device states related to the one or more conditional access policies; Receive the status of the one or more devices; as well as The one or more device states are compared with the one or more conditional access policies to verify whether the one or more device states comply with the one or more conditional access policies.

11. The method of claim 8, wherein the access token includes information identifying the device.

12. The method of claim 8, wherein the access token includes information confirming that the device is an authorized device.

13. The method of claim 8, further comprising: After receiving the request from the device, determine whether a valid access token for the device is available; as well as In response to determining that the valid access token for the device is available, the valid access token is sent to the device.

14. A non-transient computer-readable medium having instructions stored thereon, said instructions, when executed, causing a programmable device to: Using the resource client application installed on the programmable device, a master session key is generated for the communication session between the programmable device and the resource server; Using the resource client application installed on the programmable device, a random number is obtained from the generated master session key by generating a hash of the master session key; After obtaining the random number, the programmable device sends the random number to the identity platform in an authentication request, which is used to authenticate the programmable device for accessing the resource server; Receive an access token from the identity platform, the access token including the random number and including information confirming the authentication of the programmable device; Send the access token to the resource server; as well as After sending the access token to the resource server, access to the resource server is received.

15. The non-transient computer-readable medium of claim 14, wherein the resource server is a Virtual Private Network (VPN).

16. The non-transient computer-readable medium of claim 14, wherein the access token includes information identifying the programmable device.

17. The non-transient computer-readable medium of claim 14, wherein the access token includes information confirming that the programmable device is an authorized device.

18. The non-transient computer-readable medium of claim 14, wherein the access token includes information confirming that the programmable device complies with one or more conditional access policies of the resource server.

19. The non-transient computer-readable medium of claim 14, wherein the instructions further enable a programmable device to: Send the first part of the master session key to the resource server; Receive the second part of the master session key from the resource server; and The master session key is generated from the first part and the second part of the master session key, and the random number sent to the identity platform is obtained from the master session key.

20. The non-transient computer-readable medium of claim 14, wherein the random number is obtained from the session key by generating a hash of the session key.

Images