oauth2-server icon indicating copy to clipboard operation
oauth2-server copied to clipboard

Device Authorization Grant

Open lucadegasperi opened this issue 5 years ago • 19 comments

Hello, Since I needed the device authorization grant for a project I'm working on, I've decided to give a shot at implementing it in a presentable way.

For the most part I copied other grants code where needed and tried to keep the methods and interfaces as similar to what's already implemented as possible.

The interval checking between requests for an access token is currently not implemented, as I think this could be more easily delegated to a framework middleware than implement the logic right inside the package.

Pairing a user identifier with the device code is left outside the scope of this implementation as well.

I've created a laravel passport implementation based off this code that you can find here: https://github.com/lucadegasperi/passport/tree/device-flow

Let's make this grant happen!

lucadegasperi avatar Nov 28 '19 09:11 lucadegasperi

Thanks for the fixes @Sephster, do you think it's good enough to merge now?

lucadegasperi avatar Jan 05 '20 18:01 lucadegasperi

Hi @lucadegasperi - sorry I still have a wee bit more to look at. Specifically around handling of pass checking and response rates. I think this probably does need including so have started to add these in. Thanks for your patience with this.

Sephster avatar Jan 07 '20 17:01 Sephster

@Sephster Ignore my previous comments the middleware implementation don't make sense please check this as a possible candidate for handling polling rate https://github.com/yovchev/oauth2-server/commits/device-flow-grant

yovchev avatar Feb 07 '20 01:02 yovchev

@lucadegasperi and @yovchev sorry for the radio silence on this ticket. I have some time coming up this week so will aim to push this through asap. Cheers for your patience.

Sephster avatar Feb 24 '20 19:02 Sephster

No worries @Sephster I will be at hand if I can help with something.

yovchev avatar Feb 26 '20 10:02 yovchev

@yovchev thanks for your time on this. I had a look yesterday and couldn't get the examples to work. I think this is because my system wasn't creating a cache folder as it didn't have permission to do so.

I'm thinking that it might be simpler to just do away with the cache system and instead rewrite the example with a ready made SQLite DB which would probably be easier to maintain. If we went down this route, I'd be ok with just pushing through the device code grant changes and sorting out the examples in a separate PR.

I will have a look at the changes without the examples to see if we can progress them. Thanks for your patience

Sephster avatar Mar 31 '20 10:03 Sephster

@Sephster I appreciate it's a chaotic time for everyone at the moment. Is there anything that I can do to help get this merged?

AlastairDewar avatar Jun 30 '20 15:06 AlastairDewar

Hi Ally. Thanks for offering to help. There isn't much that can be done at this time to be honest and I just need to find a significant block of time to finish this off as conscious it has been sitting here a good while now. The main issue is I don't want to merge prior to making sure it covers the spec properly.

To do this I also want to rewrite the examples for Slim 4 so I can easily do some manual testing rather than just read code and tick off all of the points which is time consuming.

I'm hesitant to commit to a date as I have a baby in the house just now so my time isn't as available as it was a few months ago but hoping to get some time to work on this soon. I just can't commit to a firm date at present as don't want to disappoint. Thanks for your offer of help though and I will try my best to get this out the door sooner rather than later.

Sephster avatar Jun 30 '20 22:06 Sephster

Hi, @Sephster congrats on the baby.

Let me know if this is the speck you want to make sure is covered rfc8628 and I will do one run of tests on the latest pull request and reply here any findings.

yovchev avatar Aug 11 '20 10:08 yovchev

Hi!

I've got a question about the given example. The example uses client_secret for obtaining a device_code and obtaining an access_token. However, the standard states that a device should always be treated as a public client, see RFC8628 Section 5.6 and RFC6749 Section 2.1.

Is the client_secret optional?

Let's hope this feature gets implemented soon! 🙌

Bloemendaal avatar Feb 12 '21 13:02 Bloemendaal

@lucadegasperi Thank you, very useful! Can I use it in production or are there important things missing?

GreyXor avatar Sep 07 '21 15:09 GreyXor

@GreyXor I do use it in production, but I'm not sure if the spec has changed in the meanwhile. Probably @Sephster has a better understanding of the state of things.

lucadegasperi avatar Sep 07 '21 17:09 lucadegasperi

@lucadegasperi @Sephster thanks :) do you know if it can be merged soon ?

GreyXor avatar Dec 28 '21 13:12 GreyXor

Hi all,

Nice work!

@Sephster when can we expect this can be merged?

ivanleskovar avatar Sep 01 '22 17:09 ivanleskovar

Aiming for next major.

Sephster avatar Sep 01 '22 18:09 Sephster

@Sephster thx. Any estimate when we can expect it?

ivanleskovar avatar Sep 13 '22 06:09 ivanleskovar

@Sephster do you have estimate date for next major?

modricl avatar Nov 03 '23 12:11 modricl

Hopefully in the next few weeks. Testing underway now. If you're interested in this grant, I would welcome you giving it a spin

Sephster avatar Nov 03 '23 12:11 Sephster

@Sephster @lucadegasperi ,

Just finished taking a look and implementing this locally. Beyond the above few comments I was able to get @lucadegasperi passport implementation updated (https://github.com/RunbookSolutions/passport/tree/device-code) and got everything working using a python as the "device".

Great Work Guys!

sniper7kills avatar Nov 19 '23 00:11 sniper7kills