Five alternatives to Cognito M2M

Yan Cui

I help clients go faster for less using serverless technologies.

This article is brought to you by

Neon Serverless Postgres – the database you love, on a serverless platform. Build reliable, scalable applications faster with Neon without needing to migrate production!

Learn More

Machine-to-machine authentication is typically used when two systems need to communicate with each other. It is considered an enterprise feature and priced as such by identity providers. Cognito M2M, for example, charges $2500 per million auth requests. If you’re not an enterprise, then the pricing can seem extortionate!

But maybe you don’t actually need it. There are other ways to allow services to communicate securely with each other.

Here are five alternatives you should consider.

AWS IAM

You can use AWS_IAM auth with API Gateway for service-to-service authentication between AWS workloads.

It’s free, secure and scalable.

But it doesn’t (easily) work for non-AWS environments – you would need IAM Roles Anywhere [1] to obtain temporary credentials for your non-AWS workloads.

API keys

For simple use cases that don’t have a stringent security requirement, maybe API keys can suffice.

Add in scheduled rotation and notification (via webhooks), and you have a low-effort, low-cost solution that works well for low-security use cases.

Mutual TLS authentication

Mutual TLS (mTLS) is free and provides strong authentication for both client and server. It ensures that only trusted systems with valid certificates can communicate.

However, managing certificates becomes increasingly complex as the number of devices grows. API Gateway also has a hard limit of 1000 certificates or 1MB in a trust store.

Despite these limitations, mTLS is a good option for a lot of use cases.

Self-hosted IDP solution

Unfortunately, Cognito is not alone in charging a king’s ransom for M2M authentication. Other commercial IDP solutions (e.g. Auth0) also do the same.

Instead, you can host an open-source IDP solution such as Keycloak [2] or Zitadel [3] on EC2 or containers. You’d also need a custom Lambda authorizer to validate the JWT tokens.

This will likely be more cost-efficient than using Cognito M2M.

But you’re now responsible for the security, compliance, management and maintenance of the IDP solution and its infrastructure.

What you save on your AWS bill, you might spend (and more!) on engineering time and opportunity costs.

Whether this is a viable solution depends on the comparative cost of Cognito M2M compared to the staffing cost of hosting an IDP solution.

OAuth 2.0 Client Credentials Grant

You can implement a custom OAuth flow instead of hosting a whole IDP solution. If your use case is only to support machine-to-machine authentication, then you only need to implement OAuth 2.0’s Client Credentials Grant [4] flow.

A client registers with your authorization server and receives a pair of client_id and client_secret.

Once registered, it can authenticate itself to the authorization server by providing its client id and secret. The authorization server validates these credentials and returns a JWT token.

This is much lighter weight compared to hosting an IDP solution and gives you complete control over the authentication and authorization logic. You can easily include specific claims or metadata required by your application.

The main downside to this approach is that you can introduce vulnerabilities if the custom flow is not implemented correctly.

Links

[1] AWS IAM Roles Anywhere service

[2] Keycloak, an open-source identity solution

[3] Zitadel, an identity solution you can self-host or use their cloud offering (no extra cost for M2M auth)

[4] OAuth 2.0 Client Credentials Grant flow

Related Posts

Whenever you’re ready, here are 3 ways I can help you:

  1. Production-Ready Serverless: Join 20+ AWS Heroes & Community Builders and 1000+ other students in levelling up your serverless game. This is your one-stop shop for quickly levelling up your serverless skills.
  2. I help clients launch product ideas, improve their development processes and upskill their teams. If you’d like to work together, then let’s get in touch.
  3. Join my community on Discord, ask questions, and join the discussion on all things AWS and Serverless.