Consulting & Innovation
Solutions & Products
Infrastructure & Operations

API development

Service as a service

APIs are the new products

In the era of the cloud - and SaaS products in particular - the development and deployment of APIs is becoming increasingly relevant: APIs are the new products, because we don't need an app or a website for every service.

The development of APIs

Those who now want to offer an API or a service themselves face some challenges. The usual difficulties that services already cause within projects are intensified once again, since end customers are expected to work with them for a long time. They must be reasonably maintained and documented, as well as protected against unauthorized access, published, further developed and also billed.

It is recommended to enrich your service with existing services ("Services as a Service") and thus to achieve the separation of professionalism and organization. In our specific case, the service should only fulfill its (technical) task and do so as well as possible. We do not want to deal with user administration, the generation of subscription keys or the construction of a gateway. For this purpose, I combine two Microsoft products: Azure API Management as a platform for publishing my APIs and Azure Active Directory B2C for managing API users.

Azure Active Directory B2C (Azure AD B2C)

Azure Active Directory B2C is a cloud-based, fully-managed system and is used for identity and access management for end customers - in our case, customers of our API. The idea behind this is that the end customers of a product or SaaS solution can manage themselves and are maintained separately from the company's own Active Directory.

The Azure AD B2C therefore supports various identity providers from social networks - such as Facebook, Google, Microsoft, Amazon and Twitter - but also the registration with an own mail address. New users can also be created manually or a connection to the company's own Active Directory can be established.

The administrator of Azure AD B2C decides whether end users can use customizable pages for sign-up, sign-in or even profile edit.

Authentication/ Authorization

Various tokens can now be generated for authorization via Azure AD B2C. The tokens are supplied with the web requests as JSON web tokens (bearers) and the application checks their validity. The .NET Framework and other providers offer various libraries for this purpose. With .NET Core, the AddAzureAdB2CBearer extension is delivered and added directly for this purpose. It makes contact with the Azure AD B2C and checks the validity of the tokens. More than the annotation [Authorize] via the class or function is not needed.

However, authentication can also be more complex. Instead of an access token, an ID token can be generated that represents the specific user, or the user's own claims can be included in the tokens, which are used for the check.

Who may do what?

Authentication is usually not the end of the story: Which user is allowed to call which API parts? How many calls do I allow? Or am I perhaps aiming for usage-based billing? I would have to develop all that. More simply, I don't. I save the code for authorization and use ready-made services to secure my API and log accesses. This is the moment when API management enters the stage....


API Management (APIM)

Azure API Management is used to publish APIs to be used by internal or external developers. It also provides some other functions such as configuration and protection of the API as well as analysis of usage behavior. The APIM consists of three components - a gateway and two portals.

The gateway serves as the entry point for any developer. All requests from the APIs pass through it, are checked and logged there. The gateway controls the approved usage quotas, tokens or transforms calls according to configured policies.

The Publisher Portal - also called Admin Portal - provides an administration interface for the APIM. APIs are imported and modified via this portal. The configuration of the API, the accesses and the data flows through the gateway to the backend are also adjusted here. Furthermore, the users for the developer portal and the configuration of the bookable product packages are defined here.

The developer portal resembles a web presence of the API for the developers who ultimately use the interface. Similar to Swagger, the individual functions and their response types are listed. In addition, direct test calls with preconfigured or generated parameters are possible - but only for subscribed APIs and always with access checks. Furthermore, companies can use the developer portal to present their offered APIs with the help of blogs, issue management, classic CMS and graphical customizations.

Grafik API-Entwicklung

API administration

To add new APIs, you can start from scratch or import an existing API (via WSDL, JSON, ...). For each station of the message flow (frontend, inbound, backend, outbound) the way of working can be influenced afterwards via policies.

The created APIs can also be further developed after publication without influencing the end users. To do this, simply create a new version or revision and route it to a completely new backend or adjust other settings such as authentication or parameters.

Products and subscriptions

Prior to release, individual functions of the APIs are combined into products. Via the developer portal, an end user can register, get an overview of the APIs and subscribe to various products. As a result, the APIM generates keys for the user, which he or she must submit when calling the API. The gateway checks these keys and logs the calls. The operator of the APIM can decide which subscriptions it allows or when they expire.


Policies are configurations that are implemented by the API gateway when processing requests. They are a very powerful tool: Their scope ranges from simple adjustments like replacing header values to a strong set of rules like a call limit of e.g. only 100 per minute to custom C# code and REST calls, which e.g. notifies a team channel in case of 500 errors.

User management

The APIM can manage users itself. However, it is much more clever to use the AAD B2C for this. This way, new developers can register in the developer portal and are redirected to the sign-up page of the AAD B2C. Likewise, the login is done via the Azure AD B2C pages.

If I then do want to request a token for my API, implicit authentication can be used, whereby the APIM requests a token for the logged-in user and forwards it to the API. The gateway also stores all user calls as well. This allows me to generate reports or use Power BI to monitor the usage of my API or find out which user called which function at what time.

Back-end protection

My API is protected by the subscription mechanism. The gateway takes care of the protection and only allows calls through that include a valid subscription key. To protect the backend from direct calls, IP filters can be configured in Azure, for example. This means that only calls from the gateway are permitted and the source code remains free of security checks.

Service as a service

Our service itself no longer requires authentication or other protection mechanisms, does not have to worry about deploying different versions itself, and does not have to log which user has called it. The developer portal provided serves as a publishing platform for our API products. The portfolio can grow, be maintained, and evolve with end-user feedback.

It has never been easier or more important to publish an API as a product. Our service can simply provide its service, and we add all the other features. In a way, it is Service as a Service.

Agile becomes DevOps

Through DevOps, agile ideas are applied to the entire software lifecycle, revolutionizing software development.

Time-To-Market is between two cups of coffee

Having an idea at the coffee machine in the morning and the first customers using the feature in the afternoon - not an utopia with DevOps! 

Cloud Transformation with Arvato Systems

Learn more about Arvato Systems' cloud transformation services here.

Written by

Thomas Zühlke
Experte für Cloud Architekturen