VPN Communication Security Methods and Systems

Abstract

A method and system for using an access token to authenticate a client device for accessing a resource server comprises generating a session key for a communication session between the device and the resource server, deriving a nonce from the session key, and transmitting a request to an identification platform to authenticate the device for accessing the resource server (the request includes the nonce). Upon authentication verification, the method and system may include receiving an access token from the identification platform that includes information verifying the authentication of the device, and transmitting the access token to the resource server to enable access to the resource server, wherein the access token includes the nonce.

Description

Technology Field

[0001] The present disclosure generally relates to securely connecting to a virtual private network (VPN), and in particular to a method and system using token-based authentication to secure a VPN tunnel. Background Technology

[0002] VPNs are frequently used to allow users to transfer data from their devices to a private network over a shared or public network, as if the user's device were directly connected to the private network. This enables applications running through the VPN to benefit from the security and management advantages of the private network. To ensure security and proper authentication, VPN servers often perform authentication functions to grant users permission to access the server. This may require the VPN server to consume significant memory and processor resources for the authentication function. In some cases, accessing the VPN server requires meeting conditions other than being an authorized user. Some of these conditions may relate to device status. To ensure these conditions are met, the VPN server may verify the status of one or more devices by performing queries on them. However, the process of querying various devices to verify their status can require significant bandwidth and processor resources.

[0003] Therefore, improved methods and systems are needed to authenticate VPN users and / or protect VPN tunnels.

[0004] To address these problems, etc., in one general embodiment, a device having a processor and a memory communicating with the processor is described herein, wherein the memory stores executable instructions that enable the device to perform various functions when executed by the processor. These functions may include generating a session key for a communication session between the device and a resource server, deriving a nonce from the session key, transmitting a request to an identification platform to authenticate the device for accessing the resource server (the request includes the nonce), receiving an access token from the identification platform containing information confirming the authentication of the device upon authentication confirmation, and transmitting the access token to the resource server to enable access to the resource server, wherein the access token includes the nonce.

[0005] In another general aspect, the present application describes a method for generating an access token to provide access to a resource server. The method may include receiving from a device a request to provide the device with an access token to be used to access the resource server—the request includes a nonce 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; generating an access token in response to the determination that the device is authorized to access the resource server; including the nonce in the access token; and transmitting the access token to the device.

[0006] In another general aspect, the present application describes a non-transient computer-readable medium in which instructions are stored, wherein the instructions, when executed, cause a programmable device to generate a session key for a communication session between the programmable device and a resource server, derive a nonce from the session key, and transmit a request to an identification platform to authenticate the programmable device for accessing the resource server (the request includes a nonce), and upon authentication confirmation, receive an access token from the identification platform containing information confirming the authentication of the programmable device, and transmit the access token to the resource server to enable access to the resource server, wherein the access token includes a nonce.

[0007] [Description of the Invention] is provided to introduce, in a simplified form, some of the concepts further described in [Detailed Description of the Invention] below. [Description of the Invention] is not intended to identify the principal or essential features of the claimed subject matter, nor is it used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to an implementation that resolves all or part of the disadvantages mentioned in any part of this disclosure. Brief explanation of the drawing

[0008] The drawings depict one or more implementations of this teaching merely as examples, not limitations. Identical reference numerals in the drawings refer to identical or similar components. Additionally, it should be understood that the drawings are not necessarily to scale. FIG. 1 illustrates an exemplary system in which embodiments of the present disclosure can be implemented. FIGS. 2A and FIGS. 2B illustrate a simplified example array of data flow for providing an access token to authenticate a client device. FIG. 3 illustrates an exemplary method for requesting and receiving an access token to authenticate a client device to a resource server. FIG. 4 is a flowchart illustrating an exemplary method for generating an access token to authenticate a client device to access a resource server. FIG. 5 is a block diagram illustrating an exemplary software architecture, and various parts of this software architecture may be used with various hardware architectures described herein. FIG. 6 is a block diagram illustrating a component of an exemplary machine configured to read commands from a machine-readable medium and perform any feature described herein. Specific details for implementing the invention

[0009] In the following detailed description, numerous specific details are presented through examples to provide a complete understanding of the relevant teachings. Those skilled in the art will understand that various embodiments can be practiced without these details when reading this description. In other cases, known methods, procedures, components, and / or circuits have been described relatively abstractly without details to avoid unnecessarily obscuring the embodiments of this teaching.

[0010] VPN channels are often used to connect private client devices to external networks securely and privately. However, to use a VPN service, users must first provide authentication credentials that guarantee they have the authority to access the VPN. In conventional technology, the VPN server performs the authentication and authorization procedures internally. This may involve numerous data exchanges with client devices and / or remote authentication services such as RADIUS (remote authentication dial-in user service). This process often requires memory, processor, and / or bandwidth resources.

[0011] In addition to requiring a client device to be associated with an authorized user, some services (e.g., VPN services) may require specific conditions to be met to allow continued access to the service. In some cases, these conditions relate to the state of the device, such as having a specific operating system and not being jailbroken. These conditions are referred to as conditional access policies in this disclosure. To ensure that conditional access policies are satisfied, a VPN server typically queries the device to identify the latest device state. This is done after the user is authenticated. However, the device state may change during the session duration. To enable the detection of device state changes, the VPN server queries each device during the session duration to verify that the policy remains satisfied. This may require a significant amount of hardware and / or software resources. Due to the amount of resources required to query each client device to verify that the conditional access policy is satisfied, most VPN servers query each device infrequently (e.g., once every hour). Consequently, since there may be a time delay between when the device state changes and when the VPN server identifies the changed state, the response to changes in device state may be slow. Additionally, having the VPN server verify compliance with conditional access policies can degrade the end-user experience. Therefore, verifying compliance with conditional access policies on the VPN server itself not only requires significant bandwidth, memory, and processor resources but can also result in slower response times to changed states, degraded performance, or a degraded user experience.

[0012] To address these technical issues, for example, this description provides a technical solution for efficiently authenticating resource server users by utilizing tokens issued by an identification platform. The identification platform for authenticating users may be separate from the resource server (e.g., a VPN server). The identification platform performs the necessary authentication procedures and, once the user is authenticated, may issue an access token to the user. The access token may contain information identifying the user and information verifying that the token was issued by the appropriate identification platform. The access token may then be transmitted to a resource client (e.g., a VPN client), and the resource client may use the access token to access the resource server. In this way, the user authentication process is performed by an entity rather than the resource server, thereby reducing the amount of processor, memory, and bandwidth resources used by the resource server. Additionally, using tokens makes the authentication process simpler and more efficient.

[0013] In some implementations, when a conditional access policy must be satisfied to access a resource server, a process to ensure that such policy is satisfied may be performed as part of the authentication process. The authentication process may include an identification platform and / or a verification platform that validates the conditional access policy before an access token is issued. In one implementation, the access token may include an indication stating that the device complies with the conditional access policy. Consequently, this technical solution provides an improved method for authenticating resource server users and verifying that the user's client device complies with the conditional access policy. The improved method increases efficiency and conserves computing resources.

[0014] Tokens used to access Transport Layer Security (TLS) sessions are susceptible to replay attacks. For example, another device could infer a token from a client device and use it to access a VPN server. To prevent this, for some implementations, this description provides a technical solution to enhance the security provided by access tokens by adding a cryptographic mark (e.g., a nonce) to the access token. To generate a cryptographic mark, a session master secret can first be generated for each session. Then, the session master secret can be manipulated to generate a cryptographic mark associated with a specific session. This may involve generating a hash of the session master secret. In this way, the cryptographic mark can be computed independently by both the client and the resource server and cannot be inferred by an external attacker. Consequently, attempts to use the access token from outside the channel will fail because the cryptographic mark computed by the resource server will not match the cryptographic mark of the inferred token. Therefore, the technical solution provides an efficient mechanism that offers additional security when performing authentication procedures remotely.

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

[0016] FIG. 1 illustrates an exemplary system (100) in which embodiments of the present disclosure may be implemented. The system (100) may include a resource server (110) which may be a VPN server enabling VPN communication between a client device (120) and a public network or the Internet (150). The resource server (110) may operate to establish a tunnel (e.g., a VPN tunnel) between a resource client (140) and the resource server (110). Data passing through this tunnel may be encrypted to provide privacy and / or security. As a result, the resource server (110) may provide secure and private communication between a client device, such as the client device (120), and the Internet (150). The resource server (110) may operate as a shared resource server accessible by various computer client devices, such as the client device (120).

[0017] The network (130) may be a wired or wireless network(s) or a combination of wired and wireless networks connecting one or more components of the system (100). The client device (120) may be any type of device capable of receiving input from a user and communicating with the network (130) to transmit and receive data. Such a client device may include a personal or handheld computing device having input and output elements or connected thereto. For example, the client device (120) may be one of a mobile phone, smartphone, tablet, phablet, smart watch, wearable computer, personal computer, desktop computer, laptop computer, gaming device / computer, television, thick 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 discussed in more detail in relation to FIGS. 5 and 6.

[0018] In some implementations, the client device (120) includes a resource client (140) (e.g., a VPN client). The resource client (140) may be an application (e.g., a software program) installed on the client device (120) to establish and manage a connection between the resource client (140) and the resource server (110). As such, the resource client (140) may be provided to provide access to resources (e.g., a VPN service) of the resource server (110). For example, a VPN client is often provided on the client device (120) to establish a VPN connection with the VPN server and manage a VPN tunnel for VPN communication with the VPN server. In some implementations, the resource client (140) operates automatically in the background. Alternatively and / or additionally, the resource client (140) may provide one or more user interfaces (UI) that allow a user to interact with the resource client (140) and / or configure the resource client (140).

[0019] To ensure that the user has the authority to use the resource server (110) and / or to verify that the client device (120) is communicating with the correct resource server (110), authentication is required before a tunnel can be established for communication. To avoid the need for the resource server (110) itself to perform the authentication operation, the technical solution described in this application provides a token-based authentication mechanism in which a token is generated by an entity independent of the resource server (110). In some implementations, this is achieved by using an identification platform (160). The identification platform (160) may be an application (e.g., a software program) that provides client authentication, identification, and / or access management. The identification platform (160) may include an authentication server (170), a security token server (180), and / or one or more application programming interfaces (APIs) for managing user identification and authentication. In some implementations, the identification platform (160) also includes a web interface (not shown) that allows an administrator and / or user to interact with the identification platform (160).

[0020] The identification platform (160) can help the client device (120) add identification and access management functions to the resource client (140). Accordingly, the identification platform (160) may receive a request from the resource client (140) to authenticate the client device (120) for accessing the resource server (110). In response to this, the identification platform (160) may perform an authentication action to authenticate the client device (120). In some implementations, authenticating the client device (120) may involve communication with an authentication server (170). The authentication server (170) may provide one or more UIs that allow a user to interact with the authentication server (170) and provide authentication information. For example, the authentication server (170) may provide one or more UIs that allow a user to provide log information (e.g., username, password, etc.). When authentication information (e.g., log information, device identification information, etc.) is received, the authentication server (170) can determine whether the user has the authority to access the resource server (110). This can be done by comparing the received authentication information with the authentication information stored in a user data store (e.g., a user authentication database) to verify whether the received information matches the stored information. When the user and / or client device (120) is authenticated, the authentication server (170) can transmit data notifying the authentication to the identification platform (160). Accordingly, the identification platform (160) can 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 transmit it to the identification platform (160). In such an implementation, the identification platform (160) may be responsible for communication with the authentication server (170) and / or the storage and management of the access token.The identification platform (160) may transmit an access token to a resource client (140) to be used for communication with the resource server (110). In some implementations, the identification platform (160) may be stored on a server and accessed via a network (130) by one or more client devices. Alternatively and / or additionally, the identification platform (160) may be stored on and / or operated from a client device (120).

[0021] In some implementations, in addition to providing identification and access management functions, the identification platform (160) verifies compliance with conditional access policies. For example, when a resource server (110) requires compliance with a specific conditional access policy, such policy may be communicated to the identification platform (160). The identification platform (160) may then query the client device (120) or a device management provider (not shown) managing the client device (120) for the status of the conditional access policy. In response to receiving the status, the identification platform (160) may examine the status to verify compliance. For example, the identification platform (160) may request that the client device (120) provide information about the most recent operating system used by the client device (120). In response, the client device (120) may identify the most recent operating system and transmit the information identifying it to the identification platform (160). The identification platform (160) can compare the identified operating system with a conditional access policy to determine whether the identified operating system complies with the requirements. Thus, instead of the resource server (110) having to perform a post-certification compliance verification action, the identification platform (160) can obtain the most recent device status by working directly with the client device (120) and / or the device management provider of the client device. If it is confirmed to be compliant, the identification platform (160) can include an indication in the access token identifying that the device complies with the conditional access policy.

[0022] Once confirmation of authentication is received from the authentication server (170), the identification platform (160) can generate an access token. Alternatively, the authentication server (170) may generate an access token itself and send it to the identification platform (160). In this implementation, the identification platform (160) may be responsible for communication with the authentication server (170) and / or the storage and management of the access token.

[0023] FIG. 2a illustrates a simplified exemplary arrangement of data flows for providing an access token to authenticate a client device. As illustrated, the data flow (200A) may be initiated when the client device (120) sends an access request to the resource client (140). This may be initiated, for example, by a user of the client device (120) running the resource client (140). Alternatively, this may occur when the user uses a UI function provided by the resource client (140) to request access to the resource server (110). In other implementations, the process may be initiated in the background without direct user action. For example, it may be initiated when a web browser is opened.

[0024] When an access request is received, the resource client (140) may send an authentication request to the identification platform (160). When it is confirmed that the user has the authority to access the resource server (110), the identification platform (160) may send an access token to the resource client (140). The access token may contain information confirming that the user is authenticated to access the resource server (110) and has the authority to access it. Additionally, if compliance with a conditional access policy is required, the access token may contain information confirming that the client device (120) satisfies the conditional access policy requirements. For example, if the client device (120) satisfies the conditional access policy requirements, a flag included in the access token may be checked. In some implementations, the access token may include one or more claims. One of the one or more claims may provide an indication that the user is authenticated to access the resource server (110) and has the authority to access it (e.g., the client device is an authorized device). Another claim may provide an indication that the client device (120) complies with conditional access policy requirements.

[0025] Next, this access token may be transmitted to the resource server (110) by the resource client (140). The resource server (110) may inspect the access token to ensure that the access token contains information verifying that the user / client device (120) has the authority to access the resource server (110) and, if necessary, complies with all conditional access policies. If the access token contains the necessary information (e.g., necessary claims), the resource server (110) may authorize access to the protected resource (e.g., providing a protected tunnel for secure and / or private communication with the Internet).

[0026] The process of authenticating using access tokens and verifying compliance with conditional access policies can improve system efficiency and user experience. However, access tokens can be the target of replay attacks, where an attacker can spoof the token and retransmit it. To prevent this, in some implementations, a nonce derived by the client device (120) may be included in the access token. As used herein, the nonce may refer to a random or pseudo-random number issued to prevent communication from being reused in a replay attack. The nonce may also be derived independently by the resource server (110) to ensure authenticity. However, since the nonce is not transmitted directly by the client device (120) or the resource server (110), it cannot be inferred by an external attacker.

[0027] FIG. 2b illustrates a simplified exemplary arrangement of data flows for providing an access token including a nonce. As illustrated, the data flow (200B) may be initiated when a client device (120) sends an access request to a resource client (140). This may be initiated in a manner similar to that described above in relation to FIG. 2a. For example, the process may be initiated by a user of the client device (120) running the resource client (140).

[0028] Once an access request is received, the resource client (140) may initiate a key exchange operation process with the resource server (110). The key exchange operation may first involve sending a request to initiate communication to the resource server (110). As part of the request to initiate communication, the resource client (140) may securely transmit a portion of the encryption session key to the resource server (110). In response, the resource server (110) may transmit another portion of the encryption session key to the resource client (140). In some implementations, this is performed through a Diffie-Hellman key exchange operation. The key exchange may involve perfect forward secrecy, where only a small portion of the key may be exposed even if the key is formed. In this way, the resource server (110) may have one portion of the key, and the resource client (140) may have the other portion of the key. After the exchange, both the resource server (110) and the resource client (140) may have two portions of the key that can form a complete key. Next, the two separate parts can be used by both the resource server (110) and the resource client (140) to generate a complete key individually. In this way, only the resource server (110) and the resource client (140) can have a complete key. This complete key is referred to herein as the master session key.

[0029] In some implementations, the master session key may contain information about the active communication session. This is because a communication session (e.g., a TLS session) includes the state generated by both sides of the session (e.g., the client side and the server side). This state can be included in the exchanged key to associate the key with the active communication session. In this way, even if the master session key is compromised, the token cannot be successfully retransmitted to another device because the session information contained in the master session key is incorrect.

[0030] After key exchange communication, the resource client (140) can generate a master session key from the information exchanged with the resource server (110). Once the master session key is generated, the resource client (140) can derive a nonce from the master session key. In some implementations, the nonce is a hash of the master session key. This can provide an additional layer of security to prevent the master session key from being spoofed during communication. The generated nonce contains information that associates the nonce with the current session, so it can be used only in the current session.

[0031] When a nonce is generated, an authentication request for the provision of an access token may be sent from the resource client (140) to the identification platform (160). This request may include the nonce. Upon receipt of the request, the identification platform (160) may include the nonce in the access token it has generated. In some implementations, the nonce may be included as one or more marks included in the access token. Then, the generated access token having the nonce may be sent to the resource client (140).

[0032] When a resource client (140) receives an access token containing a nonce, it can send it to a resource server (110) to initiate communication. In response, the resource server (110) can generate a nonce derived from a master session key it has generated and compare this nonce with the nonce included in the access token. If the nonce provided in the access token matches the nonce generated by the resource server (110), the 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 retransmitted outside of the original session. As a result, the resource server (110) can securely provide access to a resource (e.g., a VPN tunnel). This can enhance security when using access tokens and prevent external attacks.

[0033] FIG. 3 is a flowchart illustrating an exemplary method (300) for requesting and receiving an access token to authenticate a client device to access a resource server. In some implementations, the steps of the method (300) are performed by a resource client, such as the resource client (140) of FIG. 1. In 305, the method (300) may be initiated by receiving an access request to the resource server. This may be initiated by receiving an execution request to the resource client. Alternatively, this may occur when a user requests access to the resource server and / or receives a network access request by utilizing UI functions provided by the resource client.

[0034] When an access request to a resource server is received, the method (300) may send an authentication request at 310. This may occur, for example, by a resource client sending an authentication request to an identification platform. In an implementation where a nonce is used for additional security, the nonce may be sent as part of the authentication request. The identification platform may then perform the necessary authentication actions to authenticate the client device / user. When the identification platform confirms that the client device / user has permission to access the resource server, the identification platform may send an access token to the resource client. Thus, the method (300) may receive the access token at 315. The access token may be received from the identification platform and may contain information confirming compliance with authentication and / or conditional access policies. Additionally, the access token may include a nonce derived from the master session key for the current session. After receiving the access token, the method (300) may send the access token to the resource server at 320. This enables the resource server to verify that the client device / user has the authority to access the resource server without the need to perform the authentication process itself.

[0035] FIG. 4 is a flowchart illustrating an exemplary method (400) for generating an access token to authenticate a client device to access a resource server. In some implementations, the method (400) may be performed by an identification platform such as the identification platform (160) of FIG. 1 and / or an authentication server such as the authentication server (170) of FIG. 1. In 405, the method (400) may be initiated by receiving a request to provide an access token. This may occur when a resource client, such as a VPN client, sends a request for an access token to the resource server to authenticate a client device. The request may be received over a network and may include information identifying the resource client and / or client device that sent the request. In some implementations, the request may also include a nonce derived from a master session key for the current session to be included in the access token.

[0036] When a request is received, the method (400) can determine whether a valid access token is available for the client device identified in the request in 410. This may occur, for example, when a request for an access token is received and an access token for the client device was created within a recently determined period (e.g., the last hour). For example, there may be a time limit associated with the token, and upon the expiration of this time limit, the token may be determined to be invalid. 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 or instead of time. In implementations where nonce is used to enhance security, when a valid access token is identified, the nonce may be added to the valid access token. This is because the nonce is associated with an active session, and consequently, even if a valid access token is available, that valid access token may not have the correct nonce.

[0037] If it is determined that a valid access token is available for the client device ("Yes" in 410), the method (400) may proceed to the step (425) of determining whether compliance with a conditional access policy is required, as further discussed below. However, if it is determined that a valid access token is not available for the client device ("No" in 410), the method (400) may determine in 415 whether the client device is authenticated. This may include determining whether a valid authorization is generated and / or received for the client device. In some implementations, a valid authorization is generated by comparing the authentication information provided by the user of the client device and / or other identification information received from the resource client (e.g., device identification information) with an authentication database to ensure that the user is authorized to use the resource server. This may require that the user be a registered user of the resource server and / or be using an authorized network (e.g., an authorized WiFi network). In some implementations, the authorization may expire after a predetermined period to prevent the possibility of unauthorized use.

[0038] If it is determined that the client device / user is authenticated (e.g., that a valid authentication authorization is available) ("Yes" in 415), the method (400) may generate an access token in 420. In some implementations, an access token is generated and operates in a manner similar to OAuth and / or OpenID Connect tokens. Thus, the token may be a security token generated and used to enable access. The access token may contain identification information about the client device and / or user. For example, the access token may contain username and / or password information. Additionally, the access token may include verification evidence showing that the access token was issued by an identification platform. For example, the access token may include a cryptographic signature as proof that the access token was generated by the appropriate identification platform. Additionally, the access token may include a nonce derived from the master session key for the current session to be included in the access token.

[0039] However, if it is determined that the client device / user has not achieved authentication (e.g., a valid authentication authorization is not available) ("No" in 415), the method (400) may retrieve authentication information for the client device / user in 445. This process may include sending an authentication request to an authentication server containing information identifying the resource client and / or client device. If the identification information is not available or is insufficient to authenticate the client device / user, the authentication server may provide a UI to allow the user to enter identification information, such as a username and / or password. Alternatively, identification information may be retrieved through identity federation. The received identification information may be provided to an identification platform. In some implementations, the process of providing a UI for receiving identification information and verifying the identification information is performed by the identification platform.

[0040] When identification information is retrieved, the method (400) can determine whether the user has the authority to use the resource server by comparing the information with the authentication database in 450. This can be performed by the authentication server. If the client device / user is identified as having authority ("Yes" in 450), the method (400) can proceed to the step (420) of generating an access token as described above. However, if the client device / user is determined not to have authority ("No" in 450), the method (400) can provide a notification to the resource client in 455 that the client device / user is not an authorized user. In response, the resource client can display a notification to the user indicating that the authentication information provided by the user is incorrect and allow the user to enter alternative identification information.

[0041] After an access token is generated, the method (400) can determine in 425 whether the resource server requires compliance with a conditional access policy. The conditional access policy may include compliance with specific device states, such as a non-jailbroken device, a state having a specific operating system, or a managed device. This may be an access policy set by an administrator, such as a VPN administrator, as a prerequisite for utilizing the resource server. If it is determined that compliance with the conditional access policy is not required, the method (400) may proceed to the step (440) of sending 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" in 425), the method (400) can determine in 430 whether the conditional access policy is satisfied. This may include performing a query on the device management provider of the resource client and / or client device to determine one or more device states. Then, the device status is transmitted to the identification platform so that it can be determined whether the client device meets the requirements.

[0042] If the device is determined to be compliant ("Yes" in 430), the method (400) may include device compliance verification in the access token in 435. This information may be provided as an indication within the token. Once device compliance is verified and compliance verification information is included in the access token, the method (400) may send the access token to the resource client in 440. In an alternative implementation, compliance verification may not be included in the access token. Instead, compliance with the conditional access policy may be verified before the access token is generated. In such an implementation, the access token may be generated after it has been verified that the client device meets the conditional access requirements. Consequently, the generation of the access token itself may be an indication that it complies with the conditional access policy.

[0043] However, if it is determined that the device does not satisfy the conditional access requirements, the method (400) may proceed to the step (455) of providing a notification to the resource client. This may include the transmission of notification information informing the user that authentication cannot be approved because the device does not satisfy one or more conditional access policy requirements. In response to this, the resource client may display a notification to the user informing them of the conditional access policy requirements.

[0044] Accordingly, in different implementations, a technical solution may be provided that enables the use of access tokens generated by an independent identification platform to authorize client devices to access resource servers, such as VPN servers, and / or to verify compliance with the resource server's conditional access policy. To achieve this, the technical solution may utilize an identification platform that communicates with resource client and / or client device management providers to authenticate users and verify that the client devices comply with the conditional access policy. In this way, verification of conditional access policy compliance can be integrated into the authentication process. The identification platform may generate and transmit access tokens that can be used to communicate securely with the resource server. Additionally, the token may include a nonce of the master session key associated with the active session to enhance security. This improves the user experience and strengthens security while increasing the system efficiency of the resource server.

[0045] FIG. 5 is a block diagram (500) illustrating an exemplary software architecture (502), and various parts of this software architecture may be used with various hardware architectures described herein that can implement any of the features described above. FIG. 5 is a non-limiting example of a software architecture, and it should be understood that many other architectures may be implemented to facilitate the functions described herein. The software architecture (502) may be executed on hardware such as a client device, a native application provider, a web server, a server cluster, an external service, and other servers. A representative hardware layer (504) includes a processing unit (506) and associated executable commands (508). Executable commands (508) represent executable commands of the software architecture (502) including implementations of methods and modules, etc., described herein.

[0046] The hardware layer (504) also includes memory / storage (510), and the memory / storage (510) also includes executable commands (508) and data associated therewith. The hardware layer (504) may also include other hardware modules (512). The commands (508) held by the processing unit (506) may be part of the commands (508) held by the memory / storage (510).

[0047] An exemplary software architecture (502) can be conceptualized as layers, each providing various functions. For example, the software architecture (502) may include layers and components such as an operating system (OS) (514), a library (516), a framework (518), an application (520), and a presentation layer (544). Optionally, the application (520) and / or other components within the layers may call API calls (524) to other layers and receive corresponding results (526). The layers depicted are essentially typical, and other software architectures may include additional layers or different layers. For example, some mobile or special-purpose operating systems may not provide a framework (518).

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

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

[0050] A framework (518) (often referred to as middleware) provides a higher-level common infrastructure that can be used by applications (520) and / or other software modules. For example, the framework (518) can provide various graphical user interface (GUI) functions, advanced resource management, or advanced location services. The framework (518) can provide a wide range of other APIs for applications (520) and / or other software modules.

[0051] The application (520) includes an embedded application (540) and / or a third-party application (542). Examples of the embedded application (540) may include, but are not limited to, a contact application, a browser application, a location application, a media application, a messaging application, and / or a game application. The third-party application (542) may include any application developed by an entity other than the vendor of the specific system. The application (520) may create a user interface for interacting with the user using functions available through the OS (514), library (516), framework (518), and presentation layer (544).

[0052] Some software architectures use a virtual machine as illustrated in the virtual machine (548). The virtual machine (548) provides an execution environment that can run applications / modules as if they were running on a hardware machine (e.g., the machine (600) in FIG. 6). The virtual machine (548) may be hosted by a host OS (e.g., OS (514)) or a hypervisor and may have a virtual machine monitor (546) that manages the operation of the virtual machine (548) and interoperability with the host operating system. Software architectures that may differ from software architectures (502) outside the virtual machine, such as the OS (550), libraries (552), frameworks (554), applications (556), and / or presentation layers (558), run within the virtual machine (548).

[0053] FIG. 6 is a block diagram illustrating components of an exemplary machine (600) configured to read commands from a machine-readable medium (e.g., a machine-readable storage medium) and perform any feature described herein. The exemplary machine (600) is in the form of a computer system (e.g., a programmable device), and within this computer system, a command (616) (e.g., in the form of a software component) may be executed to cause the machine (600) to perform any feature described herein. Thus, the command (616) may be used to implement a method or component described herein. The command (616) causes an unprogrammed and / or unconfigured machine (600) to operate as a specific machine configured to perform the described feature. The machine (600) may be configured to operate as a standalone device or may be coupled to another machine (e.g., network connected). In a networked deployment, the machine (600) may 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. The machine (600) may be implemented, for example, as a server computer, client computer, personal computer (PC), tablet computer, laptop computer, netbook, set-top box (STB), game and / or entertainment system, smartphone, mobile device, wearable device (e.g., smart watch), and Internet of Things (IoT) device. Additionally, although only a single machine (600) is illustrated, the term “machine” includes a set of machines executing commands (616) individually or jointly.

[0054] The machine (600) may include a processor (610), a storage (630), and an I / O component (650) that can be coupled to communicate via a bus (602), for example. The bus (602) may include multiple buses that combine various components of the machine (600) through various bus technologies and protocols. In one example, the processor (610) (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), an ASIC, or a suitable combination thereof) may include one or more processors (612a to 612n) capable of executing instructions (616) and processing 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 multicore processor comprising cores capable of executing instructions simultaneously. FIG. 6 illustrates a multicore processor, but the machine (600) may include a single processor having a single core, a single processor having multiple cores (e.g., a single multicore processor), multiple processors each having a single core, multiple processors each having multiple cores, or any combination thereof. In some examples, the machine (600) may include multiple processors distributed across multiple machines.

[0055] The memory / storage (630) may include main memory (632), static memory (634) or other memory, and a storage unit (636), both of which are accessible to the processor (610) via the bus (602). The storage unit (636) and the memory (632, 634) store instructions (616) that implement any one or more of the functions described herein. The memory / storage (630) may also store temporary, intermediate and / or long-term data for the processor (610). The instructions (616) may also be in memory (632, 634), in the storage unit (636), in at least one of the processor (610) (e.g., in the instruction buffer or cache memory), in memory of at least one of the I / O components (650), or in any suitable combination thereof, wholly or partially, while being executed. Accordingly, memory (632, 634), storage unit (636), memory of processor (610), and memory of I / O component (650) are examples of machine-readable media.

[0056] As used herein, “machine-readable medium” refers to a device capable of storing commands and data that cause the machine (600) to operate in a particular manner, either temporarily or permanently. As used herein, the term “machine-readable medium” does not include the temporary electrical or electromagnetic signal itself (e.g., on a carrier wave propagating through the medium), and thus the term “machine-readable medium” may be considered tangible and non-temporary. Non-limiting examples of non-temporary types of machine-readable medium may include, but are not limited to, non-volatile memory (e.g., flash memory or read-only memory (ROM)), volatile memory (e.g., static random access memory (RAM) or dynamic RAM), buffer memory, cache memory, 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 multiple media used to store a command (e.g., command (616)) executed by the machine (600) so that the machine (600) performs one or more of the features described herein when the command is executed by one or more processors (610) of the machine (600). Accordingly, “machine-readable medium” may mean a “cloud-based” storage system or storage network including a single storage device as well as multiple storage devices or devices.

[0057] The I / O component (650) may include various hardware components suitable for receiving inputs, providing outputs, generating outputs, transmitting information, exchanging information, collecting measurements, etc. The specific I / O component (650) included in a specific machine depends on the type and / or function of the machine. For example, a mobile device such as a mobile phone may include a touch input device, while a headless server or IoT device may not include such a touch input device. The specific example of the I / O component illustrated in FIG. 6 is not limited, and other types of components may be included in the machine (600). The grouping of the I / O component (650) is merely for the sake of simplicity in this discussion and is not limited. In various examples, the I / O component (650) may include a user output component (652) and a user input component (654). The user output component (652) may include, for example, a display component for displaying information (e.g., a liquid crystal display (LCD) or a projector), an auditory component (e.g., a speaker), a tactile component (e.g., a vibration motor or a force-feedback device) and / or other signal generators. The user input component (654) may include an alphanumeric input component (e.g., a keyboard or a touchscreen) configured to receive various user inputs such as user commands and / or selections, a pointing component (e.g., a mouse device, a touchpad or other pointing tool), and / or a tactile input component (e.g., a physical button or touchscreen that provides the location and / or force of a touch or touch gesture).

[0058] In some examples, the I / O component (650) may include a biometric component (656), a motion component (658), an environment component (660), and / or a location component (662) among various other sensor components. The biometric component (656) may include, for example, a component for detecting body expressions (e.g., facial expressions, voice expressions, hand or body gestures, or eye tracking), measuring biosignals (e.g., heart rate or brainwaves), and personal identification (e.g., through voice, retina, and / or face-based identification). The location component (662) may include, for example, a location sensor (e.g., a Global Position System (GPS) receiver), an altitude sensor (e.g., a barometric pressure sensor capable of deriving altitude), and / or a direction sensor (e.g., a magnetometer). The motion component (658) may include motion sensors, such as acceleration and rotation sensors. The environment component (660) may include, for example, a light sensor, an acoustic sensor, and / or a temperature sensor.

[0059] The I / O component (650) may include a communication component (664) that implements various technologies operable to connect the machine (600) to network(s) (670) and / or device(s) (680) through each communication combination (672, 682). The communication component (664) may include one or more network interface components or other suitable devices for connecting to the network(s) (670). The communication component (664) may include, for example, a component configured to provide communication via wired communication, wireless communication, cellular communication, Near Field Communication (NFC), Bluetooth communication, Wi-Fi and / or other methods. The device(s) (680) may include other machines or various peripheral devices (e.g., connected via USB).

[0060] In some examples, the communication component (664) may include a component configured to detect an identifier or to detect an identifier. For example, the 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 that identifies a tagged audio signal). In some examples, location information may be determined based on information from the communication component (664), such as (but not limited to) a geographical location via an Internet Protocol (IP) address, Wi-Fi, cellular, NFC, Bluetooth or other wireless station identification and / or a location via signal triangulation.

[0061] Although various embodiments have been described, the description is intended to be illustrative rather than limiting, and more embodiments and implementations are possible within the scope of the embodiments. While many possible combinations of features are illustrated in the accompanying 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 replaced by any other feature or component of any other embodiment unless specifically limited. Accordingly, it should be understood that any feature illustrated and / or discussed herein may be implemented together in any suitable combination. Accordingly, embodiments should be limited only in light of the appended claims and their equivalents. Furthermore, various modifications and changes may be made within the scope of the appended claims.

[0062] Generally, the functions described herein (e.g., features illustrated in FIGS. 1 through 4) may be implemented using software, firmware, hardware (e.g., fixed logic, finite state machines, and / or other circuits), or a combination of these implementations. In the case of a software implementation, program code performs a specified task when executed on a processor (e.g., a CPU or CPUs). Program code may be stored in one or more machine-readable memory devices. The features of the technology described herein are system-independent, which means that the technology may be implemented on various computing systems having various processors. For example, an implementation may include an entity (e.g., software) that causes the hardware to perform an operation (e.g., a processor function block), etc. For example, a hardware device may include a machine-readable medium that may be configured to hold instructions that cause the hardware device (including an operating system and related hardware running on the hardware device) to perform an operation. Accordingly, the command may act to configure the operating system and related hardware to perform an operation, and thereby configure or otherwise adapt the hardware device to perform the aforementioned function. The command may be provided to a hardware element executing the command via a machine-readable medium through various different configurations.

[0063] In the following, additional features, characteristics, and advantages of the present invention are described using items.

[0064] Item 1. As a device,

[0065] processor, and

[0066] It includes a memory that communicates with the above-mentioned processor,

[0067] The above memory stores executable instructions, and when the executable instructions are executed by the processor, the device,

[0068] A function to generate a session key for a communication session between the above device and a resource server,

[0069] A function to derive a nonce from the above session key,

[0070] A function to transmit to an identification platform a request to authenticate the device for accessing the resource server — said request includes said nonce —,

[0071] A function for receiving an access token from the identification platform containing information confirming the authentication of the device upon authentication verification, and

[0072] Performs the function of transmitting the access token to the resource server to enable access to the resource server, and

[0073] The above access token includes the above nonce,

[0074] Device.

[0075] Item 2. Regarding Item 1,

[0076] The above resource server is a virtual private network (VPN),

[0077] Device.

[0078] Item 3. In Item 1 or Item 2,

[0079] The access token includes information identifying the device,

[0080] Device.

[0081] Item 4. In any one of Items 1 through 3,

[0082] The above access token includes information confirming that the device is an authorized device,

[0083] Device.

[0084] Item 5. In any one of Items 1 through 4,

[0085] The access token includes information confirming that the device complies with one or more conditional access policies of the resource server.

[0086] Device.

[0087] Item 6. In any one of Items 1 through 5,

[0088] When the above executable command is executed by the processor, it additionally causes the device,

[0089] A function to transmit the first part of the above session key to the above resource server,

[0090] A function to receive the second part of the session key from the resource server,

[0091] A function to generate the session key from the first part and the second part of the session key, and

[0092] A function that enables the transmission of the above nonce to the identification platform,

[0093] Device.

[0094] Item 7. In any one of Items 1 through 6,

[0095] The above nonce is derived from the session key by generating a hash of the session key,

[0096] Device.

[0097] Item 8. As a method for generating an access token to provide access to a resource server,

[0098] A step of receiving from the device a request to provide the device with an access token to be used to access the resource server — said request includes a nonce derived from a session key generated for a communication session between the device and the resource server —,

[0099] A step of determining whether the above device has permission to access the resource server,

[0100] A step of generating the access token in response to a determination that the device has the authority to access the resource server,

[0101] The step of including the nonce in the access token, and

[0102] A step comprising transmitting the access token to the device,

[0103] method.

[0104] Item 9. Regarding Item 8,

[0105] A step of determining whether the resource server requires compliance with one or more conditional access policies,

[0106] If the resource server determines that it requires compliance with one or more conditional access policies, the step of verifying that the device complies with one or more conditional access policies, and

[0107] The method further comprises the step of including in the access token information that provides confirmation that the device complies with the one or more conditional access policies.

[0108] method.

[0109] Item 10. Regarding Item 9,

[0110] The step of verifying that the above device complies with the one or more conditional access policies is:

[0111] A step of transmitting a request to at least one of the device or a device management provider for the device to provide one or more device states regarding the one or more conditional access policies,

[0112] The step of receiving the status of one or more of the above devices, and

[0113] A step comprising comparing the state of one or more devices with the state of one or more conditional access policies to verify whether the state of one or more devices complies with the state of one or more conditional access policies.

[0114] method.

[0115] Item 11. In any one of Items 8 through 10,

[0116] The access token includes information identifying the device,

[0117] method.

[0118] Item 12. In any one of Items 8 through 11,

[0119] The above access token includes information confirming that the device is an authorized device,

[0120] method.

[0121] Item 13. In any one of Items 8 through 12,

[0122] Upon receiving the above request from the device, a step of determining whether a valid access token for the device is available, and

[0123] The method further comprises the step of transmitting the valid access token to the device in response to a determination that the valid access token for the device is available.

[0124] method.

[0125] Item 14. As a non-transient computer-readable medium storing instructions,

[0126] When the above command is executed, it causes a programmable device,

[0127] Generate a session key for a communication session between the above-mentioned programmable device and the resource server, and

[0128] Derive a nonce from the above session key, and

[0129] Sending a request to an identification platform to authenticate the programmable device for accessing the resource server — said request includes said nonce —,

[0130] Upon authentication verification, an access token containing information verifying the authentication of the programmable device is received from the identification platform, and

[0131] The above access token is transmitted to the resource server to enable access to the resource server, and

[0132] The above access token includes the above nonce,

[0133] Non-transient computer-readable medium.

[0134] Item 15. Regarding Item 14,

[0135] The above resource server is a virtual private network (VPN),

[0136] Non-transient computer-readable medium.

[0137] Item 16. In Item 14 or Item 15,

[0138] The access token includes information identifying the programmable device,

[0139] Non-transient computer-readable medium.

[0140] Item 17. In any one of Items 14 through 16,

[0141] The above access token includes information confirming that the programmable device is an authorized device,

[0142] Non-transient computer-readable medium.

[0143] Item 18. In any one of Items 14 through 17,

[0144] The access token includes information confirming that the programmable device complies with one or more conditional access policies of the resource server.

[0145] Non-transient computer-readable medium.

[0146] Item 19. In any one of Items 14 through 18,

[0147] The above command additionally causes a programmable device,

[0148] Transmit the first part of the above session key to the resource server, and

[0149] Receive the second part of the session key from the resource server, and

[0150] A session key is generated from the first part and the second part of the session key, and

[0151] Derive a nonce from the above session key, and

[0152] transmitting the above nonce to the identification platform,

[0153] Non-transient computer-readable medium.

[0154] Item 20. In any one of Items 14 through 19,

[0155] The above nonce is derived from the session key by generating a hash of the session key,

[0156] Non-transient computer-readable medium.

[0157] While the foregoing items describe what are considered to be optimal embodiments and / or other examples, it should be understood that various modifications may be made to these items, the subject matter of the invention disclosed herein may be embodied in various forms and examples, and the teachings may be applied to numerous applications (only some of which are described herein). The claims set forth below are intended to claim all applications, modifications, and changes that fall within the true scope of the teachings.

[0158] Unless otherwise specified, all measurements, values, grades, locations, scales, sizes, and other specifications described herein (including the claims set forth below) are approximate and not precise. These specifications are intended to have a reasonable range consistent with the functions described by these specifications and the articulation to which these specifications belong.

[0159] The scope of protection is limited only by the claims set forth below. Such scope is intended and should be interpreted as broad as possible in accordance with the ordinary meaning of the language used in the claims when interpreted in light of this specification and the subsequent filing history, and is intended and should be interpreted as encompassing all structural and functional equivalents. Nevertheless, none of the claims are intended to include, nor should they be interpreted in such a way, the subject matter of an invention that does not satisfy the requirements of Section 101, 102, or 103 of the Patent Act. Any unintended inclusion of such subject matter is hereby disclaimed.

[0160] Except as stated immediately above, nothing described or illustrated, whether or not described in the claims, shall be intended to provide to the public any component, step, feature, purpose, benefit, advantage, or equivalent thereof, or shall not be construed as such.

[0161] It should be understood that the terms and expressions used in this specification have the general meanings given to them in relation to their respective areas of investigation and research, except where specific meanings are otherwise provided in this specification.

[0162] Relational terms such as first, second, etc., are used solely to distinguish one entity or action from another and do not necessarily require or imply such actual relationship or order between these entities or actions. Since "comprises," "comprising," and other variations thereof are intended to encompass non-exclusive inclusions, a process, method, article, or device comprising an enumerated component may not only comprise that component but may also comprise other components that are not explicitly enumerated or are not inherent in such process, method, article, or device. A component following the article "a" or "an" does not, without further restriction, exclude the presence of additional identical components in a process, method, article, or device comprising that component.

[0163] A summary of the present disclosure is provided to enable the reader to quickly identify the essence of the technical disclosure. It is submitted on the condition that it is not used to interpret or limit the scope or meaning of the claims. Additionally, in the foregoing detailed description, it may be seen that various features are grouped together in various examples for the purpose of simplifying the present disclosure. This method of disclosure should not be interpreted as reflecting an intention that any claim requires more features than explicitly stated. Rather, as reflected by the claims set forth below, the subject matter of the invention lies in fewer features than all the features of the single example disclosed. Accordingly, the claims set forth below are incorporated into the detailed description, and each claim is independent as a separate subject matter.

Claims

Claim 1 A device comprising a processor and a memory communicating with said processor, wherein the memory stores an executable instruction, and when the executable instruction is executed by said processor, the device performs the operation of transmitting a first portion of a master session key to a resource server; the operation of receiving a second portion of the master session key from said resource server in response to transmitting the first portion of the master session key to said resource server; the operation of generating a master session key for a communication session between said device and said resource server from said first portion and said second portion of the master session key using a resource client software application installed on said device; the operation of deriving a nonce from said generated master session key by generating a hash of said master session key using a resource client software application installed on said device; the operation of transmitting said nonce from said device to an identification platform in an authentication request to authenticate said device to access said resource server when said nonce is derived; the operation of receiving an access token from said identification platform that includes said nonce and also includes information confirming the authentication of said device; and receiving said access token to said resource server A device that performs a transmitting operation and, when the access token is transmitted to the resource server, performs an operation to receive access to the resource server. Claim 2 In paragraph 1, the resource server is a device that is a virtual private network (VPN). Claim 3 In claim 1, the device, wherein the access token includes information identifying the device. Claim 4 In claim 1, the device, wherein the access token includes information confirming that the device is an authorized device. Claim 5 A method for providing access by a device to a resource server, comprising: transmitting a first portion of a master session key to the resource server; receiving a second portion of the master session key from the resource server in response to transmitting the first portion of the master session key to the resource server; generating a master session key for a communication session between the device and the resource server from the first portion and the second portion of the master session key using a resource client software application installed on the device; transmitting an authentication request from the device to an identification platform to provide an access token to be used by the device when accessing the resource server for the communication session between the device and the resource server, wherein the authentication request includes a nonce derived using the resource client software application installed on the device, and the nonce is derived from the master session key by generating a hash of the master session key; and receiving the access token including the nonce from the identification platform in response to transmitting the authentication request. Claim 6 As a non-transient computer-readable medium storing instructions, the instructions, when executed, cause a programmable device to transmit a first portion of a master session key to a resource server, receive a second portion of the master session key from the resource server in response to transmitting the first portion of the master session key to the resource server, generate the master session key for a communication session between the programmable device and the resource server from the first portion and the second portion of the master session key using a resource client software application installed on the programmable device, derive a nonce from the generated master session key by generating a hash of the master session key using the resource client software application installed on the programmable device, and when the nonce is derived, transmit the nonce from the programmable device to an identification platform in an authentication request to authenticate the programmable device to access the resource server, receive an access token from the identification platform that includes the nonce and also includes information confirming the authentication of the programmable device, transmit the access token to the resource server, and when the access token is transmitted to the resource server, receive access to the resource server. A non-transient computer-readable medium. Claim 7 In paragraph 6, the resource server is a non-transient computer-readable medium that is a virtual private network (VPN). Claim 8 In paragraph 6, the access token is a non-transient computer-readable medium comprising information identifying the programmable device. Claim 9 In paragraph 6, the access token is a non-transient computer-readable medium comprising information confirming that the programmable device is an authorized device. Claim 10 In claim 1, the resource client software application is a device that operates automatically in the background of the device. Claim 11 In claim 1, the resource client software application is a device that provides one or more user interface screens that enable a user to interact with the resource client software application. Claim 12 In claim 1, the identification platform communicates with an authentication server to authenticate a user associated with the device for access to the resource server. Claim 13 In paragraph 12, the device, wherein the authentication server provides one or more user interface elements that enable the user to provide authentication information. Claim 14 In paragraph 1, the identification platform is a device that stores the access token. Claim 15 In paragraph 1, the identification platform is a device that manages access tokens. Claim 16 In paragraph 1, the identification platform is a device stored in the device. Claim 17 In paragraph 5, the method wherein the resource server is a virtual private network (VPN). Claim 18 In paragraph 5, the method wherein the access token includes information identifying the device. Claim 19 In paragraph 6, the resource client software application is a non-transient computer-readable medium that provides one or more user interface screens that enable a user to interact with the resource client software application. Claim 20 In paragraph 6, the identification platform is a non-transient computer-readable medium that communicates with an authentication server to authenticate a user associated with the device for access to the resource server.

Images