Skip to content
monken edited this page Aug 9, 2011 · 7 revisions

Work in Progress

api.metacpan.org implements an OAuth 2.0 Server and holds the user data. It helps a great deal to be familiar with the spec (http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-4.1).

The user data consists of

id

Unique identifier for the user

identity

List of authentication providers the user has authorized against. Each entry consists of:

  • name

    Name of the authentication provider (twitter, pause, facebook, et al)

  • key

    Key provided by the authentication provider that identifies the user

  • extra

    Extra information that is available from the provider

access_token

list of access tokens for each front-end the user is connected with

code

holds the temporary OAuth code

The authentication process works as follows:

  1. The user clicks on "Twitter" as authentication method on metacpan.org
  2. She is redirected to api.metacpan.org. The query string includes client_id=metacpan.org
  3. The client_id is stored in a temporary cookie on api.metacpan.org
  4. If the user is already logged in on api.metacpan.org and the a twitter account is already connected to his account (i.e. included in the identity property), goto 6.
  5. Else (the user is already logged in but is not connected to a twitter account or he is not logged in on api.metacpan.org), api.metacpan.org does the OAuth2 handshake with twitter:
    1. The user is redirected to twitter and the user authorizes api.metacpan.org to use its user data
    2. The user is redirected back to api.metacpan.org
    3. api.metacpan.org looks up the unique identifier received from twitter in the identity property of all users
    4. if it finds a match, it logs in the user with the twitter account attached to it
    5. else, the twitter account is added to the identity property of the current user
  6. The temporary cookie from (2) is read and the user is redirected to the deposited redirect uri for the client_id metacpan.org. The query string includes a code (stored in code).
  7. metacpan.org will then verify that code by doing a server-side request to api.metacpan.org. If the code matches, metacpan.org receives an access_token from the api, which is both stored on metacpan.org in the session cookie and on api.metacpan.org in the access_token property, along with the client_id.

Using PAUSE as log in provider

Step 5 changes to:

  1. api.metacpan.org generates a random hash and stores the user id/hash tuple in a cache.
    1. The has is sent to the email address of the pause id that was supplied by the id query parameter
    2. The user receives the email and clicks on the link
    3. goto 5.4, unique identifier is the PAUSE id, s/twitter/pause/g