好的，我正在创建一个API，用于使用XML操作Web应用程序中的用户和数据。如果他们POST XML，他们可以创建用户等。我使用的是一个2脚OAuth解决方案来保护和验证API请求。然而，这个问题并不是关于安全性的这个方面，但我将描述的方面是允许用户从API请求登录而不必输入他们的用户名和密码，这就是我所拥有的：
步骤1，合作伙伴使用XML API创建用户，如果成功，系统将返回包含新ID的路径，例如“/ user / 99”。
步骤2，合作伙伴向用户/ login / 99发出请求，这将在我的数据库中创建一个新的“登录令牌”，这里是相关的属性：
UserID int FK
AccountID int FK
Token string
Expiration date
Used bit
UserID和AccountID与相应的用户和帐户表...
相关令牌是随机生成的GUID的前20个字符，删除了破折号并且所有字符都设置为ToUpper（）。
DateTime.Now。到期时间是30秒。
Used = false
步骤3，合作伙伴将了解系统的URL（与API位于不同的域），现在他们可以像这样对其进行POST：
http://otherdomain.webapp.com/core/login/ [在此插入guid]
现在，'otherdomain'部分对每个帐户都是唯一的，所以此时我们会验证：
根据提供的guid查找LoginToken，如果它与匹配子域的帐户一起使用，未过期（30秒内），并且'仍然'设置为false，请将用户登录，设置使用= true，如果通过查询字符串提供，则将它们指向主页或其他URL。
所以基本上你需要一个完整的注册应用程序和密钥以及OAuth的所有爵士乐只需要请求GUID，它允许你登录但只能工作一次，在30秒的窗口内...他们需要知识首先是登录URL，这还不错吗？
最后，如果有人能够在30秒内以某种方式知道GUID和URL，那么他们就可以登录，但是有什么机会呢？
或者，我可以添加什么来使其更安全？
答案 0 :(得分：1)
（免责声明：我不是安全专家。）
我注意到的直接问题是：
http ：// otherdomain.webapp.com/core/login/ [在此插入guid]
根据您的设置，GUID令牌必须在请求时提供给用户。这实际上是请求的密码。如果您通过HTTP发送，任何可以窥探连接的人都有令牌，并且劫持会话并不困难。这绝对必须在整个过程中使用SSL。
除此之外，问题在于你在使用它之前将令牌发送给用户，这并不是很好。但是使用SSL，它可能非常适合您的目的。在处理无法处理正常身份验证的协议时，我使用了类似的方法，用户首先通过安全通道连接并说“我想在另一个上进行传输”，服务器发回一个令牌他们可以用于该请求。它在低安全性系统上运行良好。如果您要保护关键数据，我强烈建议您在投入生产之前投入资金聘请专家来查看。