介绍
The OAuth 2.0 device authorization grant is designed for Internet- connected devices that either lack a browser to perform a user-agent- based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device.
以上是草案中的原文，我简单的说下意思就是在输入受限的设备上，比如打印机、电视机、终端设备等，可以通过设备码登录的方式实现用户的快速授权登录。
以电视机为例，电视机登录界面通过展示二维码的方式，提示用户通过手机APP或者微信扫码登录。用户通过扫码打开授权界面，点击确认即可完成授权登录的流程，在此过程中，电视机端会一直后台轮询查询用户的登录和授权确认情况，一旦确认完成即可获取用户的access_token。
使用场景
这里特别指出一下使用场景，上面提到了电视APP、终端应用、外卖柜、闸口、机载设备、按摩椅子等等都可以应用到此流程，但是反过来很多浏览器网站比如bilibili，腾讯视频等网站提供的扫码登录的实现方式并不是设备授权登录模式。这个我们以后再说，等我再研究下，对比下几家的方案。
流程
设备授权流程如图1所示，包括以下步骤：
(A) 客户端向授权服务器请求访问权限，并在请求中包含其客户端标识符。 
(B) 授权服务器发放一个设备代码和一个用户代码，并提供用户验证URI。客户端获取user_code和device_code，设备终端可以利用 verification_uri_complete 生成二维码，用户可以利用手机扫描，浏览器自动触发登录和验证user_code的流程。
(C) 客户端指导最终用户使用另一台设备的用户代理访问提供的用户体验URI。客户端为用户提供了用户代码，以便输入并审查授权请求。
(D) 授权服务器通过用户代理对最终用户进行身份验证，并提示用户输入设备客户端提供的用户提供代码。授权服务器验证用户提供的用户代码，并向用户提示接受或拒绝请求。
(E) 在最终用户审查客户端的请求（步骤D）的同时，客户端反复轮询授权服务器，以确定用户是否完成了用户授权步骤。客户端包括设备代码和其客户端标识符。在用户登录和确认授权的过程中，客户端通过定时或者long poll的方式调用/oauth2/token接口检查device_code匹配的flow流程状态。如果用户成功的完成了登录和授权流程那么客户端就可以通过这个接口拿到access_token，并完成后续的操作流程。如果用户还没有完成必要流程，那么接口就会返回对应的错误。
(F) 授权服务器验证客户端提供的设备代码，并在客户端获得访问权限时响应访问令牌，如果被拒绝访问则返回错误，或者指示客户端应继续轮询。
/oauth2/token错误代码清单
authorization_pending： 等待用户确认
slow_down：过于频繁的请求，请降速
access_denied：403，禁止访问
expired_token： 案例
这里我们以Spring-Authorization-Server为例，这个项目基本很好的支持了原生的OAuth2.1，关键他就是java实现了，如果你不在乎语言，那么可以试试CasDoor，那个是go语言实现的，也是个很不错的项目。
总结
关于OAuth2协议的学习，我想是时候多花点精力在RFC草案上了，可能会有更多收获，另外任何流程都有对应的使用场景大家千万不要搞错啦。