OAuth2.0说明
OAuth的思路
OAuth在"客户端"与"服务提供商"之间，设置了一个授权层（authorization layer）。"客户端"不能直接登录"服务提供商"，只能登录授权层，以此将用户与客户端区分开来。"客户端"登录授权层所用的令牌（token），与用户的密码不同。用户可以在登录的时候，指定授权层令牌的权限范围和有效期。
"客户端"登录授权层以后，"服务提供商"根据令牌的权限范围和有效期，向"客户端"开放用户储存的资料。
授权方式
客户端必须得到用户的授权（authorization grant），才能获得令牌（access token）。OAuth 2.0定义了四种授权方式。
- 授权码模式（authorization code）
- 简化模式（implicit）
- 密码模式（resource owner password credentials）
- 客户端模式（client credentials）
参考资料
- 理解OAuth 2.0， http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html
- OAuth 2 Simplified, https://aaronparecki.com/oauth-2-simplified/
Native APP使用OAuth的方式
Native APP使用OAuth2.0最佳的方式是调用系统浏览器发送Authorization Request给授权服务器，然后通过redirect URI调起Native APP来接受Authorization Response。根据具体平台实现方式的不同，授权服务器需要支持至少以下三种不同的redirect URI
Private-Use URI Scheme Redirection.
a. When choosing a URI scheme to associate with the app, apps MUST use a URI scheme based on a domain name under their control, expressed in reverse order
b. redirect URI为APP自定义并注册在OS中，如com.example.app:/oauth2redirect/example-provider，浏览器打开此URI会调起APP来处理此URIClaimed "https" Scheme URI Redirection. 部分OS支持，浏览器遇见这类地址会打开Native APP，样例：https://app.example.com/oauth2redirect/example-provider
Loopback Interface Redirection. 主要是桌面OS支持，样例：http://127.0.0.1:51004/oauth2redirect/example-provider
关于Android应用跳转
Google的官方文档"Android Intents with Chrome"一文，介绍了在Android Chrome浏览器中网页打开APP的两种方法，一种是用户自定义的URI scheme（Custom URI scheme），另一种是“intent:”语法（Intent-based URI）。
第一种用户自定义的URI scheme形式如下：
第二种的Intent-based URI的语法形式如下：
因为第二种形式大体是第一种形式的特例，所以很多文章又将第二种形式叫Intent Scheme URL，但是在Google的官方文档并没有这样的说法。
参考资料
- Recommendations for using OAuth 2.0 with native apps, https://oauth.net/2/native-apps/
- OAuth 2.0 for Native Apps, https://tools.ietf.org/html/rfc8252
PS, native apps MUST NOT use embedded user-agents to perform authorization requests. - PKCE (Proof Key for Code Exchange) https://oauth.net/2/pkce/
PKCE (RFC 7636) is a technique to secure public clients that don't use a client secret.
