Machine to Machine

Handling machine to machine communication with

Use Case Description

One of the most basic use cases for an API Gateway is to enable simple machine to machine API access, including self service aspects for the developers needing access to a specific service. The special case for machine to machine communication is that usually no end user is part of the communication, or that the an end user's identity and rights have been established up front.

Typical examples of services which leverage machine to machine type communication are backend services which deliver value for other applications, such as licensing services, product management services or other types of data management systems which are either intended for pure backend purposes or for which the client applications are trusted to have already authorized an end user for using it.

These types of APIs can either be secured using

  • API Keys, or
  • OAuth2 Client Credentials

From a security perspective, the methods are more or less identical, and it's a matter of taste whether you want to leverage the very simplistic "API Keys" approach, or the standard OAuth2.0 flow, which exchanges client credentials for an access key.


Workflow Description

A typical development time usage workflow will be like this:

  1. A developer needs, for a specific application, access to an API which is surfaced using the API Gateway
  2. The developer registers the application in the API Portal
  3. For this application, the developer subscribes to the backend API for which access is needed
  4. The API Portal returns (if the developer has sufficient rights) either an API Key, or Client Credentials, depending on the type of authentication of the API
  5. The developer adds these credentials to his application (server side!) to get access to the API

At runtime, this means that the maintainer of the backend API can immediately see which applications are accessing his API, and has a means of contacting the maintainers of these applications, and/or create statistics on the usage of his API.

Please note, that this authentication and authorization method is only suitable for trusted server-side applications. The issued credentials (API Key or client id and client secret) must at all times be kept safe by the client application.

How do I implement this with wicked?

Securing APIs via API Keys or the OAuth2.0 Client Credentials Flow is both possible "out of the box" using, no additional components are needed:

  1. Register your API with the API Portal in its static configuration, and specify the backend end point
  2. Make sure that only the API Gateway is able to directly call the API backend end point, e.g. by fencing off network traffic, or by implementing other means of securing the backend access (client certificates, basic authentication, not exposing the end point to the public internet etc.)
  3. Deploy the changed/updated static configuration to your environment.

Now your developers can sign up for the API using the standard functionality, as described in the section above on "development time" usage.

Back to top

© 2016-2018 Haufe-Lexware GmbH & Co. KG,,,,