OAuth - open authentication

oauth

pieces

request token - app (anApp), service (twitter) and user interaction - exposed to user when requesting authorization - in some cases auth needs to be manually entered - potentially short key (in cases where user has to enter it) access token - server (anApp) to server (twitter) only - really long key (more secure)

user twitter anApp

1. user installs anApp
2. anApp asks for permission to use user's Twitter account
   • anApp requests access to user's Twitter
3. user clicks ok
4. anApp asks twitter for request token
5. twitter sends request token
   • now your app (anApp) has a request token
   • but it doesn't give you permission to do anything
6. anApp passes request token to user
7. user tells twitter to authorize the token
   • sends request token to twitter
   • "dear twitter, if anyone has this token, it means they are allowed to use my stuff"
8. twitter authorizes token, sends back to user
9. user sends the authorized token to app
10. app sends authorized request token and asks for access token
11. twitter turns that request token into an access token and passes it back to the app
12. app from now on uses access token to get user data

why two

• while mostly an artifact of previous design, there are some benefits
• access token being server to server only means - it can carry special meanings - it can have a larger size (a very long and therefore more secure key)

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 (mobile device or set-top box).

https://stackoverflow.com/questions/3584718/why-is-oauth-designed-to-have-request-token-and-access-token https://www.youtube.com/watch?v=SXDce0e3Ue4