Sending additional parameters in Device Authorization Flow

Help
, ,
1

Hey Auth0 community! I’m working on converting my watchOS app to an independent watch app that has the ability to login on it’s own. Since I can’t use the universal login flow, I’m attempting to implement the Device Authorization Flow: Call Your API Using the Device Authorization Flow

I have finished implementation and I’m able to get login to succeed, but I am not able to see any of the additional parameters the client is including in the Device Code Request POST inside my rules.

I’m using AFNetworking to make the POST and passing in two additional params: “aivastate” & “connections”:

let parameters = [
      "client_id": "MY_CLIENT_ID",
      "scope": "openid profile picture offline_access user_metadata app_metadata",
      "audience": "MY_AUDIENCE",
      "aivastate": "EXTRA_INFO_1",
      "connections": "EXTRA_INFO_2"
    ]

    AF.request(NSURL(string: "https://\(tenant.domain)/oauth/device/code")! as URL, method: .post, parameters: parameters, encoder: URLEncodedFormParameterEncoder(destination: .httpBody)).responseJSON { (response) in
      //handle response here
    }

There’s one parameter that I absolutely need to finish authorization, so this is making it impossible to finish this type of auth flow setup. Does anyone have a solution for this or know another way to implement login on the Watch that will pass through my additional parameters?

2

Hi dylanmoo

Unfortunately, the parameters from the call to /oauth/device/code are not available in rules. This is because rules only start once the authentication flow starts, and this call does not trigger the authentication flow. Rather, it is the confirmation of the verification URL which triggers the rules pipeline.

Could I ask why you need the extra parameters? Maybe there is a workaround.

3

Hi Thomas,

We have the same issue as Dylan, except we are not interested in adding any extra parameters to the call /oauth/device/code. We only want to know what scopes were requested by the application.

We use the rules to intersect requested scopes with allowed scopes (for the authenticating user) and susequently update the tokens with the granted scopes and any extra claims.

Currently we have no way of knowing what scopes were requested by the application during the device code flow so we cannot issue tokens with the desired scopes and claims unless we grant all or hard code a limited set.

4

Hello @s.skillman

Unfortunately, as I understand it this is not possible.

I will pass your feedback along to the product team.

I have also asked internally about how to deal with this, but I’m not confident anyone will provide me with a solution.