17

OAuth 2 device flow has an odd history. It's found in early versions of the RFC, but was then taken out seemingly without an explanation I could find. Recently, a new draft was proposed specifically to reintroduce it independently.

The device flow is suitable for clients executing on devices that do not have an easy data-entry method and where the client is incapable of receiving incoming requests from the authorization server (incapable of acting as an HTTP server).

The other flows do not cover the scenario addressed by device flow so it has utility. Google supports it and has an example of it in action. Can anyone shed any light on why device flow was dropped from the OAuth 2 standard - are there security concerns we should know about?

1
  • 3
    Just noticed in tools.ietf.org/html/draft-ietf-oauth-device-flow Appendix A. Acknowledgements. The -00 version of this document was based on draft-recordon-oauth- v2-device edited by David Recordon and Brent Goldman. The content of that document was initially part of the OAuth 2.0 protocol specification but was later removed due to the lack of sufficient deployment expertise at that time. We would therefore also like to thank the OAuth working group for their work on the initial content of this specification through 2010.
    – HTKLee
    Nov 23, 2016 at 9:25

1 Answer 1

3

I should just answer my own question after stumbling upon the reason - device flow was removed from the OAuth 2 specification:

due to lack of sufficient deployment expertise at that time

Citation from Appendix A: Acknowledgements - IETF OAuth device flow draft #01.

Device flow enables a device (smart TVs, media consoles, digital picture frames, printers) to obtain user authorization by using a separate device because it is easier to enter credentials with a keyboard than say a remote control.

Draft now published as RFC 8628.

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .