Skip to content

Latest commit

 

History

History
165 lines (113 loc) · 5.78 KB

WHAT_IS_OAUTH.textile

File metadata and controls

165 lines (113 loc) · 5.78 KB
Raw

OAuth Provider

  • Owns a (password) protected resource that belongs to a user.
  • Generates keys(client_id, client_secret, redirect_uri) for OAuth clients.

OAuth Client

  • Wants to access the protected resource on any OAuth Provider.
  • Knows its own client_id, and client_secret, redirect_uri

The admin flow

admin@oauth-client:

  • Writes to admin@oauth-provider to request access, and sends a
    redirect_uri and application_name as part of the process.

admin@oauth-provider:

  • Logs in into an admin screen to register an oauth client with the
    redirect_uri and application_name.
  • Sends back the the client_id and client_secret that the admin screen
    generated to admin@oauth-client.

Now the oauth provider and oauth clients know about each other.

The end user flow

NOTE: this flow is over-simplified, and omits a lot of headers for the sake
of simplicity. Also all URLs SHOULD be HTTPS, or security goes out the door,
anyone can sniff codes and tokens going over the wire.

  • Bob(bob@gmail.com) has an account at an OAuth provider – flickr.com.
  • Bob(bob@hotmail.com) also has an account on another service – printer.com.

Note that it’s the same Bob, but he has a different username and identity
on flickr.com and printer.com.

Bob now wants his protected resources (pictures) on the flickr.com (OAuth
provider) to be accessible by printer.com(OAuth client) so that they can
print it.

  • Bob logs in into printer.com and logs in using the browser.
  • Bob clicks on a link that says “Print pictures from flickr.com”
  • The link takes Bob’s browser to
Location: http://flickr.com/authorize? client_id=PRINTER_DOT_COM_CLIENT_ID& redirect_uri=PRINTER_DOT_COM_REDIRECT_URI
  • The authorization step:
  • flickr.com knows the application_name corresponding to the client_id and
    redirect_uri and asks Bob to log in. Once Bob is logged in, flickr.com
    asks Bob in the browser:
Do you wish to allow a service named ‘printer.com’ to access flickr.com on your behalf? [Y/N] [SUBMIT] If Bob clicks yes and hits submit to allow printer.com to access his private data on flickr.com on his behalf. Note that Bob does not tell either his flickr.com username/password to printer.com.
  • Once Bob clicks yes and authorizes access, flickr.com generates a
    ONE_TIME_AUTHORIZATION_CODE_FOR_BOB for printer.com to access
    bob@gmail.com’s data on bob@hotmail.com’s behalf.
flickr.com now redirects Bob’s browser to the redirect_uri with the authorization_code: Bob redirected to: http://printer.com/callback?code=ONE_TIME_AUTHORIZATION_CODE_FOR_BOB
  • Getting an access_token in exchange for ONE_TIME_AUTHORIZATION_CODE_FOR_BOB
  • printer.com now gets a callback with the authorization code, and knows
    that Bob is logged in, therefore ONE_TIME_AUTHORIZATION_CODE_FOR_BOB
    belongs to bob@hotmail.com.
  • Now that printer.com knows the authorization_code, it can request an
    access_token from flickr.com to actually access the protected
    resource.
  • printer.com contacts flickr.com, gives the authorization_code to get
    back an access_token.
printer.com identifies itself to flickr.com and requests an access_token corresponding to ONE_TIME_AUTHORIZATION_CODE_FOR_BOB http://flickr.com/oauth/token? client_id=PRINTER_DOT_COM_CLIENT_ID& client_secret=PRINTER_DOT_COM_CLIENT_SECRET& code=ONE_TIME_AUTHORIZATION_CODE_FOR_BOB
  • flickr.com reads the request, and verifies that the client_id,
    client_secret, ONE_TIME_AUTHORIZATION_CODE_FOR_BOB are all consistent
It then generates an access_token for printer.com to be able to access Bob’s pictures, and renders a json containing the access_token: { access_token: ACCESS_TOKEN_FOR_PRINTER_TO_ACCESS_BOBS_PICTURES, … … }
  • once printer.com gets this response, it stores this access_token and knows
    that it is used to access Bob’s pictures. Alice will have her own access
    token, once she goes through the same flow as Bob.
  • printer.com accessing Bob’s pictures now
  • Bob says he wants to print sunset.jpg on flickr.com
  • printer.com to flickr.com:
get: flickr.com/images/bob/sunset.jpg? access_token=ACCESS_TOKEN_FOR_PRINTER_TO_ACCESS_BOBS_PICTURES flickr.com verifies the access_token and knows it was given out to Bob, the image belongs to Bob, all is well and it renders the sunset.jpg image so that printer.com can print it.

Shown as a picture:

+----------+          Client Identifier      +---------------+
|         -+----(A)--- & Redirect URI ------>|               |
| End-user |                                 |     OAuth     |
|    at    |<---(B)-- User authenticates --->|    Provider   |
| Browser  |                                 |               |
|         -+----(C)-- Authorization Code ---<|               |
+-|----|---+                                 +---------------+
  |    |                                         ^   v   ^
 (A)  (C)                                        |   |   |
  |    |                                         |   |   |
  ^    v                                         |   |   |
+---------+                                      |   |   |
|         |>---(D)-- Client Credentials, --------'   |   |
|  OAuth2 |          Authorization Code,             |   |
|  Client |            & Redirect URI                |   |
|         |                                          |   |
|         |<---(E)----- Access Token ----------------'   |
|         |       (w/ Optional Refresh Token)            |
|         |                                              |
|         |>---(F)------ Send Access Token --------------'
|         |                Get back data
|         |                for end user
+---------+