最近想搞个微薄工具玩玩，于是，也就有了弄个站点的想法。去腾讯围脖开放平台看相关API，发现许多不了解的术语。我本不是做Web开发的，但是碰见不懂的了解一下的心态还是有的，于是就有了这一篇。大部分是从auth.net的Beginner's Guide和RFC5849摘下来的，部分翻译加上自己理解。两篇文章结合起来看是必要的，否则，还真是难以完全领会OAuth的3-legged认证流程。
别外，刚开始把OAuth看成了0Auth。英文较多，耐心看完吧。
1. 为何要使用OAuth
The key used by users is usually a combination of username and password. This can be an OpenID or any other login credential. But this key is too powerful and unrestricted to share around. It also cannot be unshared once handed out except for changing it which will void access to every site, not just the one the user intends to block. OAuth addresses that by allowing users to hand out tokens instead. Each token grants access to a specific site for specific resources and for a defined duration.
A typical example offered by the spec (Appendix A) is when a user wants to print a photo stored on another site. The interaction goes something like this: the user signs into the printer website and place an order for prints. The printer website asks which photos to print and the user chooses the name of the site where her photos are stored (from the list of sites supported by the printer). The printer website sends the user to the photo site to grant access. At the photo site the user signs into her account and is asked if she really wants to share her photos with the printer. If she agrees, she is sent back to the printer site which can now access the photos. At no point did the user share her username and password with the printer site.
2. OAuth的一些术语
Service Provider, Consumer, User, Protected Resources, Consumer Developer/Consumer Credential(Consumer Key, Consumer Secret), Consumer Key and Secret: client credentials, Request Token and Secret: temporary credentials, Access Token and Secret: token credentials
The Service Provider needs to advertise the URIs of the following three endpoints: Temporary Credential Request: The endpoint used by the client to obtain a set of temporary credentials. 获取未授权的Request Token服务地址 Resource Owner Authorization: The endpoint to which the resource owner is redirected to grant authorization. 获取用户授权的Request Token服务地址 Token Request: The endpoint used by the client to request a set of token credentials using the set of temporary credentials. 用授权的Request Token换取Access Token的服务地址。
3. OAuth的其它技术细节
It is important to understand that security and privacy are not guaranteed by the protocol. In fact, OAuth by itself provides no privacy at all and depends on other protocols to accomplish that (such as SSL). Just like using passwords together with usernames to gain access, sites will use tokens together with secrets to access resources. And just like passwords, secrets must be protected. token相当于username，对应一个相当于password的password.
Tokens are used instead of User credentials to access resources. A Token is generally a random string of letters and numbers that is unique, hard to guess, and paired with a Secret to protect the Token from being abused. OAuth defines two different types of Tokens: Request and Access.
Request Tokens are only good for obtaining User approval, while Access Tokens are used to access Protected Resources.
Signing Request: OAuth is an authorization delegation protocol. OAuth defines a method for validating the authenticity of HTTP requests. This method is called Signing Requests.
The OAuth signature method was primarily designed for insecure communications. When OAuth is used over HTTPS, it offers a simple method for a more efficient implementation called PLAINTEXT which offloads most of the security requirements to the HTTPS layer. It is important to understand that PLAINTEXT should not be used over an insecure channel.
3-legged scenario, delegated access scenario, whatever you call it.
Requests are only made by the Consumer, it needs a way to authenticate itself with the Service Provider, but also to authenticate its authorization to access User data. This requires OAuth to support an HTTP request with two sets of credentials.
Credentials: username and password, token and token secret. The Consumer 使用 Consumer Key和Consumer Secret向Service Provider验证自身的有效性, the User使用Token 和Token Secret向Service Provide来向Consumer赋与操作自己资源的权限。
OAuth operates on two channels: a front-channel which is used to engage the User and request authorization, and a back-channel used by the Consumer to directly interact with the Service Provier. By limiting the Access Token to the back-channel, the Token itself remains concealed from the User. This allows the Access Token to carry special meanings and to have a larger size than the front-channel Request Token which is exposed to the User when requesting authorization, and in some cases needs to be manually entered.
Request Token and Access Token: A unique identifier issued by the server and used by the client to associate authenticated requests with the resource owner whose authorization is requested or has been obtained by the client. Tokens have a matching shared-secret that is used by the client to establish its ownership of the token, and its authority to represent the resource owner.
Credentials/username-password combination: Credentials are a pair of a unique identifier and a matching shared secret. OAuth defines three classes of credentials: client, temporary, and token, used to identify and authenticate the client making the request, the authorizaiton request, and the access grant.
The request signing workflow treats all Tokens the same and the workflow is identical. The two Tokens are specific to the authorization workflow, not the signature workflow which uses the Tokens equally. This does not mean the two Token types are interchangeable, just that they provide the same security function when signing requests.
OAuth uses digital signatures instead of sending the full credentials with each request. 这样接收端使用credentials相关的信息验证一下signature就能确定发送者的身份。只使用hash算法的signature只能校验信息完整性，所以需要把hash算法和shared secret结合起来，就能用来验证发送端的身份。因为shared secret是两方才知道的信息，它被加入到需要hash的信息当中，这样的算法有HMAC。而两者结合产生这种signature的算法有HMAC-SHA-1，RSA-SHA-1等等。
In OAuth, the shared secret depends on the signature method used. In the PLAIN- TEXT and HMAC-SHA1 methods, the shared secret is the combination of the Consumer Secret and Token Secret. In the RSA-SHA1 method, the Consumer Private Key is used exclusively to sign requests and serves as the asymmetric shared secret.
Consumer Secret是指从网站申请得到的App Secret。 Web server进行存储是没有风险的，而客户 端应用存储不论symmetric还是asymmetric shared secret都是存在被暴露的可能的。 这个问题现在 还没有简单的解决方法。 It is important to note, that even though the Consumer credentials are leaked in such application, the User credentials (Token and Secret) are specific to each instance of the Consumer which protects their security properties.
在2-legged scenario, 使用OAuth和HTTP 'Basic'有相同的用户体验，因为Consumer Credential 这时相当于用户名和密码，可以提示用户输入。在insecure channel中，除了省去了存储下来的风险外， 由于采用了signature的形式，OAuth提供了更为安全的方式。
signature保证authorized Consumer的请求内容不被更改，但是仍无法防止通过sniffing the network获取请求包而实现的replay attack。 As long as the shared secret remains protected, anyone listening in on the network will not be able to forge new requests as that will require using the shared secret. OAuth使用nonce和timestamp 来防止此类攻击。 nonce包含在signature当中，由Consumer生成并由Service Provice记录，攻击 者在不知道shared secret的情况下就无法replay attack了。
Using nonces can be very constly for Service Providers as they demand persistent storage of all nonce values received, ever. To make implementations easier, OAuth adds a timestamp value to each request which allows the Service Provider to only keep nonce values for a limited time. timestamp是nonce的生成时间，任何比 Service Provider保持的上个时间戳小的时间戳的请求都是无效的。From a security standpoint the real nonce is the combination of the timestamp value and nonce string. Only together they provide a perpetual unique value that can never be used again by an attacker.
4. 下面摘录自RFC5849
关于时间戳和nonce的验证: To avoid the need to retain an infinite number of nonce values for future checks, servers MAY choose to restrict the time period after which a request with an old timestamp is rejected. Note that this restriction implies a level of synchronization between the client's and server's clocks. Servers applying such a restriction MAY provide a way for the client to sync with the server's clock; alternatively, both systems could synchronize with a trusted time service. Details of clock synchronization strategies are beyond the scope of this specification.
OAuth定义了三种签名生成方法：PLAINTEXT, HMAC-SHA1和RSA-SHA1. PLAINTEXT用于加密传输方式中，和HTTP 'Basic'一样，传输不加密的credentials。Unlike 'Basic', PLAINTEXT supports delegation. When signing requests, it is necessary to use depends on the signature method has been used to allow the recipient to reproduce the signature for verification. PLAINTEXT方式不需要提供签名。oauth_signature_method参数用来指定使用 的签名方法。 oauth_signature参数提供对应的签名。
Two sets of credentials in OAuth: oauth_consumer_key, oauth_token. 并且Service Provider使用对应的secret来验证请求的正确性。
Signature Base String: The signature base string is a consistent, reproducible concatenation of several of the HTTP request elements into a single string. The string is used as an input to the "HMAC-SHA1" and "RSA-SHA1" signature methods. The signature base string does not cover the entire HTTP request. Most notably, it does not include the entity-body in most requests, nor does it include most HTTP entity-headers. It is imporant to note that the server cannot verity the authenticity of the excluded request components without using additional protections such as SSL/TLS or other methods.
在Temporary Credentials的请求环节，需要使用可靠传输方式: Since the request results in the transmission of plain text credentials in the HTTP response, the server MUST require the use of a transport-layer mechanisms such as TLS or Secure Socket Layer (SSL) (or a secure channel with equivalent protections).
在Resource Owner Authorization的请求环节，必须使用GET请求。 用户在Service Provider的页 面确认完毕后，用户被重定向至第一环节中所指定的callback url中。此请求是否使用可靠传输由 Service Provider自行决定: The way in which the server handles the authorization request, including whether it uses a secure channel such as TLS/SSL is beyond the scope of this specification. However, the server MUST first verify the identity of the resource owner.
此过程中返回一个verify code，作用如下: To make sure that the resource owner granting access is the same resource owner returning back to the client to complete the process, the server MUST generate a verification code: an unguessable value passed to the client via the resource owner and REQUIRED to complete the process.
在Token Credentials的请求过程中依然需要使用可靠方式以保证返回的token secret的安全: Since the request results in the transmission of plain text credentials in the HTTP response, the server MUST require the use of a transport-layer mechanism such as TLS or SSL (or a secure channel with equivalent protections). 同进在此次请求中需要带上上次Service Provider返回的verify code。
签名过程及用到的secret: OAuth-authenticated requests can have two sets of credentials: those passed via the "oauth_consumer_key" parameter and those in the "oauth_token" parameter. In order for the server to verify the authenticity of the request and prevent unauthorized access, the client needs to prove that it is the rightful owner of the credentials. This is accomplished using the shared-secret (or RSA key) part of each set of credentials.