REST风格的身份验证。客户端，无国籍unauthentication [英] RESTful authentication. Client-side, stateless unauthentication

问题描述

我实施了一套基于REST的服务，为一些发展，其中之一是认证服务

I'm implementing a set of RESTful services for some developments and one of these is an authentication service.

本认证服务验证身份的两种：

• 应用程序。 的AppKey为基础的认证，因此客户必须注册才能一键接入服务的其余部分。
• 用户。 知名凭据（用户+密码）为基础的用户身份验证，因此人类和机器可以通过客户端应用程序与这些RESTful服务工作。的

• Applications. AppKey-based authentication so clients must register for a key in order to access to the rest of the services.
• Users. Well-known credentials (user+password)-based user authentication so humans and machines can work with these RESTful services through client applications.

这些RESTful服务的是无国籍的

These RESTful services are stateless.

当一个客户端应用程序与认证服务，或作为身份使用证书的人或机器进行认证，这两个操作生成一个 AppToken 和 UserToken认证分别。

When a client application authenticates against the authentication service, or when a human or machine authenticates as an identity using credentials, both operations generates an AppToken and UserToken respectively.

这些令牌是一个咸鱼哈希因此后续请求到REST风格的基础设施，而共享将被认证的 AppKeys 和证书的。

These tokens are a salted hash so subsequent requests to the RESTful infrastructure will be authenticated without sharing AppKeys and credentials.

形成观点的完全无状态的方法来看，这些标记应该没有地方存储在服务层，但在某种客户端的状态（FE，Web客户端将使用其存储的的HTTP cookies ）。 这就是我目前的实施工作，现在

Form the point of view of a fully stateless approach, these tokens should be stored no where in the service layer but in some kind of client-side state (f.e., a Web client would store it using HTTP cookies). This is how my current implementations are working right now.

由于使用这些的标记重新验证每个请求的，让服务层接收来自客户端，因此可以比较令牌的来自客户端的，什么标记检查它是否是一个有效的令牌重新生成它在服务层和一个由客户拥有的比较的太贵了，我已经实现了一个服务层的 AppToken 和<强> UserToken 下，既具有到期日期和所有者（的量，令牌已为已创建的应用程序或用户），以检查是否来自客户端的令牌存在于令牌存储。

Because re-authenticating each request using these tokens and let the service layer receive the token coming from the client so it can compare what token comes from the client and check if it's a valid token re-generating it in the service layer and compare with the one owned by the client is too expensive, I've implemented a service layer AppToken and UserToken, both having an expiration date and an owner (the application or user for which the token have been created for), in order to check if the token coming from the client exists in the token store.

如何客户交互unauthenticate？的只是删除​​客户端安全状态。如果它是一个Web客户端，则丢弃该身份验证Cookie，只是刷新页面，客户端未检测到身份验证cookie和用户被重定向到登录页面。

How does clients interactively unauthenticate? Just dropping client-side security state. If it's a Web client, it drops the authentication cookie and just refreshing the page, client detects no authentication cookie and user is redirected to the login page.

从来看RESTful服务点，的这是一个无状态的unauthentication 的：客户不知道有关的招的具有一个服务层伪认证状态。 这只是一个服务实现的细节 - 一个性能优化 -

From the point of view of RESTful services, this is a stateless unauthentication: clients aren't aware about the trick of having a service layer pseudo-authentication state. It's just a service implementation detail - a performance optimization -.

我不会列出的利弊的无状态的服务，因为我绝对相信，这种做法是要走的路，但我发现一个问题：无国籍身份验证/ unauthentication意味着客户端不会通知服务器，他们关闭他们的会议，所以安全存放着大量的无用的记录结束

I'm not going to list the pros of stateless services because I'm absolutely sure that this approach is the way to go, but I find a problem: stateless authentication/unauthentication means that clients don't notify server that they close their session, so the security store ends with a lot of useless records.

这是不是一个很大的问题，如果服务的客户是那些将有有限的时间内会（FE，1小时，3小时，每天...），但会发生什么，如果一个用户进行验证永远（8个月，一年）的？。 如何区分你的什么是已过期的令牌？的

This isn't a great problem if service clients are ones that would have limited time sessions (f.e., 1 hour, 3 hours, a day...), but what happens if an user must be authenticated forever (8 months, a year)?. How do you distinguish what's an an expired token?

还有是一些方法，以解决这种情况：

There're some approaches in order to solve this situation:

1. 当服务层接收到一个请求时，它会更新令牌到期日，因此，一个自动的过程可能会丢弃那些已经过期的定义令牌的任意到期令牌（FE 24小时）。

危及架构的无状态特性，让客户通知，他们不希望再被验证的服务层，这样的服务可以删除相关联的令牌给客户端会话（但等待...如果客户端关闭Web客户端会发生什么情况？用户永远不会主动通知服务令牌必须删除...所以...僵尸令牌到那一步，所以自动化过程应该放弃他们，但。 ..什么是僵尸令牌？我不喜欢这种方法）的。

完全无状态的验证，没有店面，每个请求的认证。

这是个问题！你对此有何建议的方法 - 即使它不​​是1，2或3 - ？为什么

感谢这个较长的读取 - 老实说，我相信这个问题的结论将是非常有用的人！ -

Thanks for this long reading - I honestly believe that question's conclusions are going to be extremely useful to anyone -!

推荐答案

选择的方法：完全无状态认证和UNAUTHENTICATION

最后，我得到一个结论和协议的，以切换到整体上完全无状态的基于令牌的认证和unauthentication。

Finally, I got a conclusion and a protocol in order to switch to the whole completely stateless token-based authentication and unauthentication.

如何实现的呢？的

How to achieve it?

首先，这是你需要有无国籍基于令牌的身份验证的应用程序（但用户身份验证将努力以同样的方式，但不包括此清单）：

First of all, this is what you need to have stateless token-based authentication for applications (but user authentication would work in the same way, excluding this inventory):

• 在应用程序登记制度。应用程序是使用你的服务。这是你的应用程序访问的网络（内联网，互联网，云...），这是创造的的一些服务应用程序键的（跳过此进行用户身份验证）。
• 所以客户端服务连接是通过使用HTTPS / SSL加密的服务器证书。

• An application registration system. An application is an access to your services. It's "your application accessing some services on the net (intranet, internet, cloud...). This is creating application keys (skip this for user authentication).
• A server certificate so client to service connections are encrypted by using HTTPS/SSL.

这是鉴别一个应用的流程：

This is the flow of authenticating an application:

1. 客户端发送的认证请求认证服务。这要求必须包括在应用程序键的（AppKey）

认证服务收到previously发送的请求。

Authentication service receives the previously sent request.

现在的身份验证服务创建的应用程序标记的（AppToken），这是必要的信息来跟踪具体的认证客户端服务的身份验证服务依靠自我描述的连接。

Now authentication service creates an application token (AppToken), which is a self-describing concatenation of the necessary information to track a concrete authenticated client to the services relying on authentication service.

AppToken 的是一个复合字符串（该组合物可以是对象使用JSON序列化的）的：

AppToken is a compound string (this composition can be an object serialized using JSON) of:

• 在应用程序的散列（*一个SHA - 或其他 - 这是串联的一些应用程序信息的结果，这是信息将是一个服务秘密+的失效日期的（这是标记本身的一部分）。为何失效日期？。试想一下，在中间什么人可以打破安全和修改令牌的到期？当加密令牌就会被解密，以验证请求，再次散列到期的结果日期+的AppKey将不再产生相同的哈希值，所以令牌被废止。
• 发布日期。当前UTC日期+创建令牌时时间。
• 失效日期。在该令牌将不再有效的UTC DateT +时间。

• An application hash (*a SHA - or other - which is the result of concatenate some application info. This is info will be a service secret + Expiration date (which is part of the token itself). Why Expiration date?. Imagine that a man in the middle or something can break security and modify token's expiration? When encrypted token gets decrypted in order to authenticate a request, the result of hashing again the expiration date + AppKey will no longer produce the same hash, so token gets invalidated.
• Issued date. Current UTC Date+Time when creating the token.
• Expiration date. An UTC DateT+Time on which the token will be no longer valid.

认证服务加密步骤4的结果（在JSON序列化对象）。 **使用的AppKey的密钥或密码对称密码。就我而言，我将使用的Rijndael为。

Authentication service encrypts step #4 result (the JSON-serialized object). **Use AppKey as the key or password for a symmetric cipher. In my case, I'll use Rijndael for that.

后续请求将包括为了避免发送明文凭据此令牌。这些请求将总是包含在的AppKey 了，所以验证服务将能够确定哪些应用程序正在尝试进行身份验证的要求。

Subsequent request will include this token in order to avoid sending plain text credentials. Those request will always include the AppKey too, so authentication service will be able of identify what application is trying to authenticate the request.

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

After some time, a token becomes expired or invalid, and client requests for a new AppToken. Or the client was closed by the user and there's no persistent storage that would save security tokens, so next client session will request new ones when needed.

一些提示和详细信息.NET实现这种验证方法：

---

Some hints and details about .NET implementation of such authentication method:

• 我用 System.Security.Cryptography.RijndaelManaged 类对称加密。双方的AppKey和AppToken（并且如果基于令牌的用户验证它几乎相同的解决方案）是使用 RijndaelManaged的类生成。

• I've used System.Security.Cryptography.RijndaelManaged class for symmetric encryption. Both AppKey and AppToken (and in case of token-based user authentication it's almost the same solution) are generated using RijndaelManaged class.

加密文本被转换为十六进制字符串。这个被发送的认证响应。在我们的例子中（一个RESTful API），十六进制字符串重新presenting中的 AppToken 的将作为一个响应头。每当一个请求包括这个HEX串，认证处理将它重新转换为原始加密文本，和以后它会以评价如果令牌是有效获得解密。

Encrypted text is converted to an HEX string. This is sent with the authentication response. In our case (a RESTFul API), the HEX string representing the AppToken will be sent as a response header. Whenever a request includes this HEX string, authentication process will reconvert it to the original encrypted text, and later it'll get decrypted in order to evaluate if the token is valid.

亨里克感谢你的努力。我已经采取了一些概念，在你自己的答案，我已经把它们混合用我自己的结论。的

这篇关于REST风格的身份验证。客户端，无国籍unauthentication的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！