Authentication service with shared session tokens for sharing authentication

This application claims priority to U.S. Provisional Patent Application No. 63/506,454, filed on Jun. 6, 2023, entitled “SHARED SESSION STATE,” the content of which is incorporated herein by reference in its entirety.

The present technology pertains to an authentication service, and more particularly, to authentication service with shared session tokens for sharing authentication.

An authorization system for a computer is a critical component of ensuring data security and controlling access to resources within a computing environment. It involves the implementation of policies and mechanisms that govern the granting or denying of permissions to users or entities based on their identity, roles, or privileges. The authorization system establishes a framework to enforce restrictions and permissions, preventing unauthorized users from accessing sensitive information or performing actions beyond their authorized scope. This system typically utilizes authentication mechanisms, such as passwords, biometrics, or digital certificates, to verify the identity of users before granting them access. It also encompasses the management of user roles and permissions, allowing administrators to define and assign fine-grained access controls based on specific requirements and responsibilities. By implementing an effective authorization system, organizations can safeguard their data, mitigate security risks, and maintain compliance with regulatory standards.

Certain aspects of this disclosure are provided below. Some of these aspects may be applied independently and some of them may be applied in combination as would be apparent to those of skill in the art. In the following description, for the purposes of explanation, specific details are set forth in order to provide a thorough understanding of aspects of the application. However, it will be apparent that various aspects may be practiced without these specific details. The figures and descriptions are not intended to be restrictive.

The ensuing description provides example aspects only and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the example aspects will provide those skilled in the art with an enabling description for implementing an example aspect. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the application as set forth in the appended claims.

The terms “exemplary” and/or “example” are used herein to mean “serving as an example, instance, or illustration.” Any aspect described herein as “exemplary” and/or “example” is not necessarily to be construed as preferred or advantageous over other aspects. Likewise, the term “aspects of the disclosure” does not require that all aspects of the disclosure include the discussed feature, advantage or mode of operation.

Disclosed are systems, apparatuses, methods, computer readable medium, and circuits for sharing authentication with shared session tokens using an authentication service. According to at least one example, a method includes: in response to receiving a request to check an authentication status from a first application, transmitting a first message to an authentication service including shared information; providing first authentication credentials related to a first authentication to the authentication service; and receiving a message related to a second authentication to bypass the second authentication.

In another example, a computing system for sharing authentication with shared session tokens using an authentication service is provided that includes a storage (e.g., a memory configured to store data, such as virtual content data, one or more images, etc.) and one or more processors (e.g., implemented in circuitry) coupled to the memory and configured to execute instructions and, in conjunction with various components (e.g., a network interface, a display, an output device, etc.), cause the computing system to: in response to receiving a request to check an authentication status from a first application, transmit a first message to an authentication service including shared information; provide first authentication credentials related to a first authentication to the authentication service; and receive a message related to a second authentication to bypass the second authentication.

In some aspects, one or more of the apparatuses described herein is, is part of, and/or includes a mobile device (e.g., a mobile telephone and/or mobile handset and/or so-called “smartphone” or other mobile device), an extended reality (XR) device (e.g., a virtual reality (VR) device, an augmented reality (AR) device, or a mixed reality (MR) device), a head-mounted device (HMD) device, a vehicle or a computing system, device, or component of a vehicle, a wearable device (e.g., a network-connected watch or other wearable device), a wireless communication device, a camera, a personal computer, a laptop computer, a server computer, another device, or a combination thereof. In some aspects, the apparatus includes a camera or multiple cameras for capturing one or more images. In some aspects, the apparatus further includes a display for displaying one or more images, notifications, and/or other displayable data. In some aspects, the apparatuses described above can include one or more sensors (e.g., one or more inertial measurement units (IMUs), such as one or more gyroscopes, one or more gyrometers, one or more accelerometers, any combination thereof, and/or other sensors).

Authentication has become a time-consuming process that, while still necessary, can impact and frustrate users. For example, in an enterprise context, a user may need to reauthenticate different enterprise applications during the course of business hours. In many cases, applications cannot use operating system authentication information and must use a supplemental authentication, such as using an open authorization (OAuth 2.0) proxy to query the user for authentication credentials. Further exacerbating the repeated authentications are multifactor authentication requirements. The time spent during these authentications is repetitive and interrupts the core functions of the user. While authentication may be necessary, interruptions to the core functions of the user can have detrimental impacts, increase stress, and affect user productivity.

The disclosed technology addresses the foregoing generating a shared session state that can be reused by different sources that require authentication. In some cases, an identification token is generated and used to securely identify a client device. The identification token is used to generate session information associated with each source, and the identification token is encrypted using various encryption techniques (e.g., asymmetric, symmetric, hashing, etc.) to validate responses.

illustrates an example environment utilizing a multifactor authentication (MFA) system in accordance with some aspects of the present technology. Usercan gain authorized access to resourceby using authentication device. Usercan be any user including an employee, contractor, client, member of an organization, private individual, etc. attempting to access a service. The authentication devicecan be hardware, software-only, or combinations thereof. The authentication devicecan be a mobile device or a personal computer.

Resourcecan be any service, resource, device, or entity which requires authentication of user. For example, resourcecan be a social media service, bank, hospital, motor vehicle department, bar, voting system, Internet of Things (IOT) device, or access device. In some embodiments, resourcecan be accessed by userthrough an access device, such as a mobile phone or personal computer. In some embodiments, resourcecan be accessed by userthrough an applicationon an access devicethat is specifically designed for accessing resource, or through a more general applicationthat can access multiple services, such as a web browser, or portions of an operating system. In some embodiments, resourcecan be a plurality of resources, such as a network or enterprise system.

Resourcecan authenticate the identity of useron its own through use of an authentication mechanism and can utilize the trusted authentication providerto provide an additional factor of authentication. For example, usercan attempt to access the resourceusing the access device. In some embodiments, the access devicecan also be the authentication device, such as when userattempts to access the resourceusing an app or browser on authentication device. The resourcecan perform a first authentication mechanism by interacting with the access device. Thereafter, the resourcecan request an additional authentication using authentication device.

In some embodiments, the additional authentication can include requesting a code generated by the authentication device. For example, the MFA applicationmight generate a pseudo-random number using a mechanism agreed upon with resource. The usercan operate the authentication deviceto cause the MFA applicationto generate the pseudo-random number, which usercan then enter into the access deviceto achieve the additional authentication. In some embodiments, if the authentication deviceis equipped with a trusted platform module (TPM)for generating random numbers and encrypting. For example, the MFA applicationcan utilize the TPMto generate the pseudo-random number.

In some embodiments, the additional authentication can include requesting a code or authorization generated by the authentication deviceby making the request through the trusted authentication provider. For example, the resourcecan pass information identifying the userto the trusted authentication providerwith a request for an additional authentication. The trusted authentication providercan send a request (e.g., a push request) for authentication to the authentication device, which is known to be a device associated with the user. The user can respond to the request for authentication on the authentication deviceby interacting with the MFA applicationto perform the required actions. When the required actions are properly performed, the MFA applicationcan send a communication informing the trusted authentication providerof the successful authentication, and the trusted authentication providercan inform the resourceof the successful authentication.

In some embodiments, the additional authentication can include requesting a code generated at resourceto be entered at the authentication deviceby making the request through the trusted authentication provider. For example, the resourcecan pass information identifying the userto the trusted authentication providerwith a request for additional authentication. The trusted authentication providercan send a request (e.g., a push request) for authentication to the authentication device, which is known to be a device associated with the user. In this example, the MFA applicationpresents a user interface requesting that the userenter a code that is presented on the access devicethat originated from the resource. The user can respond to the request for authentication on the authentication deviceby interacting with the MFA applicationto perform the required action by entering the code. When the code is properly entered, the MFA applicationcan send a communication informing the trusted authentication providerof the code, and the trusted authentication providercan pass the code to the resourcewhere the resourcewill consider the additional authentication successful when the received code matches the code sent to the access device. In some aspects, the access devicemay be a TPMfor signing content to ensure integrity of communications. For example, the TPMmay sign a health report that is transmitted to an authentication service.

In some embodiments, the authentication deviceand/or the access devicecan also report context data to the trusted authentication provider. As addressed above the authentication devicecan include the MFA applicationthat can communicate with the trusted authentication provider. The access devicecan include a security agentthat can also communicate with the trusted authentication provider. The MFA applicationand the security agentcan gather and send information to the trusted authentication provider. For example, the information can include biometric, behavioral, and contextual data from user. These biometrics can include, for example, fingerprints, facial detection, retinal scans, voice identification, or gait data, among other biometrics. The context data can include a time since the user last interacted with the device, changes to the network connection experienced by the device, information about the integrity of the operating system of the device, information about what operating system and what version of the operating system the device is running, among other examples. This information can be used by the trusted authentication providerto determine if the device should be trusted to be used as part of the authentication process or trusted to access the resource. In some instances, the information can indicate that something has changed about the user, the authentication device, or the access deviceduring an authenticated session with resourcecan take certain actions depending on a configured policy to access the resource.

illustrates a timelineassociated with multiple authentications that frequently occur in the course of normal operation. In this case, the timelineis separated into distinct phases, namely a login phase, a first application phase, and a second application phase. The login phase can be an initial login or a subsequent login after the computing system locks access due to, for example, inactivity. In this case, a user is presented with an authentication view at time to, and the user enters and successfully authenticates with a password at time t. The password is an example, and the authentication can include other types of authentication mechanisms such as biometric information (e.g., fingerprint), passphrase, hardware encryption key, facial scan, etc.

At time t, the user executes a first application. In many cases, the first application may need to connect with a third-party service to validate the user with different credentials. For example, the first application may be a subscription-based service and the authentication is required to ensure that the user is authenticated for this product. In other cases, the computing system may be configured by an operations department to comport with specific requirements and may need additional authentication checks to ensure that the user is comporting with operation requirements. At time t, the computing system may attempt the authentication for the first application. For example, the third-party service may require a token, such as a JavaScript web token (JWT), that is signed by the third-party service to verify the authentication and authorization of the user. In this case, authentication is the process of verifying the identity of the user, for example, using a password. Authorization is the process of verifying that the authenticated user has credentials to use the application. For example, if the first application is an annual subscription, the third-party service verifies that the user's subscription is valid.

In this example, the first application is presumed to not find an existing authentication token and requests authentication at time t. After the user enters the authentication information and authenticates at time t, the first application can request a secondary authentication using a different mechanism at time t. In this case, the secondary authentication may be a different mechanism (e.g., a passcode sent to a mobile device) that provides more evidence of the user's identity. After the secondary authentication, the first application is loaded at time tand the user is permitted to operate in the normal course of operation.

In the normal course of operation, a second application will generally be executed. For example, the first application may be an email client. A second application, such as a word processor, or a video editor, will be needed for normal operations. For example, a second application is executed at time t. Similar to the first application, the second application may need to authenticate the user with respect to the same or a different third-party service. Accordingly, at time t, the second application attempts authentication and fails, requests authentication at time t, completes authentication at time t, and loads and displays the second application at time t. A second authentication may be presented for the second application and is omitted to limit redundant descriptions. Although not shown, the second application may include a secondary authentication similar to the first application.

The number of authentication attempts can be problematic because of password requirements, rotation of passwords, and other changing authentication mechanisms. But it is still essential that a user provides correct authentication to protect an entity or a person's intellectual assets. No existing solution for authentication exists because of inherent distrust between different systems. Even third-party services that enable a consistent authentication process within an enterprise context still require multiple authentications.

According to aspects of the disclosure, duplicative authentications can be reduced based on sharing authentication information to reduce the number of authentications performed by the user. For example, aspects of the disclosure allow authentications to be shared to prevent duplicative multifactor authentications. As will be further described below, a shared token is created by a separate authentication process at a client and is provided to the server, and the server may inform a service or an application of the existence of the shared token. The shared token is a random string or other value that is generated to temporarily identify a user and a device. For example, a token can be a random number. The client device, when authenticating with an application, can identify the existence of the shared token that is linked to a session token of application, which allow authentication credentials to be shared in some cases to reduce the number of unnecessary authentications and improve user experience.

illustrates a block diagram of an authentication systemfor remembering sessions that can be extended between different applications in accordance with some aspects of the disclosure.

The authentication systemincludes a user deviceand is connected to an authentication service, such as Cisco® Duo services, or any other third-party authentication service (e.g., OAuth, etc.). The user deviceincludes a security agentthat is configured to interface with various applications that execute on the user device, such as the VPN client, the web browser, and the email application. The security agentmay implement a remembered devices features that enable a storage mechanism to remember authentication of a user. For example, the security agentmay generate a shared token that can be provided to authentication service to identify a shared session and link authentications by different applications. The shared session is never exposed to any application and sharing of authentications occurs transparently from the perspective of the applications.

For purposes of clarity, the cookie storage may be implemented to store a shared key that can provide authentication in connection with the remember authentication credentials of the user across different applications (e.g., application executing in the browser sandbox that requires authentication, desktop application execute within the device's user space, etc.). In other cases, the shared key may be stored in locations, such as in memory, a TPM as a key-value pair, and so forth. The security agentcreates a shared token in a health report and sends the token to the authentication service, and the authentication serviceuses the shared token to identify subsequent authentication attempts from the same user. In some cases, the authentication servicecan be used between different application domains and unique session identifiers associated with different applications can be generated to reduce the number of authentications. For example, in some cases, the shared token can provide a second authentication (e.g., a multifactor authentication).

The authentication servicemay be configured to prevent malicious actors to induce the authentication serviceto share a share token with non-authentication devices. For example, the authentication servicemay be configured to detect operation of multiple instances of the security agentand not respond in the event multiple instances of the security agentare executing.

In another example, a malicious user can induce another security agentto send a health report from the authentication serviceincluding the shared token. The authentication serviceand the security agentmay be configured to limit such operations, such as allowing a shared key to have a maximum lifetime (e.g., 12 hours). Other checks by the security agentand the authentication servicemay also be implemented to validate authenticity, such as origin validation (e.g., the request from authentication serviceappears to come from *.duosecurity.com), code signing validation (e.g., the request from the security agentappears to come from a valid application), and user request validation (e.g., the request to the security agentappears to come from the appropriate user of the operating system), and so forth. In another example, instead of a shared token, a cryptographic challenge issued by the authentication serviceand signed by a private key protected by the TPM of the user devicecan be used to provide additional security during authentication. This allows the authentication serviceto authenticate the request and mitigates the leakage concerns of a shared token.

illustrates a sequence diagramfor registering a remembered session in accordance with some aspects of the disclosure. In the example illustrated in, a shared token is generated and used to share authentication credentials between a security agentand an authentication servicewithout any knowledge of the shared token by an application.

In some cases, the authentication system comprises a user device that is executing an application(e.g., a browser) in conjunction with a security agentand an authentication service. Initially, the applicationsends a pre-authentication requestto the security agent, which configures the authentication servicefor operation and a pre-authentication flow. For example, the pre-authentication requestmay configure various shared information that links the application, the security agent, and the authentication service. In one example, as part of the pre-authentication, the applicationtransmits a health report requestto the security agentto request an authentication status. The health report requestincludes user information such as a transmission identifier (txid) that identifies the application executing on a specific device. For example, a transmission identifier can identify an instance of the application. In some cases, the user information can be a token associated with system credentials (e.g., user login, etc.) to uniquely identify a user and device executing the application.

At block, the security agentis configured to search for session information that is identified by the shared token. When the security agentdetermines that the shared token is unavailable, the security agentgenerates a shared token that identifies the user information in the health report request. In some cases, a shared token is a random unique value such as, for example, a 128-bit random value. The security agentsends a health reportto the authentication serviceincluding the shared token and the session information. The authentication serviceprovides an OK responseindicating successfully receiving the request, which can be used by the security agentto identify various issues (e.g., lack of network connection), which is further provided to the application.

At block, the authentication servicereceives the health report and searches for a remembered session that identifies the user and the device based on the shared token at block. The authentication serviceidentifies that there is no valid session and then sends a prompt for authenticationto the application. After input of authentication credentials by the user at the application, the applicationtransmits the authentication credentialsto the authentication serviceand, based on receiving valid authentication credentials, the authentication servicestores a remembered session based on the shared token at block. For example, the authentication servicecan create a remembered session corresponding to the user and the device at block. The authentication serviceresponds with an OK responseindicating successful authentication to the application. In one illustrative example, the authentication servicecan generate a cookie for the applicationthat links the applicationthat links the stored session at the authentication serviceto the instance of the application. In one example, the cookie can be used to bypass later multifactor authentications at the same device. The shared session can also be used to link authentication of other applications.

illustrates a sequence diagramfor authenticating an application using a remembered session in accordance with some aspects of the disclosure. Similar to the sequence diagram, the security agentsends a pre-authentication requestand a health report requestas described above. The security agentreceives the health report requestand searches for a shared token based on information in the health report request. In this case, the shared token is available, and the security agent sends the health reportwith the shared token to the authentication service. At block, the authentication servicereceives the health reportand then searches for a remembered session based on information in the health report. Because the user was previously authenticated in connection with the shared token (e.g., as shown in), the authentication serviceidentifies a remembered session for the user and the device and then responds with an OK responsethat indicates that the authentication was successful based on stored credentials.

In some aspects, a session token can be created by the client and can be shared with a server and uniquely identifies aspects of the client device and the user associated with the security agent. In this case, the session token is provided to an authentication server, which stores the token and can share the session token with other authenticating services, thereby enabling other authenticating services to be remembered to reduce the number of authentication and supplemental authentications.

In some aspects, an application may connect to the security agent and request the security agent to send a report to an authentication service. The report may include identity information that uniquely identifies the user of the device. If the user has recently authenticated from the same device, the authentication service may remember the user, allowing the user to skip additional authentication checks. Existing solutions use a browser cookie to identify a user on a device, which is specific to a domain and cannot be shared between services. Althoughillustrates bypassing an authentication of the application, there are various permutations of this example. For example, a supplemental authentication in a multifactor authentication process may be bypassed. In some cases, authentication of different applications (e.g., applicationinmay be different from applicationin) may be bypassed.

illustrate a shared token that may be subject to interception in some cases (e.g., a man-in-the-middle attack) and the token may be used to spoof authentications. In some aspects, the pre-authentication process may include the generation of a key pair (e.g., an asymmetric key pair controlled by a security agent) for signing traffic between a security agent and an authentication service. For example, during a registration process, an application of the authentication service can generate an asymmetric key pair and register the public key with the authentication service. Registration can happen automatically on first use, or for additional security, can be set up manually by an administrator prior to first use. Each future report sent to the authentication service is signed using the private key at the client device, and the authentication service validates the signed message with the public key. A valid signature provides proof of ownership of the key to the authentication service. A hardware security module, such as a Trusted Platform Module (TPM), may also generate and store a private key of the key pair to guarantee that the private key is unique and non-exportable (e.g., to an incepting device). In contradistinction to a browser cookie, the private key cannot be moved or copied to another computer and provides an extra layer of security.

In this case, no sensitive information is exchanged directly between the client application (e.g., a web-based application) and the authentication application. All identifying information is exchanged locally (e.g., between a browser and another authentication application, or between the authentication application and the authentication service. The client application (e.g., the application requiring authentication) is not exposed to the shared token (or the private key), signature, or health report, and the security agent is not exposed to the user's authentication credentials.

illustrates a sequence diagramillustrating creation of a shared session in accordance with some aspects of the disclosure. In some aspects, an applicationand a security agentare executing on a client deviceand enable a secure connection and secure authentication with an authentication service. The authentication servicemay include multiple services to separate different functions (e.g., an identity service for authenticating identity, a health service for identifying a health of an authentication, etc.), but is illustrated as a single service for simplicity.

In some aspects, the security agentmay generate an asymmetric key-pair and transmit a public key of the asymmetric key-pair to the authentication service. The private key may be stored, for example, in a TPM and only the security agentmay be able to access the private key. As will be described below, the security agentsigns messages with the private key and the authentication servicevalidate the authenticity of the messages based on the signatures. The asymmetric key-pair can be generated at various times, for example during an initial authentication or upon a new instance of the security agent, for example.

The applicationmay initiate a pre-authentication requestto the authentication service, and the authentication servicesends a health check commandthat requests the applicationto perform an authentication health check with the security agent. The applicationthen transmits a health report requestto the security agentand includes user information associated with the client deviceof the application. At block, the security agentsearches for a private key corresponding to the user information. In the event the security agentdoes not identify the private key, the security agent is configured to generate an asymmetric key-pair (e.g., a private key and a public key).

The security agentthen sends a health reportto the authentication service, including the public key and the user information. The public key can be used in place of a shared token to identify the user and device in subsequent communications. For example, a subsequent health reportmay include a signature and the authentication servicemay use public key to verify that the signature is valid and provided by the security agent. In some cases, the health report may also be encrypted.

At block, the authentication servicereceives the health reportand may store the public key at block. For example, the authentication servicemay store a health report of the authentication of the client deviceand the public key may be stored in the health report. The storage of the public key is conditional on how device enrollment is configured. For example, the public key may not be stored when an existing key is configured based on an endpoint identifier, or when the endpoint identifier is not listed a device inventory database. The authentication servicesends an OK responseto the applicationto indicate successful reception of the health report request.

At block, the authentication servicedetermines that the public key is not associated with an existing session of the client deviceof the application. In that case, the authentication servicegenerates session information that is associated with the client deviceand/or the applicationbased on the user information provided by the applicationin the health report request. For example, the user information can identify various information such as an identifier corresponding to an instance of the application. The user information can also be a token that identifies a particular user login into an operating system of the client device. The session information is stored within the authentication serviceand can be used to verify information, such as the validity of a cookie of a browser or if other information from a client device deviates to indicate a potential attack.

The authentication servicesends a prompt for authenticationto the applicationto request input of authentication credentials (e.g., username/password, biometric credentials, etc.) to authenticate a user of the client device. In some cases, the authentication credentialsor other information identifying successful authentication are returned to the authentication service. In some cases, the authentication credentialsmay be signed by the public key, but may also be encrypted using transport layer security (TLS). At block, the authentication servicereceives the authentication credentialsand saves session information identifying the client deviceand the user. This description also presumes that the authentication servicealso verifies that the access to the requested resource (e.g., the application) is permitted. After successful authentication and storing of the session information, the authentication servicesends an authentication responseto the applicationgranting access to the requested resources.

illustrates a sequence diagramillustrating creation of a shared session after a session information in an authentication service in accordance with some aspects of the disclosure. In some aspects, a client devicemay include an applicationthat is configured to authenticate with the authentication servicein connection with the security agent. In this case, the applicationis a different application than the application, and the applicationtriggered the creation of a stored session in the authentication serviceand a public key as illustrated in. However, the applicationmay also be applicationin some cases. For example, the applicationand the applicationmay be applications that execute in a sandbox environment such as a web browser. The applicationand the applicationmay also be different native applications.

When the applicationinitializes, the applicationsends an initial authentication requestto the authentication servicefor pre-authentication processes and such. The authentication servicesends a health check commandto the application. The applicationthen sends a health report requestto the security agent. The health report requestmay include user information that uniquely identifies the user to the security agent.

The security agentin turn searches for a private key associated with the user information at block. In this case, because the private key was created and stored in the security agent, the security agentsends a signed health reportto the authentication service. The signed health reportincludes the shared token and the user information. As noted above, the DHAreturns an OK responseindicating successful reception.

At block, the authentication serviceauthenticates the security agentbased on the signature and then searches for session information stored at the DHAthat matches the user information and the shared token. In some cases, the session information can also be identified based on the user information or the shared token. The authentication serviceidentifies the stored session information that corresponds to the client deviceand a previous authentication. In some cases, blockcan include additional operations, such as identifying the health of the authentication. For example, an authentication performed outside of a 12-hour window may deemed to be stale.

In this case, the authentication servicemay provide a redirect to promptthat requests the applicationto send information that further validates the authenticity of the client deviceand the user. The applicationsearches for, identifies, and responds with authentication credentialsbased on the redirect to prompt. For example, the authentication credentialsmay include a trusted cookie that the provided by the authentication serviceas part of the authentication in, and the user has no part of this process. At block, the authentication serviceis configured to receive the authentication credentialsand verify that the authentication credentialsare valid based on information corresponding to the stored session information in the authentication service. After validating the authentication credentials, the authentication servicesends an authentication responseindicating that the applicationis authenticated.