This is third part of ProgrammableWeb’s series on Understanding the Realities of API Security. It is based on the testimony offered by ProgrammableWeb’s editor-in-chief David Berlind to the ONC’s API Security and Privacy Task Force. In the previous part -- Part 2 -- Berlind answers the following question posed by the ONC: Do You Publish API Docs Online For Availability To Third Party Developers?
Hopefully, the previous explanation of LSUD vs. SSKD sets the stage for answering this question. Under the LSUD approach, an API provider hardly discriminates against who can get access to the API. API access is largely a self-service process and the choice to take an LSUD approach is very much governed by the API provider’s business objectives. These objectives often range in purpose; everything from driving additional revenue (when there’s a hard dollar cost for using the API) to driving innovation. Generally speaking (not always), an API provider taking the LSUD approach does not concern themselves who can and who can’t get access to the API. There are caveats to this “rule” however. Salesforce.com is an API provider that largely takes the LSUD approach. The company has reported that more than 60% of the transactions with its application infrastructure are API-based. However, before a developer can interact with Salesforce.com’s APIs in a production environment, that developer must become a customer of Salesforce.com.
One important footnote to the LSUD approach is that there may be different tiers of developers. For example, there may be a free tier that provides developers with limited access to an API. And then there may be a variety of other tiers, each of which further diminishes the limitations to API access. The important thing to note here is that it’s not just about who has access to an API, it is also about the degree to which they have access to the API. This degree of access can impact everything the number of allowable API executions over a given period of time to the scope of access to the underlying resources. For people who are familiar with typical IT infrastructure, this is often described in terms of who can authenticate, and access control (what resources they have access to, based on who they authenticated as).
Like the LSUD approach, the choice to take the SSKD approach is largely one that’s driven by the API provider’s business objectives. In an SSKD approach, the small set of developers can include external developers, internal developers, or both. But in all cases, the API provider usually knows exactly who has access to its APIs and for what reasons. If it sounds like a far more intimate relationship, it is. For example, Walgreens sees APIs as a way for the company to advance the objectives of its loyalty points program. Through the API, a Walgreens customer’s loyalty card can be updated by certain activities; everything from making a Walgreens purchase to a blood pressure check. But the program is exclusive to Walgreens internal developers and a set of partners that Walgreens has chosen to help it log the behavior (eg: exercise) of its customers. This approach is very decidedly an SSKD approach whereby all the developers are known and the company’s relationship with each developer (internal or external) is very intimate.
Worth noting: in an SSKD approach, it is far easier for the API provider to set and enforce certain security standards to which all developers (internal, partners, etc.) will be held.
In the next part -- Part 4 -- of ProgrammableWeb’s series on Understanding the Realities of API Security, ProgrammableWeb editor in chief David Berlind answers the following question posed by the ONC: Must Developers Be Certified For Privacy or Security Standards By Your Organization?