/
Develop OAuth Server [5.3.0]

Develop OAuth Server [5.3.0]

Owned by Alex
Mar 09, 2015

Days, when username/password combination needs to be stored to integrate 2 websites are long gone. Nowadays using OAuth is more preferable and secure.

The OAuth works like this:

  1. WebsiteA (that wants to get some data) has a link, that user clicks in the browser and is redirected to WebsiteB (e.g. Facebook)
  2. on WebsiteB (e.g. Facebook) user requested to login (if it's not already)
  3. WebsiteB (e.g. Facebook) user is presented with permission screen, where he sees:
    1. the requestor website (WebsiteA)
    2. types of data that needs to be accessed (e.g. username, e-mail, friends, etc.)
  4. user accepts the requested and a token is generated, which allows to access only that data
  5. then this token can be used even outside of browser to perform needed activities on user behalf

Pros

  1. user's username/password is never stored on 3rd party server
  2. token can be easily revoked without need to reset account password
  3. token requestor only has access to data, that is allowed for individual token and not all website data that user, who issued the token has
  4. token-based logs can be collected to determine how it's being used

The OAuth was there for quite some time and there are plenty of open source libraries, that can be used to develop a server. This one sounds very promising: http://bshaffer.github.io/oauth2-server-php-docs/.

Solution

From implementation viewpoint I see this like this:

  1. we create login-protected page in Admin Console (won't use frames), that will allow user to confirm external application requests
  2. we create several endpoints (special URLs) in Admin Console, that will be used to request tokens in a safe way
  3. for now implement only "basic_info" scope, so that token can be used only to confirm user identify and retrieve it's firstname/lastname/e-mail
  4. improve sessions:
    1. store session expiration time (1h by default) in session record
    2. when token is issued, then store it's ID (we store tokens in separate table along with scopes) in the session
  5. when token is given in request headers consider it a valid session identifier and create/load the session
  6. token associated sessions will either have very long expiration or will match to token own expiration date

Related Tasks