Device Flow is not intended to replace browser-based OAuth in Native applications on capable devices (like smartphones). Those apps should follow the practices specified in OAuth 2.0 for Native Apps RFC 8252.
The only requirements to use Device Flow are that the device is connected to the Internet, and able to make outbound HTTPS requests, be able to display or otherwise communicate a URI and code sequence to the user, and that the user has a secondary device (e.g., personal computer or smartphone) from which to process the request. There is no requirement for two-way communication between the OAuth Client and the user-agent, enabling a broad range of Use cases.
Instead of interacting with the end-user's user-agent, the client instructs the end-user to use another computer or device and connect to the authorization server to approve the access request. Since the client cannot receive incoming requests, it polls the authorization server repeatedly until the end-user completes the approval process.
Device Flow instructs the user to perform the Authorization Request on a secondary device, such as a smartphone.
Device Flow is known to be implemented by:
- Google (https://developers.google.com/identity/protocols/OAuth2ForDevices)
- Facebook (https://developers.facebook.com/docs/facebook-login/for-devices)
- ForgeRock within OpenAM
- Curity Identity Server
- Salesforce ( https://releasenotes.docs.salesforce.com/en-us/spring17/release-notes/rn_security_auth_device_flow.htm)
More Information#There might be more information for this subject on one of the following:
- [#1] - OAuth 2.0 Device Flow for Browserless and Input Constrained Devices - based on information obtained 2018-01-04-
- [#2] - Using OAuth Device Flow For UI-Incapable Devices - based on information obtained 2018-04-21-