API Security: On-behalf of, delegated trust, and insecure

Over the last couple of years and on a few different projects a growing portion of my work has involved looking at API (and WebService) security. It's got me in a reflective mood, thinking about all the different ways I've seen the AAA (Autentication/Authorization/Audit) part of security achieved during my 12 years in Integration/SOA/Webservices /APIs. The truth is that every project I've worked on has fallen into one of three broad patterns...

On behalf of

The "on behalf of" pattern is where an API/Webservice is invoked by a system on behalf of a specified user. A great example of this is the OAuth2 model. The end user Authenticates with a login system and the client application is given an "Access Token" in order to access services on the user's behalf. The client itself doesn't have any rights other than those given by the token, and doesn't ever see the user's credentials.

The Access Token is then presented to the API with every call, and the API performs fine grained Authorization and keeps the Audit trail. Due to the inherent risks of maintaining any credentials on a mobile app, and the potential for users of an app to accept invalid HTTPS certificates this is really the best and only recommended security for APIs used by systems/applications outside the enterprise.

Delegated trust

A common pattern for services only used inside the enterprise is Delegated Trust - essentially where the system calling an API/Webservice uses a service account (or other form of Authorization such as mutual TLS) to identify themselves. The API then trusts that system to do things for any user. In this case the API delegates the responsibility of doing user level controls, and trusts the client system to do it correctly. This also means any audit records need to be kept by the calling system.

There's nothing inherently wrong with this pattern, and at times it's the only option (e.g. in situations where the activities are not triggered directly by a user, or when a COTS package doesn't allow an alternative); but it's worth considering the downsides:

  1. APIs secured using something like OAuth can immediately be reused by other systems (e.g. an API used by a website can be reused by a mobile app). An API using Delegated Trust needs refactoring to use 'on behalf of', or the same logic needs to be built into each client.
  2. Delegated trust means that authorization logic, and audit logs are split in multiple places. The former can make managing authorization rules more difficult (leading to cost and potential errors), the latter can make SIEM threat detection harder. 
  3. Security logic ends up residing in multiple places, and potentially in layers it shouldn't be. Just as we separate business from presentation logic; isolating security logic into a clear area can provide a simpler, more reusable, and more easily testable solution. Having security logic all over the place can lead to developers making mistakes and creating security holes.
  4. In addition to developer mistakes, this leaves a lot more places where malicious software can be introduced by developers, as now any code deployed to any trusted application can access services with impunity.

Network Security, AKA Insecurity

What's really shocking that I still occasionally see the third pattern (or rather anti-pattern), of enterprises relying on "Network Security" to protect services. It's been a while since I've heard "everything is inside our data centre so we're OK"; these days it's mostly "we know it's not ideal but that's the way it is". 

Network security is of course an important part of any security in depth strategy, but I don't need to dig out statistics about insider threats to demonstrate that an assumption that "it's inside the firewall so it's safe" is fallacious. Not only can all insider applications not necessarily be trusted; but there are a lot of unsaintly people in any large organisation. Some are open to temptation, others may hold a grudge. 

Even assuming complete trust of everyone in IT operations (which one shouldn't), a surprising number of organisations operate flat networks - so anyone with a network account can access servers. This could be receptionists or call centre workers; or this could be the Chief Exec (and who says they're above reproach?). Without strict access controls at every level, and good audit trails, everyone is suspect... even me!

There is hope

Fortunately things seem to be improving. Firstly "The Cloud" is breaking apart data centres, and whilst it rather misses the point to think that it's only now insecure (it always was), at least people are starting to question if that big friendly firewall which "keeps out the nasty people" is really good enough.

Secondly the rise in Apps, and using APIs outside the enterprise is causing people to think about this seriously, and in some cases jump straight from Network (No) Security straight to On Behalf Of security. At that time the introduction of API Gateway software to support this offers an opportunity to at least retrofit service accounts to APIs/Webservices at relatively little cost.

As with other poor practices such as logging personal data, and keeping Credit Card Numbers in unencrypted databases, hopefully this is an area which will soon be rather embarrassing history.