Microservices Authentication

Microservices & B2B Authentication – With AWS and Serverless (sls)

In the process of designing a good system, you must have heard of the term Microservices, where, in short, each microservice is responsible for a specific task or a group of heavily related tasks, and they communicate with each other to do the great job. During this process, a request that flows among these microservices needs to be authenticated. Of course, as you know, any not-authenticated request must be dropped. this is one case where the authentication is a must.

Another situation is when you want to deal with clients (a unique customer or a business), some clients want access to all your resources, some others want access to limited resources, and some others don’t want access at all. Generally speaking, there are different types of clients:

  • Business To Client (B2C): client is usually a normal user who wants to do the job manually where he goes to the resources, do some job, and leave.
  • Business to Business (B2B): refers to business that is conducted between companies, rather than between a company and individual consumers.

In software world, B2B is usually automated. For example, in Almeta, B2B client sends a URL to Almeta in order to be analyzed, our backend do it’s magic and a response is blurted out, normally in a JSON format. Then it can be squashed, minted and roasted on their server and served, in turn to their B2C or B2B clients.

So, in Almeta, and in order to serve our own B2C and B2B clients, everything should be authenticated. We use industry standard for this. We have to offer a robust authentication mechanism, and the most commonly used is API keys: You create one API key or more for each of our clients. This key will be used whenever the client approaches our resources in Almeta.

To do so, there are a couple of options:

  1. Do it in your own: create database table to store these API keys, and the logic to return, create, update, delete, or disable the keys. Not to mention managing Usage Plan in which you restrict access based on the client’s usage.
  2. Simply, find some cloud service to do it: if you use AWS, you are a lucky boy. Amazon API Gateway offers this feature out of the box, you just use them and it’s done. No need to deal with databases and all that logic. A good part too is that AWS offers SDK for all these things.

If you are dealing with microservices and the communication among them, should you use API keys connect them together?

Here we must distinguish among multiple things, let’s dive into them one by one.

Internal Microservices

Microservice are used internally and not exposed to the public. In this case, you don’t need to use AWS API gateway in the first place, but if so, you can use IAM role or IAM user instead.

Yes, AWS API gateway offers authentication using IAM user, you can create IAM users having AmazonAPIGatewayInvokeFullAccess permission, then send the credential in every request. API Gateway will handle the authentication for you.

A time saver note from AWS is:

If you use the API Gateway console to attach a resource policy to a deployed API, or if you update an existing resource policy, you’ll need to redeploy the API in the console for the changes to take effect.

Exposed Microservices

These are the services that are used by the clients directly. Absolutely you need to specify Usage Plan for each microservice, hence users must use different API keys for different microservices.

Luckily, AWS API Gateway offers usage plan alongside API Keys. Go ahead and create your usage plan, attach it to the resources you want, and it’s done.

Again, no need to worry about coding and maintaining all these stuffs, and interacting with the databases. Life’s awesome, thanks to AWS.

Microservices in Different Cloud Providers

There are many Cloud providers out there: AWS, GCP, Azure, etc. each one offers enormous services. You may find a service in a cloud provider that’s not available in others. As a result, you may find yourself using multiple services from different Cloud Providers. And that’s totally okey. For example, using AWS Step Functions with GCP Cloud Run.

But this leads to a tiny authentication problem i.e. how to authenticate AWS services with GCP services. These services are exposed to the public due to the fact that they are form different cloud providers but no one must use them other than you.

To overcome this problem, head over to the cloud provider you use, and search for the available authentication services offered. For example, API Gateway by AWS and Cloud Endpoints by GCP.

Infrastructure as Code (IaC)

We’re big in IaC in Almeta. To be honest, because developers love Infrastructure as Code aka IaC. Cloud Platforms have implemented such thing. In AWS case it’s called CloudFormation.

And to make life easier, Serverless Framework (sls), which we use in Almeta, is a treat for this: You write yml file that’s converted to CloudFormation understandable by AWS. Consequently, Serverless Framework supports API Keys authentication. Here is a simple example for demonstration purpose that shows how to use API Keys, Usage Plan, and the relation between them:

service: my-service
provider:
  name: aws
  apiKeys:
    - free:
        - myFreeKey
        - ${opt:stage}-myFreeKey
    - paid:
        - myPaidKey
        - ${opt:stage}-myPaidKey
  usagePlan:
    - free:
        quota:
          limit: 5000
          offset: 2
          period: MONTH
        throttle:
          burstLimit: 200
          rateLimit: 100
    - paid:
        quota:
          limit: 50000
          offset: 1
          period: MONTH
        throttle:
          burstLimit: 2000
          rateLimit: 1000
functions:
  hello:
    events:
      - http:
          path: user/create
          method: get
          private: true

If you’re familiar with Serverless framework, you will understand all the code. but if you are not but you’re interested in it, please visit the documentation page which is fully-contained and easy to understand.

There are three important points in the code above. First, we define our Usage Plans in usagePlan array property in provider object and we defined two usage plans: one is free with 5000 requests monthly as a limit and the other is paid with 50,000 requests monthly.

Second, we define ApiKeys array property in provider object in order to define our API Keys but because we want our API keys to subject to Usage Plan, we first use the usage plan name as the object key, then we add our keys under it.

To put it simpler, we defined two API Keys in each Usage Plan with predefined names and their values are left to API Gateway to specify them. you can get their values by visiting API Gateway service or by watching the output of Serverless framework when deploying that’s to say Serverless framework will print the API Keys after deployment’s done successfully.

Thrid, we mark the Rest API as private explicity which means this Rest API needs an API Key when calling it and that key must be set in the x-api-key header for the request.

API Gateway – API Keys Limitations:

  • API Key can’t be attached to more than one Usage Plan on the same stage.
  • Quota limits are always increased despite the response status code in addition there is no easy way to control it.
  • You can’t specifiy free tier for each API Key. that’s to say, each API key has pre-defined limits only but you can increase the limits with some free limits by adding it to the key limits. For example, if some key has 10k requests limits per day, you can make it 11k requests limit with 1k as free tier, but you can’t add such thing called free tier explicity.
  • Usage Plan is always attached to one stage.
  • API Keys are not attached to an actual user, it’s up to you to do the mapping.

As we explained earlier, API Gateway offers different types of authentication: IAM user, API keys, Congito which offers OAuth2, or custom authorizers using Lambda functions, so does GCP Endpoints.

In this way of connecting Microservices, you can use API keys, IAM user, or any other type of authentication that fits microservices.

Simple Implementation Steps:

That’s for API Gateway, now let’s see the steps of how we can implement the same logic in our own:

  1. Create a table for API Keys.
  2. Create a table for Usage Plans.
  3. Create a table to track each API Keys usage based on the Usage Plan.
  4. Create a table for the (API Keys and Usage Plan) relationship in order to allow one API key to be available in multiple Usage Plans.
  5. Create custom authorizer: which gets the api key from the header, verify if it’s valid and stored in API Keys tables, and it’s in its valid limits in the tracking table.
  6. Increment the usage for this API Key somehow in order to know whether it’s reached its limit or not.
  7. Create a microservice to manage all these stuffs: verification, increment, creation, update, etc.
  8. Last but not least, maintain this microservice.

There is much work to get the same feature offered by API Gateway done and don’t forget the cost. API Gateway doesn’t charge for the authentication, it just bills per request. But if you implement it in your own, you have to pay for the services you will use. In contrast, you will have the control over it which means you can customize it the way you like, not to mention the amazing adventure you will have while implementing it 😀 .

Pricing

AWS API Gateway is pretty cheap, you pay $3.5 per million requests or so based on the region you use. And if you have high traffic, you pay less. It also comes with AWS free tier for new customers where you get one million API calls for free for 12 months.

Number of requests per month Price per million
First 333 million $3.5
Next 667 million $2.8
Next 19 billion $2.38
Over 20 billion $1.51

Whereas GCP Cloud Enpoints offers 2M requests for free and $3 per million requests after that:

API calls per month per billing account Cost per million API calls
0 – 2 M $0.00
2M – 1B $3.00
1B+ $1.50

See how cheap they are; given the features they offer.

Conclusion:

Authentication for B2B and Microservices is a must, and must be robust.

Many cloud providers implemented it with high flexibility allowing developers to focus on the actual implemention of the applications.

As we can see, API Gateway offers almost all the things needed to handle microservices and B2B authentication, so no need to implement and maintain such thing and that’s our choice in Almeta.

Sources

Leave a Reply

Your email address will not be published. Required fields are marked *