I’m trying to test the Device Authorization Flow for a NodeJS CLI app using the Auth0 example app.
I’ve configured a device application in my Auth0 tenant, I’ve launched the CLI sample, and I’ve entered its client ID, my tenant’s domain, the audience for one of my APIs, and selected a scope like offline_access or openid from the list. It pops open my browser, I log in through Okta SSO, and then I’m redirected to an error page (“Looks like something went wrong!” with a tracking ID like 23d0e2efeea19326e8d0). I expected to enter a scope from the API that belongs to the audience I provided, but even if I modify the script to use one of the scopes defined on my API, I get the same result. The CLI script eventually times out trying to poll for the tokens that should’ve been created by the browser flow.
Is there a trick to this? Is the Device Auth Flow sample app out of date? Does it work for other people?
Hi @geometric . It feels as if something might be misconfigured at the login page level, or maybe a domain mismatch between the start of the flow and where your Okta connection is sending the results.
For further details, send me a .HAR file (Generate and Analyze HAR Files) via DM capturing the full browser interaction and I’ll take a look.
Hi @geometric . Thanks for sending the .HAR file. As I suspected, there’s a mismatch of domains used in the flow:
The original request (from the CLI) goes to your dev tenant’s domain (e.g. acme-dev.auth0.com)
acme-dev.auth0.com shows the login screen. The user action causes the flow to go to Okta
The user logs in to Okta. Okta sends the response to another Auth0 domain (e.g. acme.auth0.com) which is not where the flow started (acme-dev.auth0.com).
acme.auth0.com receives the unexpected response from Okta, and you get the “Looks like something went wrong!” error.
In order to fix this, configure your Okta setup to send the response back to acme-dev.auth0.com.
