开发者进行应用注册时，一般需要提交应用类型。应用类型常见的几大类：
对于web application，开发者还需要提交redirect URI，即web application接收grant code的地址，authorization server在认证完成后重定向到此地址。
授权码流程授权码流程是oauth2.0最常见的交互流程，甚至很多开放平台仅支持这一种流程。授权码流程示意见下图：
该流程主要适用于web应用，基于浏览器的重定向能力实现整个交互过程。
错误返回当resource-owner拒绝client的访问请求，或者授权请求错误，authorization server将错误信息通过redirect_uri返回给client应用，除非redirect_uri本身就不正确。
参数
说明，所有参数需经过“application/x-www-form-urlencoded”编码。
隐式授权（Implicit Grant）如上面介绍，隐式授权适用于代码运行在客户端上的应用，例如网页应用，利用浏览器的重定向能力得到resource-owner的授权。不同于授权码流程，隐式授权流程的授权请求可以直接得到access token，没有authorization code的中间过程。隐式授权过程发生在resource owner的设备上，必须有resource owner在场，且client代码不能包含client的凭证（client_secret），另外access_token返回给client时，存在暴露到同一个设备（user-agent）上其他应用的风险。
身份信息透传授权（Resource Owner Password Credentials Grant）
如果resource owner非常信任这个应用，可以将身份凭证（口令，密钥等）通过应用传递到authorization server。一般不推荐这种方式，应用可以截留用户的身份凭证明文，风险较高，RFC协议也仅建议用于存量的应用迁移到OAuth协议。个人认为，如果client本身就是authorization server，其身份验证过程这样做也是可行的，相当于authorization server的内部实现。
应用拿着client_id和client_secret直接从authorization server获取access token，这种流程仅用于访问应用本身的与resource owner无关的数据，不需要resource owner授权的场景，可以使用这种授权，一般都是机机接口调用。
扩展应用
不同厂商的开放平台可以扩展授权流程，以满足不能场景的需求，例如手机、平板等端侧设备应用，或者电视、游戏手柄等娱乐设备应用。
移动端和PC桌面的应用授权对于运行在手机、平台和PC上的应用程序，也可以通过OAuth协议得到用户的授权来安全的访问用户的数据。这种场景的授权流程和web server应用非常类似，也是authorization grant模式，主要区别是此类应用需要提供本地web server或者支持应用间跳转，并提供系统内置的“browser”（例如android的intent）实现与authorization server之间的交互。
这种授权方式的交互过程和接口和上文介绍得authorization grant模式一样，唯独授权请求的redirect_uri参数有差异：