To support API token: 添加对令牌的支持

[Thrimbda]

令牌（token）可以提供更加灵活的认证方式，有了令牌的支持，我们可以提供更加强大的API。

参考：

• OAuth Doc
• OAuth维基百科
• GitHub API Doc: OAuth

[aak1247]

这是要做API的鉴权还是身份认证

[zccz14]

@Macsnow14 你同意把我们 email 的内容 post 出来吗

[Thrimbda]

@zccz14 同意

[Thrimbda]

学习Spring的时候看到一个很好的对令牌以及OAuth验证过程的解释：链接在此
以下是一个文中描述的一个经典的令牌验证过程：

OAuth provides a clean way to handle these concerns. You’ve no doubt used OAuth already. One common case is when installing a Facebook plugin or game. Typically the flow looks like this:

1. user finds a game or piece of functionality on the web that requires access to a user’s Facebook data in order to function. One common example is "Sign in With Facebook"-style scenarios.
2. a user clicks "install," or "add," and is then redirected to a trusted domain (for example: Facebook.com) where the user is prompted to grant certain permissions (like "Post to wall," or "Read Basic information")
3. the user confirms these permissions and is subsequently redirected back to the source application where the source application now has an access token. It will use this access token to make requests to Facebook on your behalf.

In this example, any old client can talk to Facebook and the client has, at the end of the process, an access token. This access token is transmitted via all subsequent REST requests, sort of like an HTTP cookie. The username and password need not be retransmitted and the client may cache the access token for a finite or infinite period. Users of the client need not re-authenticate every time they open an application, for example. Even better: access tokens are specific to each client. They may be used to signal that one client needs more permissions than others. In the flow above, requests always ended up at Facebook.com where - if the user is not already signed into Facebook, he or she will be prompted to login and then assign permissions to the client. This has the benefit of ensuring that any sensitive information, like a username and password, is never entered in the wild in untrusted applications that might maliciously try to capture that username and password. Our application, will not be available to any old client. We can be sure that any client we deploy is friendly, as it will be one of our clients. OAuth supports a simpler flow whereby a user authenticates (typically by sending a username and password) from the client and the service returns an OAuth access token directly, sidestepping the need for a redirect to a trusted domain. This is the approach we will take: the result will be that our clients will have an access token that’s decoupled from the user’s username and password, and the access token can be used to confer different levels of security on different clients.

我认为我们可以学习其中的思想并将其融合进我们的橙汁中 :)