我使用这将在Azure托管作为云服务的C＃实现REST Web服务。 既然是REST的服务，它是无状态的，因此，没有cookie或会话状态。
Web服务只能使用HTTPS（证书由StartSSL.com提供）。
一旦用户成功登录到服务，他们会得到一个安全令牌。 此令牌将在未来的通信提供身份验证。
该令牌将包含客户端的时间戳，用户ID和IP地址。
所有通信都只会通过HTTPS发生，所以我不担心被拦截和重放攻击中使用的令牌; 令牌将到期反正。
由于这是一个面向公众的服务不过，我担心有人可以与服务注册，登录，然后修改令牌，他们收到访问其他用户的帐户。
我想知道如何才能最好地确保令牌的内容，并确认它没有被篡改。
我打算做以下，以确保令牌：
客户端成功登录到服务与被服务的作用：
- 生成一个随机值和SHA256散列它的1000倍。
- 生成私钥+哈希随机值的一次性会话密钥。
- 哈希与SHA256 1000次会话密钥，然后用它来加密令牌
- 使用私钥签名使用RSA加密的令牌。
- 将加密的令牌+签名+未加密JSON包散列随机值到客户端。
当客户端调用一个服务发送未加密JSON包到服务加密的令牌和签名。 该服务将
- 重新创建私有密钥+哈希值随机会话密钥
- 使用私人密钥验证签名
- 使用哈希会话密钥来解密令牌
- 检查令牌还没有到期
- 继续执行请求的操作...
我真的不知道任何加密，所以我有一些问题：
- 这是足够的还是矫枉过正？
- 我读来检测篡改我应该包括与令牌的HMAC。 因为我用私有密钥签名，我还需要一个HMAC？
- 我应该使用Rijndael算法代替RSA？
- 如果Rijndael算法是优选的，需要将所生成的用于IV解密？ 即我可以把它扔掉或者我需要发送它会加密令牌？ 例如加密的令牌+ HMAC + IV +散列随机值。
由于所有的通信发生了HTTPS，直到它到达客户端的未加密的JSON包是不是真的加密。
此外，我可能要在PHP重新实现服务后使这一切都需要在PHP可行也。
谢谢你的帮助
你是真的结束了思维的令牌。 说实话，最好的令牌安全性依赖于随机性，或者更准确的不可预测性 。 最好的令牌是完全随机的。 你是正确的，一个值得关注的是，用户将修改他/她的令牌，并用它来访问其他人的账户。 这是被称为一个常见的攻击“窃取会话。” 这种攻击几乎是不可能的，当令牌是随机生成的，服务器端过期。 使用用户的信息，如IP和/或时间戳是不好的做法，因为它提高了可预测性。 我没有在大学的攻击，成功地猜测是基于以微秒服务器时间戳是活跃令牌。 应用程序的作者认为微秒会改变速度不够快，他们会是不可预知的，但事实并非如此。
你应该知道，当用户代理服务器之后，代理有时会查看纯文本格式的SSL请求（出于安全原因，许多代理将进行深度包检测）。 出于这个原因，它是好的，你过期的会话。 如果你没有你的用户将很容易受到攻击，如这一点，也有可能XSS和CSRF。
RSA或Rijndael算法应该是足够充分，提供了一个合理的密钥长度。 此外，你应该使用HMAC与令牌，以防止篡改，即使你在上面签名。 从理论上讲它是多余的，因为你用私有密钥签名。 然而，HMAC是很好的测试，您的签约机制的实现可能是有缺陷的。 由于这个原因，最好使用HMAC。 你会惊讶有多少“滚你自己的”安全实现具有导致他们妥协的缺陷。
听起来你对安全相当精明。 保持良好的工作！ 我们需要在这个世界更安全意识的开发者。
编辑：
它被认为是安全的，只要他们具有强烈的对称密钥（如AES，河豚等）进行加密，只有服务器只要令牌包括防篡改哈希包括在令牌时间戳/用户ID用它，如HMAC， 其与与用户ID /时间戳一起的秘密密钥加密 。 哈希保证完整性和加密保证机密性。
如果你不加密包括HMAC（或其他散列），那么用户能够与加密令牌篡改，并将它解密的东西有效。 我没有在其中用户ID和时间戳进行加密，并使用无散列令牌的服务器上的攻击。 通过在字符串中改变一个随机字符，我能够从像58762更改我的用户ID 58531.虽然我挑不出“新”的用户ID，我是能够访问别人的帐户（这是在学术界，为一个疗程的一部分）。
对此的一个替代方法是使用完全随机的令牌值，并且在服务器端映射它存储的用户ID /时间戳（其保持在服务器侧，因此是客户端的外部控制）。 这需要一点额外的内存和处理能力，但更安全。 这是你必须做对根据具体情况决定。
作为用于再利用/从IV和其他键导出密钥，这通常是确定，条件是该键仅适用于很短的时间周期。 数学上是不可能有人能打破他们。 这是可能的。然而。 如果你想要去的偏执路线（我通常做），随机生成的所有新的密钥。
