In other words, APIs can be very taxing on authentication infrastructure because they have to verify status, authorisation, and potentially apply rate limiting.
Yet our often still-traditional app architecture mindsets don't consider the impact of those extra calls on capacity. Those extra calls to verify and authorise, even if made on a period-basis to "refresh" a session, are going to put considerable stress on the authentication infrastructure. The same authentication infrastructure that is supporting login. It's the same kind of stress we saw when browser limitations on connections per user were increased from 2 to 8. A single user was now consuming 8 times the resources to access an application. Similarly, when considering the capacity needs for an app that relies on authorisation on a per-API call basis, one has to do some math and figure out just how many times more that individual user is going to consume.
Failure to do so leads to angry users, when overwhelmed login services are what's standing between them and that Pikachu they desperately want to catch.
Scaling ID and A Critical for Availability
Identity and access are critical app services. We've seen their importance rising in our State of Application Delivery surveys for the past two years, and without giving away too much, we're already seeing increases in our 2017 data for both identity federation and application access control. And it's not just because of apps, it's because of things, too, and the growing need to scale out the entire bready of identity services infrastructure to support more things, more users, more apps using APIs to interact with back-end applications.
Availability is often solely based on a measure of downtime. If the servers were up and working correctly, they're available. It's an inside-out perspective. But like security, we need to turn that measurement around and view it from the outside-in. Capacity counts, and merely being "up" and "available" isn't enough. Services need to be "up" and "available" to everyone who wants to consume them. That means scaling as fast as your python scripts can execute.
It also means understanding the relationship between the various back-end services that actually implement the functionality presented by your APIs. Identity and access services are as critical to availability as the actual application itself. Availability, like security, is only as good as its weakest link. And if your identity services aren't as scalable (or more scalable if your model is per-API call authentication) as the rest of your application, you're going to find that availability is a significant problem, even if all your dashboards read "green" inside.
Because from the outside, we're seeing "red." Literally and figuratively.
Sign up for CIO Asia eNewsletters.