OAuth2.0說(shuō)明
OAuth的思路
OAuth在"客戶端"與"服務(wù)提供商"之間畴椰，設(shè)置了一個(gè)授權(quán)層（authorization layer）祖屏。"客戶端"不能直接登錄"服務(wù)提供商"掸绞，只能登錄授權(quán)層统扳，以此將用戶與客戶端區(qū)分開(kāi)來(lái)酝碳。"客戶端"登錄授權(quán)層所用的令牌（token），與用戶的密碼不同户辱。用戶可以在登錄的時(shí)候鸵钝，指定授權(quán)層令牌的權(quán)限范圍和有效期糙臼。
"客戶端"登錄授權(quán)層以后，"服務(wù)提供商"根據(jù)令牌的權(quán)限范圍和有效期蒋伦，向"客戶端"開(kāi)放用戶儲(chǔ)存的資料号胚。
授權(quán)方式
客戶端必須得到用戶的授權(quán)（authorization grant）触幼，才能獲得令牌（access token）。OAuth 2.0定義了四種授權(quán)方式徘公。
- 授權(quán)碼模式（authorization code）
- 簡(jiǎn)化模式（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最佳的方式是調(diào)用系統(tǒng)瀏覽器發(fā)送Authorization Request給授權(quán)服務(wù)器研叫，然后通過(guò)redirect URI調(diào)起Native APP來(lái)接受Authorization Response。根據(jù)具體平臺(tái)實(shí)現(xiàn)方式的不同璧针，授權(quán)服務(wù)器需要支持至少以下三種不同的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自定義并注冊(cè)在OS中嚷炉，如com.example.app:/oauth2redirect/example-provider，瀏覽器打開(kāi)此URI會(huì)調(diào)起APP來(lái)處理此URIClaimed "https" Scheme URI Redirection. 部分OS支持探橱，瀏覽器遇見(jiàn)這類地址會(huì)打開(kāi)Native APP申屹，樣例：https://app.example.com/oauth2redirect/example-provider
Loopback Interface Redirection. 主要是桌面OS支持，樣例：http://127.0.0.1:51004/oauth2redirect/example-provider
關(guān)于Android應(yīng)用跳轉(zhuǎn)
Google的官方文檔"Android Intents with Chrome"一文隧膏，介紹了在Android Chrome瀏覽器中網(wǎng)頁(yè)打開(kāi)APP的兩種方法哗讥，一種是用戶自定義的URI scheme（Custom URI scheme），另一種是“intent:”語(yǔ)法（Intent-based URI）胞枕。
第一種用戶自定義的URI scheme形式如下：
第二種的Intent-based URI的語(yǔ)法形式如下：
因?yàn)榈诙N形式大體是第一種形式的特例杆煞，所以很多文章又將第二種形式叫Intent Scheme URL，但是在Google的官方文檔并沒(méi)有這樣的說(shuō)法腐泻。
參考資料
- 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.
