3rd party API access: Is OAuth really required?

Question

Having a web application with a REST API (say, our-app.com), we want to open our API to 3rd party web applications (say, their-app.com). After some research, having read about OAuth, OpenID Connect, etc., I doubt if these are really required for our intended use. I think that the simpler implementation described below might do the job as well, extending our existing session-based login mechanism.

More exactly, we want to achieve the following:

• The user has an account for our web application our-app.com, and is logged in.
• The user visits their-app.com (in the same browser).
• The user agrees to share her/his data with their-app.com.
• Now, their-app.com can make authenticated cross-origin AJAX API requests to our-app.com. Since the browser sends the existing session cookie, no separate login is required if the user is already logged in on our site.

Can you please review my suggested implementation, and point our security flaws or other disadvantages? What benefits would we get from using e.g. OAuth instead?

• Their-app.com registers for using our API. As a result, "their-app.com" is added as an allowed CORS origin to our database.
• A user visits their-app.com in her/his browser.
• TheirApp requests https://our-app.com/me to find out is the user is logged in.
  • Technically, this is a "withCredentials" AJAX request.
  • Since their-app.com is a registered origin, this cross-origin API call is allowed by our web servers. (All CORS requests from an unknown origin another-app.com would be rejected.)
  • If the user is not logged in, or if the user is logged in but did not yet grant access to their-app.com, the response will include a URL. This URL points to our login page (say, https://our-app.com/login?origin=their-app.com). TheirApp should then open this link in a new tab, to allow the user to login.
  • The login page will ask for username/password (if not yet logged in), resulting in a session cookie being set, and then ask something like "Do you want to allow their-app.com to access your data?" Since all this happens in a separate tab, the password is safe from being observed by their-app.
  • If the user grants access, an entry ("their-app.com", userID) is added to the database, to remember her/his decision.
• All cross-origin requests to our API are handled this way:
  • First look up if the origin is registered. If not, reject.
  • Then look up the user's session if a session cookie was provided.
  • If a user is logged in, but did not yet grant access to the origin, we reject the request, returning a link as described above.
  • If a user is logged in, and has already granted access to the 3rd party, then we process the request in the same way as same-origin requests from our own web app.
  • If not logged in, only public data can be accessed.

Answer 1

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.

Answer 2

I didn't read all the details you wrote, I just want to make a general observation: you're planning on re-implementing part of an existing standard. Most likely, in a few months you'll realize you need another feature and you'll have to re-implement some more of that standard. Unless you're a genius cryptographer with a dedicated team of reviewers, there's a good chance you'll make a mistake (or lots of them) along the way, either in the design or the implementation.

And on top of that you're forcing all the 3rd parties to learn something new that's unique to your site. So a 3rd party who already knows how to integrate OAuth doesn't derive any benefit from their knowledge and has to spend a lot of time learning your scheme instead of just getting the job done; if they don't already know OAuth they don't get the benefit of learning it right now and being able to reuse that knowledge next time. Either way, the 3rd parties have to spend time learning your unique method of authentication instead of developing cool new features: so why should they develop something that helps you instead of developing something for one of your competitors who made integration easier?

NIH is a bad trap to fall into. Just use what's already out there.

Answer 3

Besides the more business-oriented answers already given, I think there is also a technical benefit from using OAuth:

Once the 3rd party app (OAuth client) has obtained the OAuth access token, they can use it to make requests both from the browser (e.g. using AJAX requests), and from their backend. (Correct me if this is wrong...)

With the custom solution I had proposed, only requests from the browser would be possible: The 3rd party app never gets any access token, it just implicitly uses the session cookie of our website without ever knowing it. This would reduce the power of our API, since it would force developers into a particular architecture. The browser would always be required as "proxy" to pass data between our and their backend.