3

I'm trying to figure out the best way to deploy an API in Amazon API Gateway. I'm getting totally confused about the appropriate authorization to use.

The API will be used by our customers for their own custom developed apps.

We don't need to provide end user authentication. This will be handled on a by our customers, based on the specific requirements for their apps.

What we need to do, is provide a way for our customers apps to authenticate against our API.

My understanding is that I have the following options...

  1. AWS_IAM - This may not be appropriate, adding customer credentials to our Amazon account.
  2. Cognito User Pool Authorizer - This seems to mostly be designed for user authorization, rather than client authorization.
  3. Custom Authorizer - Presumably can be tailored to our specific requirements, but would need a lot of code to be built from scratch.
  4. API Key Authentication - Quick and easy, but doesn't seem particularly secure, to simply rely on a key header.

I had originally assumed, that there would be some straightforward way to enable OAuth2 Authentication. For our use-case, the "Client Credentials" flow would have been suitable. However from the research I've done, it sounds like OAuth2 Authentication would require a Custom Authorizer Lambda. I'm really not keen on the idea of having to implement a full OAuth2 service, to authenticate the App. It will simply cost too much to build something like this.

Also if we're writing our own full custom OAuth2 Authorizer, and writing all of the functionality for the API itself, I'm not sure how API Gateway is actually providing us any value.

Is there some best practice, or standard for authenticating API clients for API Gateway?

What we need to do doesn't seem like a particularly unusual thing, there must be some standard way people do this.

Any suggestions would be very much appreciated.

user1751825
  • 4,029
  • 1
  • 28
  • 58
  • One of the points of a custom authorizer is that it is reusable across functions and that its results can be automatically cached, minimizing processing time. API Gateway's value that it provides an infinitely scalable, managed, pay-only-for-what-you-use infrastructure. It seems like you may be overestimating the complexity of writing one. – Michael - sqlbot Sep 12 '17 at 12:34
  • do i understand your use-case correctly: client app calls instance of your API Gateway which routes to the same client backends? what's added value for customer having yours in-between? on options you mentioned: 1) API keys must not be used for authentication - these are for usage policies and monetization; 2) on AWS IAM - not sure it'll be necessity to maintain credentials on aws - you could setup federated identities (you client as identity provider) and issue short-term STS tokens; 3) with custom authorizer my feeling is that you don't leverage AWS native tools – Nicholas Sep 12 '17 at 21:55
  • Thanks @Nicholas, this is helpful advice. Our setup is. Heroku based hapijs rest api, exposed through AWS API Gateway. Our customers will build their own app clients, which will use data from our API. We want a way to create, manage, and authenticate credentials for our customers. It's only really client authentication we're interested in, our customers will manage their own user authentication where required. – user1751825 Sep 13 '17 at 00:53
  • @Nicholas The federated identities through AWS_IAM sounds like it might be what we need. The ideal setup would be to use our AWS Directory Services AD. I just haven't been able to find any resources about how to set this up. Any pointers would be very helpful. – user1751825 Sep 13 '17 at 00:57

0 Answers0