深入理解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凭证的服务器。举例来讲，一般就是智能门锁厂商的服务器。当然，资源服务器和授权服务器不必须是同一个个人或者公司所有。门锁的公司可能支持你使用亚马逊或者微信的账号来登陆，那么授权服务器就变成了亚马逊或者微信的服务器。

在拥有了一些背景知识后，下面来了解一下具体的工作流程，从用户的角度，看到的是这样的流程：

Alexa app中用户点击Enable来开始账户关联过程。
app显示让用户登录第三方系统（门锁公司）的界面。
用户输入用户名密码登录成。
用户被重定向回Alexa app的界面。

当用户关联成功后，Alexa就获得并存储代表了用户的access token。Alexa给skill的每个请求中，都会携带这个token方便你skill来使用访问第三方系统。由此产生几个疑问：Alexa是如何获得到token，并关联到这个Alexa账户的？Alexa会调用安卓的浏览器，浏览器和Alexa是怎么通信的？其实亚马逊官方文档很好的解答的这些疑问，如下图所示。

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的时候传回去，让亚马逊服务器知道是这个会话。
用户认证过后，authorization server 生成authorization code（code），页面重定向用户到Alexa特定的redirect_uri，这是亚马逊的URI，并且在重定向时发送code和state参数。
接下来Alexa就可以用code来请求access token了，请求的URI是skill里设置的authorization server的Access Token URI。
Alexa保存好access token和refresh token。至此，Alexa账户就和第三方的账号（使用token）关联了。
当用户给skill发请求时，如IntentRequest，就会把这个access_token发给skill，skill的代码就可以随意使用用户的token凭证了。

授予第三方云Alexa的权限

用户在Alexa中添加了设备后，肯定希望设备的状态可以自动的异步发送到Alexa App中，用户随时查看都是最新的状态。而这个Alexa App又是亚马逊所有的，于是需要授予第三方更新Alexa app中这个设备的权限，基本原理也是将亚马逊账号的权限用OAuth协议分享给第三方云。

当用户enable启用skill并完成账户关联后，Alexa会向skill发送AcceptGrant指令，携带该Alexa用户的code和上一步从第三方云拿来的access_token，这个code就代表了Alexa用户的权限；
第三方云此时需要用code换Alexa的access_token（Oauth的流程，除了code还要发送代表该skill的client_id和client_secret，亚马逊认证是哪个skill发出的推送），同时进行该用户Alexa账号和第三方云账号的关联。
当关联好后，每当第三方厂商云检测到该用户的设备状态发生变化，比如锁被用指纹打开了，就使用该用户对应的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有没有做这个检查。）