Device Authorization Flow fails with error: Unsupported response type: device_code

Help
1

I have an Native App setup in my tenant with grant_type device_code and refresh_token. I am able to initiate a device auth process by making a call to /device/code and get back a user_code, device_code and verification_url.

My Native App is setup for user authentication through google-oauth2 and I use auth0 development keys since this is not production system.

When I visit verification_url (or even verification_url_complete) from the browser, I am presented with login challenge. There I pick Login with Google, but instead of verifying the request, I get an error; details from Logs below.

According to Auth0 documentation response_type can only be token or code, so I can see why I get the error, but there doesn’t appear to be any way to address the issue by changing my inputs since none of the requests accept response_type as a parameter.

{
  "date": "2020-08-19T16:23:30.070Z",
  "type": "f",
  "description": "Unsupported response type: device_code",
  "connection_id": "",
  "client_id": "o7upQDctKIyFJJaT41Lz3dO1mTB2D70K",
  "client_name": "NativeDeviceAuthApplication",
  "ip": "<redacted>",
  "user_agent": "Chrome 84.0.4147 / Windows 10.0.0",
  "details": {
    "body": {},
    "qs": {
      "client_id": "o7upQDctKIyFJJaT41Lz3dO1mTB2D70K",
      "response_type": "device_code",
      "redirect_uri": "https://awishcar.us.auth0.com/login",
      "scope": "openid profile email",
      "state": "g6Fo2SBfNzVraHpDZDBVcUREZU9SY3Z3N3BmczNCSXI5ajJlQqN0aWTZIHlDZ1JiT0YxeWVEMzBYVkJNX3ZoWHZCSTZPcVlpbEhjo2NpZNkgbzd1cFFEY3RLSXlGSkphVDQxTHozZE8xbVRCMkQ3MEs",
      "connection": "google-oauth2",
      "is_submitting": "false",
      "sso": "true",
      "protocol": "oauth2",
      "_csrf": "kI5JF2ni-XlCXJLK-ZZmHvnQEl40Pw0Ufdss",
      "auth0Client": "eyJuYW1lIjoibG9jay5qcy11bHAiLCJ2ZXJzaW9uIjoiMTEuMjQuNSIsImVudiI6eyJhdXRoMC5qcy11bHAiOiI5LjEzLjQiLCJhdXRoMC5qcyI6IjkuMTMuNCJ9fQ=="
    },
    "error": {
      "message": "Unsupported response type: device_code",
      "oauthError": "unsupported_response_type",
      "type": "oauth-authorization"
    },
    "session_id": "d8B9V5fE3QjLuKOrHTe8vSKybDwDK4Xw"
  },
  "hostname": "login.us.auth0.com",
  "auth0_client": {
    "name": "lock.js-ulp",
    "version": "11.24.5",
    "env": {
      "auth0.js-ulp": "9.13.4",
      "auth0.js": "9.13.4"
    }
  },
  "log_id": "90020200819162335409000115475283046620652244541420601346",
  "_id": "90020200819162335409000115475283046620652244541420601346",
  "isMobile": false
}

Here is the context data:

{
  "body": {},
  "qs": {
    "client_id": "o7upQDctKIyFJJaT41Lz3dO1mTB2D70K",
    "response_type": "device_code",
    "redirect_uri": "https://awishcar.us.auth0.com/login",
    "scope": "openid profile email",
    "state": "g6Fo2SBfNzVraHpDZDBVcUREZU9SY3Z3N3BmczNCSXI5ajJlQqN0aWTZIHlDZ1JiT0YxeWVEMzBYVkJNX3ZoWHZCSTZPcVlpbEhjo2NpZNkgbzd1cFFEY3RLSXlGSkphVDQxTHozZE8xbVRCMkQ3MEs",
    "connection": "google-oauth2",
    "is_submitting": "false",
    "sso": "true",
    "protocol": "oauth2",
    "_csrf": "kI5JF2ni-XlCXJLK-ZZmHvnQEl40Pw0Ufdss",
    "auth0Client": "eyJuYW1lIjoibG9jay5qcy11bHAiLCJ2ZXJzaW9uIjoiMTEuMjQuNSIsImVudiI6eyJhdXRoMC5qcy11bHAiOiI5LjEzLjQiLCJhdXRoMC5qcyI6IjkuMTMuNCJ9fQ=="
  },
  "error": {
    "message": "Unsupported response type: device_code",
    "oauthError": "unsupported_response_type",
    "type": "oauth-authorization"
  },
  "session_id": "d8B9V5fE3QjLuKOrHTe8vSKybDwDK4Xw"
}
2

Although there’s nothing specific to device authorization flow in the known limitations of social connection developer keys (Test Social Connections with Auth0 Developer Keys) as a personal opinion I would strongly recommend either:

  • update social connection with your own keys.
  • use a database connection for your tests.

I admit that I have no past experience that would suggest that the underlying issue here is indeed dev keys, but it is just not worth the effort and if it’s for testing having a test user in a database connection should not be that much of an overhead. Let us know if you can quickly try any of the above and if the issue persists we can try other things.