Machine to Machine

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.

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 wicked.haufe.io, 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 wicked.haufe.io functionality, as described in the section above on "development time" usage.