When you configure Device Trust with Workspace ONE Access, regardless of whether you are using the Original Device Trust or the new Factor-Based Device Trust, you will need to make a decision on the expected outcome when devices are not managed/trusted.
In the Original Device Trust flow, our documentation instructs you to send all failures back to Okta. When we send failures back to Okta, it allows your Okta Application Sign-on Policy to trigger a different authentication flow when a device is not managed by Workspace ONE. This can be anything from Okta Verify to some other authentication flow.
Lets take a quick look at what is happening under the covers. When Workspace ONE receives the SAML AuthN request from Okta, it contains an Assertion Consumer Service (ACS) URL. This is the URL that Okta wants to receive the response from Workspace ONE Access. Ultimately, Okta is expecting a SAML Response from Workspace ONE Access that contains a value in the Name ID attribute for the authenticated principal. However, since Mobile SSO has failed in this case, Okta will receive a failure to their ACS endpoint:
When the ACS endpoint receives a failure response, it will prompt the user to authenticate. This is a fairly common practice in the industry. Once the user authenticates, they may see a “This device must be secured by Workspace ONE” message or prompted for MFA based on your application sign-on policy.
This flow works great for native applications however it may not be a desirable user experience using the Okta Portal on a mobile browser if the user was already authenticated in Okta.
In Factor-Based Device Trust, the experience is very different because Workspace ONE Access will not send any failures back to Okta. The Integration is designed for Workspace ONE Access to display the error.
If you want to support this flow with the Original Device Trust (and you don’t have an application sign-on policy that requires MFA for unmanaged devices), you can also configure the original device trust to display a failure on Workspace ONE Access with a “Return to Okta” link that will send them back to the Okta Portal (This custom error can be configured for Factor-Based Device Trust as well). If the user was previously authenticated, they will be automatically logged into the Okta Portal. In this use case, the user will see an customized error similar to below:
In order to configure this failure notification you will need to modify your Okta Application Source in Workspace ONE Access:
- Log into the Workspace ONE Admin Console
- Go to Catalog -> Web Apps
- Click on Settings
- Click on Application Sources
- Click on Okta
- Click Next
- Expand Advanced Properties
- Disable “Enable Authentication Failure Notification”. This will prevent failures from being sent back to Okta.
- Go to Identity & Access Management -> Policies
- Edit your Okta Policy (or the policy that is being used by the Okta Application Source)
- Click Next
- Click on your platform policy (ie. IOS)
- Expand Advanced Properties
- Enter your Custom Error Message, Custom Error Link Text and Custom Error Link URL
- Click Save,
- Repeat this for all applicable platform policy rules.
- Next and Save
Steve The Identity Guy 
Hi Steve,
We’ve implemented Device Trust between WS-1 and Okta, so your article struck a resonant chord. Passwordless authentication works like a charm. However, in the sad path, upon Device Trust failure, clicking on the WS-1 error page only to be prompted to authenticate by Okta, and then only to get to an Okta error page is of dubious utility. Ideally, what we would like to see is a seamless fail back to Okta (i.e. no WS-1 error page), and then a step up authentication on the Okta side, all with the right entries in the Okta log. We would also like to do all this in a client and/or service specific manner. If you’re interested in discussing further, please reach out to me.
LikeLike