MicroServices认证/授权

Question

我们期待在未来实现一个微服务架构。我们不希望API网关的权限非常笨重，并且限制获取、放置、发布等等。

我们希望集中存储和管理粒度应用程序权限，因此应用程序只需要获取它们，而不是管理它们。

我已经包括了一个草图的架构，我在我的头脑中，以及下面的逻辑流程。

我的问题

这种设计模式是否可以使用任何现有的身份验证/授权规范(如OAuth2 )来实现？如果没有，是否可以创建您自己的身份验证/授权模式以用于专用网络？

​

​

App生命周期

1. 开发人员创建WebApp1
2. WebApp1是由开发人员在中注册的。他/她还注册应用程序公开的自定义权限。
3. 用户可以通过IT管理员授予或撤销对应用程序公开的粒度权限的访问。

在上面的示例中，WebApp1公开了两个权限，CreatePost & DeletePost user1只有对CreatePost的权限。

用户进程流

1. 未经身份验证的用户访问WebApp1并重定向到登录屏幕。
2. 根据LDAP验证用户的凭据，并生成UUID授权令牌。令牌存储在安全令牌服务器中，用户重定向回WebApp1，其中包含在授权头中的令牌。
3. WebApp1从请求用户拥有的权限，这可以每隔x分钟完成一次，并将其存储在本地状态。Web还检查授权令牌是否仍然有效。
4. WebApp1每隔x分钟检查用户令牌是否仍然有效，如果没有再次请求用户登录(或者在用户身份验证时发送给应用程序的原始令牌中可以包含一个刷新令牌)。

Answer 1

有趣的问题--以下是通过基于OAuth的设计模式实现目标的一些想法：

授权目标

想要的结束状态通常是给自己选择：

• 使用允许任何API组件执行授权的模式。
• 有时，您需要接近数据源才能强制执行权限。
• 其他情况下，您可能希望通过专用服务强制执行某些类型的规则。

将令牌映射到权限

我喜欢这种做事的方式。实际上，它是一种基于声明的体系结构，您需要的授权信息不会仅仅来自令牌。

我的API授权后描述了一个可扩展的模式，它从在每个API中定义claims /主体对象开始。下面是一些示例代码，其中Authorizer类提供了对每个API请求的行为的概述。

网络应用程序注册中心

我会小心地创建组件，这些组件可能会承受沉重的负载，并成为整个软件平台的瓶颈--您需要这些组件吗？

索赔与微观索赔()

一个可以很好地工作的模式是设计两个级别的API。有趣的是，这两种方法都可以使用声明，你可以将授权责任放在任何你想要的地方--并给自己选择：

• 入口点API:暴露在互联网上，进行OAuth验证，自然地锁定客户端使用访问令牌可以做的事情：
• 微服务:在一个锁定的网络中运行，无需OAuth管道就可以自由地相互呼叫。

我的API平台体系结构文章探索了这个选项，在这个选项中，声明通过头在微服务之间传递。

访问令牌有效性

您通常可以通过遵循以下规则来简化代码，因为可能有多种原因导致令牌失效：

• 保持访问令牌使用时间短~60分钟
• 处理客户端中的401个错误，如在这段代码中