Recommendations on Certifying API Clients - please share your experience!

Hi all,

Consider that I have an API Program, in which Client Application Developers can register in my Developer Portal for credentials to use a sandbox. They can use this sandbox to develop their Application against our APIs and there will be no impact if they make a mistake. Once they have completed development, they will require production credentials. Depending on the nature of the APIs, there may be security/performance concerns that mean you would like to Certify each client individually before giving Production access.

Possible options:

1) Perform a code review of their application

Pros:

- You can have 100% certainty on how they interact with your APIs

Cons:

- Source code access may be limited

- This manual process may take a VERY long time

- The review must understand the clients programming language/framework

2) Record and review an Apigee Trace session as the app performs a user journey

Pros:

- No knowledge of the client is required

- Easy to identify redundant or erroring requests

- Can be performed by any API developer

Cons:

- Still a manual process

- May not have 100% coverage of API usage

3) Create a tool to automate the certification process. This could be done by running a trace session and analysing the requests. The production credentials can be generated if this process passes

Pros:

- Less time for the API team to spend manually reviewing client requests

- Quicker for the Client Application to get feedback and improve their code

Cons:

- May have a very high overhead for the development team to create/maintain the tool

- Issues may be missed that are easily spotted by a human, if there isn't a rule in place

Any thoughts on best practices around reviewing client API usage and whether there is value in automating the process? Instinctively, I feel this would only be valuable if there were 100s of clients request access each week. It would be great to hear others experience

Thanks,

Sean

1 1 187
1 REPLY 1

Not applicable

All three approaches are problematic in so far as the API provider has no persistent visibility to or control of the app/consumer. Security reviews are valid for that version at that moment and should not be relied upon to be an accurate representation of any future state of the consumer. Here is my advice:

  1. Don't rely on the consumer for security. Rather build your security protocols into the API. TLS only, HMAC support, short lived OAuth tokens with refresh support, etc. Build all this into the API.
  2. Provide app developers with a full featured SDK which demonstrates app best practices for security. If you provide them executable samples it is much more likely that your partners will adopt your practices.
  3. Analytics matters - use analytics to observe ongoing patterns of access (volume, user agents, geo locating consumers, etc) and proactively reach out to partners if you observe significant deviations.
  4. Advance concepts like geofencing consumers can and should be implemented in the API tier if this is a concern.

Overall, unless you own the app distribution mechanism (via MDM, or you own the app store) you have no assurance that what you reviewed is what is being used in the wild.