The document discusses the OAuth 1.0 authentication protocol. It defines key terms like token, callback URI, OAuth signatures, and describes the OAuth authentication process. Client requests include parameters like OAuth_token and OAuth_signature, calculated using the signature base string. The server validates the signature to verify the client's identity before granting access to protected resources. Signatures can be generated via HMAC-SHA1, RSA-SHA1, or plaintext depending on the method used.

1. By
G Jayendra Kartheek

2. 1. Token: Unique Identifier issued by server
2. CallBack Uri: Url to which the page is redirected after authentication or
Authorization
3. Oauth_token : Temporary credentials identifier
4. Oauth_token_secret : Temporary Credentials shared secret
5. Oauth_verifier: The verification code received from the server in the
previous step.
6. Oauth_callback_confirmed: It must be present and set value true. This
parameter is used to differentiate from previous versions of protocol
7. http/1.1 200 : STATUS OK and returns true – refer document (page no 10 )

3.  Oauth provides 2 sets of credentials
1. To verify client.
2. To verify resource Owner.
 Before client making request on behalf of resource owner client must
have Authentication Token.
 Client details are in the form of unique identifier and associated with
Shared secret or RSA key pair

4.  Authentication requests include many protocol parameters each start with
“auth_” as prefix and names are case sensitive
 Clients make authenticated requests by calculating the values of a set of
protocol parameters and adding them to the HTTP request as follows:
1. Client assigns values to each of the following parameters:
1. Oauth_consumer_key
2. Oauth_token
3. Oauth_signature_method
4. Oauth_timestamp
5. Oauth_nonce
6. Oauth_version

5. 2. Parameter is not repeated again.
3. Client assigns values of the oauth_signature.
4. Client sends authenticated http request toe the server.
Oauth_signature: oauth provides 3 methods to client to verify the
ownership

6.  Server validate the Following:
1. Recalculate the signature independently and comparing the value received
from client via Oauth_signature parameter.
2. Based on (HMAC-SHA1,RSA-SHA1) methods ensuring that the combination
of nonce/timestamp/token received from client are not used before
(previous request).
3. If token is present we verify the Scope and state of authorization
4. If Oauth_version is present we see that the value is 1.0
If the request fails server should respond with appropriate http response code
1. 200 - success
2. 400 – bad request
3. 403 - unauthorized

7.  Nonce : Random string helps client to verify that requests are not made
before. This is used to prevent from replay attacks
◦ Must be unique with Timestamp+client credentials+token
credentials
 Signature : OAuth-authenticated requests can have two sets of
credentials:
1. those passed via the "oauth_consumer_key" parameter
2. 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.

8.  Signature Methods: Oauth provides 3 methods for client to prove the owner
ship
1. HMAC-SHA1
2. RSA-SHA1 (USES RSA KEY INSTEAD OF SHARED KEY)
3. PLAIN TEXT (DOESN‟T INVOLVE A SIGNATURE)
 Signature Base String : It 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. More information (page no : 19)
 String Construction : page no 19 – 3.4.1.1
 Base String Uri : Page no 20 – 3.4.1.2.

9.  The Parameters collected in the previous steps are collected and
concatenated in to a single string using Following steps
1. Name and value of each parameter is encoded
2. Parameters are sorted by name using byte value ordering (if 2 or more
have the same name then they are sorted using values)
3. Name is concatenated to its value using “=” character as separator
4. Sorted Name and value concatenated using ”&” character as separator

10.  Protocol Parameters are included in header can be transmitted using http
authorization header with auth scheme name set to Oauth
 Parameters are included as Follows:
1. Names and values are encoded per parameter
2. Each parameter is immediately followed by “=” and between „”‟
character
3. Parameters are separated by „,‟
4. Optional Parameter „Realm‟ may be included

11.  Conditions are required to meet transmit protocol parameters in http-
request if the following Conditions are met
1. The entity-body is single-part.
2. The entity-body follows the encoding requirements of the
"application/x-www-form-urlencoded"
3. The HTTP request entity-header includes the "Content-Type" header
field set to "application/x-www-form-urlencoded".

12. 1. Algorithm is defined as
Digest = HMAC-SHA1(key,text)
Text: Is set to value of signature base string
Key: Concatenate values of
1. Client shared secret after encoding
2. „&‟ character must be included in secret
3. Token shared secret after encoded
Digest: Set the value of Oauth-sign protocol after result octet is base 64

13.  Signature method uses RSASSA-PKCS1-V1_5 signature algorithm using
SHA1 as hash function for EMSA-PCKS1-V1_5.
 To use this client must have established client credentials with server that
included RSA public Key
S = RSASSA-PKCS1_V1_5-sign(K,M)
K : is set to client‟s RSA private key.
M: is set to the value of base string
S: result signature method to set value of Oauth- protocol parameter
after result octet is base 64

14.  Server Verifies signature per
RSASSA-PCK1-V1_5-VERIFY((n,e),M,S)
(n,e) set to client‟s public key
M is set to value of signature base string
S is set to octet string value of Oauth-signature protocol
parameter received from client

15.  This Algorithm doesn‟t employ signature algorithm.
 It must be used with Transport Layer Mechanism using TLS,SSL
 Doesn‟t uses Oauth_timestamps , Oauth_nonce
 Oauth protocol is set to concatenated value of
1. Client-shred secret after encoding
2. “&” character must be included
3. Token shared after being encoded

16.  The OAuth 1.0 Protocol – by E. Hammer-Lahav, Ed. ISSN: 2070-1721
 Oauth community Site - http://oauth.net/
 book can be downloaded at - http://tools.ietf.org/html/rfc5849