Securing API for third party use

Question

We have a set of microservices and would like to expose endpoints from a subset of these for third parties to use. To this end, we will build an API Gateway that acts as the access control mechanism for all our services.

In terms of how access is controlled, I've thought about the following but I'm unable to decide on the appropriate solution among them:

A. API keys aka the standard way this is usually done. The disadvantage being that api keys can be stolen and used without us ever knowing.

B. Oauth2. I don't think this works for our use case as Oauth is the answer to accessing user data on behalf of the user. Our integration will require the third party to update us with periodic updates relating to an item the customer has ordered.

C. Have a db for third party user accounts, with signed JWTs that enable access. I see this as an implementation of the RBAC (role based access control) model. RBAC traditionally acts as a solution where there are a large number of users so with one third party user - this is potentially an overkill for a solution.

D. AWS' API gateway. I don't have personal experience with this to be able to judge how good of an option it would be, and also most of our software is hosted internally so the Gateway would need to route traffic to an internal server that's probably going to increase latency - if Amazon even supports this option.

--

Which option do you think works best? It doesn't have to be A-D. If there's further reading you can suggest, please feel free to do so.

Answer 1

I have found that usually the overriding concern with this kind of thing is "what does the third party support?"

If they are able to do stuff like oauth or client ssl certs, then great you can put in whatever the standard security library that your platform supports.

As with all security problems the answer is always to use a standard off the shelf package from a reputable source. There's nothing special about this interaction which requires an unusual approach.

However, you may well find that some of them can only do basic auth, some want FTP and some want to email you an 'encrypted' excel 97 file on the third Tuesday of the month from their home PC.

Answer 2

The big things to address are:

• non-repudiation: the user should be unable to deny that the actions are theirs. That means that the identity cannot be easily stolen by someone, and that the token provided can be validated that it is correct.
• auditable: you need to be able to determine if any users are behaving badly, and terminate access if so.
• controllable: that means that you can impose rate limits, reduce access privileges if necessary, etc.
• enforceable: or the authorization for a user to be able to perform an action is enforced.

To that end, there are multiple layers, and each of those technologies have a portion of the whole security posture in place. The good thing about OAuth is that it is standards based, making it easier for systems to build integrations. However, you can provide all those guarantees without using it if you really don't want to.

The API Key

By itself, the API key can be easily sniffed out and stolen if you don't use encrypted communications. That said, blindly using an API key also isn't the right solution. It's easy, but if there is any layer in the communications which exposes the key, it's also easy to impersonate.

At the very least you want to make sure that your API key is verifiable. OAuth does this by supplying the external system with a client id, and a secret key. There are specific rules for providing the client id and secret key, including the rule to encrypt communications.

With OAuth, the keys provided by the external system are used to negotiate a session token. The session token is then provided in the Authentication HTTP header as a bearer token. Nine times out of ten, the session token is JWT.

OAuth2

OAuth provides a very robust foundation to verify the end user, and provide a limited use session token for all further communications. If you are the provider generating the session token, then you can use JWT to embed the information your application needs to not only identify the user, but embed their roles and any other attributes you use to decide access. I do recommend signing the token.

DB for authentication access

This is an implementation detail. You can use a managed service like AWS Cognito, or Atlassian Crowd to handle all the nitty gritty details, and to keep up with 3rd party identity management solutions. Cognito has the added benefit of having control over the JWT session token that is generated for your purposes.

AWS API Gateway

The biggest benefit that API Gateway gives you is the ability to rate-limit API calls. If you are using AWS Cognito, that can associate your AIM roles with the user's token automatically, and that follows through the API Gateway. The AIM roles can be used to control which buckets you have access to, etc.

However, I don't see the Gateway as an enforcement layer. I see it more as a traffic control layer to help scale your application.

I'm trying not to be too prescriptive

As long as you have the traits discussed at the beginning of my answer, you will have done a good job securing your application. There are good reasons why OAuth2 with JWT session tokens are a common solution. They pretty much tick off the majority of your access control needs.

Answer 3

HMAC is an enhancement of option A that prevents your auth key from being stolen "over the wire", and provides protection from replay and message tampering attacks. It could be a good enough solution for your needs, but in my experience may place a development burden on that third-party if there isn't a ready-made HMAC implementation available on that platform. Bear in mind that HMAC only provides authentication of the message, if you need authorization you'd be adding some sort of id / permission lookup, in which case you may be better served with B or C, as detailed in Berin's answer.