深刻理解Amazon Alexa Skill（三）

本節來討論Alexa Skill中涉及到的受權問題。

Alexa內功能的受權

Alexa會發給skill用戶的token，而後skill代碼使用這個token來訪問Web API訪問用戶的Alexa內的功能，如list等。

授予skill第三方的權限——Account Linking

參考：https://developer.amazon.com/docs/account-linking/understand-account-linking.html#account-linking-and-the-skill-model
授予skill用戶在其餘第三方系統中的權限，例如，讓亞馬遜echo控制你的智能門鎖，就須要授予特定的skill能訪問你門鎖的權限。可是門鎖權限原本是門鎖製造商的雲管理的，也就是說你要使用門鎖的App控制，那麼如何實現將這個權限授予skill呢？這就須要使用Oauth2.0來實現。

OAuth中定義了一些角色，可是隻看OAuth的說明會比較抽象，因此亞馬遜很是好的給出了OAuth角色在Alexa Skill中具體指什麼。這裏簡單翻譯一下Smart Home Skill的對應關係方便理解。在Smart Home Skill中，要求使用Authorization code grant模式。該模式中，authorization server在用戶登陸時返回一個code，而後Alexa使用這個code去access token endpoint請求一個access token/refresh token pair；這個refresh token能夠被用來在token過時時請求信的token。

• Resource owner：指使用這個skill綁定本身設備的Alexa用戶。該用戶在設備廠商的雲中有對應的帳號來控制此設備。
• Resource server：通常指設備廠商的雲服務器。受保護的資源就是用戶智能家居的信息和控制權。拿智能門鎖來說就是門鎖廠商的服務器。
• Client：指Skill。由於Skill使用得到的憑證去resource server訪問受權的資源，可是是Alexa請求authorization server得到access token。
• Authorization server：用來認證用戶並提供access token憑證的服務器。舉例來說，通常就是智能門鎖廠商的服務器。固然，資源服務器和受權服務器沒必要須是同一個我的或者公司全部。門鎖的公司可能支持你使用亞馬遜或者微信的帳號來登錄，那麼受權服務器就變成了亞馬遜或者微信的服務器。

在擁有了一些背景知識後，下面來了解一下具體的工做流程，從用戶的角度，看到的是這樣的流程：

1. Alexa app中用戶點擊Enable來開始帳戶關聯過程。
2. app顯示讓用戶登陸第三方系統（門鎖公司）的界面。
3. 用戶輸入用戶名密碼登陸成。
4. 用戶被重定向回Alexa app的界面。

當用戶關聯成功後，Alexa就得到並存儲表明了用戶的access token。Alexa給skill的每一個請求中，都會攜帶這個token方便你skill來使用訪問第三方系統。由此產生幾個疑問：Alexa是如何得到到token，並關聯到這個Alexa帳戶的？Alexa會調用安卓的瀏覽器，瀏覽器和Alexa是怎麼通訊的？其實亞馬遜官方文檔很好的解答的這些疑問，以下圖所示。

1. Alexa app彈出的登錄界面就是讓用戶跟Authorization server認證，這個訪問的URI也就是skill中設置的Authorization URI 。當Alexa app調用這個URI時還上報了一些參數，如state, client_id, response_type, scope, redirect_uri 。這些參數也是skill開發者能夠設置的。如client_id能夠向認證服務器說明是哪一個skill（好像這個client_id很容易被竊取？由於是從客戶端發出去的。可是，還須要設置一個client_secret,這個secret是存在Alexa雲的，Alexa在得到到code後（誰均可以聲稱本身是Alexa的這個skill來得到code），Alexa使用code+client_secret+clietn_id三者來得到token，因爲攻擊者沒法得到secret，因此攻擊者沒法得到access_token，OAuth仍是設計的挺安全的，亞馬遜彷佛也沒用錯。固然，這須要第三方廠商，如門鎖的廠商去檢查並記錄發出的code和client_id和client_secret的對應關係。參考）；scope彷佛是權限的具體說明，這個就要跟第三方的服務器配合來設置了；state是一個隨機的會話標記，須要在重定向用戶到亞馬遜URI的時候傳回去，讓亞馬遜服務器知道是這個會話。

2. 用戶認證事後，authorization server 生成authorization code（code），頁面重定向用戶到Alexa特定的redirect_uri，這是亞馬遜的URI，而且在重定向時發送code和state參數。

3. 接下來Alexa就能夠用code來請求access token了，請求的URI是skill裏設置的authorization server的Access Token URI。

4. Alexa保存好access token和refresh token。至此，Alexa帳戶就和第三方的帳號（使用token）關聯了。

5. 當用戶給skill發請求時，如IntentRequest，就會把這個access_token發給skill，skill的代碼就能夠隨意使用用戶的token憑證了。

授予第三方雲Alexa的權限

用戶在Alexa中添加了設備後，確定但願設備的狀態能夠自動的異步發送到Alexa App中，用戶隨時查看都是最新的狀態。而這個Alexa App又是亞馬遜全部的，因而須要授予第三方更新Alexa app中這個設備的權限，基本原理也是將亞馬遜帳號的權限用OAuth協議分享給第三方雲。

1. 當用戶enable啓用skill並完成帳戶關聯後，Alexa會向skill發送AcceptGrant指令，攜帶該Alexa用戶的code和上一步從第三方雲拿來的access_token，這個code就表明了Alexa用戶的權限；
2. 第三方雲此時須要用code換Alexa的access_token（Oauth的流程，除了code還要發送表明該skill的client_id和client_secret，亞馬遜認證是哪一個skill發出的推送），同時進行該用戶Alexa帳號和第三方雲帳號的關聯。
3. 當關聯好後，每當第三方廠商雲檢測到該用戶的設備狀態發生變化，好比鎖被用指紋打開了，就使用該用戶對應的Alexa上的token向亞馬遜預設好的event事件結點URL發送POST請求，該請求中須要攜帶設備狀態、Alexa雲中該設備的ID（endpointId，這樣亞馬遜才知道要更新哪一個設備狀態，設備的ID在discover的時候上報），攜帶Alexa的access_token（疑問：這個access_token的權限範圍是多少？亞馬遜對權限的管控能區分出用戶的哪一個設備對應哪一個Alexa access_token嗎？答：有能力作到，由於Alexa雲清楚的知道access_token給的哪一個skill，如步驟2所述；同時設備ID又是skill來上報的。可是須要實驗證實Alexa有沒有作這個檢查。）