Is OAuth Really Required for 3rd Party API Access?

Is OAuth Really Required for 3rd Party API Access?

It all comes down to the old adage: “Good IT security is hard“.

While none of the concerns are known by us here to be fatal (we can’t know your whole business and client model), they do raise serious doubts or at least things to really think hard about, and are worth taking soberly.

• Flip it round and look at your users’ perspective. You are asking your users/customers to invest their time/money/resources in learning and leveraging your API (use-case: one supplier) vs. a standardised well-known API (use-case: many). If you cease activity their effort is wasted. If they want to reuse their own work they cannot as easily transfer or reapply it without additional and perhaps prohibitive work which they can avoid by not adopting that path at the start. There’s a reason open standards are open – they may not suit everyone, but they have other advantages in the wider picture.

• They will also be concerned how certain they are of this concept’s long-term benefit to them as users. They may consider and evaluate the durability of your business, your approach, your commitment to this path, and their commitment to your commitment to this path, and they will at some level evaluate how certain they are that you and the product and their use of the product will all still be around in years to come (many aren’t). What about interoperability? Perhaps it will be a concern whether their other suppliers care to include some lesser and proprietary API or a well-known one they can sell as a feature to other users of theirs, or whether data can be got out into other packages without having to write “shims” for each one. Will they want the maintenance burden or doubts this might raise?

• Third, even if people might be keen for it, consider this too: what basis do you have for believing your approach would be more securely implemented than existing versions? That’s not the same as “more securely designed”. A home-made setup might be far better adapted and suited for your needs but are you confident you have the competence and skills to both design, and develop an implementation of that design, that will stand up to the real world of ITSec? Even if you think you can, would third parties whose trust you seek to use it, agree with you completely?

• Fourth, consider that a framework that has its own developer focus, may respond more quickly and dependably to changes in the security world affecting it, or on the positive side, emerging new standards/developments. Do you have the resources in your business to commit to maintain a focus on keeping it up to date continually, once produced? (You might, you haven’t described the business). Plan for a bigger resource drain than expected.

Your question wording is telling, and should be the final piece you need:

I >>doubt if these are really required<< for our intended use. I think that the >>simpler implementation … might do the job as well<<

In other words you seem unconvinced yourself that there is any real downside except that they may have extra features and competencies you don’t need. But even so it might still be worth using the package even if you don’t need all it has, because of its other many advantages of doing so. After all, few people use “most” features of any major software (the humble MS Word through to Apache web servers being quick examples) and yet the software is used, just not all features.

As a business, your aim is likely to be based on confidence (yours+clients), speed and cost/time efficiency. For most businesses considering a security need, a ready-made solution might routinely beat home-made proprietary hands down on all major fronts, even if it is more than they need today.