Passwordless vault access through secure vault enrollment

The present Application for Patent claims the benefit of U.S. Provisional Patent Application No. 63/587,060 by Melberg et al., entitled “PASSWORDLESS VAULT ACCESS THROUGH SECURE VAULT ENROLLMENT,” filed Sep. 29, 2023, which is assigned to the assignee hereof, and which is expressly incorporated by reference herein.

The present disclosure relates generally to identity management, and more specifically to passwordless vault access through secure vault enrollment.

An identity management system may be employed to manage and store various forms of user data, including usernames, passwords, email addresses, permissions, roles, group memberships, etc. The identity management system may provide authentication services for applications, devices, users, and the like. The identity management system may enable organizations to manage and control access to resources, for example, by serving as a central repository that integrates with various identity sources. The identity management system may provide an interface that enables users to access a multitude of applications with a single set of credentials.

A method is described. The method may include: performing a sign-in or registration process to register a user with an application of an identity management system, where the sign-in or registration process includes receiving an indication of at least one credential associated with an identity of the user; performing a vault enrollment process to configure a secure vault for the user of the application, where the vault enrollment process includes: generating a cryptographically random identifier; combining the cryptographic random identifier with one or more attributes of the user to generate a Recovery Key (e.g., a secret key); using a client-side encryption function to derive a symmetric key from the Recovery Key; generating a cryptographically random asymmetric keypair that includes a private key and a public key; encrypting the private key of the cryptographically random asymmetric keypair with the symmetric key derived from the Recovery Key; storing one or more of the Recovery Key (e.g., a device key, a vault key, a secret key, or any combination thereof), the symmetric key, the private key, and the public key on a first client device of the user; and uploading, to the identity management system, data associated with the secure vault configured for the user of the application; performing a device pairing operation to transfer the Recovery Key from the first client device to a second client device of the user, where the second client device is operable to use the Recovery Key to generate the symmetric key, the private key, the public key, or a combination thereof; and using one or more of the Recovery Key, the symmetric key, the private key, or the public key to access the application of the identity management system via the second client device of the user.

An apparatus is described. The apparatus may include: one or more memories storing processor-executable code; and one or more processors coupled with the one or more memories. The one or more processors may be individually or collectively operable to execute the code to cause the apparatus to: perform a sign-in or registration process to register a user with an application of an identity management system, where the sign-in or registration process includes receiving an indication of at least one credential associated with an identity of the user; perform a vault enrollment process to configure a secure vault for the user of the application, where the vault enrollment process includes: generating a cryptographically random identifier; combining the cryptographically random identifier with one or more attributes of the user to generate a Recovery Key; using a client-side encryption function to derive a symmetric key from the Recovery Key; generating a cryptographically random asymmetric keypair that includes a private key and a public key; encrypting the private key of the cryptographically random asymmetric keypair with the symmetric key derived from the Recovery Key; storing one or more of the Recovery Key, the symmetric key, the private key, and the public key on a first client device of the user; and uploading, to the identity management system, data associated with the secure vault configured for the user of the application; perform a device pairing operation to transfer the Recovery Key from the first client device to a second client device of the user, where the second client device is operable to use the Recovery Key to generate the symmetric key, the private key, the public key, or a combination thereof; and use one or more of the Recovery Key, the symmetric key, the private key, or the public key to access the application of the identity management system via the second client device of the user.

A non-transitory computer-readable medium storing code is described. The code may include instructions executable by at least one processor to: perform a sign-in or registration process to register a user with an application of an identity management system, where the sign-in or registration process includes receiving an indication of at least one credential associated with an identity of the user; perform a vault enrollment process to configure a secure vault for the user of the application, where the vault enrollment process includes: generating a cryptographically random identifier; combining the cryptographically random identifier with one or more attributes of the user to generate a Recovery Key; using a client-side encryption function to derive a symmetric key from the Recovery Key; generating a cryptographically random asymmetric keypair that includes a private key and a public key; encrypting the private key of the cryptographically random asymmetric keypair with the symmetric key derived from the Recovery Key; storing one or more of the Recovery Key, the symmetric key, the private key, and the public key on a first client device of the user; and uploading, to the identity management system, data associated with the secure vault configured for the user of the application; perform a device pairing operation to transfer the Recovery Key from the first client device to a second client device of the user, where the second client device is operable to use the Recovery Key to generate the symmetric key, the private key, the public key, or a combination thereof; and use one or more of the symmetric key, the private key, or the public key to access the application of the identity management system via the second client device of the user.

In some examples described herein, the sign-in or registration process may include operations, features, means, or instructions for receiving, via the first client device or the second client device, a user input including the at least one credential of the user and a one-time password (OTP) provided by the identity management system.

In some examples described herein, the OTP includes a 6-digit email verification code. In some examples described herein, the first client device includes a mobile client, and the second client device includes a web client. In some examples described herein, the first client device includes a web client, and the second client device includes a mobile client.

Some examples described herein may further include installing the application or a plug-in (e.g., a browser extension) associated with the application on the first client device or the second client device, where at least one step of the vault enrollment process is performed using the application or the browser extension.

In some examples described herein, the Recovery Key may be transferred from the first client device to the second client device via a user input (e.g., a quick response (QR) code), or a secure communication link between the first client device and the second client device.

In some computing systems, a software application may request a user to log into an account using authentication information, such as a combination of a username and a password. Users who have accounts for several different applications must therefore remember several different usernames and passwords. Additionally, or alternatively, the necessity of separately logging in to each application may impose a considerable burden on a user, who must enter usernames and passwords for each application used. In some cases, a user may employ a service of an identity management system to help manage passwords or other identifying information of the user that may be use for accessing the user's accounts with various software applications. Such a service may be referred to herein as a vault or a credential manager (e.g., a digital wallet). The identity management system may necessitate that a user perform a multi-step unlock sequence to access the user's vault. In some cases, however, the multi-step sequence may rely on multiple knowledge factors, such as a password and a personal identification number (PIN). In some examples, however, a quantity of digits included in the PIN (e.g., six digits) may constrain a quantity of users of an identity management system that may be supported by a respective PIN. For example, a six-digit PIN may not provide sufficient PIN diversity for the identity management system to support an increasing quantity of users (e.g., without introducing security vulnerabilities to the identity management system). Additionally, necessitating that users remember two relatively complex knowledge factors may lead to an increase in forgotten-password requests, which may lead to a degraded user experience.

Various aspects of the present disclosure generally relate to passwordless vault access through secure vault enrollment and, more specifically, to a framework for enabling user access to secure data without knowledge factors. For example, a user may use an identity management system to manage the user's access to an account the user has with an application. To enable the identity management system to store various identifying information of the user, such that the user may access the account, the user may determine to perform a vault enrollment process. In accordance with the vault enrollment process, the user may submit a single credential to the identity management system via a user interface on a first client device of the user. The user interface may be part of a client (e.g., software application running on or accessed via the first client device) associated with the identity management system, such as web client or a mobile client. The credential may be of relatively low complexity and may be relatively easy for the user to remember, such as an email address. The client may then randomly generate a secret key (e.g., a Recovery Key) that may be stored on the client device.

For example, to configure a secure vault for the user (e.g., to enroll the user for access to a secure vault), the client may first generate a cryptographically random identifier that includes a device key. The client may then generate the secret key by combining the device key with one or more attributes of the user (e.g., some identifying information of the user that is accessible by the client on the client device). The client may use a client-side encryption function (e.g., an encryption function of the client) to derive a symmetric key from the secret key. The client may generate an asymmetric keypair (e.g., a cryptographically random asymmetric keypair) that includes a private key and a public key. The client may then encrypt the private key of the cryptographically random asymmetric keypair with the symmetric key derived from the secret key. The client may store at least one of the multiple keys on the client device of the user (e.g., a mobile device, a laptop). The stored key may be referred to herein as a Recovery Key and may be used as a backup for account access. The client may then upload data to the identity management system (e.g., to one or more servers of the identity management system). The data may be associated with the secure vault configured (e.g., enrolled) for the user.

In some examples, the user may wish to access the vault from multiple devices. For example, the user may wish to access the vault for access to the application on a second client device of the user. As such, the identity management system may enable secure sharing of one or more of the stored keys between the first and second client devices of the user. For example, the client may perform a device pairing operation to transfer the Recovery Key from the first client device to the second client device of the user. The second client device may include the client (or another client associated with the identity management system) and may use the Recovery Key (e.g., a device key) to generate a vault key, a security key, the symmetric key, the private key, the public key, or a combination thereof. The user may then access the application on the client device using one of the symmetric key, the private key, the public key, or some combination thereof. Aspects of the disclosure are initially described in the context of a computing system and flowcharts. Aspects of the disclosure are further illustrated by and described with reference to apparatus diagrams, system diagrams, and flowcharts that relate to passwordless vault access through secure vault enrollment.

illustrates an example of a computing systemthat supports passwordless vault access through secure vault enrollment in accordance with various aspects of the present disclosure. The computing systemincludes a computing device(such as a desktop, laptop, smartphone, tablet, or the like), an on-premises system, an identity management system, and a cloud system, which may communicate with each other via a network, such as a wired network (e.g., the Internet), a wireless network (e.g., a cellular network, a wireless local area network (WLAN)), or both. In some cases, the network may be implemented as a public network, a private network, a secured network, an unsecured network, or any combination thereof. The network may include various communication links, hubs, bridges, routers, switches, ports, or other physical and/or logical network components, which may be distributed across the computing system.

The on-premises system(also referred to as an on-premises infrastructure or environment) may be an example of a computing system in which a client organization owns, operates, and maintains its own physical hardware and/or software resources within its own data center(s) and facilities, instead of using cloud-based (e.g., off-site) resources. Thus, in the on-premises system, hardware, servers, networking equipment, and other infrastructure components may be physically located within the “premises” of the client organization, which may be protected by a firewall(e.g., a network security device or software application that is configured to monitor, filter, and control incoming/outgoing network traffic). In some examples, users may remotely access or otherwise utilize compute resources of the on-premises system, for example, via a virtual private network (VPN).

In contrast, the cloud system(also referred to as a cloud-based infrastructure or environment) may be an example of a system of compute resources (such as servers, databases, virtual machines, containers, and the like) that are hosted and managed by a third-party cloud service provider using third-party data center(s), which can be physically co-located or distributed across multiple geographic regions. The cloud systemmay offer high scalability and a wide range of managed services, including (but not limited to) database management, analytics, machine learning (ML), artificial intelligence (AI), etc. Examples of cloud systemsinclude (AMAZON WEB SERVICES) AWS®, MICROSOFT AZURE®, GOOGLE CLOUD PLATFORM®, ALIBABA CLOUD®, ORACLE® CLOUD INFRASTRUCTURE (OCI), and the like.

The identity management systemmay support one or more services, such as a single sign-on (SSO) service, a multi-factor authentication (MFA) service, an application programming interface (API) service, a directory management service, or a provisioning servicefor various on-premises applications(e.g., applicationsrunning on compute resources of the on-premises system) and/or cloud applications(e.g., applicationsrunning on compute resources of the cloud system), among other examples of services. The SSO service, the MFA service, the API service, the directory management service, and/or the provisioning servicemay be individually or collectively provided (e.g., hosted) by one or more physical machines, virtual machines, physical servers, virtual (e.g., cloud) servers, data centers, or other compute resources managed by or otherwise accessible to the identity management system.

A usermay interact with the computing deviceto communicate with one or more of the on-premises system, the identity management system, or the cloud system. For example, the usermay access one or more applicationsby interacting with an interfaceof the computing device. In some implementations, the usermay be prompted to provide some form of identification (such as a password, personal identification number (PIN), biometric information, or the like) before the interfaceis presented to the user. In some implementations, the usermay be a developer, customer, employee, vendor, partner, or contractor of a client organization (such as a group, business, enterprise, non-profit, or startup that uses one or more services of the identity management system). The applicationsmay include one or more on-premises applications(hosted by the on-premises system), mobile applications(configured for mobile devices), and/or one or more cloud applications(hosted by the cloud system).

The SSO serviceof the identity management systemmay allow the userto access multiple applicationswith one or more credentials. Once authenticated, the usermay access one or more of the applications(for example, via the interfaceof the computing device). That is, based on the identity management systemauthenticating the identity of the user, the usermay obtain access to multiple applications, for example, without having to re-enter the credentials (or enter other credentials). The SSO servicemay leverage one or more authentication protocols, such as Security Assertion Markup Language (SAML) or OpenID Connect (OIDC), among other examples of authentication protocols. In some examples, the usermay attempt to access an applicationvia a browser. In such examples, the browser may be redirected to the SSO serviceof the identity management system, which may serve as the identity provider (IdP). For example, in some implementations, the browser (e.g., the user's request communicated via the browser) may be redirected by an access gateway(e.g., a reverse proxy-based virtual application configured to secure web applicationsthat may not natively support SAML or OIDC).

In some examples, the access gatewaymay support integrations with legacy applicationsusing hypertext transfer protocol (HTTP) headers and Kerberos tokens, which may offer universal resource locator (URL)-based authorization, among other functionalities. In some examples, such as in response to the user's request, the IdP may prompt the userfor one or more credentials (such as a password, PIN, biometric information, or the like) and the usermay provide the requested authentication credentials to the IdP. In some implementations, the IdP may leverage the MFA servicefor added security. The IdP may verify the user's identity by comparing the credentials provided by the userto credentials associated with the user's account. For example, one or more credentials associated with the user's account may be registered with the IdP (e.g., previously registered, or otherwise authorized for authentication of the user's identity via the IdP). The IdP may generate a security token (such as a SAML token or OAth 2.0 token) containing information associated with the identity and/or authentication status of the userbased on successful authentication of the user's identity.

The IdP may send the security token to the computing device(e.g., the browser or applicationrunning on the computing device). In some examples, the applicationmay be associated with a service provider (SP), which may host or manage the application. In such examples, the computing devicemay forward the token to the SP. Accordingly, the SP may verify the authenticity of the token and determine whether the useris authorized to access the requested applications. In some examples, such as examples in which the SP determines that the useris authorized to access the requested application, the SP may grant the useraccess to the requested applications, for example, without prompting the userto enter credentials (e.g., without prompting the user to log-in). The SSO servicemay promote improved user experience (e.g., by limiting the number of credentials the userhas to remember/enter), enhanced security (e.g., by leveraging secure authentication protocols and centralized security policies), and reduced credential fatigue, among other benefits.

The MFA serviceof the identity management systemmay enhance the security of the computing systemby prompting the userto provide multiple authentication factors before granting the useraccess to applications. These authentication factors may include one or more knowledge factors (e.g., something the userknows, such as a password), one or more possession factors (e.g., something the useris in possession of, such as a mobile app-generated code or a hardware token), or one or more inherence factors (e.g., something inherent to the user, such as a fingerprint or other biometric information). In some implementations, the MFA servicemay be used in conjunction with the SSO service. For example, the usermay provide the requested login credentials to the identity management systemin accordance with an SSO flow and, in response, the identity management systemmay prompt the userto provide a second factor, such as a possession factor (e.g., a onetime passcode (OTP), a hardware token, a text message code, an email link/code). The usermay obtain access (e.g., be granted access by the identity management system) to the requested applicationsbased on successful verification of both the first authentication factor and the second authentication factor.

The API serviceof the identity management systemcan secure APIs by managing access tokens and API keys for various client organizations, which may enable (e.g., only enable) authorized applications (e.g., one or more of the applications) and authorized users (e.g., the user) to interact with a client organization's APIs. The API servicemay enable client organizations to implement customizable login experiences that are consistent with their architecture, brand, and security configuration. The API servicemay enable administrators to control user API access (e.g., whether the userand/or one or more other users have access to one or more particular APIs). In some examples, the API servicemay enable administrators to control API access for users via authorization policies, such as standards-based authorization policies that leverage OAuth 2.0. The API servicemay additionally, or alternatively, implement role-based access control (RBAC) for applications. In some implementations, the API servicecan be used to configure user lifecycle policies that automate API onboarding and off-boarding processes.

The directory management servicemay enable the identity management systemto integrate with various identity sources of client organizations. In some implementations, the directory management servicemay communicate with a directory serviceof the on-premises systemvia a software agentinstalled on one or more computers, servers, and/or devices of the on-premises system. Additionally, or alternatively, the directory management servicemay communicate with one or more other directory services, such as one or more cloud-based directory services. As described herein, a software agentgenerally refers to a software program or component that operates on a system or device (such as a device of the on-premises system) to perform operations or collect data on behalf of another software application or system (such as the identity management system).

The provisioning serviceof the identity management systemmay support user provisioning and deprovisioning. For example, in response to an employee joining a client organization, the identity management systemmay automatically create accounts for the employee and provide the employee with access to one or more resources via the accounts. Similarly, in response to the employee (or some other employee) leaving the client organization, the identity management systemmay autonomously deprovision the employee's accounts and revoke the employee's access to the one or more resources (e.g., with little to no intervention from the client organization). The provisioning servicemay maintain audit logs and records of user deprovisioning events, which may help the client organization demonstrate compliance and track user lifecycle changes. In some implementations, the provisioning servicemay enable administrators to map user attributes and roles (e.g., permissions, privileges) between the identity management systemand connected applications, ensuring that user profiles are consistent across the identity management system, the on-premises system, and the cloud system.

Although not depicted in the example of, a person skilled in the art would appreciate that the identity management systemmay support or otherwise provide access to any number of additional or alternative services, applications, platforms, providers, or the like. In other words, the functionality of the identity management systemis not limited to the exemplary components and services mentioned in the preceding description of the computing system. The description herein is provided to enable a person skilled in the art to make or use the present disclosure. Various modifications to the present disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the present disclosure. Accordingly, the present disclosure is not limited to the examples and designs described herein, but is to be accorded the broadest scope consistent with the principles and novel features disclosed herein.

shows an example of a flowchartthat supports passwordless vault access through secure vault enrollment in accordance with aspects of the present disclosure. The flowchartmay implement one or more aspects of the computing system, as shown and described with reference to. For example, one or more operations of the flowchartmay be implemented (at least in part) by the identity management system, a first client device(such as a web client or a mobile client), and a second client device(such as a mobile client or a web client), which may be examples of corresponding devices and systems described herein, including with reference to. The flowchartdepicted in the example ofshows an example of a passwordless vault access scheme, whereby a user of the identity management systemcan securely access an applicationof the identity management systemwithout providing a password.

The described techniques enable consumers to securely access their apps, credentials, and other secure data without the need to provide a knowledge factor. The identity management systemutilizes a multi-step “unlock” sequence that relies on two knowledge factors: a password created by the user at registration, used to establish an authenticated session with an IdP (such as the identity management system); a cryptographically random string made up of a quantity of alphanumeric characters (e.g., a range of 16 to 24 alphanumeric characters), used as input for creating a symmetric key. This symmetric key is used to encrypt/decrypt keys used to encrypt/decrypt credentials and is never shared with the identity management system. The techniques described herein support techniques for avoiding knowledge factors altogether.

With client-side encryption, a second knowledge factor may be introduced to user registration and authentication flows. A 6-digit personal identification number (PIN) may not have sufficient entropy, making it difficult to scale beyond a threshold number of registered users without a risk to product health. The password and PIN may not be coupled together if the identity management systemdoes not implement a secure remote password (SRP) to avoid revealing secrets to the IdP. Having users memorize two complex knowledge factors may cause churn and increase forgotten-password requests. Other organizations may leverage phishing resistant solutions like passkeys and device authenticators to authenticate users.

Usersmay have at most one knowledge factor for both authentication and encryption. Servers of the identity management systemmay refrain from putting any sensitive user data at risk, even with significant computing power. Userscan regain access to their account/vault with or without the assistance of another useror individual. The techniques described herein generally provide for passwordless authentication and passwordless vault access.

In some implementations, the identity management systemmay support passwordless authentication through Fast Identity Online (FIDO2). Some identity verification techniques involve knowledge-based credentials that are stored on a server. Such credentials may include short message service (SMS) one-time passwords (OTP) and passwords. Possession-based credentials, on the other hand, are kept on-device. These credentials may include local biometric and multi-device FIDO credentials. Delegating authentication to an IdP like the identity management systemmay provide several technical advantages. For example, an applicationcan simply configure authentication to be passwordless for its users based on one of the following methods: email or SMS; clicking on a link from the user's email client; providing a one-time password sent to their email address; providing a one-time password sent via SMS; and device biometrics The techniques described herein may utilize device biometrics (where supported) to quickly and securely login. Additionally, or alternatively, the described techniques may leverage “progressive enrollment”, granting users the ability to provide their password as a fallback.

The identity management systemmay provide the following additional method as passwordless techniques: a method that utilizes the authenticator application on a desktop or mobile app and biometrics to quickly and securely login, and phishing-resistant, for example, when the identity management systemadopts a passwordless authentication solution relatively quickly, as an associated identity provider lets us configure this within their login mechanism.

shows an example of a flowchartthat supports passwordless vault access through secure vault enrollment in accordance with aspects of the present disclosure. The flowchartmay implement one or more aspects of the computing system, as shown and described with reference to. For example, one or more operations of the flowchartmay be implemented (at least in part) by the identity management system, a first client device(such as a web client or a mobile client), and a second client device(such as a mobile client or a web client), which may be examples of corresponding devices and systems described herein, including with reference to. The flowchartdepicted in the example ofshows an example of a passwordless vault access scheme that enables a userof the identity management systemto securely access an applicationof the identity management systemwithout providing a password.

The passwordless vault access schemes described herein may utilize web authentication and pseudo-random function extension(s). As an authentication extension (e.g., to WebAuthn) the pseudo-random function extension may grant developers the ability to derive cryptographically random 32-byte Array Buffers, which can represent symmetric key material. Contained within a browser context, clients may be able to easily derive deterministic symmetric keypairs.

During registration, a browser client may request pseudo-random function (PRF) support when an authenticator (device, browser, etc.) explicitly requests it. After a successful authentication request, the browser can retrieve access to the PRF key and generate a cryptographic key in raw format.

Once a symmetric key is generated, it can be used as a derived wrapper key, encrypting the vault encryption/decryption keys. This allows web clients access to derive shared keys, and builds off of a well-known protocol by utilizing a possession-factor to derive symmetric keys. Device-assisted mechanisms can be used to avoid passwords. Device-assisted mechanisms can be used to avoid passwords. Some password managers rely on leveraging the user's smartphone “as a password”. The device acts as a hardware security module (HSM), which provides the relying party with a key to decrypt sensitive data.

Device-assisted account access may be used instead of the knowledge factor (password) with a possession factor, something the user “has”. As long as this secondary device is accessible, data can be decrypted securely. Examples of device-assisted schemes include: establishing a secure connection between two devices, where secrets can be shared within an end-to-end encrypted channel; swipe-to-login, using push notifications to initiate a Diffie-Hellman key exchange; login with device, using push notifications and a fingerprint passphrase to initiate a Diffie-Hellman key exchange; Bluetooth Diffie-Hellman key exchange over Bluetooth. One or more of the above-mentioned processes may be enabled during onboarding.

For example, a user is often subject to an extensive setup that accomplishes the following: establish a long-lived session on the primary device (e.g. home computer); download a mobile application; generate and store a public/private keypair on the device; and link devices to the mobile application. A relationship between devices can be managed in a variety of ways, and a client of the identity management systemcan take an iterative approach to implement a zero-trust model between two devices/agents.

With the techniques described herein, there may be a relatively low likelihood of breaking key encryption, as keys are stored and randomly generated on an HSM. The user experience may be similar to the technology of passkeys. The described techniques can be performed offline, and may be phishing and social-engineering proof. Passkeys may improve upon FIDO authenticators and existing passwordless solutions. Passkeys may help reduce the prevalence of passwords throughout the industry. Implemented with both user experience and security in mind, passkeys provide an easy recovery solution, as credentials are backed up to first and third party cloud providers. Aspects of the present disclosure support multiple enrollments per device, and may offer a phishing-resistant authentication method. The identity management systemmay offer built-in support for all major operating systems, and relatively easy recovery.

shows an example of a flowchartthat supports passwordless vault access through secure vault enrollment in accordance with aspects of the present disclosure. The flowchartmay implement one or more aspects of the computing system, as shown and described with reference to. For example, one or more operations of the flowchartmay be implemented (at least in part) by the identity management system, a first client device(such as a web client or a mobile client), and a second client device(such as a mobile client or a web client), which may be examples of corresponding devices and systems described herein, including with reference to. The flowchartdepicted in the example ofshows an example of a passwordless vault access scheme that enables a userof the identity management systemto securely access an applicationof the identity management systemwithout providing a password.

The techniques described herein support device-assisted recovery. Similar to the device-assisted model, clients of the applicationcan utilize a high-entropy, randomly generated Recovery Key (e.g., device key) that is generated and stored on a client device. At the time of vault enrollment, a client devicewith secure storage may perform the following steps: generate a cryptographically random-character random identifier (e.g., an identifier with a quantity of alphanumeric characters within a range from 16 to 24), known as a Recovery Key; combine, via XOR or concatenation, additional attributes (e.g., userID) to create a Recovery Key (e.g., a secret key); derive an symmetric key using the Recovery Key as an input; generate a random asymmetric keypair; and encrypt the private key with the symmetric key derived from the Recovery Key.

The usermay not have to remember a password, or passphrase to unlock their vault, as keys are derived from a randomly generated identifier that is bound to the client device. Users that intend to access their account on another client deviceor browser may use a secure transfer scheme to get access to this key. For example, a secure communication channel used in the device-assisted model may provide users with the ability to transfer secrets between client devices. This device bootstrapping scheme may function as a recovery-initiated unlock, prompting the userto enter a recovery key/phrase, which is stored by a secure client. Using the device-assisted recovery schemes described herein, it may be difficult to “break” the key encryption, as keys are stored and randomly generated by an HSM of the client device.

To support passwordless vault access, the identity management systemmay leverage one or more of the techniques described herein. For passwordless authentication, email/SMS, biometrics, or both can be enabled for all users of the application. Additionally, or alternatively, the identity management systemcan leverage passkeys, proof-of-private possession, push notifications or OTPs generated via authenticator applications, etc. To support passwordless vault access, the identity management systemmay employ a device-assisted model, which provides userswith improved security by using one or more “trusted” devices to assist with unlocking the vault (and potentially authentication). In some implementations, the identity management systemmay provide passwordless vault access via device-assisted recovery, prompting the userto enter a—character recovery (e.g., a quantity of characters within a range of 16 to 24 characters) or bootstrap key (also referred to herein as a Recovery Key or device key) to unlock their vault when trust has not been established. Additionally, or alternatively, the identity management systemmay support passwordless vault access via push notifications to unlock the vault from a trusted client. In some other implementations, the identity management systemmay support passwordless vault access via proof-of-private possession, joining authentication with vault access.

The described techniques may further support email and biometrics with a Recovery Key. Usersthat register for an account may have a client deviceand a Recovery Key that is generated and stored for them upon successful authentication. To adequately and securely generate and store this key, the applicationmay assert device posture rules by prompting users to install a native mobile application.

In some implementations, a plug-in (e.g., a browser extension) or native mobile applicationmay function as trusted agents of the identity management system. In some examples, multi-device use may involve manual input of the Recovery Key for the first-time use. In other examples, the Recovery Key may be transferred using push notifications, among other examples. An IdP may support passkey enrollment and sign-in as a primary factor. Additionally, users that have enrolled their mobile device as a vault authenticator may be able to access cryptographic keys to decrypt secrets across multiple devices, without needing to manually input their Recovery Key.

In some implementations, push notifications can be used to “unlock” vaults instead of requiring a Recovery Key to be input by the user for users without a browser extension. At any point, users can set up a connection with a native client of the identity management system to securely exchange a Recovery Key. The techniques described herein may further support trusted device authentication and unlock. After a userhas registered on a client devicewith secure storage, they can reuse their existing session and symmetric keys (e.g. vault keys) to bootstrap a secondary device. By extending adaptation of the OAuth 2.0 token exchange protocol, the identity management system may enable a client to establish a web or native session by receiving tokens (access, identity, etc.) from the authenticated client, requesting client-scoped tokens from the authorization server, establishing a browser or native app session using newly granted client tokens. Upon session generation, clients can then securely communicate with one another to establish trust and share vault information. As a result, one previously authenticated device can be used to establish authenticated context with any other device, simplifying login attempts and auto-unlocking the vault for a client application of the identity management system. Users of the application(e.g., client) may be able to utilize a secondary device to login to their account and unlock their vault.

shows an example of a flowchartthat supports passwordless vault access through secure vault enrollment in accordance with aspects of the present disclosure. The flowchartmay implement one or more aspects of the computing system, as shown and described with reference to. For example, one or more operations of the flowchartmay be implemented (at least in part) by the identity management system, a first client device(such as a web client or a mobile client), and a second client device(such as a mobile client or a web client), which may be examples of corresponding devices and systems described herein, including with reference to. The flowchartdepicted in the example ofshows an example of a passwordless vault access scheme that enables a userof the identity management systemto securely access an applicationof the identity management systemwithout providing a password.

The techniques described herein support device-assisted recovery. Similar to device-assisted models, clients of the applicationcan utilize a high-entropy, randomly generated Recovery Key (e.g., device key) that is generated and stored on a client device. At the time of vault enrollment, a client devicewith secure storage may perform the following steps: generate a cryptographically random-character random identifier (e.g., the characters being within a range of 16 to 24 characters), known as a Recovery Key; combine, via XOR or concatenation, additional attributes (e.g., user ID) to create a Recovery Key (e.g., a secret key); derive an symmetric key using the Recovery Key as an input; generate a random asymmetric keypair; and encrypt the private key with the symmetric key derived from the Recovery Key.

The usermay not have to remember a password, PIN, or passphrase to unlock their vault, as keys are derived from a randomly generated identifier that is bound to the client device. Users that intend to access their account on another client deviceor browser may use a secure transfer scheme to get access to this key. For example, a secure communication channel used in the device-assisted model may provide users with the ability to transfer secrets between client devices. This device bootstrapping scheme may function as a recovery-initiated unlock, prompting the userto enter a recovery key/phrase, which is stored by a secure client. Using the device-assisted recovery schemes described herein, it may be difficult to “break” the key encryption, as keys are stored and randomly generated by an HSM of the client device.