Fortify those APIs – Interview with Telefónica’s Luis Velarde

Though application program interfaces (APIs) are the gateway for communications service providers (CSPs) to connect to the digital world, malicious users will strike even here, leaving commands and data open to manipulation and attack.

Indeed, much of TM Forum’s work on the Open API Program is about opening up systems and exposing technology into the wider world, but that openness in itself can create security risks if not addressed by design.

Furthermore, in the context of General Data Protection Regulation (GDPR) firms are susceptible to severe financial penalties for mismanaging information and data entrusted to them. Reinforcing the essential nature of cybersecurity, including the role of security in an API-driven economy, must be a priority for any organization that holds, processes or moves citizens' data.

“We have to somehow standardize how we are going to guarantee security,” affirmed Luis Velarde, Solutions Architect Senior Manager, Telefónica.

Velarde is heavily involved with the security and identity architecture for digital services deployment and standardization of the digital identity concept within Telefónica. He also recently led the development of three new compliance test kits and Open API conformance profiles for TM Forum, helping to lay the foundations for an Open API conformance program.

In this interview, we delve further into the work Velarde has been doing with the Forum to secure Open APIs from the perspective of individual users, specifically how to ensure that the countless stakeholders involved with the APIs have the necessary levels of access so as not to affect areas that they shouldn’t.

JOB: What have you been doing to help address the challenge of API access and security?
LV: As part of TM Forum’s Open API Program, we have defined a set of operations that will enable a lot of functionality in the integration interaction between digital service providers and carriers. But, the next step to guarantee this interaction is security, which is what we started work on. To do this, we don’t need to reinvent the wheel. The technology exists, and OAuth 2.0 – open standards which can provide or deny access to APIs – is appropriate for securing API services.

In the end, many of the applications, and the APIs involved are implemented by firms, but used by an individual. So, we need to not only secure the API itself, but also provide a specific mechanism to identify who is interfacing. We can rely on an existing industry standard, OpenID Connect, combined with OAuth 2.0. The former allows us to identify the individual triggering the interaction, while the latter allows us to guarantee that this interaction includes the proof of authorization for that individual to get access to that application/resource.

About OAuth: OAuth originally began in 2006 as a standard for authorization when developers at Twitter and Ma.gnolia were looking for a way to delegate authentication. OAuth2.0 is a later evolution published in October 2012.

JOB: Some people have referred to OAuth as a bit of a bottleneck in the architecture. Do you think that is a misinterpretation of the functionality?
LV: If you want to be secure, you need proof of secureness or authorization to get access to something, and that access itself needs to be carefully curated. For example, we are proposing that as part of the identity information, we could also extend this information to include what specific resources the individual can manage so that the application can restrict their activity as necessary.

So no, I don’t think this is a bottleneck at all, but a necessity and a safeguard.

JOB: You also identified some gaps in the overall end-to-end security story as part of your analysis. Could you elaborate on that gap?
LV: The gap is the lack of a complete scope. The scope defines who is authorized for what and is part of an authorization ‘token’. You can go as granular as you want.

You could, for example, provide a token to get access to a product catalog of APIs, so you can have full access to do and see anything in that product catalog. Or, you can create a scope for access to a specific category only. Or another example API relevant to telcos is that of billing. You can create a scope for checking invoices for a specific account or a specific bill item, or scope to view only or view and update, etc., so it depends how granular you want to go.

Of course, if you want to go more granular, this is what could be the time-consuming, complex bottleneck, which is why the next steps of defining the scope is so important. This is not underway yet, but we are looking to construct guidelines on how authorization should be defined, and how we want to define the scope so as not to become a bottleneck, but still be secure enough.

In conclusion
LV: Security by design is a critical element of open ecosystems, not only legally but also to ensure trust with customers and partners. TM Forum's Open API Program enables members to transform their architecture in to an open, modularized, flexible architecture, and security using OAuth 2.0 and OpenID Connect is a key aspect of the design and implementation strategy that we advocate.

However, security should not be a reason not to create open flexible architectures. There are standardized solutions available to support you on that journey to transform your business or organization.