RESTful身份验证。客户端,无状态未验证

第三个

无状态身份验证,基于令牌。假设传输级别加密。

• [X]S S --X由S的公钥签名
• [X|Y] --X和Y在同一个信封中
• Y [M]S Y -> S --Y向S发送签名消息M。

目标: 客户C希望与服务S通话。

1. 客户端C发送其共享密钥或公钥 PK C 用于对服务A进行身份验证,C知道其端点和公钥( PK A )。

2. A [now + interval | user-id or PK C ]S A -> C

   解释如下:

   服务A在当前日期/时间上添加一个间隔作为过期时间。在要发送的缓冲器中现在是到期日期和用户id, PK公司 C (假设您拥有有效的身份提供程序)。

   [now + interval | user-id or PK C ] = T

   A在上面签名;

   [T]S A

3. 客户端C希望与后端服务S对话。

4. C [[M|[T]S A ]S C -> S

   C向服务S发送消息M加上它从A获得签名的令牌。

5. S关心C是否真的发送了它,并验证了C的签名 S C 它是从信封上读出来的。

   S验证签名 S A 的代币。失败意味着请求被拒绝。

   S验证令牌 [T] 秒 A. :用户id/ PK公司 C 正确且标记日期>=现在Expired token表示向客户端C发送“token Expired”消息。如果token签名错误,则拒绝权限。

   (可选;S授权C,离题)

6. S执行工作并发送回 [M 2 ]S S 至客户C。

这不会是太多的开销;验证签名是一项非常快速的操作。

证书

问题' C# Sign Data with RSA using Bouncy Castle '显示了如何对正在发送的消息进行签名和验证。

你需要证书;如果你正在使用配置管理器(你应该这样做!;)),就像木偶一样,那么你 create a certificate signing request (CSR) 然后 sign it using puppet 。

在上发布脚本 未经认证 特别是

有一种叫做 证书吊销请求 ,基本上是已撤回且不可信任/使用的公钥的列表。位置 PK公司 C 然后广播撤销,它基本上是通过要求客户端再做一次 证书签名请求 圆形的

此外,如果您想要特定的过期功能 代币 ,将唯一ID(UUID/GGUID)添加到令牌 T 当你创建它时 令牌吊销列表 ,类似地在更改时广播,即在令牌UUID过期时清除它们。因此,服务也会检查 令牌吊销列表 如果接收到的T在其中。

基于哈希的令牌

看看软件巨头们在做什么。例如,使用共享密钥的亚马逊REST接口:

Amazon S3 REST API使用基于keyed-HMAC的自定义HTTP方案 (哈希消息身份验证代码)进行身份验证。进行身份验证 一个请求,首先将请求的选定元素连接到 形成一个字符串。然后使用您的AWS密钥进行计算 该字符串的HMAC。非正式地,我们将此过程称为“签署 请求,”我们将HMAC算法的输出称为“签名” 因为它模拟了真实签名的安全属性。 最后,使用添加此签名作为请求的参数 本节中描述的语法。

Read more on Amazon's scheme.

上面的子版本/攻击向量

• 我所描述的方案最初需要SSL,它很容易受到众多证书颁发机构的攻击, as well as a number of other things 。
• 你很容易受到重播攻击,即中间的人重新发送消息。如果您的REST接口 幂等的 你很安全。如果您添加一个已知加密的服务器,您也是安全的 随机数 响应请求。

选择的方法:完全无状态认证和未认证

最后,我得出了一个结论 协议 以便切换到整个完全无状态的基于令牌的认证和未认证。

如何实现?

首先,这就是应用程序需要的无状态基于令牌的身份验证(但用户身份验证的工作方式相同,不包括此清单):

• 申请注册系统。应用程序是对您的服务的访问。这是“你的应用程序访问网络上的一些服务(内联网、互联网、云…)。这是在创建 应用程序密钥 (跳过此项进行用户身份验证)。
• 服务器证书,以便使用HTTPS/SSL对客户端到服务的连接进行加密。

这是验证应用程序的流程:

1. 客户端向身份验证服务发送身份验证请求。此请求必须包括 应用程序密钥(AppKey) 。

2. 身份验证服务接收以前发送的请求。

3. 现在,身份验证服务创建 应用程序令牌 (AppToken),它是必要信息的自描述串联,用于跟踪具体的经过身份验证的客户端到依赖于身份验证服务的服务。

4. 应用令牌 是复合字符串( 该组合可以是使用JSON序列化的对象 )第页,共页:

   • 一个应用程序散列(*a SHA-或其他-这是连接一些应用程序信息的结果。这是信息将是服务机密+ 到期日期 (这是令牌本身的一部分)。 为什么是截止日期? 。想象一下,中间人或其他人可以破坏安全并修改令牌的过期时间?当加密的令牌被解密以验证请求时,再次散列到期日+AppKey的结果将不再产生相同的散列,因此令牌将无效。
   • 发布日期 。创建令牌时的当前UTC日期+时间。
   • 到期日期 。一个UTC日期T+时间,在该时间令牌将不再有效。

5. 身份验证服务对步骤#4的结果(JSON序列化对象)进行加密**使用AppKey作为对称密码的密钥或密码。在我的情况下,我会使用Rijndael。

6. 后续请求将包括此令牌,以避免发送纯文本凭据。这些请求将始终包括 应用程序密钥 同样,身份验证服务将能够识别哪个应用程序正在尝试对请求进行身份验证。

7. 一段时间后,令牌过期或无效,客户端请求新的AppToken。或者客户端被用户关闭,并且没有可以保存安全令牌的持久存储,所以下一个客户端会话将在需要时请求新的令牌。

关于.NET实现这种身份验证方法的一些提示和细节:

• 我用过 System.Security.Cryptography.RijndaelManaged 类进行对称加密。AppKey和AppToken(在基于令牌的用户身份验证的情况下,它几乎是相同的解决方案)都是使用 RijndaelManaged 班

• 加密后的文本将转换为十六进制字符串。这是与身份验证响应一起发送的。在我们的示例(RESTFul API)中,HEX字符串表示 应用令牌 将作为响应标头发送。每当请求包含此HEX字符串时,身份验证过程都会将其重新转换为原始加密文本,稍后会对其进行解密,以评估令牌是否有效。

感谢Henrik的努力。我在你自己的回答中采纳了一些概念,并将它们与我自己的结论混合在一起。