OAuth 2. Specifications :
2. Glossary of security terms - http://tools.ietf.org/html/rfc4949
3.Nice Link to hanlde apps that maintain session :
4. http://tutorials.jenkov.com/oauth2/request-response.html --- by Jenkon, Nice one
5. https://developers.google.com/accounts/docs/OAuth -- Google Docs
6. http://oauth.net/code/ -- OAuth Code svn links
7. http://www.salesforce.com/us/developer/docs/api_rest/Content/quickstart_oauth.htm -- Nice Linke from sales force
* Responsibilities of Auth Server
* OAuth Server must keep the extra parameters, send in the request and send it back
* 1. Register a client :
* Once registered it uses client_id till it issues access token.
* It uses the same client_id to also re-issues access tokens
* Client_id is not required to get access to the resource once the access token has been issued,.
* 2. Authenticate the User-Authentication request ( HTTPS must )
* steps :
* a.) A request Url is send from the client ( perhaps a redirect Authorisation End Point ) to the user ( This Url must be previoulsy known to the Client )
* This Url is the Authentication End Point to the Auth Server.
* E.g of an Authentication End Point : https://www.linkedin.com/uas/oauth2/authorization?response_type=code&client_id=j4d653dncw6l&state=STATE&redirect_uri=http://restful-fundamentals.blogspot.in/2013/04/oaut-informaion-system-security-glossary.html
* It has following fields
* response_type = code ( see http://tools.ietf.org/html/rfc6749#section-4.1#3.1.1 Response Types )
* redirect_url = the Url to which the oAuth server will redirect to.
* client_id = id of the client who is also the referrer
* state = any state which the client wants to associate with the user. Like it could be sessionId of the user, just to relate the user with a particular code that the client will eceive
* This is an important variable
*User via the user-agent now sends the GET the above authentication URL to the oAuth server
*Auth server checks this URL to see what action it needs to take
*Response_type parameter defines what kind of response to process
*Response_type = code , sends a signal to the OAuth server that a user authentication needs to done
*Before that it needs to first perform some preliminary validations
*Preliminary validations to be done by the OAuth server
*Validations by OAuth Server :
*1. Validate the Client_id is valid , possibly if it a system valid client_id
*2. If some mandatory paramters are missing
*4. Redirect_url - This URl must match exactly with the redirect_url that was initially registered
*Once the validation has been done it sends the request to the Resource Server for actual authentication.
*This is a matter of contract between the OAuth server and Resource Server
*The Contract shall tell what kind of request header and request body the OAuth server must send to the R-Server and what response will it ,in turn, receive back
*The good question to ask is :
*1. Does the OAuth Server store the user's credentials.
*If not ..... Then how does a oAuth server relates the 'Authorization code' it generated to the user ..
*It can only relate that to the Client_id ?
*Does not the OAuth server need to store the user credential , to get the right identification with the Client
*The response send by the server is received by the OAuth server
*oAuth server redirects to the Redirect_url of the client.
*E.g of the Redirect Url send by the OAuth Server to the User for redirect :
* *The browser now receives the redirect Url and then sends a GET http request to the redirect url of the client
*At this point the OAuth server has a map of Client_id and Authorisation_code it has issued. ( It may or may not have a map of authorisation_code with the user's credentials. Ie. it may not know against which user's authentication , this authentication_code has bee issued ??
*-- How can the above problem if solved.? If the resource server returns an unique identifier, that corresponsds uniquely with each user + crdential. Like email@example.com + pwd wuthentication will issues an OAuthServer_user_credentila = alalkga. This Id issuded by the Server to the OAuth server must be unique into the server system
*Client sees the redirect Url which has the authorisation_code. If the response has an error, then no further communication.
*3. Client's Exchange of Authorisation Code for an Access Token ( see 3.2 Token EndPoint of the Specs )
*Client now uses an Token End Point, an end Point on the OAuth server. Clearly this End point must be known prior to the client
*E.g of Token End Point
*This is the end point to exchange tokens
* The token endpoint is used by the client to obtain an access token by
*presenting its authorization grant or refresh token. The token
*endpoint is used with every authorization grant except for the
* implicit grant type (since an access token is issued directly).
* The client MUST use the HTTP "POST" method when making access token
Parameters sent without a value MUST be treated as if they were
omitted from the request. The authorization server MUST ignore
unrecognized request parameters. Request and response parameters
MUST NOT be included more than once.
*10. Access tokens ( 10.3 )
* This specification does not provide any methods for the resource
server to ensure that an access token presented to it by a given
client was issued to that client by the authorization server