
GiridharanD.41770 (Customer) asked a question.
We use ChromeOS for our meeting room devices, Gsuite is IDP with OKTA and during enrollement user are prompted for username and clicking Next, then nothing happens, (following URLs are already whitelisted: *.okta.com, *.oktacdn.com, *.mixpanel.com) it stays on the same login page, any one faced similar issue?

My name is Alexandru from Okta Support.
Right now, Passwordless Authentication flow, although not explicitly documented, is not currently supported for Chrome OS devices.
As you do have factor sequencing enabled, this will not work.
Just to clarify login to chromebook via OKTA is not supported.
Reards,
Giri
Logging in to Chromebooks is fully supported and many customers are doing this in production. If the Google Workspace account that is being used to sign in to ChromeOS is federated then the user will be sent to Okta during the ChromeOS login process.
When Factor Sequencing is enabled, users will be stuck after inserting username because is not supported by ChomeOS devices.
There is already an idea suggested on Okta Ideas: https://ideas.okta.com/app/#/case/110072
As this idea has already been implemented in our Okta Ideas, the only option at hand would be for us to vote that option so that our Engineering Team could consider working on it.
The issue with the login screen not progressing with factor sequencing enabled can by worked around by adding a routing rule for "other" platforms (ChromeOS is not listed as a platform). This rule does not need to do anything, it just needs to exist so that the default routing rule does not trigger. The issue with factor sequencing only exists when the default routing rule runs.
Just replying here to say thanks for posting this fix- it helped us avoid a potentially huge problem with our Chrome OS fleet. 🙏
We're running into the same issue (users stuck after entering the username on the Okta prompt on the ChromeOS device login screen), but we didn't get it working after adding that "routing rule" for "other" platforms. Do we have to add a (dummy) "identity provider" in the Identity Providers page if we don't already have another identity provider configured (a little loathe to do this, since we don't actually use any other identity providers).
James was successful with it just 3 days ago, so there is something different between your environments. I am not sure if there is a new feature flag that once again breaks the ChromeOS login process, but I do know for certain that disabling factor sequencing resolves the issue.
I'll clarify to avoid any confusion;
Worked for us. But is very bad and weird need this.