API Security and Customer IAM

15 Dec API Security and Customer IAM

While browsing through LinkedIn, I came across this table in a post from Mark O’Neill, an analyst from Gartner. Looking at his very brief post promoting their $195 research note, I realised that at least one third of (their) view on required API security building blocks can be delivered by a single solution, Identity and Access Management. As I’m not any kind of expert on the other blocks, let’s concentrate on the six seven highlighted blocks (tokenization is not highlighted) where an identity and access management should be your choice. So this is an article about API security and CIAM.

Authentication of the API client

Having unsecured APIs can serve as an unbarred back gate to an otherwise secured application, so I would recommend building robust authentication to the API level as well. The added security helps you monetise your APIs if needed. But even free APIs should have the authentication capabilities built in; if not for today, then for tomorrow. CIAM solutions are not just for authenticating an end user.

Authentication of the end user

Where API security and CIAM is concerned, this is the bread and butter of any decent identity and access management solution. It makes a world of difference how you’re implementing it though, if you simply bolt on the user authentication too tightly to the app or application, changing authentication requirements becomes challenging. If it is the job of the app / application to serve the authentication screen for the end user, you have to deploy a new app / application each time you want to add/change/remove authentication options. Allowing the identity provider (IAM) to serve the screen (we call it a discovery screen), you can change authentication options on the fly without the need to redeploy. Convenient, time saving, and allows you to quickly respond to changing circumstances.

Token issuance

One part in the API security and CIAM scenario is e.g. the OAuth Authorisation Server. A proper CIAM solution implements this functionality and issues the tokens. Token issuance, to my knowledge, is also related to signature validation. If you select a CIAM solution, make sure it can both sign and encrypt the issued tokens.

Fine-grained authorisation

When API security and CIAM is integrated, you have plenty of choices on how to implement fine-grained authorisation. The first step is to evaluate if the user has a right to use the resource at all. This is done at the CIAM part using authorisation policies, where different conditions and available attributes are evaluated reaching a yes / no decision. After that the e.g. OAuth scopes can be used to determine what functionalities will be available.

Third party identity provider (IdP)

A good choice for your users is to allow them to use an identity they already have. Social identities are quick and easy way to capture visitors. Applications and apps that require perhaps stronger security than Donald Duck identities, can use the CIAM solution to integrate to several kinds of third party IdPs, such as banks, mobile network operators or government – all actors who have properly vetted digital identities.

Integration with access Management

Well, duh. This is what CIAM is for. However, there’s again a choice you can make when considering access management. Much like with a previous point about authentication. If you build the access functionality directly to the app / application API, you are asking for trouble. Let the CIAM solution take care of evaluating the authorisation policies and building the identity profiles and creating the assertions / claims / attributes your API needs. That’s what it’s made for.

[edited to add]

Tokenization

Sometimes the obvious escapes me. Tokenization is a fancy word for a basic functionality that we have had in our products since… well, a long time. We call the entity that performs tokenization “Identity Broker Engine”. Using the IBE it is possible to pull in data from various sources and transform these attributes. The transformation can create a non-sensitive attribute out of a sensitive one – i.e. tokenization. This has been a standard practise among many of our customers before the word tokenization became known.

So, if you are in the process of creating an API security framework for your solutions, CIAM can provide (at least) 33,3% 38,9% of required functions in a single package:

Contact us now