2016-09-28 22 views
1

我想记录每个设备/ userId的一些持久性细节/历史记录。我不想在另一个系统中使用单独的帐户,因此我想避免使用帐户关联。文档表明这很好,请参阅下文。使用亚马逊Alexa请求中提供的userId安全地进行身份验证?

它是安全的假设,其中包括用户id的任何请求必须是从原来的设备?

  • 能的用户ID猜测?
  • userId可以暴露吗? (假设没有重大的AWS入侵)
  • 可以请求拦截? (我使用AWS lambda来处理请求)

相关文档:https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/docs/linking-an-alexa-user-with-a-user-in-your-system

请注意,帐户当技能需要与需要身份验证的系统连接需要链接。如果您的自定义技能只需跟踪用户在会话之间保存属性,则不需要使用帐户链接。相反,您可以使用每个请求中提供的userId来标识用户。当用户在Alexa应用中启用您的技能时,会生成给定用户的userId。除非用户禁用该技能,否则该用户对您的技能的每个后续请求都包含相同的userId。

回答

0

我不认为有任何方式来id设备的(你写“device/userId”)所以是的,你会使用userId,它是非常标准的使用Alexa userId作为密钥存储/查找用户的详细信息/历史记录。正如你已经得出结论,它听起来不像你需要帐户链接。

我假设用户id是随机生成的值,该值不能被猜到,并且请求被加密,从而不应该有一个问题存在。我相信我读过,如果用户删除你的技能,然后再次添加它,那么userId是不一样的(所以你没有办法知道它实际上是同一个用户,而不使用帐户链接)。我提到的一点是,它让我假设用户没有一个用于他们所有技能的userId(我认为这将被视为'暴露'userId),而是为每个技能生成一个新的userId。所以你应该安全。

+0

这是非常危险的假设标识,不是为了安全,是随机生成的。对于许多通用键具有与其嵌入的配置文件信息并且通常是顺序生成的。他们可能会被混淆,但这并不意味着安全。如果内部生成逻辑暴露​​出来,这些ID可能会变得非常弱。 –

+0

@JimRush是的,的确如此,但他建议使用它们的方式(以及我使用它们的方式)与亚马逊提供的示例一致。 – Tom

+0

由于没有关于此事的文件,这个问题可能需要发布在亚马逊的论坛上,以获得一些有信誉的来源的答案。这都是猜测。 –

相关问题