Saturday, January 29, 2011

Mobile, Token Based Authentication

We've had some recent discussion on mobile authentication and thought it might be a good time to discuss how this works in the Where U At? application where we had white space to start fresh. For the most part we took a lot of insight from Twitter to use a token based authentication method, but not use OAuth. It's more of a service based OAuth that fits better in a paradigm where applications will interact as a service and want to tightly control the authentication service.

As everything in Where U At? it's a REST implementation that looks like the following (a few details are omitted):

  1. POST: /tokens
    1. Request Data
      1. email
      2. password
      3. manufacturerId
    2. Returns: Token
  2. GET: /tokens/{UUID}
    1. Returns: Token
  3. DELETE: /tokens/{UUID}
Behind the scenes we have a few objects that make this all work on the server.
  1. Token
    1. token_id
    2. expiration
    3. user_id
    4. device_id
  2. User
    1. user_id
    2. email
    3. name
    4. password (one way encrypted)
  3. Device
    1. device_id
    2. type
    3. manufacturer_id
    4. security_id
Any application can create a token (i.e. login) and store the token or token_id locally and reuse that. For any requests to our other services you simply pass an X-Token header with the token_id as the value. The other resources will validate the token is valid (i.e. that it exists and is not expired).

Any application can verify the token using a GET request if they so desire. Additionally, they can delete a token to perform a logout.

We follow a practice that only one user and one device can have a token active at any time. This means that if I login into my iPhone and then my iPad the token for the iPhone is deleted on the server. This works for us in a Location Based Application with push notifications to ensure only one device for a user is updating location at a time. It also ensures push notifications go to the right device.

A token_id has the same security behavior as a cookie based session id like every web app in existance these days and can be "stolen". To prevent this all requests are encrypted using standard SSL (not just login) so that only the server and device ever can see the token.

No comments:

Post a Comment