Oauthlib: Device Code Grant Type

The Spec is still in draft https://tools.ietf.org/html/draft-ietf-oauth-device-flow-13, but it will be great if anyone start to implement it in oauthlib. PRs are welcomed

@JonathanHuot is there a good documentation on where contributors can begin to add this feature ?

You can ask on our Gitter channel.

As thedrow mention it, we're very reactive in Gitter. You can also have a look on the other grants and see how they are currently implemented. Also note that we are differenting the _client_ code from the _server_ code, but we have sometime common code to both client and server.
If you are looking into the client part, ideally, you should also propose a PR to requests-oauthlib which is the main "client" downstream of oauthlib.

You can also have a look on our Contributing page https://oauthlib.readthedocs.io/en/latest/contributing.html for more generic stuff.

I'm more interested in the server side as I need to implement this for a project I'm working on. Atm I've done it using my custom code but I very much want to do it the correct way.

Will jump on gitter to discuss :)

I cant help but feel like leaving the client side out is a bad idea.

I can build the client side but the device code server itself is still alot a work

I'm just thinking of the architecture needed for this in the context of the VERY needed JWT support.

@duaneking do we have an open issue for that change maybe we can discuss it ? I can pause this work until that change has happened.

@duaneking, full JWT support may have architecture changes but it should not prevent @jcampbell05 of completing his work. The Device Flow has nothing to do with JWT and should not be conflicting with the JWT new architecture.
_EDIT:_ If JWT new architecture implies a lot of refactoring, I'll prefer completing this DeviceFlow and doing the JWT refactoring once DeviceFlow done. Only because no one has started this refactoring discussion and it is far from being completed than the DeviceFlow.

About client's side, if it's implemented during the first PR, that's would be great I confess. Also, it helps to test the Device Flow implementation itself.

@JonathanHuot so I've been thinking about the client I'm basically writing my own client to test it anyways, so I guess it won't hurt to implement in this library either.

My biggest push back was on having features be half done; If you are adding a client then that resolves this. Thank You.

I don't have bandwidth to finish this right now - so hopefully someone can pick this up or perhaps I can resume later on

No more in draft https://tools.ietf.org/html/rfc8628