API Authentication Model

Posted on Thursday, June 5th, 2008 at 11:36am by Rob Wilkerson

So I’m in the process of modeling a few applications that will include a fairly rich set of APIs and I had some time to spend really thinking through how I want to design the authentication model. After thinking about it for a while, I decided that, well, I can’t decide. As a result, I thought I’d call on any collective wisdom I can gather and see what others are doing and, perhaps more importantly, why.

First, let me state that these applications are not DoD(Department of Defense)-grade applications. We need something stronger than security through obscurity and something (significantly) less than national security cryptography.

The two options I’ve considered thus far are:

Explicit Authentication and Session Persistence

This method would mean exposing an authenticate API and then establishing a persistence mechanism to allow authenticated “sessions” to call other APIs without having to re-authenticate – at least not for some period of time.

At this point, this model just doesn’t feel right to me. It feels like an application authentication model that’s been forced into an API context. Square peg, meet round hole.

Implicit, Non-Persistent Authentication

This method would mean creating some sort of authentication process, but not exposing it as an API. The idea would be that the system consuming the API would call the API that it needs, for example getThings(), and pass authentication credentials to that API. The API, then, would call the internal authentication process to validate those credentials before executing its core functionality. Authentication, then, would be done for each call, but reasonably transparent to the developer.

I’d appreciate any insight into what others are doing, any prevailing wisdom that maybe I haven’t read or any other thoughts some generous reader may care to offer.

, , 5 Comments

Subscribe5 Comments on API Authentication Model

  1. Matt said...

    I use a model where the user authenticates with username/password, and is returned a valid sessionID, which they can reuse to access methods until it expires.

    It uses the login time, username, and IP address with a SECRET VALUE to generate an md5 hash which is the sessionID. This means they are non-sequential, and unlikely to be guessed.

    Session hashes are stored in a database table, which is looked at when a session has is received as part of a non-login request, and the user is selected from this if the has is valid.

    Oh, and all of this is done over an SSL connection. It is up to the client application to store the session hash/key/id, and attempt to re-login if an invalid session message is returned on any future request.

    ...on
  2. Matt said...

    Oh, and for why?

    Previously we had a system where the client application sent username/password, and then received a series of IDs, which correspond to userID, groupID and companyID. It would be trivial for a client to be hacked to bypass the login sequence, and attempt to access data with just an ID. Which could mean they could access administrator data if they chose the right ID.

    ...on
  3. Rob Wilkerson said...

    That sounds inline with how I would expect my first option to execute, though I’d probably just use a md5 hash of a UUID (for convenience).

    Both ways – at least the way I’m conceiving them – have some useful pros and some annoying cons which is why I was hoping that there was some governing body of API authentication models that could say, “Do it my way because my way is good and doing it any other way is punishable by public flogging.”

    That kind of authoritative response would relieve me of an awful lot of responsibility for the solution I choose. :-)

    ...on
  4. Brad Greenlee said...

    This may be overkill for your needs, but check out OAuth: http://oauth.net/

    ...on
  5. Rob Wilkerson said...

    Thanks, Brad. I’ve actually considered oAuth, but as you suggested, I found that it was a little over the top. Or maybe I was looking at it the wrong way. oAuth felt more like an interface-to-application solution rather than a system-to-system solution.

    I’m not sure that explained it very well, but I can’t think of a better way to phrase it at the moment.

    ...on

Leave your own comment or...subscribe to those of others

Formatting may be applied to comments using Textile markup.