• Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,259
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. ByG Jayendra Kartheek
  • 2. 1. Token: Unique Identifier issued by server2. CallBack Uri: Url to which the page is redirected after authentication or Authorization3. Oauth_token : Temporary credentials identifier4. Oauth_token_secret : Temporary Credentials shared secret5. 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 protocol7. 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 theownership
  • 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