我的应用程序认证与授权是否安全可靠？

如今，大多数应用程序由于威胁级别升高都需要认证和授权机制。这些机制不仅要确保安全，还要能够应对日益增长的流量而具备可扩展性。问题不在于应用程序是否具备认证和授权功能，而在于这些功能是否真正提供安全性、可扩展性以及更多相关特性。

认证和授权本身就是一个专业领域，但大多数开发人员/架构师最初都会选择自研机制。由于缺乏领域专业知识，这些自研机制通常安全性较低，同时还需要在非核心活动上花费大量时间，导致产品路线图受到影响，产品价值提升缓慢。

本文将详细讨论在这一领域常见的错误，以及在我们已经陷入困境时如何避免或克服这些问题。

应用程序的演进

当出现创建新产品/服务的新业务想法时，重点完全放在快速增加价值和进入市场上。非核心需求也以基本形式出现，比如应用程序仅需通过提供用户名和密码进行用户认证。随着时间的推移，根据市场反馈，认证和授权相关的功能会逐渐添加。一旦产品/服务成熟，您会意识到添加更多认证和授权功能（如多因素认证、密码策略、单点登录、外部身份提供商支持、合规性要求）不仅变得复杂，而且耗时。

此外，有时业务部门/组织内有不同的相关产品，由于各自为政，认证和授权机制表现不一致。当客户在解决方案中使用多个产品时，这会给人留下不良印象，因为同一业务部门/组织的两个不同应用程序以不同方式处理相同的事情。

最后，如今单体应用程序正在向微服务转型，从可扩展性的角度来看，无状态认证和授权成为当务之急，这也使开发人员/架构师能够拥有专门的身份和访问管理服务。

面临的挑战是什么？

重新发明认证和授权时面临的主要挑战包括：

• 复杂性：如前所述，认证和授权本身就是一个领域，随着时间的推移，维护变得复杂，因为它从未得到利益相关者的专门关注，主要焦点是产品的业务价值增加。因此，决策是从时间角度而非长期价值角度做出的，这导致工作流程僵化，系统灵活性降低。
• 实施困难：由于这不是主要领域，实施客户或市场需求的功能需要时间。
• 功能缺失：如今，独立软件供应商关注安全性，他们期望具备围绕认证和授权的常见功能，如果采用自研方案，这些功能往往缺失，如单点登录、OAuth/OIDC支持等。
• 合规性：存在各种合规性要求，满足其中许多要求（如GDPR或其他安全相关合规性）非常耗时。
• 可扩展性问题：由于认证和授权是应用程序/服务的一部分，根据微服务指南，每个领域应有不同的微服务以实现更好的可扩展性。
• 路线图加速：产品路线图中的业务价值增加受到影响，因为大部分时间都花在非核心活动上。

应该采取什么方法？

如果您正在构建新的应用程序/服务，请尝试使用外部化的认证和授权机制，而不是将其内置在应用程序/服务中。同时，不要重新发明轮子，而是使用开源的身份和访问管理解决方案（如Keycloak）或付费产品。虽然会有初始投资，但仅涉及集成方面，而您可以利用许多开箱即用的功能/灵活性以及更好的安全性，从而获得回报。

选择合适的解决方案

我认为需要做出的关键决策之一是选择开源还是付费产品。这取决于许多因素，如用例需求、预算批准等，但您需要考虑以下事项：

• 付费产品将提供更好的支持，并且更有可能影响其路线图。
• 开源不需要投资，但除非您积极贡献，否则影响路线图并不容易。

集成指南

当您集成外部认证和授权系统进行JWT令牌验证时，有两种高级方法：

• 集中式架构：在这种情况下，认证和授权验证活动在网关级别进行，之后请求在单个微服务级别不再进行认证。
• 分布式架构：在这种情况下，认证和授权在微服务级别进行，基本上作为边车容器，即在应用程序外部但在同一Pod内部。
• 混合架构：您可以选择混合机制，其中某些部分在网关级别验证，某些部分在微服务级别验证。

提示

• 不要将认证和授权相关工作保留在应用程序内部。您可以在集中式架构中使用Kong在网关级别处理，在分布式架构中使用OAuth2代理作为边车。
• 不要将对资源的访问与对资源实例的访问混为一谈。对资源的访问是授权的一部分，而对资源实例的访问应属于应用程序的一部分。