深刻理解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有没有作这个检查。）