令牌是一段只有Server X可能创建的数据，它包含足够的数据来识别特定的用户。

您可以提供您的登录信息并向服务器X请求一个令牌;然后您可以呈现您的令牌，并要求服务器X执行一些特定于用户的操作。

令牌是使用来自密码学领域的各种技术的各种组合以及来自更广泛的安全研究领域的输入来创建的。如果你决定创建自己的代币系统，你最好非常聪明。

When you register for a new website, often you are sent an email to activate your account. That email typically contains a link to click on. Part of that link, contains a token, the server knows about this token and can associate it with your account. The token would usually have an expiry date associated with it, so you may only have an hour to click on the link and activate your account. None of this would be possible with cookies or session variables, since its unknown what device or browser the customer is using to check emails.

它只是哈希与数据库中的用户或其他方式相关联。该令牌可用于身份验证，然后授权用户访问应用程序的相关内容。要在客户端检索此令牌，需要登录。第一次登录后，你需要保存检索到的令牌，而不是任何其他数据，如会话，会话id，因为这里的一切都是令牌，以访问应用程序的其他资源。

令牌用于确保用户的真实性。

更新: 目前，我们有更先进的基于令牌的技术，称为JWT (Json Web令牌)。这种技术有助于在多个系统中使用相同的令牌，我们称之为单点登录。

基本上，基于JSON的令牌包含用户详细信息和令牌到期详细信息。因此，如果令牌无效或过期，可以根据详细信息使用该信息进一步验证或拒绝请求。

问题老了，技术先进了，现在的状态是这样的:

JSON Web Token (JWT)是一个基于JSON的开放标准(RFC 7519)，用于在Web应用程序环境中在各方之间传递声明。令牌的设计是紧凑的，url安全的和可用的，特别是在web浏览器单点登录(SSO)上下文中。

https://en.wikipedia.org/wiki/JSON_Web_Token

令牌是一段只有Server X可能创建的数据，它包含足够的数据来识别特定的用户。

您可以提供您的登录信息并向服务器X请求一个令牌;然后您可以呈现您的令牌，并要求服务器X执行一些特定于用户的操作。

令牌是使用来自密码学领域的各种技术的各种组合以及来自更广泛的安全研究领域的输入来创建的。如果你决定创建自己的代币系统，你最好非常聪明。

从Auth0.com

Token-Based Authentication, relies on a signed token that is sent to the server on each request. What are the benefits of using a token-based approach? Cross-domain / CORS: cookies + CORS don't play well across different domains. A token-based approach allows you to make AJAX calls to any server, on any domain because you use an HTTP header to transmit the user information. Stateless (a.k.a. Server side scalability): there is no need to keep a session store, the token is a self-contained entity that conveys all the user information. The rest of the state lives in cookies or local storage on the client side. CDN: you can serve all the assets of your app from a CDN (e.g. javascript, HTML, images, etc.), and your server side is just the API. Decoupling: you are not tied to any particular authentication scheme. The token might be generated anywhere, hence your API can be called from anywhere with a single way of authenticating those calls. Mobile ready: when you start working on a native platform (iOS, Android, Windows 8, etc.) cookies are not ideal when consuming a token-based approach simplifies this a lot. CSRF: since you are not relying on cookies, you don't need to protect against cross site requests (e.g. it would not be possible to sib your site, generate a POST request and re-use the existing authentication cookie because there will be none). Performance: we are not presenting any hard perf benchmarks here, but a network roundtrip (e.g. finding a session on database) is likely to take more time than calculating an HMACSHA256 to validate a token and parsing its contents.