Is Known Device
Checks if the device is registered to the current user
Description
This step ensures that the device attempting to access the application is registered to a specific user. It allows the device to act as a user-identifying factor, which enhances the security of the flow. This step could be used as part of a two-factor authentication approach, leveraging something the user has (their device) and something the user knows (such as a password). It can also be used to elevate trust for known devices, and reduce user friction accordingly.
This step checks if the device is cryptographically bound to the end-user. The validation process involves issuing a challenge to the client to sign using the cryptographic key generated as part of device registration (via the Register Device step). This process is handled implicitly by the client SDK and no user interaction is required.
If the device is known for this user, the journey proceeds to the Success branch. If the device is unknown, you can design the journey to proceed with registering the device for a verified user or implement any other necessary actions.
The output variable is a key_id generated during device registration is used here to verify if the device is recognized as trusted. This ID allows you to manage the device, including updating its details (see Update device key) or removing it from the user’s account if it’s compromised (see Delete device key), ensuring that only known devices can access the application.
Configuration
| Field | Description |
|---|---|
| User Auth State | Indicates the status of user authentication within this journey. If set to the user is authenticated (default), the user context is automatically provided by the journey. If set to the user is not authenticated, the journey does not authenticate the user before invoking this step, so a user identifier must be configured (see External User ID). |
| External User ID | User identifier, specified as an expression. Only configured if the journey doesn't authenticate the user before invoking this step. |
| Output variable | Variable used to store the device key_id generated during the device registration process, inherited by the which can be used in subsequent journey steps. |
Examples
Here are some examples of how to specify a user identifier for the step if the user hasn't authenticated in the journey.
Verification flow
Suppose a journey performs a document verification to verify the user's identity (Verify identity documents), without authenticating the user. If the journey collects a username using a form (Get information from client) and stores it in the username field in the regForm output variable, the user can be set to regForm.username.
Post-login flow
Suppose the user was authenticated before the journey is initiated, such as by logging in using another IDP or they're still authenticated from their last journey. The client can invoke the journey with an authToken parameter that can be validated by the journey using an external web service and used to obtain the user identifier.
If the journey provides @policy.request().params.authToken as input to the web service request and stores their response in an output variable named username, the user can be set to username.
