oauth2-server
oauth2-server copied to clipboard
Device Authorization Grant
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!
Thanks for the fixes @Sephster, do you think it's good enough to merge now?
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 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
@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.
No worries @Sephster I will be at hand if I can help with something.
@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 I appreciate it's a chaotic time for everyone at the moment. Is there anything that I can do to help get this merged?
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.
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.
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! 🙌
@lucadegasperi Thank you, very useful! Can I use it in production or are there important things missing?
@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 @Sephster thanks :) do you know if it can be merged soon ?
Hi all,
Nice work!
@Sephster when can we expect this can be merged?
Aiming for next major.
@Sephster thx. Any estimate when we can expect it?
@Sephster do you have estimate date for next major?
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 @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!