This is the 10000 ft view on understanding OAuth.
Consider this scenario as example. You are in LinkedIn and you want to display your tweets in the LinkedIn stream.
There are two ways of doing this. The first one would be to give your twitter credentials to LinkedIn, let LinkedIn fetch your data. ( This is like say when you friend asks for money, you give your credit card as well as the PIN. Lame.) The other way is to use OAuth. In OAuth, you delegate your powers to LinkedIn, like say you allow LinkedIn to only fetch your tweets. LinkedIn cannot access your setting page in twitter and change your wall paper. (This is very similar to using a Valet Key for car).
Basically there are three entities involved. The user (you), consumer(LinkedIn) and the service provider (twitter).
For this delegation to happen, LinkedIn must agree terms with Twitter. LinkedIn goes to Twitter and gets its credentials. In OAuth world, they call it the Consumer Token/ Consumer Key. Token:Key :: Username:Password.
Now you are in LinkedIn and your are clicking a link to access your tweets. Internally, LinkedIn will send its Consumer Token/ Key to Twitter. Twitter will verify that LinkedIn is a valid consumer and reply back a Request Token.
Using this Request Token, LinkedIn will direct your browser to Twitter's page where in you will be asked to enter your username and password. Once this authentication is done, it will be redirected to LinkedIn. Also, the Request Token becomes an User-Authorized Request Token.
Using this new authorized Request Token, LinkedIn asks Twitter for an Access Token(Key+Secret). Once it exchanges for an Access Token, LinkedIn is good to go. It can now access the tweets. But you still need Consumer Secret and Access Token Secret to access the resources.
This process of requesting an access token is one time process. Access Tokens are valid depending on the vendor agreement or until you revoke the access.
The above process is called an OAuth dance. Of course, a complicated dance step :).
While there are several tokens, each one serves its unique purpose and in also increases a layer of security. The below is the summarization of the user of each tokens.
Consumer Key - Identifies the Consumer. The only way Twitter can identify LinkedIn is requesting for access.
Consumer Secret - The URL is signed using consumer secret, but secret is not sent along the URL.
Request Token - We have this because only using this can LinkedIn redirect to Twitter's page. This is like Twitter saying "Fine, LinkedIn, I appreciate you coming to me. But please get this form signed by the user."
Access Token - Once you submit the signed form, Twitter gives you the key to the locker (but with limited privileges). Also, once you decide to revoke the access, Access Token becomes invalid. Once this becomes invalid, LinkedIn will no more be able to access your tweets. To gain access, you will have to dance again. This is important because, in case you did not have an access token, you would be using your password to authenticate. To revoke access, you will have to change your password. Access Tokens to rescue!
1. A man in the middle changes some parameters of your request ? Every request is signed with a Secret, based on the values in request. And, this can be decrypted only by Server. If anything goes wrong, the request becomes invalid.
2. A man in the middle sniffs your packet and repeats the same request (Repeat Attack)? Yes, this is possible. To avoid this, OAuth has specified the use of nonce (number only once). Each request will generate a random text called nonce and this is send along with the request. The server stores these nonces and will know if the same request is hitting twice.
Happy Dancing. Also visit this page for detailed understanding of OAuth's security architecture.
