如何迁移现有的旧版Web应用以使用OAuth2

我目前有一个拥有15年历史的单片式Web应用程序，具有近一百万的用户，使用自制的授权和身份验证系统：JAAS，用户名和密码存储在具有基本密码哈希的DB中，还有一些2FA个人验证问题（不同哈希算法等）。

在接下来的12-18个月中，我将全面检查应用程序，主要侧重于UI，但同时还要慢慢升级基础部分（升级到Spring，Spring Security等）。在这个项目中，我们决定逐个模块解决UI升级；完成每个模块后，使其可用；一个绝好的机会，可以将整体拆分成单独的Web应用程序（所有应用程序都保持相同的UX设计）。

我在计划和解决方案时遇到的问题是在身份验证和授权级别。我需要一个跨领域的解决方案，该解决方案应涵盖所有模块，以便将用户从一个Web应用程序定向到另一个Web应用程序时，这是一个无缝过渡-他们甚至都不知道他们位于不同的Web应用程序上。OAuth2听起来是完美的解决方案。

我一直在努力了解如何整合这一点。我是否必须构建自己的自定义OAuth2服务器？那让我感到震惊。但是我该如何：

1. 将我所有的用户帐户和授权过程迁移到第三方OAuth2服务器
2. 自定义外观以匹配我的应用程序的其余部分（不确定这将有多容易/可能）
3. 阻止通过第三方服务器连接时出现典型的“应用程序XYZ想要访问您的帐户的权限...”弹出窗口？（例如：Google OpenID，Facebook等）。

我的目标是为用户提供从当前状态到新状态的无缝过渡，但提供创建独立的Web应用程序的功能，这些功能都可以在Web应用程序外部进行身份验证和授权。

披露：我是Auth0的工程师。

这取决于一个要点...您需要确定是否：

1. 您想直接花费大量时间（并间接花费金钱）来构建和/或维护自己的身份提供者和授权服务器
2. 或者您更喜欢直接花钱并使用Auth0等第三方身份验证提供程序。

从功能需求的角度来看，这两种选择都是完全可行的。通过自定义开发，您可以完全控制您决定支持的功能，因此，我将把答案的一部分集中在Auth0如何响应您列出的要求上。

但是，在进行此操作之前，无论您做出什么决定，对于身份验证，都应该专注于OpenID Connect而不是OAuth2。如果您计划还包含API，而不仅仅是将整体拆分成单独的Web应用程序，则后者将更为适用。

如何将现有用户迁移到基于Auth0的系统？

您可以决定继续使用数据库，并依靠Auth0来提供与可能需要使用的身份验证相关协议的所有合规性，或者可以将用户迁移到Auth0托管的数据库中，而不必担心如何存储和验证密码。

如果您希望继续使用数据库，请参阅使用自定义数据库使用用户名和密码对用户进行身份验证

应用程序通常依赖用户数据库进行身份验证。Auth0使您可以轻松连接到这些存储库，并将它们用作身份提供程序，同时保留用户凭据并提供许多其他功能。

_{（文档仅以MySQL为例，支持其他数据库引擎）}

另一方面，您可以利用将用户迁移到Auth0中所述的迁移过程，将用户凭据无缝地移动到Auth0数据库。

Auth0支持将用户从自定义数据库连接自动迁移到Auth0。每次登录时，此功能一次将您的用户添加到Auth0数据库，并且避免要求您的用户同时重置所有密码。

如果您希望所有用户立即开始使用我们的密码哈希算法，则还可以通过Management API在Auth0中创建所有用户。这具有要求用户重置其密码的副作用。

如何继续使用自定义两步身份验证（验证问题）？

通过使用规则，可以完全自定义Auth0提供的身份验证管道。这意味着，即使您不必实施任何与协议相关的内容，您仍然可以微调有关如何在应用程序中进行身份验证的小细节。

这包括继续使用现有的验证问题作为执行两步身份验证过程的一种可能性，在该过程中，用户提供了由Auth0验证的初始密码，然后您要求他们提供来自自定义规则的更多信息。（规则只是JavaScript，因此可能性是无限的）

但是，您也可以决定放弃验证问题，而选择Auth0 Guardian作为增加验证过程安全性的一种方式。

如何自定义身份验证UI的外观？

使用Auth0，您可以利用默认的登录页面或诸如Lock之类的身份验证小部件，立即获得一个干净的身份验证UI 。所有这些都支持某种程度的自定义，您始终可以决定自己创建自己的UI，而是利用对用户界面没有任何约束的较低级别的Auth0库（Auth0.js）。

有关自定义的更多信息：

• 自定义锁10的外观
• 如何自定义托管页面

如何防止显示明确的同意页面？

您既可以将Auth0用作身份验证提供者，也可以将其用作API的OAuth2授权服务器（目前仅在美国地区可用）。

作为身份提供者，您不必担心同意页面，用户使用由Auth0管理的凭据进行身份验证，然后将其重定向到您的应用程序-就是这样。

在OAuth2即服务方案中，启用同意后，路线图包括允许绕过某些应用程序的同意页面。

最后要说的是，这似乎是一个非常有趣且具有挑战性的项目，因此无论您做出最终决定，都祝您好运。

当我不得不重新实现旧版应用程序的身份验证系统时，我已经在上一份工作中经历了类似的事情。我们实现了自己的身份提供者和授权服务器，说实话，我仍然觉得我们可能忘记了一些必不可少的东西。

我认为这是滚动自己的安全性的最大问题，有时会出现最后期限强加捷径的情况，而安全性并不是创建捷径的好地方。

如果您还有其他问题，请告诉我是否对您有所帮助。