链接访问委托模式

假设一家销售瓶装水的中型企业具有RESTful API（Water API），可用于更新注册用户的用水量。 任何注册用户都可以通过任何客户端应用程序访问API。 它可能是一个Android应用程序，一个iOS应用程序，甚至是一个Web应用程序。 该公司仅提供API，任何人都可以开发客户端应用程序来使用它。 所有用户数据都存储在Microsoft Active Directory中。 客户端应用程序不应直接访问API并进行查询以查找有关用户的信息。 只有注册用户可以访问API。 这些用户不应看到其他用户的信息。 同时，对于用户进行的每次更新，Water API必须更新MyHealth.org上维护的用户医疗记录。 用户还在MyHealth.org上拥有个人记录，并且它也公开了一个API（MyHealth API）。 Water API必须调用MyHealth API来代表用户更新用户记录。 总之，移动应用程序代表最终用户访问Water API，然后Water API必须代表最终用户访问MyHealth API。

Water API和MyHealth API在两个独立的域中。 这表明需要访问授权协议。 同样，这里的要点是声明：“ Water API还必须更新MyHealth.org上维护的用户的医疗记录。”

挑战有两个解决方案。

在第一个解决方案中，最终用户必须从MyHealth.org获得Water API的访问令牌（Water API充当OAuth客户端），然后Water API必须根据用户名在内部存储令牌。 每当用户通过移动应用程序向Water API发送更新时，该应用程序都会先更新其自己的记录，然后找到与最终用户相对应的MyHealth访问令牌，并使用它来访问MyHealth API。 通过这种方法，Water API具有存储MyHealth API访问令牌的开销，并且它应该在需要时刷新访问令牌。

上图中说明了第二种解决方案。 它是围绕OAuth 2.0链式授予类型配置文件构建的。 该移动应用必须携带有效的访问令牌，才能代表最终用户访问Water API。 在第3步中，Water API与自己的授权服务器进行对话以验证访问令牌。 然后，在步骤4中，Water API将从移动应用程序获得的访问令牌交换为JWT访问令牌。 JWT访问令牌是一种特殊的访问令牌，它承载一些有意义的数据，并且也由Water API领域中的授权服务器签名。 JWT包含最终用户的本地标识符及其在MyHealth域中的映射标识符。 最终用户必须在Water API域中允许此操作。

在步骤6中，Water API使用JWT访问令牌访问MyHealth API。 MyHealth API通过与自己的授权服务器对话来验证JWT访问令牌。 它验证签名； 并且，如果它是由受信任的实体签名的，则访问令牌被视为有效。 由于JWT包含来自MyHealth域的映射用户名，因此它可以标识相应的本地用户记录。

但是，这引起了安全隐患。 如果让用户使用映射的MyHealth标识符更新Water API域中的配置文件，则他们可以将其映射到任何用户标识符，这会导致安全漏洞。 为避免这种情况，帐户映射步骤必须使用MyHealth域启动OpenID Connect身份验证。 当用户想要添加其MyHealth帐户标识符时，Water API域将启动OpenID Connect身份验证流程并接收相应的ID令牌。 然后使用ID令牌中的用户标识符完成帐户映射。

这是我的《 高级API安全性》一书中介绍的十种API安全性模式之一。 您可以从本书中找到有关此内容的更多详细信息。

翻译自: https://www.javacodegeeks.com/2014/10/chained-access-delegation-pattern.html