I recently wanted to create a microblogging tool to play around with, which led to the idea of setting up a website. While looking at the relevant APIs on Tencent Weibo Open Platform, I encountered many unfamiliar terms. Although I’m not a web developer, I still have the desire to learn about things I don’t understand, hence this article. Most of it is taken from auth.net’s Beginner’s Guide and RFC5849, with some translations and my own understanding. Reading both articles together is necessary; otherwise, it’s truly difficult to fully grasp the OAuth 3-legged authentication process.
Also, I initially mistook OAuth for 0Auth. There’s a lot of English, so please read patiently.
- Why use 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). 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.
- Some terms of 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. Get the unauthorized Request Token service address Resource Owner Authorization: The endpoint to which the resource owner is redirected to grant authorization. Get the user authorized Request Token service address Token Request: The endpoint used by the client to request a set of token credentials using the set of temporary credentials. Token is exchanged for the service address of Access Token.
- Other technical details of 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 is equivalent to username, which corresponds to a password equivalent to 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.
This can be a 3-legged scenario or a delegated access scenario, whatever you call it.
Requests are made solely 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 uses its Consumer Key and Consumer Secret to verify its validity with the Service Provider. The User uses its Token and Token Secret to grant the Consumer permission to access its resources.
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 The authorization 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 same tokens. 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. This way, the recipient can verify the sender’s identity by using the signature with the credentials. A signature using only a hash algorithm can only verify information integrity, so a hash algorithm and a shared secret need to be combined to verify the sender’s identity. Because the shared secret is information known only to both parties, it is added to the information that needs to be hashed; such algorithms include HMAC. Algorithms that combine both to generate this signature include HMAC-SHA-1, RSA-SHA-1, etc.
In OAuth, the shared secret depends on the signature method used. In the PLAIN-TEXT and HMAC-SHA1 methods, the shared secret is a combination of the Consumer Secret and the Token Secret. In the RSA-SHA1 method, the Consumer Private Key is used exclusively to sign requests and serves as the asymmetric shared secret.
The Consumer Secret refers to the App Secret obtained from the website. Storing it on the web server is risk-free, but storing either the symmetric or asymmetric shared secret on the client application carries the risk of exposure. There is currently no easy solution to this problem. It is important to note that even though Consumer credentials are leaked in such applications, User credentials (Token and Secret) are specific to each instance of the Consumer, protecting their security properties.
In a 2-legged scenario, OAuth and HTTP ‘Basic’ provide the same user experience because the Consumer Credential is equivalent to a username and password, prompting the user for input. In an insecure channel, besides eliminating the risk of storage, OAuth offers a more secure method due to its signature-based approach.
The signature ensures that the authorized consumer’s request content cannot be modified, but it still cannot prevent replay attacks achieved by sniffing the network to obtain request packets. As long as the shared secret remains protected, anyone listening in on the network will not be able to forge new requests, as that would require using the shared secret. OAuth uses nonce and timestamp to prevent such attacks. The nonce is contained in the signature, generated by the consumer and recorded by the service provider; an attacker cannot perform a replay attack without knowing the shared secret.
Using nonces can be very constrained for service providers, as they require persistent storage of all received nonce values. To make implementations easier, OAuth adds a timestamp value to each request, allowing the service provider to keep nonce values only for a limited time. The timestamp is the nonce’s generation time; any request with a timestamp smaller than the previous timestamp stored by the service provider is invalid. 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.
- The following is excerpted from RFC5849:
Regarding timestamp and nonce verification: 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 synchronize 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 defines three signature generation methods: PLAINTEXT, HMAC-SHA1, and RSA-SHA1. PLAINTEXT is used in encrypted transmission methods, transmitting unencrypted credentials, similar to HTTP ‘Basic’. Unlike ‘Basic’, PLAINTEXT supports delegation. When signing requests, its use depends on the signature method used to allow the recipient to reproduce the signature for verification. PLAINTEXT does not require a signature. The oauth_signature_method parameter specifies the signature method to use. The oauth_signature parameter provides the corresponding signature.
OAuth consists of two sets of credentials: oauth_consumer_key and oauth_token. The Service Provider uses the corresponding secret to verify the validity of the request.
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 important to note that the server cannot verify the authenticity of the excluded request components without using additional protections such as SSL/TLS or other methods.
In the request phase of Temporary Credentials, a reliable transmission method is required: 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).
In the request link of Resource Owner Authorization, GET request must be used. After the user completes the confirmation on the Service Provider’s page, the user is redirected to the callback URL specified in the first step. Whether this request uses reliable transport is determined by the Service Provider: The way 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 resource owner’s identity.
During this process, a verification code is returned, serving the following purpose: To ensure that the resource owner granting access is the same resource owner returning 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.
The Token Credentials request still requires a reliable method to ensure the security of the returned 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). Simultaneously, this request must include the verification code returned by the Service Provider previously.
Signature process and secrets used: 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.
Leave a Reply