In times of DevOps, high automation and decoupled microservices, we need well-maintained interfaces that not only work today, but also in a scalable world with a flexible roadmap. Whenever a new service is created, an API is also provided.

APIs are the new products

In the era of the cloud – and in particular of SaaS products – the development and deployment of APIs is becoming more and more relevant: APIs are the new products because we do not need an app or a website for every service.

The development of APIs

Anyone who wants to offer an API or a service himself faces some challenges. The usual difficulties that already cause services within projects are compounded once more, as end users should work with them for a long time. They must be both well-maintained and documented, as well as protected against unauthorized access, published, further developed and also be billed.

It is advisable to enrich your service with existing services (“Services as a Service”) and thus achieve the separation of professionalism and organization. In our specific case, the service should only fulfill its (technical) task and do it as well as possible. We do not want to deal with user administration, the generation of subscription keys or the construction of a gateway. To do this, 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)

The Azure Active Directory B2C is a cloud-based, full-managed system designed to provide end-user identity and access management – in our case, our API customer. The idea behind it is that the end customers of a product or SaaS solution can manage themselves and be maintained separately from the company’s 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 its own email address. You can also manually create new users or connect to the company’s Active Directory.

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

Authentication / Authorization

The Azure AD B2C can now generate various tokens for authorization. The tokens are included in the web requests as JSON Web Token (Bearer) and the application verifies its validity. The .NET Framework and other providers offer various libraries. For .NET Core, the extension AddAzureAdB2CBearer is delivered and added directly. It contacts the Azure AD B2C and checks the validity of the tokens. It does not need more than the annotation [Authorize] about the class or function.

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

Who is allowed what?

With the authentication, it is usually not done: Which user is allowed to call which API parts? How many calls do I allow? Or maybe I’m striving for usage-based billing? I would have to develop all that. It is simpler, I do not do it. 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 offers a few more features like configuration and protection of the API as well as usage analysis. The APIM consists of three components – a gateway and two portals.

The gateway is the entry point for every developer. All requests from the APIs wander through it, are checked and logged there. The gateway controls approved usage quotas, tokens, or transformed calls according to configured policies.

The Publisher Portal – also known as the Admin Portal – provides a management interface for the APIM. This portal imports and modifies the APIs. The configuration of the API, the accesses and the data flows through the gateway to the backend are also adjusted here. Furthermore, the users are defined here for the developer portal and the configuration of the bookable product packages.

The developer portal resembles an API web site for the developers who ultimately use the interface. Similar to Swagger , the individual functions and their response types are also listed here. 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 APIs using blogs, issue management, classic CMS and graphical adjustments.

API administration

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

The created APIs can be further developed after publication without affecting the end users. For this purpose, a new version or revision is simply created and routed to a completely new backend or adapted to other settings such as authentication or parameters.

Products and subscriptions

Prior to release, individual features of the APIs are combined into products. Through the Developer Portal, an end user can register, get an overview of the APIs and subscribe to different products. As a result, the APIM generates keys for the user, which it must submit when the API is called. The gateway checks these keys and logs the calls. The operator of the APIM can decide which subscriptions he allows or when they expire again.

Policies

Policies are configurations that are implemented by the API Gateway when processing requests. They are a very powerful tool: they range from simple customizations such as replacing header values ​​with strong rules such as a call limit of, for example, only 100 per minute, to your own C # code and REST calls, such as a team -Channel notified of 500 errors.

user management

The APIM can even manage users. But it is much more clever to use the AAD B2C for this purpose. This allows new developers to register in the Developer Portal and be redirected to the AAD B2C sign-up page. Likewise, the login takes place via the pages of the Azure AD B2C.

If I then want to request a token for my API, the 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 saves all user calls. So I can generate reports or use Power BI to monitor the use of my API or find out which user called which function at what time.

Back-end protection

The subscription mechanism protects my API. The gateway takes care of the security and only allows calls that provide a valid subscription key. To protect the backend from direct calls, for example, IP filters can be configured in Azure. As a result, only calls from the gateway are allowed and the source code remains free of security checks.

Service as a service

Our service itself no longer needs any authentication or other protection mechanisms, does not have to worry about deploying different versions, and does not need to log the requesting user. The provided developer portal serves as a publication platform for our API products. The portfolio can be grown, maintained and evolved with end-user feedback.

It’s never been so easy and never been so important to publishing an API as a product today. Our service can simply make its service available, we get all other features from Azure – somehow like service as a service.

Example code for authentication with ID token against AAD B2C: https://github.com/ArvatoSystems/CoreApiVersioningAADB2CAuth

This post is automatic translated from the german version: https://cloud-blog.arvato.com/api-entwicklung/