Authorize device without using /oauth2/device redirect



  • Hi All...

    We are currently looking to implement device authentication using Fusion Auth Oauth2 endpoints. We are able to send a GET request to /oauth2/authorize with all the required information and are able to get back a 302 redirect with the location populated with the expected fields ( code, locale, state and userState ). At this point we would expect the device to be authorised but when polling /oauth2/token we do not get a success.

    We understand the redirect is to take the user to a success page in a happy day scenario, and don't understand why the device is not approved? Is there a missing step?

    Regards



  • Once you get a code, you need to exchange that for a token.

    From https://fusionauth.io/docs/v1/tech/oauth/#example-device-authorization-grant

    The Device Authorization Grant will be considered approved when the Authorization Grant code has been exchanged for a token.

    I see you mention polling, but has the user provided the code and authenticated as mentioned here: https://fusionauth.io/docs/v1/tech/oauth/#pass-user_code-to-fusionauth ?



  • @dan said in Authorize device without using /oauth2/device redirect:

    https://fusionauth.io/docs/v1/tech/oauth/#pass-user_code-to-fusionauth

    Thanks for the reply. We are currently trying to authorise a device, but would like to use the endpoints provided by Fusion to accomplish this.

    We first call /oauth2/device_authorize, this in turn returns a user_code to the device and a device_code.

    We then use the user_code supplied by the user and call /oauth2/device/validate? if we get a HTTP 200 we continue.

    Next we call /oauth2/authorize, here we supply the user_code, and a username and password for the user wanting to authorise the device. In return we get back a 302 which directs use to the redirect uri.

    At this stage the device is polling /oauth2/token with the device_code and urn:ietf:params:oauth:grant-type:device_code grant type.

    We would have hoped that at this stage the device would have gotten returned credentials but this does not seem to be the case. Unsure of what call would authorise the device?



  • Thanks for breaking it down step by step for me. It sure looks like you're performing the appropriate flow.

    What status code are you getting when you poll /oauth2/token? Are you seeing an error message?



  • We have the demo app for testing the device portion of the flow setup and it polls, it constantly gets HTTP 400 (authorization_pending). Which is expected until we call /oauth2/authorize, but after getting back the 302, we don't see this message change.

    When we test the out the box solution from Fusion auth this flow does work however. It seems the out the box solution does 2 redirects and we unsure if any of those steps adds to the authorize process.

    Screenshot 2020-05-21 at 09.56.02.png

    I should mention we on version 1.14.0



  • Ah. I think it might be helpful to examine the 400 response.

    According to the docs: https://fusionauth.io/docs/v1/tech/oauth/endpoints#response-4

    The request was invalid and/or malformed. The response will contain a JSON message with the specific errors. The error response JSON is covered in the OAuth Error section of the API documentation.

    Can you share the error message from the response?

    As for being on 1.14, that should be OK, though it's always a good idea to stay close to the latest stable release. FYI 1.16.x doesn't require running ElasticSearch, so may be worth upgrading for operational simplicity. See here for more: https://fusionauth.io/community/forum/topic/67/what-is-the-advantage-of-using-elasticsearch-as-the-search-engine



  • Looks like someone else worked through the device grant example and ran into a CORS issue. Not sure if this is applicable, but just wanted to mention it:

    https://github.com/FusionAuth/fusionauth-example-device-grant/pull/2



  • @dan said in Authorize device without using /oauth2/device redirect:

    https://github.com/FusionAuth/fusionauth-example-device-grant/pull/2

    We have kept at it but still cant get the call to /oauth2/authorize to grant access to the device. When polling we get the response 400 with authorization_pending as per the documentation.

    Nothing manages to change the state and have /auth2/token return the access_token.

    We are very keen to use Fusion Auth for our production use case, but this one issue is causing headaches we didnt expect. All other requirements are being met with current fusion auth tooling.

    We are not running Fusion auth on local but testing in a hosted environment to ensure everything works has expected.



  • I understand your frustration.

    You may have seen this, but I thought I'd share it anyway: https://fusionauth.io/learn/expert-advice/oauth/oauth-device-authorization

    One thing I noticed when looking back over the topic is that you don't mention calling into /oauth/device with activationComplete set to true. (Step 13 in the diagram in the link above.) Perhaps that is the issue? If so, let me know and I can correct the documentation.



  • @megeshg If you do intend to run this in production, I would recommend a paid edition. We can offer you direct engineering support to ensure your use case works flawlessly.

    If you do figure it out - let us know, or perhaps as we review the thread something will jump out that we can share with you.



  • We have decided to use this with the redirects enabled in java, which then returns the success HTML, we then use this HTML to validate its successful.

    @dan we are not call /oauth/device would we need to? when in the flow would we need to do this? Dont see this in the documentation? https://fusionauth.io/docs/v1/tech/oauth/endpoints

    @robotdan If something has come up please let me know.



  • @megeshg said in Authorize device without using /oauth2/device redirect:

    we are not call /oauth/device would we need to? when in the flow would we need to do this? Dont see this in the documentation?

    Hmmm. I think I must have been mistaken when I suggested that. I can't track down where I came up with that. My apologies.

    I'm glad you found a solution.


Log in to reply
 

Looks like your connection to FusionAuth Forum was lost, please wait while we try to reconnect.