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.