Comments on “ API Authentication Model ”

API Authentication Model

2008-06-05T20:57:25-04:00

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.

API Authentication Model

2008-06-05T20:20:11-04:00

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

API Authentication Model

2008-06-05T19:18:09-04:00

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. :-)

API Authentication Model

2008-06-05T19:12:37-04:00

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.

API Authentication Model

2008-06-05T19:09:52-04:00

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.