这是一个场景（我没有提出它，我没有足够的空间来改变它）：
CompanyFoo.com。LogIntoCompanyBar.jsp的JSP页面上的URL链接。网址链接为CompanyBar.com/loginpage.php?token={token}。它基本上是一个SSO解决方案，使得来自CompanyFoo（基于Java）的用户无缝登录到CompanyBar（基于PHP）。当用户登录到CompanyBar的网站时，这不是必须与REST API的每个请求一起传递令牌的情况。 API唯一的工作是允许SSO进入CompanyBar的网站，并且在此之后令牌变得无用。
流量将使用HTTPS（TLS）进行加密。
现在，我控制的是安全性，令牌生成和API - 我正在Java方面工作。
我创建了一次性随机生成的HMAC令牌。盐是随机产生的。我有一个DB表，它存储用户名，令牌的日期创建，令牌，盐和秘密。秘密也是随机的，因为令牌只是一次性使用，我通过将它与存储在数据库表中的内容进行比较，有效地验证了传递给API调用的令牌。如果它们相同，那么我将用户数据返回给调用者。除非我遗漏了某些东西（这是非常可能的），否则我没有看到使用任何实际非随机数据的秘密，例如基于Java的webapp的用户密码。
令牌将通过Authorization HTTP Header传递给REST API调用。
如果你还在我身边，我肯定需要一些方向。
从我收集的内容来看，基于令牌的身份验证并非旨在保护服务器免受MITM /第三方攻击，而是保护服务器免受客户端的攻击。 但我可以采取哪些措施来保护DOS API或重播攻击的REST API URL？
假设REST API URL为CompanyFoo.com/rest/companybar/userdata。当然，CompanyBar需要知道REST API URl。但是，让我们说一些心怀不满的员工或随机个人对URL有所了解，并且有着邪恶的意图..
让我想到也许我可以为REST API使用基本身份验证和基于令牌的身份验证。在调用API之前，Basic将通过Tomcat-users.xml进行Tomcat身份验证。令牌可用于授权。 （请记住，webapp与Tomcat-users.xml无关.webapp由供应商提供，利用自己的数据库进行用户身份验证。它为webapp用户生成Tomcat会话和特定于供应商的会话。 ）双层保护。如果一个人窃取了令牌，他仍然需要知道Tomcat用户名和密码才能利用REST API，反之亦然。
但是，同时使用基本身份验证和基于令牌的身份验证来保护REST API免受来自客户端的攻击，例如重放或DOS攻击？如果答案是否定的，那么使用这两种身份验证方法的优点和缺点是什么？