APIs are everywhere in our day-to-day lives. We don’t realize that we use them, at least not all the time. For those of us who work with APIs, it might be a bit more obvious when apps are fetching information from a backend API, but a great app should make that process seamless.

APIs are the backbone for your thermostat, your connected car, and anything in between. If you’re tech-savvy, you’ve probably got some level of smart home setup backed by APIs. If you’re not tech-savvy, you probably still use some type of online banking backed by APIs.

APIs are everywhere, and if they break, a piece of our day-to-day life might become problematic (my house could get really cold). This is a relatively minor inconvenience, but a broken API could have more serious consequences for APIs in financial and health services. A breach of an API providing critical personally identifiable information (PII) could have severe consequences for a person.

Bigger Footprint, Bigger Target

With the rapid growth of APIs and their ubiquity, there are also more APIs for bad actors to target. The development of APIs is also often separated into its own segment. For instance, API developers and app developers are not necessarily on the same team.

Furthermore, the API developers are not necessarily responsible for securing the API — that’s usually the responsibility of the security team. Even further, the security team might not be responsible for all aspects of API security. A separate identity and access management (IAM) team might handle authentication and authorization.

Understanding The Teams Involved

The API developers are focused on delivering the service, driving adoption and usage of the API itself, and creating the best experience possible for the API consumer. Sure, they might put some safeguards in place, but it would probably be some fairly rudimentary approaches that really don’t scale well or are robust enough.

As part of driving adoption and usage of the API for consumers using the API, the API dev team will (should) provide an API developer portal. There are many ways to go about that, but most API gateways available in the market have this capability built-in to a great extent. This would typically also come with solid documentation for the APIs exposed to the consumers.

The security team is responsible for all aspects of security within the infrastructure, including APIs. Rate limiting and other mitigations against (distributed) denial of service attacks and other protections offered by API gateways are top of mind here. This team should also work with the OWASP Top 10 API Security Vulnerabilities in mind. A review of this list reveals several top common vulnerabilities related to identity.

Organizations differ here, and the security team might be responsible for everything. But in many cases, a dedicated IAM team is responsible for this within the organization as a whole, not only for identity for APIs.

We now have a definition of several possible distinct teams involved in APIs and the security around APIs. To add to this complexity, the movement towards decentralized identities and verified credentials will put more control in the hands of the end user, more directly than before. This should be considered in the overall approach to API security and be a part of the future roadmap.

Standards Enables Better Teamwork

The teams involved in APIs must work closely together to achieve the best possible overall API security, especially regarding identity and APIs. Leveraging standards such as OAuth and OpenID Connect (OIDC) will go a long way. These standards are built for handling authentication and authorization, especially regarding APIs.

Using these standards will put the IAM team more in charge of the identity aspects of API security. It will also make the work easier for the app developers who can use lots of out-of-the-box libraries and SDKs to handle authentication and authorization specifically in APIs.

Bridge the Gap With Tech

Several technical integrations, libraries, and tools can be leveraged to bring these teams closer together. One example that comes to mind is the tight integration between API developer portals and the authorization server that handles the OAuth and OIDC flows.

When a developer needs to handle authentication and authorization for an API, the API developer portal can integrate tightly with the authorization server to define configurations automatically, creating a one-to-one mapping with the OAuth client used to issue tokens to a given API. This is important to be able to track API usage based on access tokens. It’s also important for issuing specific tokens for APIs to reduce the attack surface (this ensures one single token can’t be used to access all APIs).

Another technical integration point may not be specific to the work of the API team but more between the application developers and the IAM team. In a traditional approach, an OAuth flow runs in a browser, even on mobile apps, and as such, the user authentication (whatever mechanism) is server-side rendered. The IAM team owns the authorization server and what the authentication screen looks like. The application team has little to no control over the UX for the app they are developing.

Leveraging a hypermedia authentication API (HAAPI) moves the ownership of the user experience around authentication to the application team. However, the IAM team still controls all other aspects of how user authentication is handled. This creates another technical integration point that allows for a better user experience for authentication.

Conclusion

Teams need to be talking and collaborating. Securing APIs is more critical than ever, and bolting on security after the fact is very difficult. Therefore, developers focused on creating the best service possible need to involve security from the beginning. Similarly, security needs to involve the team responsible for identity (if that team is different) from the beginning as well. There needs to be ongoing collaboration in order to not only provide a great service but a secure service as well.